On Fri, Mar 16, 2012 at 4:13 PM, Ben Pfaff <b...@nicira.com> wrote: > On Fri, Mar 16, 2012 at 04:03:23PM -0700, Jesse Gross wrote: >> On Fri, Mar 16, 2012 at 1:13 PM, Ben Pfaff <b...@nicira.com> wrote: >> > diff --git a/utilities/ovs-vsctl.8.in b/utilities/ovs-vsctl.8.in >> > index 0d858a1..57f76d5 100644 >> > --- a/utilities/ovs-vsctl.8.in >> > +++ b/utilities/ovs-vsctl.8.in >> > @@ -69,7 +69,8 @@ When such a ``fake bridge'' is active, \fBovs\-vsctl\fR >> > will treat it >> > much like a bridge separate from its ``parent bridge,'' but the actual >> > implementation in Open vSwitch uses only a single bridge, with ports on >> > the fake bridge assigned the implicit VLAN of the fake bridge of which >> > -they are members. >> > +they are members. (A fake bridge for VLAN 0 receives packets that >> > +have no 802.1Q tag or a tag with VLAN 0.) >> >> How do we handle this situation? The meaning of vlan 0 can be >> ambiguous - some drivers consider it to mean the same thing as >> untagged and some consider it to be a vlan just like any other. Do we >> actually do anything to deal with this? > > Not certain what you're asking. This paragraph describes OVS > behavior, which should be driver-independent modulo VLAN bugs (that we > have several ways to work around). A "fake bridge" is just > implemented as OVS ports with tag=0.
My question was don't we distinguish between an untagged packet and one tagged with vlan 0? Looking at the code, it appears that we don't for the purposes of access ports. I guess that's good since drivers don't necessarily distinguish either (and otherwise it makes priority tags weird). _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
