* macvlan device blocks traffic for 30 secs
@ 2010-02-25 16:48 Jan Engelhardt
2010-02-25 16:54 ` Patrick McHardy
0 siblings, 1 reply; 7+ messages in thread
From: Jan Engelhardt @ 2010-02-25 16:48 UTC (permalink / raw)
To: kaber; +Cc: Netfilter Developer Mailing List
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: macvlan device blocks traffic for 30 secs
2010-02-25 16:48 macvlan device blocks traffic for 30 secs Jan Engelhardt
@ 2010-02-25 16:54 ` Patrick McHardy
2010-02-25 17:17 ` Jan Engelhardt
0 siblings, 1 reply; 7+ messages in thread
From: Patrick McHardy @ 2010-02-25 16:54 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: macvlan device blocks traffic for 30 secs
2010-02-25 16:54 ` Patrick McHardy
@ 2010-02-25 17:17 ` Jan Engelhardt
2010-02-25 17:19 ` Patrick McHardy
0 siblings, 1 reply; 7+ messages in thread
From: Jan Engelhardt @ 2010-02-25 17:17 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Developer Mailing List
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: macvlan device blocks traffic for 30 secs
2010-02-25 17:17 ` Jan Engelhardt
@ 2010-02-25 17:19 ` Patrick McHardy
2010-02-25 17:33 ` Jan Engelhardt
0 siblings, 1 reply; 7+ messages in thread
From: Patrick McHardy @ 2010-02-25 17:19 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: macvlan device blocks traffic for 30 secs
2010-02-25 17:19 ` Patrick McHardy
@ 2010-02-25 17:33 ` Jan Engelhardt
2010-02-25 17:35 ` Patrick McHardy
0 siblings, 1 reply; 7+ messages in thread
From: Jan Engelhardt @ 2010-02-25 17:33 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Developer Mailing List
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).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: macvlan device blocks traffic for 30 secs
2010-02-25 17:33 ` Jan Engelhardt
@ 2010-02-25 17:35 ` Patrick McHardy
2010-02-27 15:22 ` Jan Engelhardt
0 siblings, 1 reply; 7+ messages in thread
From: Patrick McHardy @ 2010-02-25 17:35 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: macvlan device blocks traffic for 30 secs
2010-02-25 17:35 ` Patrick McHardy
@ 2010-02-27 15:22 ` Jan Engelhardt
0 siblings, 0 replies; 7+ messages in thread
From: Jan Engelhardt @ 2010-02-27 15:22 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Developer Mailing List
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-02-27 15:22 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-25 16:48 macvlan device blocks traffic for 30 secs Jan Engelhardt
2010-02-25 16:54 ` Patrick McHardy
2010-02-25 17:17 ` Jan Engelhardt
2010-02-25 17:19 ` Patrick McHardy
2010-02-25 17:33 ` Jan Engelhardt
2010-02-25 17:35 ` Patrick McHardy
2010-02-27 15:22 ` Jan Engelhardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).