On Thu, Jun 11, 2009 at 01:51:06PM -0600, Daniel Robbins wrote: > I do think that having the bridge code do PVLANs could end up being better. > In particular, I think this could be *very* useful for virtualization, where > you are adding/removing interfaces from the bridge often. Why? Because it > eliminates the need to dynamically create/remove ebtables rules and keep > them in sync with the interfaces on the bridge. In the virtualization case, I think it's actually easier: do it via MAC addresses instead of interfaces. In this case, since you're creating the virtual environments, you'll know the MAC address that gets generated for each VE. 1) Set your policy to deny. 2) Permit all frames destined to/from the promiscuous MACs. 3) Permit all broadcast frames to the promiscuous MACs. That takes care of the "isolated" use case. If you need to support the "community" case: 4) Add pairwise bidirectional rules to permit communications between each MAC in a community. Why is this easier? Since you know the MACs of the VEs, you have a trivial way of identifying the rules associated with a VE. This way, you know what rules to spin up and remove during the turnup or disabling of a VE. Moreover, since all of the rules permit specific traffic, the order doesn't even matter. There's two obvious cases where this won't scale: 1) Many VEs on a single host where the VEs form a complicated routing heirarchy. In this case, you'll have a rat's nest of MAC rules. But I'd say in this case a private VLAN solution was a bad design choice. 2) Many VEs in many communities spread across many hosts. For example, it might get bad if you had 5 communities across 100 hosts, with each community having 100 VEs. This would mean each host needs a full set of 10000 MAC rules for each community - 50000 ebtables rules. In this case, I'd again prefer a routed design (well, any case actually...) and if a common "community" LAN was a software requirement, I'd use multipoint GRE or L2TP. But for one node with a bunch of unrelated VEs, this is very little work to maintain. Ross -- Ross Vandegrift ross@xxxxxxxxxxx "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
