2010/6/29 Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>: > 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. > A nice idea. I have thought about it a bit earlier. BUT linux implementation of bridging has two limitations that makes it impossible: 1. There cannot be nested bridge devices. 2. Each device can belong to only one bridge device. Eventually I have come to understanding that my problem has no fine solution with no risks for performance. Partially I can solve it on application layer, partially by using bridging. And talking with you enlightened me on the ways of doing it. Thanks for your efforts and ideas. -- Best regards Anatoly Muliarski -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
