The 3rd stanza indicates untagged + PVID. This means that frames egressing lan1 will be untagged on VLAN 1 and untagged ingress frames on lan1 will be associatd with VLAN 1.
The second stanza explicitly defines the egress, but not the ingress behavior. It appears that the implicit assumption (and functional behavior) is that untagged ingress frames will be assigned to VLAN 1. I have yet to see a valid reason why one would set the egress behavior as untagged but not the ingress. [1]
The first stanza does not explicitly specify untagged or PVID, but it seems that it also behaves the same as the above. However, here both untagged + PVID are implicit.
Therefore, the corollary question is this: If all three of those options produce the same functional result, why are there three ways that this can be expressed? Why not simply have either nothing added or a :u for untagged + PVID and :t for tagged? Is there ever a reason in DSA to not explicitly specify the ingress and/or egress behaivor for untagged frames on a port?
it should be noted that some managed switches allow multiple VLANs to be marked as untagged in the port-vlan membership, and then the PVID field is used to specify which VLAN is functionally associated with the port as untagged; obviously only one untagged VLAN is allowed on a given port at a time. âŠī¸
The issues/questions I have with the asymmetric VLAN idea are:
I am not aware of any network hardware that supports this, except for devices running OpenWrt.
I don't quite understand how it would be possible to choose different VLANs for untagged ingress (i.e. PVID) vs untagged egress. The best I could imagine is to blackhole ingress, but I don't see how that is useful except maybe for UDP type applications where you could theoretically make a port tx-only.
I don't see any practical reason why this would be beneficial. Maybe it's a failure of imagination on my part.
@jow -- since you had written about it in the linked thread, maybe you could comment on my questions (I'm trying to remember if we had this conversation via PM at some point in the past??).
That is an interesting example. I would argue, though, that this technically violates the 802.1q spec insofar as there are two or more untagged VLANs present on a port. Further, this requires that the host connected to this port needs to be configured to have two (or more) different addresses, untagged and on the same ethernet port. While possible on some OS's, this is not best practice. It would not be possible for this to work with DHCP client configurations, either, as only one of the addresses could ever be assigned. The other address would still need to be manually assigned (static IP). And as such, it would only work with some OS's since many only allow a single address on the port.
Finally, while not the fault of the switch, both networks would have equal access to the shared resource -- a fact that may not be desirable if one network is untrusted (say a server that has content for guests). Unless the two networks are equally trusted, I'd generally say that it's better to have inter-vlan routing such that you can provide exactly the desired access from the second network. In fact, it's possible that a host straddling two or more VLANs in this way could be abused as a jump host for VLAN hopping.
So while this is a clever way to manipulate the untagged networks, I think it's really more of an academic and intellectual exercise rather than something practical and useful, at least in my opinion. I'd love to know if anyone is really using DSA this way and why they are doing this vs standard routing methods.
In the example hosts connected to the ports are not vlan aware , and only need one address. Vlans are only used internally on the switch for the asyn vlan, to implement the segregation.
Vlan hopping , on a port that steers everything incoming to PVID , how would that work?
And in ideal world, this setup is usually implemented on proper managed
layer 2 switches with (port isolation or private vlans).
This is layer 2 segregation so does not eat up cpu power for intervlan/firewall , only using switching. Layer 3 has way more options but also needs lots of
cpu (which is in short demand on simpler routers)
If the hosts on each port all have just one address and use a common subnet, they would all have to be associated with a single L3 interface. But, an L3 interface can only be associated with one VLAN. How would this work in a normal network with internet connectivity, DHCP servers, and the like?
That L3 interface (with DHCP server) would need to be physically external, though -- it would need to connect, in this case, to port ethernet 2 -- it cannot be internal (i.e. this device can only be a switch, not a router) because the interface cannot be associated with multiple VLANs.