David,
You appear to have an awful lot of interfaces I'm not familiar with.
Here's what I can tell you in that regard:
-vifX.Y is the default naming convention for domU interfaces where X is the
domU and Y is the eth# in the domU
-tapX is an interface for an HVM domU, but X isn't related to the domU and I
don't know how to tell which tap interface goes where
-xenbrX is the bridge on older Xen systems, usually a fake ethX is created
on these as well, and I thought it needed to be added to xenbr0 along with
the other interfaces, but I believe someone disagreed with me regarding that
on a previous thread where another user couldn't get bridging working
-ethX is the bridge on newer Xen systems, and it has an IP assigned directly
instead of having a separate fake eth0
-pethX is the physical Ethernet interface as renamed by the Xen network
script
-I know of no reason why you would need to use multiple physical interfaces
and bridges for multiple networks/subnetworks unless they are physically
separated or perhaps separated by VLANs, this is assuming the NICs are
properly configured on the domUs and nothing is interfering with traffic on
the bridges or physical connection
-vif0.X - I don't believe I have ever seen this before, as I have always
seen dom0 use ethX one way or another, and yours appears to be doing that
based on your ip addr list output
-vethX - same as vif0.X
-It might be helpful to post the dom0 output from iptables -nL and route
-You might need to check out iptables and routes on your domUs
-Your physical switch could be limiting the port to one MAC or something
like this, I have seen issues with Cisco switches doing so in the past on
this list
Also, are you running SELinux? I haven't read about any issues with Xen
networking caused by it, but it's probably worth investigating.
Good luck,
Dustin
-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of David
Dyer-Bennet
Sent: Friday, September 19, 2008 18:42
To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] Still confused about bridging (I think)
I know I'm confused about *something*, because packets aren't getting
through.
The hardware has two NICs, eth0 connects to the corporate lan on
192.168.1.14, and to a private cluster lan on 172.17.0.1.
In dom0, I can reach systems on both lans.
In a guest on 172.17.1.2, I can't reach anything. Nothing in 172.17,
nothing in 192.168.1. The guest is domain 9, called vl01.
In dom0 A bridge, xenbr0 (specified in my control files for the domains),
is set up to let everybody talk to everywhere.
[root@prcapp02 xen]# brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.000000000000 yes
xenbr0 8000.2ed4b2e93fd1 no vif9.0
vif7.0
tap0
peth0
vif0.0
In dom0 the following interfaces exist (I think most exist only
accidentally, from starting and stopping test domains as I try to work out
what's going on):
[root@prcapp02 xen]# ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: peth0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:1e:c9:b3:2a:88 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global eth1
inet 172.17.0.100/16 brd 172.17.255.255 scope global secondary eth1:100
inet6 fe80::21e:c9ff:feb3:2a88/64 scope link
valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
inet6 fe80::200:ff:fe00:0/64 scope link
valid_lft forever preferred_lft forever
6: vif0.0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
7: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:1e:c9:b3:2a:86 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.14/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.16/32 brd 192.168.1.16 scope global eth0:16
inet6 fe80::21e:c9ff:feb3:2a86/64 scope link
valid_lft forever preferred_lft forever
8: vif0.1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
9: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
10: vif0.2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
11: veth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: vif0.3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
13: veth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
14: xenbr0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 2e:d4:b2:e9:3f:d1 brd ff:ff:ff:ff:ff:ff
24: vif7.0: <NO-CARRIER,BROADCAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
25: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
500
link/ether 2e:d4:b2:e9:3f:d1 brd ff:ff:ff:ff:ff:ff
inet6 fe80::2cd4:b2ff:fee9:3fd1/64 scope link
valid_lft forever preferred_lft forever
27: vif9.0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
I can't capture what's on the domU, since VNC is refusing to have anything
to do with cut-and-paste. But the single eth0 has the right address,
and the routing table has the right gateway (172.17.0.100).
tcpdump on the domU shows traffic for 192.168.1 going past, but no sign of
any traffic for 172.17 even when I make sure there is some.
--
David Dyer-Bennet, dd-b@xxxxxxxx; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home