High RxBadPkt on TL-SG108E
Hardware Version : V1
Firmware Version : 1.1.2 Build 20141017 Rel. 50749
ISP :
I'm getting very high RxBadPkt on ports configured as VLAN access port. Setup is Router - Cisco switch - TP-Link01 - TP-Link02. Cisco shows no errors or dropped packages. On the trunk ports (Tagged) of the TP-link switches the RXBadPkt is the total count of the RxBadPkt packages connected to a configured access port ( Untagged 802.1Q PVID). Connecting the same device (laptop or AP) to a port without a configured PVID (so default PVID1) on either switch the RxBadPkt is 0 and stays 0. I'm not noticing bad performance on the access ports but the high RxBadPkt seems really strange. What could be the cause of this?
Configuration of the second TP-Link switch with a connected access point on port 8 with configured VLAN:
Configuration of the first switch:
Now monitoring the statistics shows a lot of RxBadPkt when Access Point is connected to VLAN on port 8 (Monitoring was refreshed shortly before screenshot):
Same on switch 01:
Connecting access point (or whatever device) to a port without a configured VLAN shows no RxBadPkt. In this case connected to port 5 on switch 1. Same result on switch 2. The same device on a configured VLAN and the RxBadPkt sky rockets very quickly.
Regards
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
@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.
- Copy Link
- Report Inappropriate Content
@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.
- Copy Link
- Report Inappropriate Content
@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?
- Copy Link
- Report Inappropriate Content
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:
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
@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.
- Copy Link
- Report Inappropriate Content
@traeu, it is indeed confusing. In my opinion it would be better if the table header would say something like RxTaggedPkt instead of RxBadPkt.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 46450
Replies: 33
Voters 0
No one has voted for it yet.