Business case: TL-SG108E can be used for basic QoS and Egress rate limiting.

Problem: The management interface is exposed on every VLAN, and DHCP is also taken from the first DHCP server to respond not from the specific management VLAN1.

Feature Request: Request to attach the Management Interface and DHCP to a specific VLAN or at least isolate it to only to VLAN1. 

 

 

Background

 

Aim: to pair an eero6+ with an SG108E and have the SG108E "smartness" compensate for the lack of features on the eero while still taking advantage of the eero6+ mesh wifi.
Note: the SG108E would give you 5 spare device ports, with this configuration.

 

The Ideal Setup:
+---------------------------------------------+
|        switch — SG105E / SG108E       |
+----------------.----------------------------+
|   VLAN 500  |            VLAN 1            |
+-------.--------+---------.--------.---------+
| port 1 | port 2 |  port 3 | port 4 | port 5  |
+--------+------+---------^--------^---------+
| NBN  | WAN | LAN  | DEVICE 1 — n |
+-------+-------^--------+-------------------+
            |    ROUTER    |
           +-----------------+

 

I was hoping that the management page for the switch would only be accessible from VLAN1. It turns out that it is accessible from any VLAN so long as you know its IP address. This kind of setup is not great having an external network (NBN) be directly interfaced as anyone on the other end of the cable (ISP) could potentially access the management page and with some time access the device.

 

That was the idea.
I've tried a few implementations of that idea. Starting with variants of the basic port vlan feature of the smart switch. That includes:

• VLAN 1 : Ports 1,2 — VLAN 2 : Ports 3,4,5,6,7,8
• VLAN 2 : Ports 1,2 — VLAN 1 : Ports 3,4,5,6,7,8
• VLAN 2 : Ports 1,2 — VLAN 3 : Ports 3,4,5,6,7 — VLAN 1 : Port 8

 

No matter which port you plug in you may access the management interface. Do let me know if I missed something obvious.

 

Moving onto the more advanced 802.1Q VLAN mode. I tried the following variations:

• VLAN 500 : untagged Ports 1,2 — VLAN 1 : untagged Ports 3,4,5,6,7,8
  Port 1-2 PVID : 500
  Port 3-8 PVID: 1
• VLAN 500 : untagged Ports 1,2 — VLAN 600 : untagged Ports 3,4,5,6,7,8 — VLAN 1 : no members
  Port 1-2 PVID : 500
  Port 3-8 PVID: 600
• VLAN 500 : untagged Ports 1,2 — VLAN 600 : untagged Ports 3,4,5,6,7 — VLAN 1 : untagged 8
  Port 1-2 PVID : 500
  Port 3-7 PVID: 600
  Port 8 PVID: 1

 

Then I read the manual and it describes the behaviour such as if a port receives a tagged frame it will read the tag and forward to the appropriate vlan. If a port receives an untagged frame it will add the pvid as a tag and forward as if it were tagged. This leads me to believe the implementation is very basic, which would be also fine, as I can force what I want by being 'clever'. And the 'very basic' assumption also fits with the fact the user interface allows you to enable more than one untagged vlan on one port simultaneously (which should be an error).

• VLAN 500 : untagged Port 1 — VLAN 600 : untagged Port 2 — VLAN 1 : untagged 3,4,5,6,7,8
  Port 1 PVID : 600
  Port 2 PVID: 500
  Port 3-8 PVID: 1
  Note: the swapping of PVID on Port 1 and 2.

 

I had hoped that on receipt of an untagged packet on Port 2 it wold be forwarded to VLAN 500 and emerge untagged at Port 1 and similarly a receipt of an untagged packet on Port 1 would be forwarded to VLAN 600 and emerged untagged at Port 2. However this is not the case, vlan membership is controlled by the egress rule only (tagged/untagged/not member) despite the PVID value set, so traffic is blocked since the port pvid is corresponds to a non member and the description of the forwarding in the user guide is not exactly what it seems (omitted the blocking description). Note: this would have worked nicely as anyone trying to access the switch from the outside world on Port 1 would have had their response packets forwarded to Port 2 the router wan interface. Effectively dropping the data.

 

This finally led me to another tricky solution, making the ports an opposite tagged member of the other port, only to make each an opposite VLAN member, so the data would not drop.

• VLAN 500 : untagged Port 1, tagged Port 2 — VLAN 600 : untagged Port 2, tagged Port 1
  Port 1 PVID : 600
  Port 2 PVID: 500
  VLAN 1 : untagged 3,4,5,6,7,8
  Port 3-8 PVID: 1

 

Expectation: a switch should not output on the input port. Thus,
- Untagged enter on Port 1, PVID 600, will exit on VLAN 600 untagged on Port 2. 
- Tagged 600 enter on Port 1, will exit VLAN 600 untagged on Port 2.
- Tagged 500 enter on Port 1, will exit VLAN 500 tagged on Port 2.
- Untagged enter on Port 2, PVID 500, will exit on VLAN 500 Port 1 untagged.
- Tagged 500 enter on Port 2, will exit VLAN 500 untagged on Port 1.
- Tagged 600 enter on Port 2, will exit VLAN 600 tagged on Port 1.

 

Anyway, while this tricked to the switch into not blocking the untagged packets, the switch still responds to requests but as tagged on the same port, so the expectation that it would not was not correct, also this cross config has the side effect of allowing tagged traffic to be responded to from the management interface as well.

 

The reason I'm making this post is because I am a bit burned out after all this testing and I can't think if there is another tricky solution or not. Again, I am looking for passthrough communications in port 1 and 2 as if it were a straight cable, while also blocking the management interface on those ports. Do let me know if you think a different config would work for that.

 

This feature request (option to isolate the management interface to VLAN1 and take DHCP only on VLAN1) could be solved by a firmware update.