[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-users] Still confused about bridging (I think)
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |