|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] a lot of packet loss
Sorry, you were right. My problem was caused by a misconfigured vif. I just tought that it is a Xen-realted problem because if i didn't use domains there were no network problem. Thank all of you for your help. On Sat, May 2, 2009 at 10:56 AM, Bhasker C V <bhasker@xxxxxxxxxxxxx> wrote: > > On Fri, 1 May 2009, Fischer, Anna wrote: > >> Are you pinging between two different (remote?) DomUs, or between a DomU >> and a (remote?) Dom0 ? I don't see that from your description. Also, you >> should use tcpdump -i ethX to specify which network interface to trace on. >> Otherwise you will trace on the default interface, and I am not sure that is >> what you want (especially when tracing in Dom0). >> > In fact i had to spend some time in vain to understand the setup. > Attila, can you give us a brief information on what is the network setup > and where are you trying the ping requests and what is not behaving the way > it is supposed to ? > This does not look like Xen issue to me and i guess it is something to > do with the network setup ... > >>> -----Original Message----- >>> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-users- >>> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Attila Szamos >>> Sent: 01 May 2009 16:15 >>> To: xen-users@xxxxxxxxxxxxxxxxxxx >>> Subject: Re: [Xen-users] a lot of packet loss >>> >>> I commented out the resolv.conf, but nothing changed. >>> I also tried the tcpdump issue. I experienced this: >>> >>> root@test5:~# ping 172.27.68.28 >>> PING 172.27.68.28 (172.27.68.28) 56(84) bytes of data. >>> 64 bytes from 172.27.68.28: icmp_seq=10 ttl=64 time=0.189 ms >>> 64 bytes from 172.27.68.28: icmp_seq=11 ttl=64 time=0.218 ms >>> >>> --- 172.27.68.28 ping statistics --- >>> 16 packets transmitted, 2 received, 87% packet loss, time 15004ms >>> rtt min/avg/max/mdev = 0.189/0.203/0.218/0.020 ms >>> >>> >>> On the host: >>> root@test6:~# cat dom0tcpdump > dom0tcpdump >>> root@test6:~# cat dom0tcpdump | grep ICMP >>> 01:03:19.108715 IP 172.27.68.114 > 172.27.68.28: ICMP echo request, id >>> 7461, seq 10, length 64 >>> 01:03:19.108754 IP 172.27.68.28 > 172.27.68.114: ICMP echo reply, id >>> 7461, seq 10, length 64 >>> 01:03:20.108733 IP 172.27.68.114 > 172.27.68.28: ICMP echo request, id >>> 7461, seq 11, length 64 >>> 01:03:20.108770 IP 172.27.68.28 > 172.27.68.114: ICMP echo reply, id >>> 7461, seq 11, length 64 >>> >>> On the guest: >>> root@test-vm2:~# tcpdump > domutcp >>> root@test-vm2:~# cat domutcp | grep ICMP >>> 01:03:19.142677 IP 172.27.68.114 > 172.27.68.28: ICMP echo request, id >>> 7461, seq 10, length 64 >>> 01:03:19.142677 IP 172.27.68.28 > 172.27.68.114: ICMP echo reply, id >>> 7461, seq 10, length 64 >>> 01:03:20.108578 IP 172.27.68.114 > 172.27.68.28: ICMP echo request, id >>> 7461, seq 11, length 64 >>> 01:03:20.108578 IP 172.27.68.28 > 172.27.68.114: ICMP echo reply, id >>> 7461, seq 11, length 64 >>> >>> It is very interesting, because it seems that the ICMP packets even >>> dont reach the host OS, but If I ping the host OS, each ICMP echo >>> request got an ECHO reply. >>> >>> I read about this network problem in another forums, and someone had >>> the same problem. He tought it is scheduling problem. >>> >>> >>> >>> >>> On Sat, May 2, 2009 at 12:49 AM, Bhasker C V <bhasker@xxxxxxxxxxxxx> >>> wrote: >>>> >>>> On Fri, 1 May 2009, Attila Szamos wrote: >>>> >>>>> I've fix-ed the timesyncronization problem. But I don't know where >>> >>> to >>>>> >>>>> start with the network problem. >>>>> If I ping the VM a lot of packet didn't get an echo reply. >>>>> >>>>> root@test6:~# ping perftest-vm2 >>>>> PING test-vm2 (172.27.68.28) 56(84) bytes of data. >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=1 ttl=64 time=0.346 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=2 ttl=64 time=0.048 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=3 ttl=64 time=0.039 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=4 ttl=64 time=0.041 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=6 ttl=64 time=0.032 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=7 ttl=64 time=0.044 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=8 ttl=64 time=0.038 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=43 ttl=64 time=8.05 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=56 ttl=64 time=0.042 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=57 ttl=64 time=0.036 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=58 ttl=64 time=0.041 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=59 ttl=64 time=0.038 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=60 ttl=64 time=0.041 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=61 ttl=64 time=0.038 >>> >>> ms >>>>> >>>>> 64 bytes from test-vm2 (172.27.68.28): icmp_seq=62 ttl=64 time=0.033 >>> >>> ms >>>>> >>>>> --- test-vm2 ping statistics --- >>>>> 64 packets transmitted, 15 received, 76% packet loss, time 63064ms >>>>> rtt min/avg/max/mdev = 0.032/0.594/8.056/1.995 ms >>>> >>>> Does the ping directly to IP address too gives the same issue ? >>>> sometimes DNS is a pain... >>>> also on the domU side, try commenting out the complete resolv.conf >>>> just to take DNS out of the way and try direct IP ping. >>>> >>>> you can also on the domU side run a tcpdump and check why the >>> >>> particular >>>> >>>> icmp sequence number is missing. you can see the replies from domU >>> >>> and >>>> >>>> if the reply does not come to the dom0, then there could be a problem >>> >>> with >>>> >>>> xen. >>>> else >>>> ... >>>> >>>>> >>>>> I've tried to switch the networking to 'route' from 'bridge', but it >>>>> didn't help. Any suggestions? >>>>> >>>>> _______________________________________________ >>>>> Xen-users mailing list >>>>> Xen-users@xxxxxxxxxxxxxxxxxxx >>>>> http://lists.xensource.com/xen-users >>>>> >>>> >>>> Bhasker C V >>>> Registered linux user #306349 >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 >> > > Bhasker C V > Registered linux user #306349 > > > _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |