[Lxc-users] LXC Container: Network Configuration

[C Anthony Risinger]

i'm not a networking guru, but i've inlined a few comments.  i also
don't use debian/ubuntu so i'm unsure the correct way to solve them
...

On Tue, Nov 29, 2011 at 9:57 PM, Patrick Kevin McCaffrey <pkm at uwm.edu> wrote:
>
> ip route:
> default via 174.102.192.1 dev eth4  metric 100
> 169.254.0.0/16 dev eth4  scope link  metric 1000
> 174.102.192.0/19 dev eth4  proto kernel  scope link  src 174.102.217.33
> 192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.1
> 192.168.20.0/24 dev eth1  proto kernel  scope link  src 192.168.20.1
> 192.168.30.0/24 dev eth2  proto kernel  scope link  src 192.168.30.1
> 192.168.40.0/24 dev eth3  proto kernel  scope link  src 192.168.40.1

notice there is no entry for your bridge (br0), or it's network
(192.168.80.0/24) ... this is a problem.  this prevents the other
other networks from seeing it, and prevents internet access.

> ip link:
> ..........
> 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN qlen 1000
>    link/ether 00:04:23:09:6a:15 brd ff:ff:ff:ff:ff:ff
> ..........
> 161: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
>    link/ether 00:04:23:09:6a:15 brd ff:ff:ff:ff:ff:ff

NO-CARRIER implies you do not have a physical cable connected to eth1.
 it's not required by any means, but a bridge tends to assume some of
the properties of the first enslaved devices (eth1 in this case, not e
the identical MAC address) unless told otherwise.  if you are not
connected a cable to eth1, you'll likely need to manually issue an:

ip link set br0 up

... and *maybe*:

ip link set eth1 up

... there is probably a way to do this via config; not sure.  for
example, my local server (KVM guests, but similar net setup) looks
like:

2: lan0.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast master lan0 state UP qlen 1000
    link/ether 00:23:54:16:74:82 brd ff:ff:ff:ff:ff:ff
3: wan0.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast master wan0 state UP qlen 1000
    link/ether 00:02:e3:20:3f:73 brd ff:ff:ff:ff:ff:ff
5: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:23:54:16:74:82 brd ff:ff:ff:ff:ff:ff
6: wan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:02:e3:20:3f:73 brd ff:ff:ff:ff:ff:ff

... where (lan|wan)0 are the bridges, and (lan|wan)0.0 are the physical links.

> ip addr:
> ..........
> 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN qlen 1000
>    link/ether 00:04:23:09:6a:15 brd ff:ff:ff:ff:ff:ff
>    inet 192.168.20.1/24 brd 192.168.20.255 scope global eth1

i might be a little off here, but eth1 is an ENSLAVED device -- it
does not get it's own IP address.  the bridge (br0) effectively
becomes eth1 (hence the identical MAC)

you need to remove any IP address assignments from this device if you
want to enslave it to br0 ... NOTE! you do NOT have to enslave ANY
existing device to a bridge!  you can simply let you VMs be added to
the bridge, give it an IP, and that will get it into the routing table
(i think this is probably what you really want)

> 161: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
>    link/ether 00:04:23:09:6a:15 brd ff:ff:ff:ff:ff:ff

... see previous comment.  this bridge shares a MAC with eth1 and they
cannot both have an IP (eth1 having an IP is probably preventing this
bridge from being assigned `192.168.80.1`)

>
> ----------------------------------------------------------------------------------------------------------
>
> brctl show:
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.000423096a15       no              eth1

this is fine, so long as eth1 DOESN'T have an IP ... my guess is you
don't really want to enslave any physical devices to the bridge (br0).
 simply allow the bridge to act as a virtual "switch" and let routing
do the rest :-)

> I think I've got everything you requested.  I'm new to the whole 'mailing list' thing.  In the future, should I upload attachments of command output, or just plain text in the email body?

in the body is fine just like you did -- some lists may block
attachments -- the only suggestion i would make on your "netiquette"
is to avoid top-posting ... i'll let you research why if you need to,
but the short-version is something like "it breaks the natural flow of
the conversation".  better to bottom-post ... but best to trim
previous messages to context, and reply inline.

protip: you want to make it easy as possible for *anyone* (possibly at
a glance or just joining the conversation) to scan the problem,
understand the problem, and provide a solution ... without
backtracking thru 10 other messages (hint: they won't ;-).  achieve
this thru good editing, good debug info up front, and (proactively)
demonstrating/listing your attempts to solve on your own.

-- 

C Anthony