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

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

Ross Vandegrift

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie
Bridge mailing list

[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