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

@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?

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.

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

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.