|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-users] eth0 on dom0 not working on a bridged conf
I am not sure. If you don't see any packets it is always worth checking if iptables is dropping packets. How does your "iptables -L" look like? I think there have been many issue with networking on several distributions with the older Xen version. Maybe it'd be worth a try to upgrade to a newer Xen version? > -----Original Message----- > From: Javier Merino [mailto:jmerino@xxxxxxxxxx] > Sent: 04 September 2008 12:32 > To: Fischer, Anna > Cc: Dustin.Henning@xxxxxxxxxxx; xen-users@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Xen-users] eth0 on dom0 not working on a bridged conf > > I'm still with the same problem, but I know better what is not working. > > It is not just arp packets, but all incoming ethernet traffic to eth0 > en > dom0. > > If I enforce arp to bind the mac addr to the ip addr, dom0 sends the > ping, the external host replies to the ping, but the reply is never > seen > at dom0. > > *this is what I see from the external host with tshark when dom0 pings > it* > 9895.649694 172.30.1.16 -> 172.30.1.11 ICMP Echo (ping) request > 9895.649754 172.30.1.11 -> 172.30.1.16 ICMP Echo (ping) reply > > > *this is how I have enforced arp, and how ping is sent and echo > received > from domU 172.30.1.81, * > *but not from the external host 172.30.1.11* > > blade06:~/debug# arp -n > blade06:~/debug# tshark -i eth0 ether host 00:14:5e:da:3a:a2 & > [1] 3944 > blade06:~/debug# Capturing on eth0 > > blade06:~/debug# ping -c 1 172.30.1.11 > PING 172.30.1.11 (172.30.1.11) 56(84) bytes of data. > 0.000000 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell > 172.30.1.16 > 1.000062 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell > 172.30.1.16 > 2.000121 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell > 172.30.1.16 > From 172.30.1.16 icmp_seq=1 Destination Host Unreachable > > --- 172.30.1.11 ping statistics --- > 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time > 0ms > > blade06:~/debug# arp -n > blade06:~/debug# ping -c 1 172.30.1.81 > PING 172.30.1.81 (172.30.1.81) 56(84) bytes of data. > 26.529660 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.81? Tell > 172.30.1.16 > 64 bytes from 172.30.1.81: icmp_seq=1 ttl=64 time=0.568 ms > > --- 172.30.1.81 ping statistics --- > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > rtt min/avg/max/mdev = 0.568/0.568/0.568/0.000 ms > 26.529773 Xensourc_a4:65:f2 -> Ibm_da:3a:a2 ARP 172.30.1.81 is at > 00:16:3e:a4:65:f2 > 26.529785 172.30.1.16 -> 172.30.1.81 ICMP Echo (ping) request > 26.529868 172.30.1.81 -> 172.30.1.16 ICMP Echo (ping) reply > blade06:~/debug# 31.528379 Xensourc_a4:65:f2 -> Ibm_da:3a:a2 ARP Who > has 172.30.1.16? Tell 172.30.1.81 > 31.528389 Ibm_da:3a:a2 -> Xensourc_a4:65:f2 ARP 172.30.1.16 is at > 00:14:5e:da:3a:a2 > > blade06:~/debug# arp -n > Address HWtype HWaddress Flags > Mask Iface > 172.30.1.81 ether 00:16:3E:A4:65:F2 > C eth0 > blade06:~/debug# arp --set 172.30.1.11 00:09:6b:b5:0d:90 > blade06:~/debug# arp -n > Address HWtype HWaddress Flags > Mask Iface > 172.30.1.81 ether 00:16:3E:A4:65:F2 > C eth0 > 172.30.1.11 ether 00:09:6B:B5:0D:90 > CM eth0 > blade06:~/debug# ping -c 1 172.30.1.11 > PING 172.30.1.11 (172.30.1.11) 56(84) bytes of data. > 188.243727 172.30.1.16 -> 172.30.1.11 ICMP Echo (ping) request > > --- 172.30.1.11 ping statistics --- > 1 packets transmitted, 0 received, 100% packet loss, time 0ms > > blade06:~/debug# > > > Javier Merino escribió: > > You are right Anna(except that my external machine is 172.30.1.11): > > arp tables in dom0 has not binding for the external machine > > (172.30.1.11) while it has for domU (172.30.1.81). > > > > But my external machine 'can see' the arp packets sent from dom0 and > > is replying to them. So arp-request packets are going out the bridge, > > but arp-response packets seems not to be going back from the bridge > > xenbr0. I'm not sure about this. > > > > Thank you both. > > > > NOTES: > > Dustin: the other set up I have with xen 3.0 has the same brctl > > configuration. I suppose it is the 3.0 conf as Anna said. > > I have not setup an interface for 'default router' 172.30.1.1 at my > > router, but I think this should not interfere. > > > > *dom0 172.30.1.16* > > blade06:~# ping 172.30.1.81 > > PING 172.30.1.81 (172.30.1.81) 56(84) bytes of data. > > 64 bytes from 172.30.1.81: icmp_seq=1 ttl=64 time=0.898 ms > > ... > > blade06:~# ping 172.30.1.11 > > PING 172.30.1.11 (172.30.1.11) 56(84) bytes of data. > > From 172.30.1.16 icmp_seq=1 Destination Host Unreachable > > ... > > blade06:~# arp -n > > Address HWtype HWaddress Flags > > Mask Iface > > 172.30.1.1 > > (incomplete) eth0 > > 172.30.1.11 > > (incomplete) eth0 > > 172.30.1.81 ether 00:16:3E:A4:65:F2 > > C eth0 > > > > *domU 172.30.1.81* > > test:~# ping 172.30.1.11 > > PING 172.30.1.11 (172.30.1.11) 56(84) bytes of data. > > 64 bytes from 172.30.1.11: icmp_seq=1 ttl=64 time=0.603 ms > > ... > > test:~# ping 172.30.1.16 > > PING 172.30.1.16 (172.30.1.16) 56(84) bytes of data. > > 64 bytes from 172.30.1.16: icmp_seq=1 ttl=64 time=0.424 ms > > ... > > test:~# arp -n > > Address HWtype HWaddress Flags > > Mask Iface > > 172.30.1.11 ether 00:09:6B:B5:0D:90 > > C eth0 > > 172.30.1.16 ether 00:14:5E:DA:3A:A2 > > C eth0 > > > > *external machine 172.30.1.11* > > * - 1st while pinging domU from dom0 (at 0.000000) > > * - 2nd while pinging ext mach from dom0 (at 41.160119 and after) > > blade01:~# tshark -i peth0 ether host 00:14:5e:da:3a:a2 > > Capturing on peth0 > > 0.000000 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.81? Tell > > 172.30.1.16 > > 41.160119 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell > > 172.30.1.16 > > 41.160153 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at > > 00:09:6b:b5:0d:90 > > 42.160092 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell > > 172.30.1.16 > > 42.160114 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at > > 00:09:6b:b5:0d:90 > > 43.160099 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell > > 172.30.1.16 > > 43.160120 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at > > 00:09:6b:b5:0d:90 > > 44.167066 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell > > 172.30.1.16 > > 44.167089 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at > > 00:09:6b:b5:0d:90 > > 45.164106 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell > > 172.30.1.16 > > 45.164130 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at > > 00:09:6b:b5:0d:90 > > 46.164119 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell > > 172.30.1.16 > > 46.164141 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at > > 00:09:6b:b5:0d:90 > > 49.240145 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.1? Tell > > 172.30.1.16 > > 50.240151 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.1? Tell > > 172.30.1.16 > > 51.240156 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.1? Tell > > 172.30.1.16 > > > > Fischer, Anna escribió: > >> No I think that is correct because Javier is using an old Xen > version > >> (3.0.3). What does your ARP table on Dom0 show? Does it have a > >> binding for 172.30.1.81 (your external machine)? It looks as if your > >> ARP requests from Dom0 do not reach the network, and so the ping > >> request does not go out. > >> > >> > >>> -----Original Message----- > >>> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-users- > >>> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dustin Henning > >>> Sent: 03 September 2008 17:48 > >>> To: 'Javier Merino'; xen-users@xxxxxxxxxxxxxxxxxxx > >>> Subject: RE: [Xen-users] eth0 on dom0 not working on a bridged conf > >>> > >>> I think eth0 should be included under interfaces here: > >>> > >>> bridge name bridge id STP enabled interfaces > >>> xenbr0 8000.feffffffffff no vif0.0 > >>> peth0 > >>> vif3.0 > >>> > >>> The appropriate brctl command will add it to the bridge (not at a > Linux > >>> machine to get you that command). This is because peth0 is the > >>> physical > >>> connection to the network and eth0 is where your address is > assigned. > >>> This > >>> is the normal setup for older versions of xen, except eth0 should > have > >>> been > >>> automatically added to the bridge during startup. On newer > versions, > >>> xenbr0 > >>> is deprecated and eth0 is the bridge (which has the address > assigned to > >>> itself). > >>> Dustin > >>> > >>> -----Original Message----- > >>> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx > >>> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Javier > >>> Merino > >>> Sent: Wednesday, September 03, 2008 12:20 > >>> To: xen-users@xxxxxxxxxxxxxxxxxxx > >>> Subject: [Xen-users] eth0 on dom0 not working on a bridged conf > >>> > >>> Hi, > >>> > >>> I've installed xen 3.0.3 from packages (xen-linux-system) on a > debian > >>> etch, and i've configured it with network-bridge script in the > default > >>> way (netdev=eth0, bridge=xenbr0, etc...) which is ok for me. > >>> > >>> the problem I have: > >>> > >>> I cannot ping any outer machine from dom0 (nor any outer machine > can > >>> ping me). It gives me a "Destination Host Unreachable" message that > >>> makes me think there is no arp response. > >>> > >>> other symptoms: > >>> > >>> I can ping from dom0 any domU's I create... > >>> ... and from those domU's I can ping dom0 and also the outer > >>> machines that I was unable to ping from dom0. => so, xenbr0 if > working > >>> properly with peth0, vifX.0 (and eth0 on domU's) > >>> > >>> Configuration looks fine in comparation with other xen 3.0 > machines I > >>> have working. Here is a "/etc/xen/scripts/network-bridge status": > >>> > >>> ============================================================ > >>> 6: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue > >>> link/ether 00:14:5e:da:3a:a2 brd ff:ff:ff:ff:ff:ff > >>> inet 172.30.1.16/24 brd 172.30.1.255 scope global eth0 > >>> inet6 fe80::214:5eff:feda:3aa2/64 scope link > >>> valid_lft forever preferred_lft forever > >>> 13: xenbr0: <BROADCAST,NOARP,UP,10000> mtu 1500 qdisc noqueue > >>> link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff > >>> inet6 fe80::200:ff:fe00:0/64 scope link > >>> valid_lft forever preferred_lft forever > >>> > >>> bridge name bridge id STP enabled interfaces > >>> xenbr0 8000.feffffffffff no vif0.0 > >>> peth0 > >>> vif3.0 > >>> > >>> 172.30.1.0/24 dev eth0 proto kernel scope link src 172.30.1.16 > >>> default via 172.30.1.1 dev eth0 > >>> > >>> Kernel IP routing table > >>> Destination Gateway Genmask Flags Metric Ref > Use > >>> Iface > >>> 172.30.1.0 0.0.0.0 255.255.255.0 U 0 0 > 0 > >>> eth0 > >>> 0.0.0.0 172.30.1.1 0.0.0.0 UG 0 0 > 0 > >>> eth0 > >>> ============================================================ > >>> > >>> > >>> If I manually "/etc/xen/scripts/network-bridge stop", eth0 > begins > >>> working correctly with the exterior (I can ping, ssh, outer > machines > >>> and > >>> viceversa). > >>> > >>> dmesg, xend.log and xen-debug.log looks fine for me, but I may > missed > >>> up something . > >>> > >>> I've installed tshark to test the communications when network- > bridge > >>> is up, but my knowledge is not enough to understand what's > happening. > >>> I'll send the output of whatever you ask me. > >>> > >>> Thanks if anyone can help. I am lost after trying almost my best. > >>> > >>> _______________________________________________ > >>> 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 > >>> > >> > >> _______________________________________________ > >> 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 _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |