WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

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


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