Switch – Frame tag decision based on switch port TPID (EtherType)

metro-ethernetservice-providerswitchvlan

I'm working on developing the ingress logic of a software switch and have a doubt.

So here's my understanding. When a frame ingresses a switch, its 13th and 14th byte are checked against standard 802.1Q TPID, i.e. 0x8100. If it matches, the frame is decided as tagged. Oherwise untagged.

Now there's another concept of configuring a switch port's ingress and egress TPID. If not otherwise configured, it's taken as 0x8100 by default. Suppose a user configures a custom ingress TPID of 0x9100, then the frame will only be considered tagged if its TPID is 0x9100.

My doubt is, is this decision only relevant in case the port itself is a "tagged" member of the VLAN? What happens when the port is untagged member of a VLAN (i.e. a trunk port). Will the frame undergo the same routine of tagging decision?

I understand if a frame is decided to be untagged, it is pushed a pvid based on the native VLAN which the port is part of. And unicasted/broadcasted into that VLAN domain.

I also have to work on provider bridging logic of the switch. In that case the ingress TPID of the switch is configured as 0x88a8. So a frame ingressing with TPID 0x8100 or any value other than 0x88a8 will be considered untagged. If so, the frame's tag containing the CVLAN will be looked up against CVLAN-->SVLAN mapping in the switch and added an SVLAN with TPID 0x88a8. Hence making the frame tagged and forwarding it into SVLAN.

Am I understanding it correctly?

Best Answer

The first 6 bytes of an ethernet frame are the destination MAC address, the next 6 bytes are the source MAC address. The next two bytes, 13th and 14th bytes, are the payload length (<= 1500) or the EtherType field (>= 1536). An EtherType of 0x8100 indicates the presence of and 802.1Q tag, and the real EtherType field is moved four bytes over.

An untagged frame is a native VLAN (the VLAN as configured on the switch interface; some vendors can only use VLAN 1 as the native VLAN).

What happens to tagged frames received on non-trunk switch interfaces is undefined. Some switches will simply forward them, and some switches will drop them (possibly as giant frames).

The EtherTypes you mention (0x88a8 and 0x9100) are registered.

The EtherType of 0x88a8 is registered, and it is used by Provider Bridging (IEEE 802.1AD) & Shortest Path Bridging (IEEE 802.1AQ).

The EtherType of 0x9100 is registered, and it is used for VLAN-tagged (IEEE 802.1Q) frames with double tagging.

Related Topic