[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m163c2ztrf.fsf@fess.ebiederm.org>
Date: Tue, 01 Sep 2009 06:20:20 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Or Gerlitz <ogerlitz@...taire.com>
Cc: netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: 2.6.31 ARP related problems with multiple macvlan NICs
Or Gerlitz <ogerlitz@...taire.com> writes:
> Using multiple (e.g 2) macvlan devices set over the same uplink NIC
> and 2.6.31-rc7 I can get only one of the macvlan devices to respond on
> arp request where the same scheme works fine on 2.6.29.1 and 2.6.30.
>
> The only devices for which the system responds on ARP request is the
> first match in the routing table, e.g mv0 below. Next are the commands
> I am using to set the environment that reproduces the problem.
>
> Looking on net/ipv4/arp.c I do someting that may be related which
> was commited for 2.6.30 and reverted for -stable and .31 so the
> fact that this test actually works with 2.6.29.1/2.6.30 makes me
> think that the problem I see is not directly connected to the "ipv4: arp
> announce, arp_proxy and windows ip conflict verification" commit/revert.
>
> The problem is also not directly related to macvlan, I think, e.g
> I have the same issue when having multiple veth pairs connected
> to a bridge, only ping to/through the first routing hit works.
I just tested. If the two macvlans are in separate network namespaces
all is well, so definitely not macvlan.
As you have observed there are no real changes to arp.c
Interesting I can reproduce this to machines on the same network
segment but not to machines on different network segments.
Weird.
Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists