chrisisbd wrote

A packet arriving on the port I have assigned to VLAN ID 2 will get sent to the other ports I have assigned to it, but it will also get sent to those same ports (and every other port) because they are all on VLAN ID 1.

No, untagged packets arriving on untagged port 2 will be forwarded to the VLAN defined in the PVID of port 2, not to any other VLAN this port is also a member of. So, if PVID of port 2 is 1, all untagged packets will be forwarded only to the default VLAN 1, not to any other VLAN. If PVID is 2, all untagged packets will be tagged with VID 2 and therefore will be forwarded only to VLAN 2 members.

To have the switch forward all untagged packets arriving on untagged ports 2 and 3 into VLAN 2, you would have to set both PVIDs of port 2 and 3 to the VID 2.

Setting PVID to 1 makes only sense for untagged ports not belonging to any VLAN or for tagged ports to handle untagged packets and send them to the default VLAN (= any ports on TL-SG108E, but not on other switches, such as for example the TL-SG2008).

Maybe this table makes it somewhat clearer what happens with various settings:

chrisisbd wrote

So I *think* the packet will go to any/all ports that are in the VLAN given by the PVID that has been added to the packet.
Is this right?

This is right. And since all ports in factory settings are always members of the Default VLAN 1 (sometimes also called Native VLAN) and every PVID is 1, too, the switch behaves in factory setting like any other (unmanaged) switch.

If no port is a member of the VLAN given in the PVID then the packet will be dropped.

Theoretically, yes. But in practice: if no port is a member of a given VLAN, you cannot set this VID as PVID for any port. The switch's UI does not allow this. To be able to set a PVID N, not only the VLAN N must exist, but the port to be assigned this PVID N must also be a member of VLAN N.

In other words: you can have a VLAN 20 with no member port, but you can't assign this VID 20 to any port in this case, therefore - if you only use untagged packets outside the switch - no packet inside the switch will ever get tagged with this VID 20. It could arrive tagged already, but that's another story.

Thus, as I said in my other reply, there is absolutely no use (in my 'standalone' case) for more than 8 VLANs.

I'm not sure what you mean with 8 VLANs. For unmanaged mode you need no VLAN at all, even while the switch internally uses the Default / Native VLAN 1 to accomplish forwarding of untagged traffic. Packets then will arrive untagged at the switch and will leave the switch untagged. From the outside perspective, It is much the same as having no VLAN tags at all (and in fact outside the switch you indeed don't have VLAN tags).

As long as you don't need more than one subnet handled by the switch, you don't need 802.1Q VLANs at all. If you need two segmented subnets, you need two VLANs and a third one for untagged packets. If you need 25 segmented subnets you need 26 VLANs including the one for untagged packets.

If you just want to separate ports for security reasons into different segments in the same subnet, use MTU VLANs (Multi-Tenant Unit VLANs). Then you have 7 VLANs for 7 ports and a single port shared by those 7 VLANs, which then totals 8 VLANs.

chrisisbd wrote

I see, this just gives 7 isolated segments that can't talk to each other but can send/receive from the 'upload' port.

That's correct.

What I'm actually after is a mix of segments, some of which can talk to each other and some can't. I may not be able to achieve all I want with just
the managed switch but (with the help I've received here) I think it will do quite a lot of what I need.

There is still another VLAN mode, it's called "Port-based VLAN". This probably will do what you need by allowing mixed segments. I never tried this mode, since I need 802.1Q VLANs, but maybe you want to play with it to see wether it will work the way you want.

chrisisbd wrote

>In the TP-Link Port Based VLAN each port can only belong to one VLAN, in everyone else's implementation ports can belong to multiple VLANs.

If a port is a member of more than one VLAN, it is not Port-based anymore, but an 802.1Q-based VLAN. It does not make any sense to me to have an untagged port with membership in more than one VLAN if the device connected to such untagged port can't handle VLAN tags at all.

sgs wrote

I'm seeing a related weird problem in that there appears to be no way to tag VLAN 1 or remove it from a port as it possible on all other switches I own (mostly NetGear).

Yes, that's what bothers me the most with TL-SG108E, too.

We have > 1,000 WiFi routers in the field which use VLAN 1 for the LAN and a VLAN trunk to the APs for Multi-SSIDs. We can't switch away from VLAN 1 being the LAN and therefore can't use TL-SG108E/PE in this case, b/c even trunk ports are fixed untagged members of VLAN 1 on this switch. So we are forced to use Netgear GS108E to carry VLAN tagged traffic from our TP-Link WiFi routers to the TP-Link EAPs if the customer demands an inexpensive 8-port switch.

Is there any way to do that with this switch without rearranging all the VLANs on the network?

No. Using VLAN 87 instead of 1 as the default VLAN for untagged packets would require to be able to define this VID for the default VLAN. You could use it as a "secondary default VLAN", but even then VLAN 1 is still not useable for tagged traffic on a trunk port.

IMHO, if a VLAN is assigned manufacturer-specific semantics, then at least a higher VID should be used (>4090) rather than VID 1.