thr3ads.net - Xen users - [Xen-users] a lot of packet loss [May 2009]

If this information is useful, please help other people find it:
Share via:

Attila Szamos

2009-May-01 21:15 UTC

[Xen-users] a lot of packet loss

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

I''ve tried to switch the networking to ''route'' from
''bridge'', but it
didn''t help. Any suggestions?

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Bhasker C V

2009-May-01 22:49 UTC

head link

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

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 msDoes 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@lists.xensource.com
> http://lists.xensource.com/xen-users
>
Bhasker C V
Registered linux user #306349



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Attila Szamos

2009-May-01 23:15 UTC

head link

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@unixindia.com>
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@lists.xensource.com
>> http://lists.xensource.com/xen-users
>>
>
> Bhasker C V
> Registered linux user #306349
>
>
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Fischer, Anna

2009-May-01 23:39 UTC

head link

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

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).
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
> bounces@lists.xensource.com] On Behalf Of Attila Szamos
> Sent: 01 May 2009 16:15
> To: xen-users@lists.xensource.com
> 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@unixindia.com>
> 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@lists.xensource.com
> >> http://lists.xensource.com/xen-users
> >>
> >
> > Bhasker C V
> > Registered linux user #306349
> >
> >
> >
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Attila Szamos

2009-May-01 23:42 UTC

head link

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

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@gmail.com>
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@unixindia.com>
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@lists.xensource.com
>>> http://lists.xensource.com/xen-users
>>>
>>
>> Bhasker C V
>> Registered linux user #306349
>>
>>
>>
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Attila Szamos

2009-May-01 23:43 UTC

head link

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

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@gmail.com>
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@gmail.com>
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@unixindia.com> 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@lists.xensource.com
>>>> http://lists.xensource.com/xen-users
>>>>
>>>
>>> Bhasker C V
>>> Registered linux user #306349
>>>
>>>
>>>
>>
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Fischer, Anna

2009-May-01 23:50 UTC

head link

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

> Subject: Re: [Xen-users] a lot of packet loss
> 
> 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.
Well it depends. It could be that those lost packets actually never leave Dom0.
Do you see them going out on the physical interface (e.g. peth0 or something
like that) on Dom0 ?

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Attila Szamos

2009-May-02 00:04 UTC

head link

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

Yes, I do.

Ping from perftest6 DomU (perftest7 is not a Xen machine, the OS runs
natively on the bare metal):

root@perftest-vm2:~# ping perftest7
PING perftest7 (172.27.68.114) 56(84) bytes of data.
64 bytes from perftest7 (172.27.68.114): icmp_seq=1 ttl=64 time=4.00 ms
64 bytes from perftest7 (172.27.68.114): icmp_seq=8 ttl=64 time=0.000 ms
64 bytes from perftest7 (172.27.68.114): icmp_seq=9 ttl=64 time=0.000 ms
64 bytes from perftest7 (172.27.68.114): icmp_seq=10 ttl=64 time=0.000 ms
64 bytes from perftest7 (172.27.68.114): icmp_seq=11 ttl=64 time=0.000 ms
64 bytes from perftest7 (172.27.68.114): icmp_seq=12 ttl=64 time=0.000 ms
64 bytes from perftest7 (172.27.68.114): icmp_seq=13 ttl=64 time=0.000 ms

--- perftest7 ping statistics ---
16 packets transmitted, 7 received, 56% packet loss, time 19000ms
rtt min/avg/max/mdev = 0.000/0.571/4.000/1.399 ms


And I can see this on the perftest6 (dom0):

root@perftest6:~# tcpdump -i peth0 > dom0tcp
root@perftest6:~# cat dom0tcp | grep ICMP
01:58:08.601810 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 1, length 64
01:58:08.601987 IP perftest7 > perftest-vm2: ICMP echo reply, id
27149, seq 1, length 64
01:58:09.597674 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 2, length 64
01:58:10.597695 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 3, length 64
01:58:11.597713 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 4, length 64
01:58:12.597733 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 5, length 64
01:58:13.597752 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 6, length 64
01:58:14.597773 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 7, length 64
01:58:15.597797 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 8, length 64
01:58:15.597957 IP perftest7 > perftest-vm2: ICMP echo reply, id
27149, seq 8, length 64
01:58:20.600165 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 9, length 64
01:58:20.600450 IP perftest7 > perftest-vm2: ICMP echo reply, id
27149, seq 9, length 64
01:58:21.597909 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 10, length 64
01:58:21.598126 IP perftest7 > perftest-vm2: ICMP echo reply, id
27149, seq 10, length 64
01:58:22.597927 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 11, length 64
01:58:22.598174 IP perftest7 > perftest-vm2: ICMP echo reply, id
27149, seq 11, length 64
01:58:23.597947 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 12, length 64
01:58:23.598100 IP perftest7 > perftest-vm2: ICMP echo reply, id
27149, seq 12, length 64
01:58:24.597967 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 13, length 64
01:58:24.598149 IP perftest7 > perftest-vm2: ICMP echo reply, id
27149, seq 13, length 64
01:58:25.598028 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 14, length 64
01:58:26.598047 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 15, length 64
01:58:27.598066 IP perftest-vm2 > perftest7: ICMP echo request, id
27149, seq 16, length 64






On Sat, May 2, 2009 at 1:50 AM, Fischer, Anna <anna.fischer@hp.com>
wrote:>> Subject: Re: [Xen-users] a lot of packet loss
>>
>> 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.
>
> Well it depends. It could be that those lost packets actually never leave
Dom0. Do you see them going out on the physical interface (e.g. peth0 or
something like that) on Dom0 ?
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Fajar A. Nugraha

2009-May-02 00:52 UTC

head link

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

On Sat, May 2, 2009 at 7:04 AM, Attila Szamos <szamosa@gmail.com>
wrote:> Yes, I do.
>
> Ping from perftest6 DomU (perftest7 is not a Xen machine, the OS runs
> natively on the bare metal):

Xen problems are usually "nothing works" or "it breaks under
heavy
load" thing, not partial packet loss. You might want to try:

- testing from domU to dom0
- testing from dom0 to external host (perftest7)

that should determine whether the problem is related to xen or it''s
basic network problem (bad cables, etc.)

Also, how do you assign domU''s mac address? If it''s manually,
could
there be duplicate MAC address on your network?

Regarads,

Fajar

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Bhasker C V

2009-May-02 08:56 UTC

head link

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@lists.xensource.com [mailto:xen-users-
>> bounces@lists.xensource.com] On Behalf Of Attila Szamos
>> Sent: 01 May 2009 16:15
>> To: xen-users@lists.xensource.com
>> 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@unixindia.com>
>> 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@lists.xensource.com
>>>> http://lists.xensource.com/xen-users
>>>>
>>>
>>> Bhasker C V
>>> Registered linux user #306349
>>>
>>>
>>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/xen-users
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
Bhasker C V
Registered linux user #306349



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Attila Szamos

2009-May-02 09:47 UTC

head link

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@unixindia.com>
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@lists.xensource.com [mailto:xen-users-
>>> bounces@lists.xensource.com] On Behalf Of Attila Szamos
>>> Sent: 01 May 2009 16:15
>>> To: xen-users@lists.xensource.com
>>> 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@unixindia.com>
>>> 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@lists.xensource.com
>>>>> http://lists.xensource.com/xen-users
>>>>>
>>>>
>>>> Bhasker C V
>>>> Registered linux user #306349
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Xen-users mailing list
>>> Xen-users@lists.xensource.com
>>> http://lists.xensource.com/xen-users
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/xen-users
>>
>
> Bhasker C V
> Registered linux user #306349
>
>
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Xen users - May 2009 - a lot of packet loss

[Xen-users] a lot of packet loss

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

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

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

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

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

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

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

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

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

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