2010/6/28 Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>: >> 3. Mirroring specific sessions to VLAN 9 - and I can postpone this task >> for the future. > > Please clarify what you are meaning by "mirroring specific sessions". Session may be not fully correct word - more precisely it should understand as IP traffic flows specified by address:port pairs to dump the traffic. >> Bridging is a good idea, but its current implementation lacks some >> features important to me - as impossibility to limit traffic directions >> between bridge devices and the fact that a network device can belong to one >> bridge only. > > Please clarify "impossibility to limit traffic direction between bridge > devices". > > It is trivial to allow bridging one way while blocking it the other way. > > I.e. set an EBTables policy to DROP and only allow bridging the direction > you want. > > VID:100 --> VID:9 > VID:101 --> VID:9 > VID:102 --> VID:9 > ... > VID:199 --> VID:9 > > Bridging does not have to be by-directional. You can easily make EBTables > not bridge the traffic. Your explanation is correct BUT in current bridging model there would be a hundred attempts to flood ALL broadcast/multicast traffic received from every bridge port. Yes, I can filter them out by using ebtables rules, but this unnecessary attempts will waste CPU time. Writing "to limit traffic direction between bridge devices" I meant there is no support to exclude attempts of flood to ALL ports by limiting a direction of flooding in the description of a bridge device. > It may be my mis-understanding, but I'm still not seeing why you can't do > this in EBTables using bridging. > > If you bridge all your VLANs together and configure EBTables to filter the > traffic, I don't see what the problem will be. > > All your layer 3 traffic will behave as if it is on one large network, > passing through the bridge with out the need for modification. Granted, you > can modify the traffic if you /want/ to, but I don't see the /need/ for it. > At least based on my (mis)understanding. OK bridging will work, but I am afraid to meet performance issues afterwards as I stated above. > Let me ask you this: > > Do you want your different user VLANs to be able to communicate with each > other? (Inter user VLAN communications) > > How would this scenario work for you: > > - Bridge all the user VLANs and the VLAN 9 together. > - Configure the bridge to drop the frames by default. > - Configure the bridge to selectively bridge the frames that you want to. > - Optionally alter the bridged frames if you want to. > > I think I did something similar to what you are wanting to do a number of > years ago. I bridged about 40 different VLANs (sharing one IP subnet) > together and configured them so that they could not talk with each other > (preventing the spread of virus / worms) but so that they could talk to the > router that was on a different VLAN that was part of the bridge. In the > process I had to modify the MAC address of traffic b/c the switch that was > being used had a flaw where it could not see the same MAC address on more > than one VLAN. This has been in place and working just fine for a number of > years. Originally it started out on a P-II 233 MHz system with 128 MB of > memory and it was able to do it with out any problems. The only reason we > replaced the box was because it was physically old and we did not want the > hardware to dye on us. I ended up copying the EBTables scripts from the old > system to the new system and made very minor modifications to get everything > to work (essentially as it was) with out any problems. Very interesting. Thank you for your advise, It worth to employ ebtables in solving my tasks. And I have met the same problem with MACs in other project and I had to generate different source MACs for different VLANs and eventually I had to replace the switch to cope with the problem of matching destination MACs for different VLANs. -- 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
