@R1D2 thanks for you confirmation.

I saw that the switch basically get an IP from DHCP from a "random" VLAN allowed on the trunk port to the router. I'm wondering if I could disable ICMP for the switch mac address on the DCHP server, so that eventually it will be assigned an IP from the only VLAN I wil allow. Do you think this makes sense? Do you think it is doable? Thanks.

Whoever designed this didn't think very far ahead.

There should be a screen (perhaps on the screen with PVID settings) that allows you to specify which ports the internal "CPU" is connected to. It could default to all for ease of use, but as it is, if you have multiple vlans defined, and each vlan has a dhcp server, which one the TL-SG108E will obtain its ip address from is random (or more likely whichever dhcp server responds the fastest).

Also, there is no way to limit what vlans have access to the Web interface.

This should be solvable with proper firmware.

If they can't figure out how to do it, then they should at least allow limiting what ports have access, but in general that is not as useful as being able to specify the management vlan.

There were hints that limiting access to vlan 1 would prevent access, but that is not true (at least with TP-Link TL-SG108E v4 with firmware 1.0.0 Build 20181120 Rel.40749).

I think I will be returning two switches to Amazon. I thought they were a bargain, but now I see why they are so inexpensive. They can't be used in a business environment. (no access control to management interface, no https)

@R1D2 

given your nickname you should be familiar with this statement: you either implement vlan or you don't. There is no "try".

What I mean is if you implement VLAN you should also implement VLAN for the switch "ethernet interface" IP. It's not a matter of DHCP vs static. What Bongo said is correct, whichever DHCP reply first, it wins. And you are wrong when you say that a static IP will do, because a static IP itself is meaningless if you don't know if VLAN tagging is on or off and what tag is used for the "ethernet interface". If I set a static IP to the switch but it is sent with the wrong tag (or no tag at all) the packet will not be routed where I need.

That said, the swich it's cheap and some of us can deal with it, but the implementation is wrong and for sure it could be fixed with a firmware update. If you don't it's because you don't want to. Also cutomers can decide to accept this limitation of return the switch as faulty. in In any case, please, accept the critics from your customers because this switch from this point of view is faulty indeed.

R1D2 wrote

You don't even recognize that I'm just a user like you, I'm not from TP-Link. You are not my »customer«.

 

And for the switch's Ethernet interface of an Easy Smart switch: you can reach it through any VLAN. Believe it or not (or just test it). Since VLANs are implemented in layer 2, there is no such thing as »routing« in this layer. What's more, the 802.1Q standard does not dictate the implementation. It even doesn't define a »management VLAN« nor does it define how the switch's interface must behave. It just defines minimum requirements; any vendor is free how to implement the details. That's why the TL-SG108PE has »Port VLAN« and »MTU VLAN« in addition to »802.1Q VLAN«, the former two being a special preset of 802.1Q VLAN just created for ease of use (and much appreciated by my customers, whom I recommend to choose this priceworthy Easy Smart switch). Being a software developer with 35 years of experience in networking since early ARPAnet, please don't try to teach me what 802.1Q VLAN is and what not.

@R1D2 

We appreciate that you volunteer your time to help new users.

I can confirm you can reach the management interface through any vlan.  That's the problem, there is no way to limit access.

There is a lot of untested speculation in reviews of the product on Amazon and youtube, including that the reason that access was allowed was because vlan 1 was not removed from the port that you wanted to restrict.  But I have confirmed that even if every port is on its own vlan, you can access the management from every port.  For example using this config:

You can plug into any port and have access, but there is no access between any two ports (no, I didn't test every of the 28 possible 8 choose 2 port combinations) 

I can also understand TP-Link's decision to try to make the switch as idiot proof as possible, because when selling at this pricepoint, there will be a lot of buyers that have never used a fully managed switch, and TP-Link probably does not want to deal with people "locking themselves out" and having to listen to the moaning when a user has to press the reset button and lose their config they never took the time to backup.

And I can understand why the default for the factory config is to obtain an IP address via dhcp, especially since they chose 192.168.0.1 as the default ip address, which is likely to conflict with many home devices (including TP-Link's home routers).

And I agree that the only way to avoid having problems with the current TL-SG108E firmware if multiple vlans are used and there are multiple DHCP servers, is to configure a static ip address and disable the dhcp client.

I don't have the PoE version of the switch, I have the TL-SG108E v4, which I bought specifically for the vlan support.  I have a Ubiquiti EdgeRouter X that has a vlan-aware switch with all 5 user accessible ports connected via the switch, the router is essentially a router on a stick. 

The way the EdgeRouter X presents individual switch-ports as if they were interfaces directly connected to the CPU is by using high vlan numbers 4088-4094 for ports and switch0.  The "CPU" has an internal connection to the switch (implemented in the same SoC) and the CPU is a member of all those vlans.

I speculated that the TL-SG108E was doing something similar to allow access to the CPU management interface from any defined vlan.  And if that is the case, it should be relatively easy to remove specific ports from that hidden vlan. But since the TL-SG108E allows creating vlans from 2-4094, and vlan 1 is predefined (and I couldn't figure out any way to delete it), if they are using vlans to allow access to the CPU, they must be using one of the reserved (0,4095) vlans.  Or they are using some other feature I am not aware of.

I just wish I could find third party firmware that would remove some of the limits on this switch. It could be much better.

Oh, and the firmware also has confirmed bugs.  Google Not So Smart TL-SG105E  The second curl example will lobotomize the TL-SG108E 8051 CPU while still allowing the switching function to work.  I reproduced the effect with a TL-SG108E 4.0 with latest firmware updates 1.0.0 Build 20181120 Rel.40749. 

Hello @R1D2,

Thanks for the detailed reply, I have read some of your other posts in the this forum, and you are a real asset to the forum.

What you are describing is the method that must be used on routers without dedicated switch chips, like the ER-8 or ER-4, that have indiviual ethernet controllers on every routed port.  And using the bridge interface just makes them an expensive, low performance switch, which is not what they were designed for.

Since you have an ER-X and the EP-R6 (which is essentially an outdoor version of the ER-X SFP), you can try this on either one, since they are both based on the MediaTek MT7621A SoC, which has a 32bit MIPS CPU and a dedicated portion that is an switch chip.  I use fw v1.10.10 because v2.0.6 has problems on the MediaTek SoC based routers.

You can configure the ER-X switch in vlan-aware mode, and put vlans (with up to one pvid for untagged, or one or more vids for tagged frames).  These vlans don't require an associated vif, and if the vif doesn't exist, the router is unaware of them.  However, these vlans will still be switched without the assistance of the CPU.  The only involvment of the CPU is in configuring the switching registers in the switch chip, the switch chip does the heavy lifting in dedicated silicone circuitry. 

Since you have an ER-X and the EP-R6 (which is essentially an outdoor version of the ER-X SFP), you can try this on either one, since they are both based on the MediaTek MT7621A SoC.  I use fw v1.10.10 because v2.0.6 has problems on the MediaTek SoC based routers.

Log into the CLI and enter the following commands:

/sbin/switch 

/sbin/switch dump

/sbin/switch vlan dump

/sbin/switch pvid dump

More info can be found here and here.