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
[email protected]
"If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher."
--Woody Guthrie
_______________________________________________
Bridge mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/bridge
