From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20090611235845.GB3432@kallisti.us> References: <20090610074542.39f713eb@nehalam> <20090611235845.GB3432@kallisti.us> Date: Thu, 11 Jun 2009 18:15:46 -0600 Message-ID: From: Daniel Robbins Content-Type: multipart/alternative; boundary=0016e645b9be2254b9046c1b9cb4 Subject: Re: [Bridge] RFC: Simple Private VLAN impl. List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ross Vandegrift Cc: Stephen Hemminger , bridge@lists.linux-foundation.org, Joakim Tjernlund --0016e645b9be2254b9046c1b9cb4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Thu, Jun 11, 2009 at 5:58 PM, Ross Vandegrift wrote: > 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. > In my particular configuration, there are no communities - each VE is an island, and will only be able to communicate with the network gateway (which is non-local, ie. not on the linux bridge itself.) That should lock down layer 2. With OpenVZ, each VE's MAC will have a common SWSoft 00:18:51 prefix. After I get that working, I need to lock down layer 3 with iptables, so the PVLAN functionality can't be bypassed. If you have any configuration examples for ebtables, especially simple ones, I would welcome them :) Thanks, Daniel --0016e645b9be2254b9046c1b9cb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 11, 2009 at 5:58 PM, Ross Vandegrift= <ross@kallisti.us= > wrote:
2) Many VEs in many communities spread across many hosts.= =C2=A0For
example, it might get bad if you had 5 communities across 100 hosts,
with each community having 100 VEs. =C2=A0This would mean each host needs a full set of 10000 MAC rules for each community - 50000 ebtables
rules. =C2=A0In 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.

In my particular configuration, there = are no communities - each VE is an island, and will only be able to communi= cate with the network gateway (which is non-local, ie. not on the linux bri= dge itself.) That should lock down layer 2. With OpenVZ, each VE's MAC = will have a common SWSoft 00:18:51 prefix.

After I get that working, I need to lock down layer 3 w= ith iptables, so the PVLAN functionality can't be bypassed.
<= br>
If you have any configuration examples for ebtables, especial= ly simple ones, I would welcome them :)

Thanks,

Daniel
--0016e645b9be2254b9046c1b9cb4--