Date: Thu, 4 Dec 2014 20:41:37 -0800 From: "David P. Discher" <dpd@dpdtech.com> To: Adam McDougall <mcdouga9@egr.msu.edu> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working Message-ID: <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> In-Reply-To: <5480D8EF.9000804@egr.msu.edu> References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <CAOtMX2gEGxTyXjitBu=pjkteocp1pSGxnb%2BWDb_jL3f0YNOjrg@mail.gmail.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Thanks Adam - On Dec 4, 2014, at 1:58 PM, Adam McDougall <mcdouga9@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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUgTeCAAoJEEmwU6XuhYWOX5gH/3wWp8sxlAho+Q9GScLvsCIw mGq9H5o53DQN/9s6c3iQJXJQtSKWsw8OQ++cEp4k/uK6NN5iF43326If52Eowx8q LWA3J4QZEtYm03Q4IRzH0e6J8agx78SmrVR/0tTrTjz6FkAVgTV+ZnTZfb3o9s6t 7t9PxFh1t752UqsRlnGX9ZI4498H7wxs7pIpOD2Aq7O7fAjPoR/WhPFWziuLbOOl DXv65FdYRf7wgNlSFXPMEd2/ywY0bcAePluOzdh1+nJJXj0+RL9hXrDvIDjEBAjh R9GgRy/nBwIcCrDpqjVJrPgMUkBqM3ZkHQ5ltlykfQaFzo5wGHp/W6FtQArO3kE= =E4Hp -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D993418-E632-44BA-8FE2-2F3F34188F20>