Using the command show vlan you will see the port and vlan mapping inside the switch.
Using that table the switch will not tag any frames inside, because already knows based on the vlan table which frame belongs to which vlan.
If a frame needs to be sent on trunk it will be tagged with the vlan tag corresponding to the vlan where the port sending the frame resides.
The access port does not strip or add vlan. This process belongs only to trunk links.
It's because all traffic within the switch is tagged. There is typically never untagged traffic in the switch. Also consider that the developers don't always parse packets over and over. On the way into the device, typically, there will be metadata attached to the packet/frame as it's within the switch.
The order in which the process occurs will generally be device dependent. Consider that in hardware, when you parse packets using logic gates, as you add the complexity of parsing, the best option is to parse add metadata in a fixed field format on the way in. I won't go into a Verilog/VHDL level discussion of the topic at this point (unless asked) but generally when processing packets in a device, there is metadata you don't see. An example of this is when you're using route-maps to alter the contents of a packet. At that point, there are actually two copies of each header type.
> It's because all traffic within the switch is tagged. There is
> typically never untagged traffic in the switch.
Would you have some information about VLAN-unaware switches, as TPMR (Two ports MAC relay). These devices have no enhanced interface for taken into account VLANs?
I haven't really encountered TPMR in the real world, but based on what information I've gathered on the tech, it's really a very simplistic bridge that should be able to be implemented entirely in a single chip and at low power.
The theory behind TPMR should be that it's a simple store and forward bridge or even a cut-through bridge unless there is additional tech to manage the network (think OAM).
As a result, by definition of the TPMR spec suggests that there should actually be no knowledge of VLANs required by the device since it's really intended to be more of a repeater than a bridge. In fact, I'd theorize that the entire TPMR spec can be implemented using two Ethernet PHY chips and no Ethernet MAC. This is amazing since it's the only Ethernet tech I'm aware of which would do such a thing. I think I'll sim it up and try it out... I'd love to see how complex it would be to take two Intel 10GBe Phy chips and use a minimal FPGA implementation to store and forward between interfaces.
Thanks for yet another crazy idea which I don't have enough time for but have to do haha
Thanks for these comments.
> In fact, I'd theorize that the entire TPMR spec can be implemented using two Ethernet PHY chips
> and no Ethernet MAC
A transparent firewall can be theorized by a TPMR. A function between the two PHY chips can analyse entirely the unity: the MAC part, the IP part and other upper layers. Frames not conform to the security rules are dropped.
I know there is a relation between TPMR and OAM, but it is yet weird for me. I have to see that... during the year.
Of course, a TPMR component is also used to change the PHY signal, from a copper support to a fiber optical support for example.