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
|
Home