<html><body> <tt>David Stevens/Beaverton/IBM wrote on 10/27/2011 02:51:18 PM: > Stefan Berger <stefanb@linux.vnet.ibm.com> wrote on 10/25/2011 05:50:09 AM: > > > The below algorithm also seems to assume that the VM does not send > > 802.1Q (VLAN) headers. I remember having had problems when trying to > > receive 802.1Q headers when the VM's interface is on a bridge and the > > remote traffic comes through the network. I wonder whether it generally > > doesn't work. I think at least in the code you should look at the > > header, check for ETHERTYPE_IPv4 and then use eh_data[0], otherwise > > either discard it or if ETHERTYPE_VLAN (0x8100) is used read the > > encapsulated protocol ID and make sure ETHERTYPE_IPv4 is found there and > > then use eh_data[4] for further processing.</tt> <tt>> > Stefan,</tt> <tt>> I added code similar to what you had, but when trying to test it,</tt> <tt>> I realized that this cannot work with the existing filters. It appears</tt> <tt>> to me that if a VLAN header is present, that packet won't match any of</tt> <tt>> the protocols supported and will be dropped (ETHERTYPE_VLAN won't match</tt> <tt>> IPv4, ARP, RARP, etc). If so, then decoding a VLAN DHCP ACK does no good</tt> <tt>So that sounds like an ebtables problem then not being able to handle ethernet packets with a VLAN header.</tt> <tt>> because the VM will never see it, and the rules will never even check a</tt> <tt>> source IP address for a packet that ebtables won't match as an IP packet.</tt> <tt>> Right?</tt> <tt>You're right. Implementation-wise I still think you should look at the Ethernet header and</tt> <tt>check for ETHERTYPE_IPV4 to get the offset for the payload and for now skip all other types</tt> <tt>of packets. One could setup VMs on the same host, have their interfaces connected to a bridge</tt> <tt>and have them talk via VLAN and possibly provoke errors in the packet parser(s).</tt> <tt>The conclusion is that VMs sending VLAN traffic themselves is not supported. If a bridge has</tt> <tt>a VLAN interface of the host for sending/receiving VLAN traffic to/from the physical</tt> <tt>network, the filtering still works as expected.</tt> <tt>> > I saw later your post for VLAN filtering. I haven't played with</tt> <tt>> vlans much, and especially not with ebtables filtering of vlans. If</tt> <tt>> we cannot apply the higher-layer protocol rules without making a</tt> <tt>> complete copy of all of them for VLANs, then I'm not sure I see the</tt> <tt>> point in having address learning decode VLAN headers.</tt> <tt>That's fine then.</tt> <tt>> For the "no spoofing" case, allowing all VLAN packets is clearly</tt> <tt>> not right, so it appears to me that the current nwfilters simply do</tt> <tt>> not support the presence of VLANs.</tt> <tt>Yes, VLAN traffic directly from the VM is not supported with the example</tt> <tt>filters and has limitations when trying to evaluate the packets. The VLAN</tt> <tt>support I posted can serve other purposes.</tt> <tt>> I can leave the current (untested) address matching checks in. It</tt> <tt>> doesn't hurt the non-VLAN case, if you see some way of adding full VLAN</tt> <tt>> no-spoofing support in the future. But unless I'm missing something, it</tt> <tt>> doesn't look to me like the VLAN case works at all now and not supporting</tt> <tt>> that in DHCP snooping is not a new problem.</tt> <tt>Agreed.</tt> <tt> Stefan</tt> <tt>> > +-DLS</tt></body></html>