|
[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'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 ms26.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) replyblade06:~/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 -nAddress 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 -nAddress 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 -nAddress 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 -nAddress 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 peth00.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.16Fischer, 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 |