Re: [libvirt] [libvirt PATCHv4 1/2] add DHCP snooping

Thursday, 27 October 2011

David Stevens/Beaverton/IBM wrote on 10/27/2011 02:51:18 PM:

...
 Stefan Berger <stefanb(a)linux.vnet.ibm.com&gt; 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.

 Stefan,
  I added code similar to what you had, but when trying to test it,
 I realized that this cannot work with the existing filters. It appears
 to me that if a VLAN header is present, that packet won't match any of
 the protocols supported and will be dropped (ETHERTYPE_VLAN won't match
 IPv4, ARP, RARP, etc). If so, then decoding a VLAN DHCP ACK does no good 
So that sounds like an ebtables problem then not being able to handle
ethernet packets with a VLAN header.

...
 because the VM will never see it, and the rules will never even check
a
 source IP address for a packet that ebtables won't match as an IP packet.
  Right? 
You're right. Implementation-wise I still think you should look at the
Ethernet header and
check for ETHERTYPE_IPV4 to get the offset for the payload and for now skip
all other types
of packets. One could setup VMs on the same host, have their interfaces
connected to a bridge
and have them talk via VLAN and possibly provoke errors in the packet
parser(s).

The conclusion is that VMs sending VLAN traffic themselves is not
supported. If a bridge has
a VLAN interface of the host for sending/receiving VLAN traffic to/from the
physical
network, the filtering still works as expected.

...

  I saw later your post for VLAN filtering. I haven't played with
 vlans much, and especially not with ebtables filtering of vlans. If
 we cannot apply the higher-layer protocol rules without making a
 complete copy of all of them for VLANs, then I'm not sure I see the
 point in having address learning decode VLAN headers. 
That's fine then.

...
  For the "no spoofing" case, allowing all VLAN packets is
clearly
 not right, so it appears to me that the current nwfilters simply do
 not support the presence of VLANs. 
Yes, VLAN traffic directly from the VM is not supported with the example
filters and has limitations when trying to evaluate the packets. The VLAN
support I posted can serve other purposes.

...
  I can leave the current (untested) address matching checks in. It
 doesn't hurt the non-VLAN case, if you see some way of adding full VLAN
 no-spoofing support in the future. But unless I'm missing something, it
 doesn't look to me like the VLAN case works at all now and not supporting
 that in DHCP snooping is not a new problem. 
Agreed.

   Stefan

...

         +-DLS 

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005