Re: ebtables & VLAN redirect

[Grant Taylor <gtaylor@riverviewtech.net>]

On 06/29/10 14:29, Grant Taylor wrote:
> The simple fact that you have the amount of incoming traffic that you 
> want to filter and forward a subset of implies that there will be CPU 
> time spent analyzing which traffic to forward.

Along these lines, I have what some might consider a devious idea.

Create a bridge for each VLAN.  That will give you the VLAN interface 
and it's associated bridge interface.  Then bridge the bridge interfaces 
in to a larger bridge.

Using all the smaller bridges will keep the possible rules that you need 
to match smaller, thus less load on the CPU.  You could also turn down 
the VLANs individual bridge when you didn't want to monitor any traffic 
on it, thus reducing the load further.

So, you would end up with a topology somewhat like this:

eth0.101 <-> br101 <-> br9
eth0.102 <-> br102 <-> br9
eth0.103 <-> br103 <-> br9 <-> eth1.9
...
eth0.199 <-> br199 <-> br9

In this case, br9 is nothing more than a collector from all the other 
bridges.

It's the interaction between eth0.<VID> and br<VID> that has to do the 
filtering.

When you don't want to monitor traffic on say, eth0.123, simply remove 
it from br123.  Doing so will cause br123 to disable (but not remove) 
its self which will cause br9 to disable the port that is br123.  - 
Then when you want to monitor eth0.123, re-add it to br123, causing 
br123 to re-enable, causing br9 to re-enable br123's port.

Using br9 to aggregate all the VLANs together will also make it easier / 
less load to make sure that you don't have inter-VLAN communications 
because only the traffic you are interested in will make it that far, 
not all the traffic that you are talking about.  Seeing as how there 
will be much less traffic, matching the EBTables rules to see what can 
talk to what (for br9) will be much less load on the system.

Something to think about.



Grant. . . .