Re: Link aggregation between NetBSD agr and Linux bond interfaces

[Gert Doering <gert%greenie.muc.de@localhost>]

Hi,

On Thu, Dec 08, 2016 at 11:04:50AM +0100, BERTRAND Joël wrote:
> > Great.  You should also run tcpdump on both member links to determine
> > whether or not the agr driver is properly putting packets into those
> > queues.
> 
> 	I run tcpdump of both members. When NetBSD sends an arp request, Linux 
> doesn't receive this request. And when linux sends request, NetBSD 
> doesn't receive it.

There are *10* interfaces involved here.  You need to check the full
packet flow to see where it gets lost

It starts with agr0 -> check, you see the packets.

Then you need to do tcpdump on tap0, tap1 on the NetBSD side.

If you see the packets there, run tcpdump on your outgoing "real" interface
to see if the openvpn packets go out (very likely not the problem).

If yes, then run tcpdump on tap1, tap2 on the Linux side, and see if
you can see the ARP query *from the NetBSD* side coming *in*.

And if all this is yes, then tcpdump on the bond interface.


("both members" is not meaning anything, as that could be 4 different
tapping points for each of them)


From the tcpdumps you are showing, it seems as if the packets correctly
traverse agr0->tap0->tap3 - which is good.

You also see LACPv1 frames, which is also good (so the other idea of
disabling LACP to see if that's the culprit should not be necessary).

I infer you do not see the packets agr0 sent out as "incoming" on the bond
interface on the linux side - which hints at "something in the bond
config is not right" (and not on the NetBSD side).

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert%greenie.muc.de@localhost
fax: +49-89-35655025                        gert%net.informatik.tu-muenchen.de@localhost