Xen project Mailing List

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

To: "Fischer, Anna" <anna.fischer@xxxxxx>

From: Bhasker C V <bhasker@xxxxxxxxxxxxx>

Date: Sat, 2 May 2009 09:56:11 +0100 (BST)

Cc: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>, Attila Szamos <szamosa@xxxxxxxxx>

Delivery-date: Sat, 02 May 2009 01:57:01 -0700

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

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

©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.