TP-LINK TL-SG108E VLAN broadcast broken

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
TP-LINK TL-SG108E VLAN broadcast broken
TP-LINK TL-SG108E VLAN broadcast broken
2016-08-16 09:05:52
Model : TL-SG108E

Hardware Version : v1

Firmware Version : 1.1.2 Build 20141017 Rel.50749

ISP : TWC

So I recently decided to segment my home network into VLANs, primarily tinfoil-hat driven by having too many proprietary black-box devices that I want isolated into their own networks. My goal is to offer full internet connectivity to each VLAN but otherwise have them fully isolated from each other. I will ignore any routing for the purpose of this question and instead focus on a layer2 VLAN issue I’m having in the network. However, for the purpose of debugging that might be requested, I will explain my router is an SBC running Linux, so I do have opportunity to sniff and capture packets across all VLANs at a single point.


I purchased a TP-Link “smart router” model TL-SG108E [1]. It seemed link a smoking deal compared to other VLAN-capable routers and the only downside seemed to be the requires-Windows admin GUI - I don’t normally use or have Windows running. I also have an EdgeRouter X [2] running in the environment.


I recently found an issue with the TP-Link device that I hadn’t noticed previously: devices on VLANs are receiving broadcast packets that I wouldn’t expect them to receive. Specifically I have devices running plex that broadcast on UDP port 32414, either their local broadcast (i.e. 192.168.1.255) or a global broadcast (255.255.255.255). I have devices on a VLAN attached to the TP-Link that should NOT be receiving these broadcasts: yet running tcpdump on a device, I can see that it is receiving these broadcasts.


So now the nitty-gritty details. Here's a network diagram [3]:






I have validated connectivity is correct for all devices. That is to say, with the exception of broadcast packets at the heart of this issue, the VLANs are properly segmented off from each other. For example, host odroid-xu4-2 cannot connect to port 80 on odroid1 or beagle2 (where I have httpd running for the purpose of this test). They are on separate VLANs and the VLAN switches do not route traffic between them.


I’ve used the socat tool to test broadcast and receiving, using these two commands:


sender> socat - udp-sendto:255.255.255.255:12345,broadcast

receivers> socat -u udp-recv:12345,reuseaddr -


The results are that when broadcasting from within a VLAN, on either switch, only hosts within that VLAN see the traffic. When broadcasting from a host that is not part of a VLAN, hosts connected to TP-LINK see the broadcast traffic, regardless of VLAN settings, and hosts on the EdgeRouter X [3] don’t see broadcast traffic. Here are the specific tests, I'll refer to the TP-Link devices as TPL and Edgerouter X devices as ERX:


broadcast from odroid-xu4-2 (192.168.1.81, no VLAN / ERX):
beagle (no VLAN / TPL) - expected to receive: PASS
odroid1 (VLAN 70 / ERX) - expected to not receive: PASS
pi22 (VLAN 70 / TPL) - expected to not receive: FAIL (broadcast packets received - they shouldn't have been)
beagle2 (VLAN 40 / TPL) - expected to not receive: FAIL (broadcast packets received - they shouldn't have been)


broadcast from pi22 (192.168.70.41, VLAN 70 / TPL):
odroid1 (VLAN 70 / ERX) - expected to receive: PASS
beagle (no VLAN / TPL) - expected to not receive: PASS
beagle2 (VLAN 40 / TPL ) - expected to not receive: PASS
odroid-xu4-2 (no VLAN / ERX) - expected to not receive: PASS


broadcast from odroid1 (192.168.70.43, VLAN 70 / ERX):
pi22 (VLAN 70 / TPL) - expected to receive: PASS
beagle (no VLAN / TPL) - expected to not receive: PASS
beagle2 (VLAN 40 / TPL) - expected to not receive: PASS
odroid-xu4-2 (no VLAN / ERX) - expected to not receive: PASS


The point of these tests it to show: a broadcast sent from a device that is not part of a VLAN is inappropriately being received by devices that are part of a VLAN on TP-Link. The Edgerouter X does not exhibit this problem: devices on a VLAN there do not receive the broadcast traffic.


When broadcasting from within a VLAN, everything works as expected and the broadcast traffic is isolated to that VLAN alone, on both switches.


This leads me to the conclusion that the TP-Link device is broken. It correctly isolates VLANs for direct traffic: attempting to connect to beagle2:80 fails from all hosts (No route to host), attempting to connect to port odroid1:80 only works from pi22 (same VLAN). However, the TP-link incorrectly sends non-VLAN broadcasts to all ports, regardless of VLAN settings. The Edgerouter X does not exhibit this behavior.


I post here in hopes of:
A) Any additional troubleshooting steps this community might suggest that I missed
B) Someone else out there has a TL-SG108E handy and can repeat and validate my results.
C) This forum might be monitored by TP-Link support staff and perhaps a fix suggested or new firmware published that resolves the issue




[1] https://www.amazon.com/TP-LINK-8-Port-Gigabit-Ethernet-TL-SG108E/dp/B00K4DS5KU/ref=sr_1_1?ie=UTF8&qid=1471298992&sr=8-1&keywords=tl-sg108e

[2] https://www.amazon.com/Ubiquiti-EdgeRouter-Advanced-Gigabit-Ethernet/dp/B00YFJT29C/ref=sr_1_1?ie=UTF8&qid=1471299248&sr=8-1&keywords=ubiquiti+edgerouter+x


[3] https://www.lucidchart.com/publicSegments/view/f506bb85-3abc-4720-9515-146394183c7a/image.png
0
0
#1
Options
2 Reply
Re:TP-LINK TL-SG108E VLAN broadcast broken
2016-09-03 11:27:16
For your problem, it is advised to contact their supporter directly. They will help you.
0
0
#2
Options
Re:TP-LINK TL-SG108E VLAN broadcast broken
2016-09-18 09:20:45
In fact, I don't think this a problem. As I know, in TP-LINK Easy Smart Swtiches like TL-SG108E, the VLAN 1 includes all the ports and cannot be deleted. That is to say, when the traffic comses from VLAN 1 (no vlan I guess what you mean), it will be able to broadcast to all the ports in the VLAN as well.
0
0
#3
Options