lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <50CCE2F2.6040503@redhat.com> Date: Sat, 15 Dec 2012 15:52:02 -0500 From: Vlad Yasevich <vyasevic@...hat.com> To: Jamal Hadi Salim <jhs@...atatu.com> CC: Stephen Hemminger <shemminger@...tta.com>, David Miller <davem@...emloft.net>, or.gerlitz@...il.com, netdev@...r.kernel.org, mst@...hat.com, john.r.fastabend@...el.com Subject: Re: [PATCH 00/11] Add basic VLAN support to bridges On 12/14/2012 04:59 PM, Jamal Hadi Salim wrote: > On 12-12-14 11:50 AM, Vlad Yasevich wrote: >> >> 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. > >> 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 >> 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@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists