Yes, I am in Germany. Where are you from?

Here are my quick & dirty test results with original firmware as delivered when I bought the switch last year (Build 20160108 Rel.57851).

First of all: you were right, I was wrong. This switch indeed supports overlapping VLANs in a similar manner as PVLANs. I'm really surprised that the TL-SG108E for such a favourable price does support this kind of setup. Truly amazing!

Now the bad news: In my network the LEDs blinked more or less synchronously, but at a very low rate. I had to flood the switch with ARP requests using tomw's cool arpflood script to get blinkenlights like in a discotheque. During this ARP attack I did a speed test simultaneously, but since I have only stone-age speed of 12 Mbit/s downstream here in underdeveloped Germany it performed well with almost no degradation. The setup was as you described with PVID 1 for port 1, PVID 2 for ports 2-6 and PVID 3 for ports 7+8 and following VLANs:




This is the captured traffic, ARP requests highlighted:




Statistics show that data to port 1 goes to both VLANs 2 and 3 as expected and vice versa:




While I'm at it, I did also the same test using old-fashioned, classic VLAN setup. For this I did setup a TL-WDR4300 with OpenWRT, configured one LAN port as a VLAN trunk, created two additional private subnets and installed the usual forwarding rules to the WAN. Since for the WAN VLAN we use VLAN 2 already on this router, I changed the switch's VLAN IDs to 3 and 4, but it is basically the same setup except for the fact that I now have two broadcast domains and a tagged VLAN trunk to the WDR, which connects to the ISP's modem. The TL-SG108E config is as follows (PVID same as before + 1 for the new VLAN IDs), only remarkable difference here is port 1 being a tagged (trunk) port now instead of untagged:




Same test conditions (ARP flood & simultaneous speed test):




Here are the result of the dslreports speed test (1 & 2 was the "PVLAN" without and with ARP flooding, 3 was classic VLAN without ARP flooding, no big difference):




Unfortunately, this doesn't help you much - you have to find out what causes the broadcast flood in your network. Probably it's coming from the cable network? I don't know. I'm always trying to keep traffic in my networks as low as possible despite the fact that we have big bandwidth nowadays - when I started we had serial lines with roughly 9,600 bps (bit per second) in local networks - unbelievable today, isn't it? :)

So you will have to use tcpdump / wireshark and find out what causes your switch to perform such a light show - if it's a bug in the switch, I couldn't trigger it with my systems. But you certainly see the difference of classic VLANs versus overlapping ones even at this low traffic utilization.

Nevertheless I hope this helps somewhat - and be it only to think about such a setup to create different broadcast domains while maintaining the same functionality as with overlapping VLANs and a single subnet. It was really great fun to do the tests and to learn something new about the TL-SG108E! :D

tomw wrote

You can't remove ports from vlan1, so anything coming in on vlan1 will go out on all ports, regardless of all other settings. If your modem is on port 1, having pvid 1, all that traffic will always go out on all ports. To avoid this you should not use vlan 1, meaning no pvid=1 on any port.

Yes, that's right. In my regular network setup I don't use PVID=1 at all. For the test I just waned to be as near as possible to pleased's setup.

Nice. However, I don't understand why you can see the ARP flood in the first test but not the second so I'm not sure what difference I'm seeing. You are doing the ARP flood from a machine on the Apartment VLAN while the Wireshark monitor is on the Home VLAN (or vice-versa)?

No, I connected port 1 to my local network and used a more or less fast server to generate the broadcasts. Cocoa Packet Analyzer did run in the Home VLAN for some tests and for comparison/screenies in the Apartment VLAN. Since I have no cable modem, it's not a real WAN I connected the switch to, but my small office network with several servers I can use to simulate incoming traffic on port 1.

I couldn't see the ARP flood in my second test, because with a trunk ports the Home and Apartment are different subnets and therefore different broadcast domains - what is the main reason VLANs have been invented for.

I suppose I could flash the router I have to DD-WRT (haven't checked other options) and set up your "classic" VLANs. OTOH, maybe new firmware would fix my blinkenlights problem.

I would recommend to find out what causes the massive traffic and then try to resolve the problem at the root of the cause. Only if the switch itself causes additional broadcast traffic not coming in to port 1 from somewhere or being forwarded from remaining ports, the switch's software deserves to be fixed.

If the packet "crossing VLANs" and sent to the router is triggering broadcasts, how could that come from the cable modem or cable network? The router is doing NAT and I don't understand why it would incite that response.

So, do you have a cable modem or a router before the cable modem? That can make a big difference depending on the ISP's setup. Back in time where I had a direct leased line into the CIX, we had to take measures to isolate my local network at the ISP, not at my office. But I'm no longer in ISP business, don't know what they do today.

Back to your trying to duplicate my blinkenlights, I don't see that you tried a speed test from Home, for example, to see if Apartment blinked along. If it didn't, that would implicate my router (though the root cause still would be the SG108e, as I understand).

Of course, yes. The laptop I did run the speed tests and the analyzer on was connected to the Apartment VLAN and I got blinkenlights just as you described in your first post, synchronously on all ports. It's no wonder - since it is a common broadcast domain.

To summarize:

Splitting up broadcast domains into smaller ones and feeding traffic for several logically separated subnets over one cable are the main reasons to use VLANs at all, client isolation is another one. Therefore I really wondered what advantage it has to use only a single subnet over several VLANs other than to have a common uplink and to isolate clients, but at the expense of having duplicate broadcast traffic coming in on the uplink port.

pleased wrote

Ah, but if you were generating ARP packets without VLAN tags, then wouldn't the SG108e broadcast them on all remaining ports, even though the port 1 uplink is tagged?

Yes. Usually on cheap SOHO switches there is a fixed default VLAN which can't be changed or turned off. It's a real mess if you ask me, since we have more than 1,000 WiFi routers in the field, which use VLAN 1 as the WAN on routers with only a single built-in switch such as the TL-WDR4300 (it's the default VLAN for WAN ports in OpenWRT and most of its clones). But this VLAN 1 is a "normal" VLAN as any other and it can be disabled or used for anything else. Likewise untagged packets can be assigned to any other VLAN. In my opinion this is how things should be according to the standard in 802.1Q. TP-Link's way to assign a fixed VLAN as default VLAN all ports are always members of will make problems connecting TL-SG108E or even EAP WiFi APs with VLANs to our WiFi routers without re-configuration, that's why I don't like this idea of a fixed default VLAN 1.

Bigger switches have a non-fixed default VLAN and it can be disabled as well as ports being removed from it. Also, on VLAN trunks (ports using tagged packets) one can define to discard untagged ingress packets instead of accepting them. Furthermore, any router or server can be configured to only send tagged packets and this is what I did. So, every packet coming into the switch always has a VLAN tag, there can be no untagged packets on the trunk port in my setup. Therefore, default PVID=1 is not only unused in such setups, but also unusable, which outweighs the first point.

BTW: To avoid mis-understandings: In TL-SG108E docs and the web UI up to V2 TP-Link uses the term "Trunk" for Link Aggregation. Starting with V3 docs/web UI they now call it LAG (Link Aggregation Group). LAG has nothing to do with VLAN trunk ports - just to clarify the terms.

As I understand the router isolates my LAN so that any IP packets outbound should only incite IP packets inbound on my LAN. So ... may there be a broadcast coming through my router (issued from beyond my router) in response to an outbound packet "crossing VLANs"?

If things have not changed meanwhile (I'm not up-to-date in every aspect), only multicasts should come through, e.g. TV streams over cable, but not regular broadcasts. However, all this depends on setup of the router and ISP policies.

You mean, the ARP flooding is to be expected to cause blinkenlights.

ARP flooding was the only way for me to test wether any broadcasts on the uplink port 1 will really cross VLAN borders and therefore light all LEDs. I couldn't imagine that a cheap switch allows this. Most switches I know don't allow a subnet spanning different VLANs - except if PVLANs are supported - and thus always require separate subnets if VLANs are being used. That was what I learned about TL-SG108E - that it allows one subnet spanning different VLANs. It does not mean that ARP flooding is the reason of the effect you are observing at your device, it just is a presumption that some kind of broadcasts are causing the effect. Without ARP flooding I could not observe any unusual LED activity.

However, did you determine if the speed test alone, without ARP flooding, caused blinkenlights? Is your "stone-age speed of 12 Mbit/s downstream" through a modem/router? I.e.. blinkenlights on speed test alone means it's not just my (cheap) router at fault.

No, speed test alone from within one of the VLANs did not light up all LEDs, but only LEDs of the ingress/egress ports as it should be. There were some regular broadcasts (ARP, SMB multicast), but in usual (long) intervals only. Yes, I use a router connected to an ADSL modem, not a cable modem.

Well, the containing net has to communicate with them somehow, so some broadcasts are required (unless you would manually configure the routing tables!)

That's what a router is for and no, routes do not have to be set up, since most routers establish a default route for LAN devices and forwarding from LAN to WAN automagically, together with standard firewall rules to secure the LAN from outside access.

pleased wrote

Not so pleased. I installed Wireshark and viewed the traffic on an "Apartment" port. It appears that when the destination of a packet coming from the router port is on a port whose PVID matches the router port's, the packet is sent out that port only. Otherwise, the packet is broadcast to all ports on the router port's primary VLAN. Thus my blinkenlights.

So my gut feeling was right then? You have one big VLAN with secondary VLANs in a primary VLAN causing blinkenlights? :D

Yes, it's technically a nightmare as it also is with PVLANs.

TP-Link should fix it and please: also fix the messy default VLAN 1 assignment for untagged packets or let the user choose a default VLAN ID for them at least.
I would be able to sell more TL-SG108Es and EAPs.