802.1AX/802.3AD - abnormal LACP packet size?
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
802.1AX/802.3AD - abnormal LACP packet size?
Region : France
Model : TL-SG2424
Hardware Version : V1
Firmware Version : 1.0.0 Build 20140126 Rel.34563
ISP :
Hi there,
This is my first post on this forum so please pardon any unexpected behavior from my side.
I'm a the owner of several TL-SG2008 1.0 (firmware: 1.0.0 Build 20140126 Rel.34563) smart switches (not able to select this model number from the drop down list).
I have them from a few months now and wanted since configure the feature I mainly bought them for: LACP.
As I have had difficulties since weeks to understand why my setup isn't working (reviewed from all possible angles), I started to look for similar issues on the Internet and found the following topic FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working.
I then did a couple of packet captures on different brands equipment to analyze LACP traffic. On one side I did setup LACP on one of the equipment port, on the other side I connected a host with a NIC in promiscious mode and sniffed all traffic.
And indeed the TL-SG2008 is sending 128 bytes packets when other equipment are sending 124 bytes packets- the extra 4 bytes are at the end of the packet:
[CODE]
TP-Link
0000 01 80 c2 00 00 02 e8 de 27 6b 9d 1b 88 09 01 01 ........'k......
0010 01 14 80 00 e8 de 27 6b 9d 1b 07 7e 80 00 00 07 ......'k...~....
0020 c5 00 00 00 02 14 00 00 00 00 00 00 00 00 00 00 ................
0030 00 00 00 00 06 00 00 00 03 10 00 00 00 00 00 00 ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 80 31 60 7c .............1`|
FreeBSD
0000 01 80 c2 00 00 02 00 00 24 cf ec 9a 88 09 01 01 ........$.......
0010 01 14 80 00 00 00 24 cf ec 9a 01 2b 80 00 00 03 ......$....+....
0020 4d 00 00 00 02 14 ff ff 00 00 00 00 00 00 00 00 M...............
0030 ff ff 00 00 00 00 00 00 03 10 00 00 00 00 00 00 ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 ............
HP
0000 01 80 c2 00 00 02 a0 b3 cc 32 12 b7 88 09 01 01 .........2......
0010 01 14 12 a0 a0 b3 cc 32 12 a0 ff ff 00 00 00 09 .......2........
0020 75 00 00 00 02 14 00 00 00 00 00 00 00 00 00 00 u...............
0030 00 00 00 09 86 00 00 00 03 10 27 10 00 00 00 00 ..........'.....
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 ............
Extreme Networks
0000 01 80 c2 00 00 02 00 04 96 1f 50 6a 88 09 01 01 ..........Pj....
0010 01 14 91 f4 00 04 96 1f 50 6a 80 00 00 00 00 12 ........Pj......
0020 47 00 00 00 02 14 00 00 00 00 00 00 00 00 00 00 G...............
0030 00 00 00 00 3b 00 00 00 03 10 00 02 00 00 00 00 ....;...........
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 ............
[/CODE]
What this implies it that LACP is not working in my setup, which is a critical issue as this is a feature I mainly bought these switches for.
Did anyone expect such behavior as well? Or maybe can tell if this 128 bytes behavior is also happening with other TP-Link switches?
I'm not sure yet but these extra 4 bytes look like a CRC32 added at the end of the packet. This would correspond to the Frame Check Sequence (FCS) specified in the 802.3AD/802.1AX standard, but then shouldn't this FCS be added/stripped by the underlying MAC layer directly? And if so, aren't we having an extra FCS here, added somehow alongside the effective FCS which is added/stripped by the underlying MAC layer, making thus this packet 128 bytes long instead of 124 as on other equipment?
Thanks in advance for your help.
Best regards,
Model : TL-SG2424
Hardware Version : V1
Firmware Version : 1.0.0 Build 20140126 Rel.34563
ISP :
Hi there,
This is my first post on this forum so please pardon any unexpected behavior from my side.
I'm a the owner of several TL-SG2008 1.0 (firmware: 1.0.0 Build 20140126 Rel.34563) smart switches (not able to select this model number from the drop down list).
I have them from a few months now and wanted since configure the feature I mainly bought them for: LACP.
As I have had difficulties since weeks to understand why my setup isn't working (reviewed from all possible angles), I started to look for similar issues on the Internet and found the following topic FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working.
I then did a couple of packet captures on different brands equipment to analyze LACP traffic. On one side I did setup LACP on one of the equipment port, on the other side I connected a host with a NIC in promiscious mode and sniffed all traffic.
And indeed the TL-SG2008 is sending 128 bytes packets when other equipment are sending 124 bytes packets- the extra 4 bytes are at the end of the packet:
[CODE]
TP-Link
0000 01 80 c2 00 00 02 e8 de 27 6b 9d 1b 88 09 01 01 ........'k......
0010 01 14 80 00 e8 de 27 6b 9d 1b 07 7e 80 00 00 07 ......'k...~....
0020 c5 00 00 00 02 14 00 00 00 00 00 00 00 00 00 00 ................
0030 00 00 00 00 06 00 00 00 03 10 00 00 00 00 00 00 ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 80 31 60 7c .............1`|
FreeBSD
0000 01 80 c2 00 00 02 00 00 24 cf ec 9a 88 09 01 01 ........$.......
0010 01 14 80 00 00 00 24 cf ec 9a 01 2b 80 00 00 03 ......$....+....
0020 4d 00 00 00 02 14 ff ff 00 00 00 00 00 00 00 00 M...............
0030 ff ff 00 00 00 00 00 00 03 10 00 00 00 00 00 00 ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 ............
HP
0000 01 80 c2 00 00 02 a0 b3 cc 32 12 b7 88 09 01 01 .........2......
0010 01 14 12 a0 a0 b3 cc 32 12 a0 ff ff 00 00 00 09 .......2........
0020 75 00 00 00 02 14 00 00 00 00 00 00 00 00 00 00 u...............
0030 00 00 00 09 86 00 00 00 03 10 27 10 00 00 00 00 ..........'.....
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 ............
Extreme Networks
0000 01 80 c2 00 00 02 00 04 96 1f 50 6a 88 09 01 01 ..........Pj....
0010 01 14 91 f4 00 04 96 1f 50 6a 80 00 00 00 00 12 ........Pj......
0020 47 00 00 00 02 14 00 00 00 00 00 00 00 00 00 00 G...............
0030 00 00 00 00 3b 00 00 00 03 10 00 02 00 00 00 00 ....;...........
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 ............
[/CODE]
What this implies it that LACP is not working in my setup, which is a critical issue as this is a feature I mainly bought these switches for.
Did anyone expect such behavior as well? Or maybe can tell if this 128 bytes behavior is also happening with other TP-Link switches?
I'm not sure yet but these extra 4 bytes look like a CRC32 added at the end of the packet. This would correspond to the Frame Check Sequence (FCS) specified in the 802.3AD/802.1AX standard, but then shouldn't this FCS be added/stripped by the underlying MAC layer directly? And if so, aren't we having an extra FCS here, added somehow alongside the effective FCS which is added/stripped by the underlying MAC layer, making thus this packet 128 bytes long instead of 124 as on other equipment?
Thanks in advance for your help.
Best regards,