Re: Link aggregation between NetBSD agr and Linux bond interfaces

[BERTRAND Joël <joel.bertrand%systella.fr@localhost>]

Gert Doering a écrit :
> Hi,
>
> Then you need to do tcpdump on tap0, tap1 on the NetBSD side.

	I have done. When Linux tries to ping NetBSD over bound0/agr0.
192.168.100.1 is Linux IP address and 192.168.100.2 is NetBSD one.

einstein# tcpdump -i tap1 -p -vv (netbsd)
tcpdump: listening on tap1, link-type EN10MB (Ethernet), capture size 
262144 bytes
11:24:34.116353 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.100.2 tell 192.168.100.1, length 28
11:24:36.115263 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.100.2 tell 192.168.100.1, length 28
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
einstein# tcpdump -i tap0 -p -vv
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 
262144 bytes
11:24:41.135257 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.100.2 tell 192.168.100.1, length 28
11:24:43.135210 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.100.2 tell 192.168.100.1, length 28
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
einstein# tcpdump -i agr0 -p -vv
tcpdump: listening on agr0, link-type EN10MB (Ethernet), capture size 
262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

	You can see that both tap0 and tap1 on NetBSD side receive ARP request.

einstein# ifconfig agr0
agr0: flags=0xb843<UP,BROADCAST,RUNNING,SIMPLEX,LINK0,LINK1,MULTICAST> 
mtu 1500
        agrport: tap0, flags=0x3<COLLECTING,DISTRIBUTING>
        agrport: tap1, flags=0x3<COLLECTING,DISTRIBUTING>
        address: f2:0b:a4:36:c5:8b
        inet 192.168.100.2/24 broadcast 192.168.100.255 flags 0x0
        inet6 fe80::f00b:a4ff:fe36:c58b%agr0/64 flags 0x0 scopeid 0x6

	Of course, bond0 on linux side is configured to use round robin 
algorithm. On NetBSD side, tap0 and tap1 receive packets but these 
packets are not transmitted to agr0. Thus, NetBSD cannot answer to ARP 
request.

	If I try to ping linux server from netbsd, tcpdump (on netbsd side) 
returns :
einstein# tcpdump -i agr0 -p -vv
tcpdump: listening on agr0, link-type EN10MB (Ethernet), capture size 
262144 bytes
11:28:20.677465 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.100.1 tell 192.168.100.2, length 28
11:28:21.680338 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.100.1 tell 192.168.100.2, length 28
11:28:22.679356 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.100.1 tell 192.168.100.2, length 28
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
einstein# tcpdump -i tap0 -p -vv
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 
262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
einstein# tcpdump -i tap1 -p -vv
tcpdump: listening on tap1, link-type EN10MB (Ethernet), capture size 
262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
einstein#

	Packets are sent on agr0, but not on tap0 and tap1 ! Of course, I have 
verified that tap0 and tap1 are agr0 slave interfaces :

einstein# einsteig agr0
agr0: flags=0xb843<UP,BROADCAST,RUNNING,SIMPLEX,LINK0,LINK1,MULTICAST> 
mtu 1500
        agrport: tap0, flags=0x3<COLLECTING,DISTRIBUTING>
        agrport: tap1, flags=0x3<COLLECTING,DISTRIBUTING>
        address: f2:0b:a4:36:c5:8b
        inet 192.168.100.2/24 broadcast 192.168.100.255 flags 0x0
        inet6 fe80::f00b:a4ff:fe36:c58b%agr0/64 flags 0x0 scopeid 0x6


> 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).

	If I understand tcpdump traces, my trouble comes from NetBSD agr 
configuration.

	Regards,

	JKB