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
Hoping for a firmware update because i bought 2 of them.
- Copy Link
- Report Inappropriate Content
Firmware Version | 1.0.0 Build 20160722 Rel.50167 |
Hardware Version | TL-SG108E 3.0 |
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
edegrave wrote
Model : 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?
I asked tp-link for this problem some months ago.My model number is 108E V2. They said need not worry about this, This is the Statistical mechanism of chipset.
If the packet size is 64Byte, if this packet is untag, this packet is RxGoodPkt. If this packet is tagged, this packet is RxGoodPkt and Rx BadPkt.
In a word, every tagged packets, if the size is 64byte, will be be identified as bad packet. [B][/B]
- Copy Link
- Report Inappropriate Content
TPTHZ wrote
I asked tp-link for this problem some months ago.My model number is 108E V2. They said need not worry about this, This is the Statistical mechanism of chipset.
If the packet size is 64Byte, if this packet is untag, this packet is RxGoodPkt. If this packet is tagged, this packet is RxGoodPkt and Rx BadPkt.
If it is statistical only, they should change the column names to "RxTotalPkt" and "RxTaggedPkt" instead of "RxGoodPkt/RxBadPkt".
- Copy Link
- Report Inappropriate Content
R1D2 wrote
If it is statistical only, they should change the column names to "RxTotalPkt" and "RxTaggedPkt" instead of "RxGoodPkt/RxBadPkt".
:(
They said the tagged 64byte packets be thought to be small packet(less than 64byte), So this packet is bad packet.....
The value of port statistic is get from register in chipset,so they can't change them.
The chipset of TL-SG108E V2 is RTL8370N. If other switch use this chipset,meybe will meet the same problem.
[h=2][/h]
- Copy Link
- Report Inappropriate Content
I have the same problem.
V 3.0
:mad:
- Copy Link
- Report Inappropriate Content
TPTHZ wrote
They said the tagged 64byte packets be thought to be small packet(less than 64byte), So this packet is bad packet.....
64 byte is the minimum required size for an Ethernet frame so that collision detect (CSMA/CD) will work. If a frame is tagged, additional 4 bytes for the VLAN will be appended to the frame header.
If an Ethernet frame is smaller than 60 bytes + 4 bytes frame checksum, it's a bad "packet" (actually, it's an Ethernet frame, not a packet!), no matter wether it is tagged or not. If RxBadPkt shows untagged Ethernet frames less than 60 bytes or tagged frames less than 64 bytes, than those are not only considered bad frames, but they actually are bad frames. Any NIC sending out data ensures, that smaller frames get padded to 60 bytes (without the 4 bytes FCS) at least. If such frames wouldn't be padded, CSMA/CD could not work properly.
See also: https://serverfault.com/questions/510657/is-the-64-byte-minimal-ethernet-packet-rule-respected-in-practice
- Copy Link
- Report Inappropriate Content
Checking in on this one. I have the same problem on the TL-SG108PE. However, I think the comment that this is an erronisous error is incorrect. 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, (https://community.ui.com/questions/strange-MAC-addresses-in-insight-report/321e6759-0af5-4ef2-a3b9-985a7e5b1457#answer/0f1921c1-0394-4595-8939-38106a9c6d5e) so the TL-SG108PE is handling this packet poorly. By using the port monitoring on the TL-SG108PE interface I can see when a bad rx packet is logged and almost immidiately after the bogus MAC is logged in the Unifi interface.
TPLINK please resolve this issue.
Firmware Version | 1.0.0 Build 20181120 Rel.40990 |
Hardware Version | TL-SG108PE 2.0 |
- Copy Link
- Report Inappropriate Content
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
Information
Helpful: 0
Views: 47117
Replies: 33
Voters 0
No one has voted for it yet.