High RxBadPkt on TL-SG108E

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

High RxBadPkt on TL-SG108E

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
33 Reply
Re:High RxBadPkt on TL-SG108E
2019-10-28 12:37:11 - last edited 2019-10-28 12:48:10

@R1D2 It is the TPLINK TL-SG108PE itself that emits the bogus packet. Something about the way this device drops the tagged 802.11q packet causes the packet to be transformed in such a way as to be seen by the Unifi as this rouge/bogus packet. If you are familiar with this thread, then you know how easily this can be reproduced. Having a VLAN with a Trunk port is enough to cause this, and disabling the VLAN is enough to prevent the rouge/bogus packets from appearing on the network. Checking any of the address tables in my Netgear switches shows the bogus packet only on the uplink ports. The same is true for the Unifi switch. This can be traced all the way back to the TP-LINK TL-SG108PE and the timing always coincides with a bad packet appearing on the 802.11q VLAN trunk port. If the TP-LINK TL-SG108PE is indeed dropping the badrx packet as stated in this thread, then why does the packet escape and arrive on all of the uplinked switches?

R1D2 wrote

 

cool1two wrote

I also have a Unifi setup, and when ever a bad rx frame is recorded on the TPLINK, a bogus MAC is logged in the Unifi as 08:00:45:00:01:XX. Unifi says this is a bad IP header,

 

Of course a bogus MAC will be counted as a bad RX frame, nothing wrong with this. Which device does emit the bogus MAC in your network? According to the OUI it must be a device using a NIC produced from CONCURRENT COMPUTER CORP.

 

Anyway, the original discussion was about a bad RX frame count when using VLANs for frames with a valid MAC and this can be safely ignored according to TP-Link R&D.

 

  0  
  0  
#23
Options
Re:High RxBadPkt on TL-SG108E
2019-10-28 15:24:44

@cool1two, I see. Seems that my switches ignore such bogus packets, even UBNT ER-X configured as a switch (sits between EAPs and TL-SG108E). Nothing unusual in the logfiles. 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#24
Options
Re:High RxBadPkt on TL-SG108E
2019-10-30 13:03:25

@R1D2 I would like to confirm something with you, or the community in general. Normally your trunk port, between switches, is an untagged member of VLAN 1 and a tagged member of all uplinked VLANS. The trunk port is also configured as PVID 1.

 

Can you setup a test VLAN using two ports on each of your switches such as Port 5 and 6? Make port 5 a tagged member of VLAN 2000 and port 6 Untagged member of VLAN 2000. Set Port 5 and 6 to have a PVID of 2000, and remove the ports as untagged ports from VLAN 1.

 

If configured correctly you should be able to uplink your two indentically configured switches via the Tagged port and not encounter a spanning tree (loop) issue. Pings should be able to pass between the two devices connected to port 6 on each switch. Do you see any rx packet errors on port 5 in this configuration?

  0  
  0  
#25
Options
Re:High RxBadPkt on TL-SG108E
2019-10-30 22:16:24 - last edited 2019-10-30 22:35:48

 

cool1two wrote

@R1D2 I would like to confirm something with you, or the community in general. Normally your trunk port, between switches, is an untagged member of VLAN 1 and a tagged member of all uplinked VLANS. The trunk port is also configured as PVID 1.

 

No. In my network, members of System VLAN 1 are only trunk ports and they are tagged members of VLAN 1 with a PVID (Primary VLAN ID) of 1. Access ports are always a member of only one VLAN (but not VID 1), which makes it their Primary VLAN.

 

Can you setup a test VLAN using two ports on each of your switches such as Port 5 and 6? Make port 5 a tagged member of VLAN 2000 and port 6 Untagged member of VLAN 2000. Set Port 5 and 6 to have a PVID of 2000, and remove the ports as untagged ports from VLAN 1.

 

 

I have such setup in my network except that trunk PVIDs are always 1 (the unused System VLAN). This is the current port statistics of a TL-SG108E, port 4-5, 7-8 are trunk ports, port 5 to wireless APs over an EdgePoint R6 PoE switch, port 7 to a TL-SG105, port 8 to the core switch, port 6 access port, system's NIC in sleep mode:

 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#26
Options
Re:High RxBadPkt on TL-SG108E
2020-03-09 14:37:56 - last edited 2020-03-09 14:44:04

hello! I just registered here because my sg105e seems to have the same problem with rxbadpkt on my trunk port with vlan 1 & 2. all other untagged access ports have 0 rxbadpkt. but there is one thing that i really can not explain: It seems like the rxbadpkt gets a lot more when i press the refresh button. for example, i let the switch run now for 5 minutes and when i hit refresh one time, it increases by maybe 200 packets. BUT if i rapidly press the refresh-button 20 times really fast, the rxbadpkt also increases the same amount, about 200 more. i can not explain this, but it looks like maybe interacting with the webpage or refreshing content is creating bad packets?! or maybe there is an error with the reading of the rxbadpkt and everytime it reads the value, it gets accidentally more?

can anyone confirm this behavior?

 

Edit: I also noticed, when i clear the statistic and immediately start to press refresh, the numbers increase always by 4...0 4 8 12 16 20 24 28 32 at every refresh and at some point, other bad packets also start to appear and the numbers look like this 0 4 8 12 16 20 25 29 33....but the increases by 4 every time i press refresh are still noticeable.

  0  
  0  
#27
Options
Re:High RxBadPkt on TL-SG108E
2020-03-09 15:05:22

@traeu,

 

1) please see post #16 in this thread for an explanation what this rxbadpkt statistics mean. You do not need to worry about, it's not a malfunction.

 

2) Of course refreshing the switch's web UI will increase the rxbadpkt count when data has been sent. The switch will tag this traffic internally and its interface is an internal (invisible) trunk, too, meaning the web UI can be reached from within any VLAN on TL-SG105E.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#28
Options
Re:High RxBadPkt on TL-SG108E
2020-03-09 15:33:41

@R1D2 Thanks for your answer. i was confused because of post #20

If this counter not only shows packets smaller than 64 bytes but also packets with the size of 64, than it makes sense to me, because the outgoing 64 byte size packets on my coreswitch on that port are the exact same number than the rxbadpkt.

  0  
  0  
#29
Options
Re:High RxBadPkt on TL-SG108E
2020-03-09 16:41:08

@traeu, it is indeed confusing. In my opinion it would be better if the table header would say something like RxTaggedPkt instead of RxBadPkt.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#30
Options
Re:High RxBadPkt on TL-SG108E
2020-12-01 21:05:54 - last edited 2020-12-01 21:27:48

I saw this also so investiaged and from captures on the port saw that it's a management protocol (https://en.wikipedia.org/wiki/Realtek_Remote_Control_Protocol) that is periodically sending out 60 byte frames, which would be causing the RxBadPkt increase if that is looking for frames less than 64 bytes.

 

EDIT: If I disable the Loop Prevention feature of the switch, then the errors drasitically reduce, almost nothing now.

  0  
  0  
#32
Options
Re:High RxBadPkt on TL-SG108E
2020-12-01 21:46:46
Agreed, this seems to be directly related to having a RealTek device connected to the network. I can't confirm if it has to be directly attached to the TP-LINK switch to cause this problem. In my case the RealTek device was and ASUS Wireless router in Wireless Ethernet Bridge mode. Removing this device from the network reduced or eliminated the problem.
  0  
  0  
#33
Options
Related Articles