On Wed, Jul 28, 2010 at 2:01 PM, Ben Pfaff <span dir="ltr">&lt;<a href="mailto:blp@nicira.com">blp@nicira.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The kernel and user datapaths have code that assumes that 802.1Q headers<br>
are used only inside Ethernet II frames, not inside SNAP-encapsulated<br>
frames.  But the kernel and user flow_extract() implementations would<br>
interpret 802.1Q headers inside SNAP headers as being valid VLANs.  This<br>
would cause packet corruption if any VLAN-related actions were to be taken,<br>
so change the two flow_extract() implementations only to accept 802.1Q as<br>
an Ethernet II frame type, not as a SNAP-encoded frame type.<br>
<br>
802.1Q-2005 says that this is correct anyhow:<br>
<br>
    Where the ISS instance used to transmit and receive tagged frames is<br>
    provided by a media access control method that can support Ethernet<br>
    Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or<br>
    is media access method independent (e.g., 6.6), the TPID is Ethernet<br>
    Type encoded, i.e., is two octets in length and comprises solely the<br>
    assigned Ethernet Type value.<br>
<br>
    Where the ISS instance is provided by a media access method that<br>
    cannot directly support Ethernet Type encoding (e.g., is an IEEE<br>
    802.5 or FDDI MAC), the TPID is encoded according to the rule for<br>
    a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that<br>
    encapsulates Ethernet frames over LLC, and comprises the SNAP<br>
    header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by<br>
    the two octets of the assigned Ethernet Type value.<br>
<br>
All of the media that OVS handles supports Ethernet Type fields, so to me<br>
that means that we don&#39;t have to handle 802.1Q-inside-SNAP.<br></blockquote><div><br>I&#39;m fairly certain that it is possible for us to receive non-Ethernet II 802.3 packets from legacy devices.  This is really the only purpose of SNAP (I suppose that you could define your own protocol that doesn&#39;t have an EtherType and put it inside of SNAP but that seems like even more of an edge case), so if we are going to support SNAP in general then that implicitly means that we expect to potentially get non-Ethernet II frames.  Linux may not really handle SNAP packets but it does at least check for them on Ethernet devices (in eth_type_trans()), which means that it thinks in might get them.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this<br>
is actually allowed by the standards.  So this commit also adds that<br>
support.<br></blockquote><div><br>This seems like a really weird case to me as it implies that you have a device that supports an EtherType (because you are using it for the VLAN TPID) but the packet isn&#39;t using it inside the VLAN.  The only use case that I can think of is if you have a legacy device connected to an access port of a modern switch and the switch is putting the SNAP encoded packets onto a VLAN.  Is this the use case that you were imagining? <br>
</div></div>