Joakim Tjernlund/Transmode wrote on 10/06/2009 19:09:09: > > Ross Vandegrift <ross@xxxxxxxxxxx> wrote on 10/06/2009 18:27:52: > > > > On Wed, Jun 10, 2009 at 05:32:06PM +0200, Joakim Tjernlund wrote: > > > I am not sure this is so special anymore. I know that this > > > adds "support burden" but so does a lot of stuff in the kernel. > > > > Private VLANs are additional restrictions on a bridge's filtering > > database. No kernel support is required because Linux (via ebtables) > > has a much more generic way to affect the filtering of frames. > > hmm, yes I am starting to get a grip on this now. > > > > > Have anybody managed to do Private VLAN with several switches by > > > just using ebtables? Seems like most people here thinks that > > > ebtables is the right tool but none has provided any examples > > > on how to do it so I am starting to think that noone is so the > > > claim to just use ebtables might be false. > > > > I don't have a Linux machine with enough interfaces to build a > > meaningful private VLAN config, but I can step you though a simple > > conceptual explanation. > > > > One very common installation I can think of - a single router > > provides service to many clients in the same VLAN which must be > > isolated. Say the router is using eth0 and the clients are on > > eth1-ethX. > > > > Then what you want to do looks something like the following: > > > > 0) Deny all frames not explicitly permitted: > > ebtables -P FORWARD DENY > > > > 1) Permit any frames with ingress eth0: > > ebtables -A FORWARD -i eth0 -j ACCEPT > > > > 2) Permit any frames with egress interface eth0. > > ebtables -A FORWARD -o eth0 -j ACCEPT > > > > > > Think about ebtables as a low-level way to specify policy for the > > handling of frames, much in the same way that iptables is a low-level > > way to specify policy for IP packets. > > I have managed to convince myself that I can do Private VLAN with ebtables, > even between bridges :) > I do need some help to figure out how to setup the ebtable rules in an simple > manner that allows me to add/remove ports and also flip between Isolated and > Promiscuous port mode. > > Check out http://www.rfc-editor.org/internet-drafts/draft-sanjib-private-vlan-10.txt , > Table 1 and ignore community ports for now: > --------------------------------------------------------------- > | | isolat-| promis-| commu-| commu-| interswitch | > | | ted | cuous | nity1 | nity2 | link port | > --------------------------------------------------------------- > | isolated | deny | permit | deny | deny | permit | > --------------------------------------------------------------- > | promiscuous | permit | permit | permit| permit| permit | > --------------------------------------------------------------- > | community1 | deny | permit | permit| deny | permit | > --------------------------------------------------------------- > | community2 | deny | permit | deny | permit| permit | > --------------------------------------------------------------- > | interswitch | | | | | | > | link port | deny(*)| permit | permit| permit| permit | > --------------------------------------------------------------- > > (*) Please note that this asymmetric behavior is for traffic > traversing inter-switch link ports over an isolated VLAN only. > Traffic from an inter-switch link port to an isolated port will be > denied if it is in the isolated VLAN. Traffic from an inter-switch > link port to an isolated port will be permitted if it is in the > primary VLAN (see below for the different VLAN characteristics). > > N.B.: An interswitch link port is simply a regular port that > connects two switches (and that happens to carry two or more VLANs). These are the rules i come up with when I have a bridge with four interfaces. Promisc, Isolated, Community and a Interswitch port. The Interswitch port is modelled with 3 VLANs 4042, 4043 and 4044 #Static rules #.4042 = Promisc/primary VLAN #.4043 = Isolated VLAN #.4042 = Community VLAN #These VLANs represent the interswitch port #Do not leak pkgs between the above VLANs ./ebtables -A FORWARD -i eth0.4042 -o eth0.4043 -j DROP ./ebtables -A FORWARD -i eth0.4042 -o eth0.4044 -j DROP ./ebtables -A FORWARD -i eth0.4043 -o eth0.4042 -j DROP ./ebtables -A FORWARD -i eth0.4043 -o eth0.4044 -j DROP ./ebtables -A FORWARD -i eth0.4044 -o eth0.4042 -j DROP ./ebtables -A FORWARD -i eth0.4044 -o eth0.4043 -j DROP #Port rules #Promisc Port, eth1.1 ./ebtables -A FORWARD -i eth1.1 -o eth0.4043 -j DROP ./ebtables -A FORWARD -i eth1.1 -o eth0.4044 -j DROP #Isolated Port, eth1.2 ./ebtables -A FORWARD -i eth1.2 -o eth0.4043 -j ACCEPT ./ebtables -A FORWARD -i eth1.2 -o eth1.1 -j ACCEPT ./ebtables -A FORWARD -i eth1.2 -j DROP ./ebtables -A FORWARD -o eth1.2 -i eth0.4042 -j ACCEPT ./ebtables -A FORWARD -o eth1.2 -i eth1.1 -j ACCEPT ./ebtables -A FORWARD -o eth1.2 -j DROP #Community Port, eth1.3 ./ebtables -A FORWARD -i eth1.3 -o eth0.4042 -j ACCEPT ./ebtables -A FORWARD -i eth1.3 -o eth0.4044 -j ACCEPT ./ebtables -A FORWARD -i eth1.3 -j DROP ./ebtables -A FORWARD -o eth1.3 -i eth0.4042 -j ACCEPT ./ebtables -A FORWARD -o eth1.3 -i eth0.4044 -j ACCEPT ./ebtables -A FORWARD -o eth1.3 -i eth1.1 -j ACCEPT ./ebtables -A FORWARD -o eth1.3 -j DROP This is getting out of control. I was hoping there would be a simpler way to express the above. Adding ports or changing roles won't be funny. Anyone? Jocke _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
