Xen project Mailing List

Re: [Xen-users] a lot of packet loss

From: Attila Szamos <szamosa@xxxxxxxxx>

Date: Sat, 2 May 2009 01:43:12 +0200

Delivery-date: Fri, 01 May 2009 16:45:27 -0700

Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=PVK2wjJ3lYhxKbTPayoUh0k3iDUhZTAc+NGADoi86xHtPQW/aYsM7OPEvvr8ZV3W8t cgnJVhM2tau696NEUeOudbr737dIaoE8BPV/d3pg+nh1om59pFGk4Ivru+PrRCxn4R2H fAEyikM7p6Q6YS8VgVR9arEWLqagYRojqYvaI=

List-id: Xen user discussion <xen-users.lists.xensource.com>

Anna, thank you for your advise, I will use "-i ethX" next time. On Sat, May 2, 2009 at 1:42 AM, Attila Szamos <szamosa@xxxxxxxxx> wrote: > I tried another tcpdump-thing. > > I pinged from the VM to another non-xen-kernel machine. I ran a > tcpdump on the xen host machine and the ping-target machine. The point > is that on the host machine, on which the ICMP packets flow through: > > 01:29:53.075672 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 8, length 64 > 01:29:53.075841 IP perftest7 > perftest-vm2: ICMP echo reply, id > 24077, seq 8, length 64 > 01:29:54.075686 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 9, length 64 > 01:29:54.075884 IP perftest7 > perftest-vm2: ICMP echo reply, id > 24077, seq 9, length 64 > 01:29:55.075700 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 10, length 64 > 01:29:55.075926 IP perftest7 > perftest-vm2: ICMP echo reply, id > 24077, seq 10, length 64 > 01:29:56.075715 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 11, length 64 > 01:29:57.075728 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 12, length 64 > 01:29:58.075742 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 13, length 64 > 01:29:59.075761 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 14, length 64 > 01:30:00.075769 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 15, length 64 > 01:30:01.075783 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 16, length 64 > 01:30:02.075798 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 17, length 64 > 01:30:03.075812 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 18, length 64 > 01:30:04.075825 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 19, length 64 > 01:30:05.075840 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 20, length 64 > 01:30:05.075987 IP perftest7 > perftest-vm2: ICMP echo reply, id > 24077, seq 20, length 64 > 01:30:10.082287 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 21, length 64 > 01:30:10.082448 IP perftest7 > perftest-vm2: ICMP echo reply, id > 24077, seq 21, length 64 > 01:30:11.079923 IP perftest-vm2 > perftest7: ICMP echo request, id > 24077, seq 22, length 64 > > On the perftest7 machine if a packet arrives, it gets a reply. So it > seems that the packets are lost on the network. It imples that the > problem is with the network, but If I dont use domU-s, there is no > unreplied packets. > > > > > > On Sat, May 2, 2009 at 1:15 AM, Attila Szamos <szamosa@xxxxxxxxx> wrote: >> 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

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.