FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working

Fri Dec 5 04:41:38 UTC 2014

Thanks Adam -

On Dec 4, 2014, at 1:58 PM, Adam McDougall <mcdouga9 at egr.msu.edu> wrote:

> 
> Is the switch side set to "active" for the lacp mode (instead of
> passive)?  Also, try:
> sysctl net.link.lagg.0.lacp.lacp_strict_mode=0
> 
> If either of those work, I'll explain more, don't have time to dig for
> old email right this minute.

Yes, the switch was in active mode.  Turn strict mode off (which I thought I did before, but of course this sysctl clears when destroying the interface).  So, the LACP did finally negotiated, at least in ifconfig :

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
	ether 00:30:48:35:cc:25
	inet 192.168.0.50 netmask 0xffffff00 broadcast 192.168.0.255
	inet6 fe80::230:48ff:fe35:cc25%lagg0 prefixlen 64 scopeid 0x4
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	media: Ethernet autoselect
	status: active
	laggproto lacp lagghash l2,l3,l4
	laggport: em1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

lacp debug shows good info - though the partner info from the freebsd host is still zeros. 

	em1: lacpdu transmit
	actor=(8000,00-30-48-35-CC-25,008B,8000,0002)
	actor.state=7d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING,DEFAULTED>
	partner=(FFFF,00-00-00-00-00-00,0000,FFFF,0000)
	partner.state=3c<AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
	maxdelay=0

But it’s not passing any traffic.  The switch however does not see the mac address via lagg0.  Turning lagg0 off, and just running em1, with the same ip, it works.

Got ssh going on the switch:

	TL-SG2008#show mac address-table interface gigabitEthernet 1/0/5

	MAC                vlan-id port     type    aging
	---                ------- ----     ----    -----

	TL-SG2008#

	TL-SG2008#show lacp internal
	Flags:  S - Device is requesting Slow LACPDUs
			F - Device is requesting Fast LACPDUs
			A - Device is in active mode       P - Device is in passive mode

	Channel group 4
								LACP port     Admin     Oper    Port        Port
	Port      Flags   State     Priority      Key       Key     Number      State
	Gi1/0/5   SA      Up        32768         0x4       0x270   0x5         0x5

	Channel group 5
								LACP port     Admin     Oper    Port        Port
	Port      Flags   State     Priority      Key       Key     Number      State
	Gi1/0/8   SA      Up        32768         0x5       0x35f   0x8         0x7d

Doing another pcap on the lagg0 and em1 … the arp is being sent on the lagg … however it is not being past down to em1. 

What even makes less sense, as typing this email … the ping to my MacBook (with has staticly assigned 192.168.0.2) wakes up, but the ping from my macbook to the NAS-lagg (192.168.0.50) doesn’t do anything.   PCAP of em1 while this is was happening, shows nothing. 

	[ pts/0 nas.dpdtech.com:~ ]                                                     
	[ dpd ]> ping 192.168.0.2
	PING 192.168.0.2 (192.168.0.2): 56 data bytes
	64 bytes from 192.168.0.2: icmp_seq=13 ttl=64 time=1.127 ms
	64 bytes from 192.168.0.2: icmp_seq=14 ttl=64 time=0.987 ms
	64 bytes from 192.168.0.2: icmp_seq=15 ttl=64 time=95.997 ms
	64 bytes from 192.168.0.2: icmp_seq=16 ttl=64 time=108.118 ms
	64 bytes from 192.168.0.2: icmp_seq=17 ttl=64 time=1.033 ms

	64 bytes from 192.168.0.2: icmp_seq=62 ttl=64 time=0.975 ms
	64 bytes from 192.168.0.2: icmp_seq=63 ttl=64 time=1.050 ms
	64 bytes from 192.168.0.2: icmp_seq=64 ttl=64 time=1.002 ms
	64 bytes from 192.168.0.2: icmp_seq=65 ttl=64 time=1.029 ms
	64 bytes from 192.168.0.2: icmp_seq=66 ttl=64 time=1.079 ms
	64 bytes from 192.168.0.2: icmp_seq=70 ttl=64 time=0.957 ms

	64 bytes from 192.168.0.2: icmp_seq=90 ttl=64 time=0.987 ms
	64 bytes from 192.168.0.2: icmp_seq=92 ttl=64 time=0.988 ms
	64 bytes from 192.168.0.2: icmp_seq=93 ttl=64 time=1.050 ms
	64 bytes from 192.168.0.2: icmp_seq=94 ttl=64 time=88.678 ms
	64 bytes from 192.168.0.2: icmp_seq=95 ttl=64 time=1.059 ms

	64 bytes from 192.168.0.2: icmp_seq=120 ttl=64 time=1.118 ms
	64 bytes from 192.168.0.2: icmp_seq=121 ttl=64 time=1.276 ms
	64 bytes from 192.168.0.2: icmp_seq=144 ttl=64 time=53.300 ms

	64 bytes from 192.168.0.2: icmp_seq=191 ttl=64 time=93.479 ms
	64 bytes from 192.168.0.2: icmp_seq=192 ttl=64 time=68.839 ms
	64 bytes from 192.168.0.2: icmp_seq=193 ttl=64 time=1.019 ms
	64 bytes from 192.168.0.2: icmp_seq=194 ttl=64 time=1.096 ms
	64 bytes from 192.168.0.2: icmp_seq=195 ttl=64 time=1.031 ms

	64 bytes from 192.168.0.2: icmp_seq=241 ttl=64 time=0.993 ms
	64 bytes from 192.168.0.2: icmp_seq=242 ttl=64 time=1.095 ms
	64 bytes from 192.168.0.2: icmp_seq=243 ttl=64 time=1.482 ms

Feels like some there is some glue missing.

-
David P. Discher
http://davidpdischer.com/
AIM: DavidDPD | Y!M: daviddpdz 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20141204/da1d5b3a/attachment.sig>