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.
>
> 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