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 <p...@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
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
