macvlan device blocks traffic for 30 secs

macvlan device blocks traffic for 30 secs

[Jan Engelhardt]

Hi,


it's a while since I have last toyed with macvlan, but for some 
experimenting, it came up as something usable again. What I noticed 
while testing:

guest# ip link add link eth0 name mqv0 type macvlan
guest# ip link set dev mqv0 up

At this point, any connections drop for a specific amount of time.

host$ ping 192.168.100.101
PING 192.168.100.101 (192.168.100.101) 56(84) bytes of data.
64 bytes from 192.168.100.101: icmp_seq=1 ttl=64 time=4.87 ms
64 bytes from 192.168.100.101: icmp_seq=2 ttl=64 time=0.353 ms
64 bytes from 192.168.100.101: icmp_seq=3 ttl=64 time=0.341 ms
64 bytes from 192.168.100.101: icmp_seq=4 ttl=64 time=0.335 ms
64 bytes from 192.168.100.101: icmp_seq=5 ttl=64 time=0.345 ms
64 bytes from 192.168.100.101: icmp_seq=6 ttl=64 time=0.378 ms
64 bytes from 192.168.100.101: icmp_seq=7 ttl=64 time=0.283 ms
64 bytes from 192.168.100.101: icmp_seq=8 ttl=64 time=0.372 ms
64 bytes from 192.168.100.101: icmp_seq=37 ttl=64 time=5.04 ms
64 bytes from 192.168.100.101: icmp_seq=38 ttl=64 time=0.291 ms

and I am not quite sure why that is. The ARP entries don't change.
Can you reproduce this?


Jan

Re: macvlan device blocks traffic for 30 secs

[Patrick McHardy]

Jan Engelhardt wrote:
> it's a while since I have last toyed with macvlan, but for some 
> experimenting, it came up as something usable again. What I noticed 
> while testing:
> 
> guest# ip link add link eth0 name mqv0 type macvlan
> guest# ip link set dev mqv0 up
> 
> At this point, any connections drop for a specific amount of time.
> 
> host$ ping 192.168.100.101
> PING 192.168.100.101 (192.168.100.101) 56(84) bytes of data.
> 64 bytes from 192.168.100.101: icmp_seq=1 ttl=64 time=4.87 ms
> 64 bytes from 192.168.100.101: icmp_seq=2 ttl=64 time=0.353 ms
> 64 bytes from 192.168.100.101: icmp_seq=3 ttl=64 time=0.341 ms
> 64 bytes from 192.168.100.101: icmp_seq=4 ttl=64 time=0.335 ms
> 64 bytes from 192.168.100.101: icmp_seq=5 ttl=64 time=0.345 ms
> 64 bytes from 192.168.100.101: icmp_seq=6 ttl=64 time=0.378 ms
> 64 bytes from 192.168.100.101: icmp_seq=7 ttl=64 time=0.283 ms
> 64 bytes from 192.168.100.101: icmp_seq=8 ttl=64 time=0.372 ms
> 64 bytes from 192.168.100.101: icmp_seq=37 ttl=64 time=5.04 ms
> 64 bytes from 192.168.100.101: icmp_seq=38 ttl=64 time=0.291 ms
> 
> and I am not quite sure why that is. The ARP entries don't change.
> Can you reproduce this?

No, this works fine here. It might be related to filter reprogramming
of the NIC. Which driver are you using?

Re: macvlan device blocks traffic for 30 secs

[Jan Engelhardt]

On Thursday 2010-02-25 17:54, Patrick McHardy wrote:
>Jan Engelhardt wrote:
>> it's a while since I have last toyed with macvlan, but for some 
>> experimenting, it came up as something usable again. What I noticed 
>> while testing:
>> 
>> guest# ip link add link eth0 name mqv0 type macvlan
>> guest# ip link set dev mqv0 up
>> 
>> At this point, any connections drop for a specific amount of time.
>> 
>> host$ ping 192.168.100.101
>> PING 192.168.100.101 (192.168.100.101) 56(84) bytes of data.
>> 64 bytes from 192.168.100.101: icmp_seq=1 ttl=64 time=4.87 ms
>> 64 bytes from 192.168.100.101: icmp_seq=2 ttl=64 time=0.353 ms
>> 64 bytes from 192.168.100.101: icmp_seq=3 ttl=64 time=0.341 ms
>> 64 bytes from 192.168.100.101: icmp_seq=4 ttl=64 time=0.335 ms
>> 64 bytes from 192.168.100.101: icmp_seq=5 ttl=64 time=0.345 ms
>> 64 bytes from 192.168.100.101: icmp_seq=6 ttl=64 time=0.378 ms
>> 64 bytes from 192.168.100.101: icmp_seq=7 ttl=64 time=0.283 ms
>> 64 bytes from 192.168.100.101: icmp_seq=8 ttl=64 time=0.372 ms
>> 64 bytes from 192.168.100.101: icmp_seq=37 ttl=64 time=5.04 ms
>> 64 bytes from 192.168.100.101: icmp_seq=38 ttl=64 time=0.291 ms
>> 
>> and I am not quite sure why that is. The ARP entries don't change.
>> Can you reproduce this?
>
>No, this works fine here. It might be related to filter reprogramming
>of the NIC. Which driver are you using?

tap0 on one the host, e1000 inside the virtualbox.

Re: macvlan device blocks traffic for 30 secs

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2010-02-25 17:54, Patrick McHardy wrote:
>> Jan Engelhardt wrote:
>>> it's a while since I have last toyed with macvlan, but for some 
>>> experimenting, it came up as something usable again. What I noticed 
>>> while testing:
>>>
>>> guest# ip link add link eth0 name mqv0 type macvlan
>>> guest# ip link set dev mqv0 up
>>>
>>> At this point, any connections drop for a specific amount of time.
>>>
>>> host$ ping 192.168.100.101
>>> PING 192.168.100.101 (192.168.100.101) 56(84) bytes of data.
>>> 64 bytes from 192.168.100.101: icmp_seq=1 ttl=64 time=4.87 ms
>>> 64 bytes from 192.168.100.101: icmp_seq=2 ttl=64 time=0.353 ms
>>> 64 bytes from 192.168.100.101: icmp_seq=3 ttl=64 time=0.341 ms
>>> 64 bytes from 192.168.100.101: icmp_seq=4 ttl=64 time=0.335 ms
>>> 64 bytes from 192.168.100.101: icmp_seq=5 ttl=64 time=0.345 ms
>>> 64 bytes from 192.168.100.101: icmp_seq=6 ttl=64 time=0.378 ms
>>> 64 bytes from 192.168.100.101: icmp_seq=7 ttl=64 time=0.283 ms
>>> 64 bytes from 192.168.100.101: icmp_seq=8 ttl=64 time=0.372 ms
>>> 64 bytes from 192.168.100.101: icmp_seq=37 ttl=64 time=5.04 ms
>>> 64 bytes from 192.168.100.101: icmp_seq=38 ttl=64 time=0.291 ms
>>>
>>> and I am not quite sure why that is. The ARP entries don't change.
>>> Can you reproduce this?
>> No, this works fine here. It might be related to filter reprogramming
>> of the NIC. Which driver are you using?
> 
> tap0 on one the host, e1000 inside the virtualbox.

I have no idea about virtualbox. I guess it might be related to
bridging.

Re: macvlan device blocks traffic for 30 secs

[Jan Engelhardt]

On Thursday 2010-02-25 18:19, Patrick McHardy wrote:
>>>> Can you reproduce this?
>>> No, this works fine here. It might be related to filter reprogramming
>>> of the NIC. Which driver are you using?
>> 
>> tap0 on one the host, e1000 inside the virtualbox.
>
>I have no idea about virtualbox. I guess it might be related to
>bridging.

There is no vm bridging at all, it's plain routing between tap and eth 
(aka "Host Only Networking" in VMware slingo).

Re: macvlan device blocks traffic for 30 secs

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2010-02-25 18:19, Patrick McHardy wrote:
>>>>> Can you reproduce this?
>>>> No, this works fine here. It might be related to filter reprogramming
>>>> of the NIC. Which driver are you using?
>>> tap0 on one the host, e1000 inside the virtualbox.
>> I have no idea about virtualbox. I guess it might be related to
>> bridging.
> 
> There is no vm bridging at all, it's plain routing between tap and eth 
> (aka "Host Only Networking" in VMware slingo).

Well then you have to send me some more data, like tcpdumps, a
description of the entire networking setup etc.

Re: macvlan device blocks traffic for 30 secs

[Jan Engelhardt]

On Thursday 2010-02-25 18:35, Patrick McHardy wrote:
>>>>> No, this works fine here. It might be related to filter reprogramming
>>>>> of the NIC. Which driver are you using?
>>>> tap0 on one the host, e1000 inside the virtualbox.
>>> I have no idea about virtualbox. I guess it might be related to
>>> bridging.
>> 
>> There is no vm bridging at all, it's plain routing between tap and eth 
>> (aka "Host Only Networking" in VMware slingo).
>
>Well then you have to send me some more data, like tcpdumps, a
>description of the entire networking setup etc.

I'd have the tcpdump data ready, but since I investigated further, the 
case is already closed. The breakdown in networking is specific to 
Virtualbox; I tried both VMware bridging to a real NIC, and VMware 
bridging to a tap device, neither of which caused a disruption.