Re: RFC: Simple Private VLAN impl.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Thu, Jun 11, 2009 at 02:50:30PM +0200, Joakim Tjernlund wrote:
> 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
    ^^^^ I assume you mean 4044 here.

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

Makes sense.

> #Isolated Port, eth1.2
> ./ebtables -A FORWARD -i eth1.2 -o eth0.4043 -j ACCEPT

You may or may not mean this - depends on your goal.  You want to
support the case of an isolated port on bridge A talking to a
promiscuous port on bridge B?

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

You also want the community port to have access to the promiscuous
port locally:
./ebtables -A FORWARD -i eth1.3 -o eth1.1 -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?

Not sure how you expected it to look.  To change the filtering
attributes of a bridge with n ports, you're going to need to have two
rules for each port-pair (one for each direction).  That's 2n^2 rules
in the worst case, and there isn't a way around that.

This is where the opportunity for some development and abstraction
comes in.  If I were you, I'd write a "port manager" script that let
me define port rules and roles in a much simpler language.  That
script would then output the required ebtables ruleset to acheive
that.

This is a central feature of netfilter stuff, by the way -
conceptually, it's very low-level.  It's kind of like an "assembly
language" for packet handling.  Search google and freahmeat for
iptables software - you'll find thousands of programs designed to make
the writing of large and complicated iptables rulesets easier.

I doubt such software exists for the creation of private VLANs via
ebtables.

-- 
Ross Vandegrift
ross@xxxxxxxxxxx

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie
_______________________________________________
Bridge mailing list
Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/bridge

[Netdev]     [AoE Tools]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]     [Linux Resources]

Add to Google Powered by Linux