Dear Mike,
if your separate networks are already organized with VLANs externally, then you
might use it (like me) in the following way:
-{vlan-trunk}--[eth0]--+--[vlaNNN]--{vlanNNN}--[brNNN]--+--[veth.c1|eth0]
| +--[veth.c2|eth0]
+--[vlanMMM]--....
On your host, attach vlan adapters to the physical interface. This will switch
the into promicuous mode (L2-Mode) and needs not IP (L3) configuration. Each
vlan interfaces will untrunk one vlan. Then connect bridges to this vlan
interfaces. Also, as the bridge is a L2 device, it needs no IP configuration.
But you may use the bridge's IP configuration parameters to access this net on
the host; think it as an additional virtual network card which is already
connected to the bridge. But normaly, you dont't wont that and use an
additional vlan here. Attach an additional vlan adapter to the eth0 for this
and assign the hosts IP config to it.
To connect the containers, attach the outerside of the veths to the
corresponding bridge. Inside, at "eth0", you'll see your "enrolled" vlan and
you have connectivity to other containers on this bridge and all other members
in this vlan. If you need to access more than one vlan inside the container,
just add additional veths to the container configuration and connect it to the
appropriate bridges.
On the host's route, you need to switch the port for the host to trunked vlan
mode as if you will interconnect switches. And you should prune the vlan trunk
to the vlans you need to reduce the (broadcast) traffic to the hosts interface.
But you may also do it without using vlans and may good-old subnets for
separation. Then, just connect one bridge to the eth0 of the host and also
attach the veths of the containers to it. Here you probably want to assign an
IP to the bridge for accessing host. Note that the access to the subnet here is
"selected" only by the IP configuration inside the container.
greetings
Guido
On 2013-03-12 05:21, Mike wrote:
> I have two sets of containers on a host, depicted as c1.* and c2.*
> below. Wondering what's the best way to connect them to the physical
> interface. Fill in the "?".
>
> But I want to generally wall off the sets from each other. E.g., think
> of them as externally- and internally-visible servers, respectively.
> Also want to control traffic among each set.
>
> Generally, there may be a handful of sets, may be a dozen containers in
> a set.
>
> My approach would be to bridge them all together with the physical i/f,
> then separate them with ebtables (which I haven't used yet). Wondering
> if there's a more elegant approach, using...VLANs? multiple bridges?
> iptables?
>
> +-------------------------------+
> | host |
> |+------+ |
> || |-----------+ |
> || c1.2 | eth0/.1.2 |----\ |
> || |-----------+ | |
> |+------+ | |
> |+------+ | |
> || |-----------+ | |
> || c1.3 | eth0/.1.3 |--\ | |
> || |-----------+ |-----------+
> |+------+ ? --| eth0/.0.2 |-----
> |+------+ |-----------+
> || |-----------+ | | |
> || c2.2 | eth0/.2.2 |--/ | |
> || |-----------+ | |
> |+------+ | |
> |+------+ | |
> || |-----------+ | |
> || c2.3 | eth0/.2.3 |----/ |
> || |-----------+ |
> |+------+ |
> +-------------------------------+
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Lxc-users mailing list
> Lxc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-users
>
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
