On 12/14/2012 04:59 PM, Jamal Hadi Salim wrote:

On 12-12-14 11:50 AM, Vlad Yasevich wrote:

quoted

Interesting.  But, but how complex would be be to configure a vlan
filter for say 10 different vlans,

Shouldnt be hard. At the simple level you need one rule per VLAN.
I am assuming only one vm per vlan and that you can key on something
in the header.

quoted

each one of them only permitted
to be forwarded to their respective VM.

Again assuming something in the header is going to say "this packet
is allowed to go to this VM", a MAC address, an IP src/destination
etc, correct?

The VLAN id in this case is what should decide where the packet is going.

  Oh, and Vlan tags should

quoted

be stripped when they are being forwarded.

Assuming they are not already stripped at vnetx,
you could write a very simple action (probably one page of code) to
strip vlans and do everything at br0;
Your filter finds them at br0, your action strips them and pipes to
another action that redirects to the correct device. i.e in unix speak:
filter at br0 for VMx | strip vlan tag | redirect to vnetx

So you would completely bypass the bridge?  Not sure how much I like 
that since what would happen if 2 VMs are to share VLAN.  In such a 
case, broadcasts/multicasts only should only get forwarded to both of
these VMs.

I guess we could add the filters on the vnetx interfaces (which are just
taps).  Then its 2 filters per vlan (1 ingress 1 egress).  Need to think 
about this a bit.

Thanks
-vlad

At the very minimal you need to identify those packets and that depends
where you want to deploy the policy.
If you deploy at the br device, you will see the raw packet i.e the vlan
header wont be stripped.
i.e youd have to enter some u32 rule with protocol "protocol 802.1q"
If you deploy at each vnetx device assuming it is a vlan device, you
wont see the vlan headers and you'll have to key on something else on
the header "protocol ip"

cheers,
jamal

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html