cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
801
Views
11
Helpful
19
Replies

A frame with a tag such as native vlan.

If a frame with a tag corresponding to the native VLAN enters the trunk port, will the switch take down that frame and send it on over the trunk link as untagged, or will it send it with a tag corresponding to the native VLAN?

How I understand it:
(Let's assume that the addressing is correct).
PC-A will send a frame to Switch1, which will give it VLAN tag 20. The frame will go through the trunk port to Switch2. Switch2 will check the VLAN tag and find that the frame has a tag corresponding to the native VLAN, so IN MY OPINION the tag will be removed because the native VLAN only transmits untagged traffic. So, then Switch2 will send the untagged frame to Switch3, which in turn will forward the frame to PC-B.

krzysztofmaciejewskiit_2-1714335645930.png

 

What will it look like in this case?
Since the access ports are the same as the native VLAN. I wonder if at least one actual tagging of a frame will happen at all in this situation. I realize that the switch somehow “tags” the frame as it passes through the access port, but the actual tagging only takes place when the switch knows it needs to pass the frame through the trunk port.

How I understand it:
In my opinion, a frame when it hits an access port on Switch1 will not be tagged before being sent to Switch2, because Switch1 will realize that the frame is to be forwarded to a trunk port that has a native VLAN the same as the potential VLAN tag.

krzysztofmaciejewskiit_3-1714335927597.png

 

 

19 Replies 19

Take a look at the MAC addresses assigned to interfaces in your own Cisco switches and you are likely to find reuse across multiple interfaces. Some time ago, with IEEE encouragement, equipment vendors started shipping products that reuse the same MAC addresses in different subnets/VLANs in order to conserve addresses (reuse within an individual platform, not across multiple platforms). 48 bits for MAC addresses sounded like an absurdly large number 40+ years ago, but not so much anymore.

Originally, addresses were handed out to vendors by the IEEE in 24-bit OUI blocks, which lead to fragmentation of the addresses and loss of assignment efficiency. The OUI blocks were further chopped up by the vendors into sub-block pools for burning into each product that rolled of the assembly line, so inefficiency was exacerbated. Reuse of MAC addresses within a platform allows for smaller sub-block pools to be allocated to each platform. The IEEE, seeing an impending slow-motion train wreck, has taken multiple steps to mitigate against eventual depletion of EUI-48 addresses such as EUI-64 addressing, and the creation of "small" and "medium" address block allocations to complement the original OUI block size (now referred to as "large").

Disclaimer: I am long in CSCO

"48 bits for MAC addresses sounded like an absurdly large number 40+ years ago, but not so much anymore."

Yea, 281 trillion, plus change, does seem fairly large.  Heck it's only 2 to 3 times the unfunded liabilities of USA.

Like IPv4 addresses, MACs are not just assigned sequentially.  It's the block assignments that eat up the address space.

Fortunately, with IPv6, the address space is SO LARGE, we use /64s for p2p links.  Although, I wonder if some time in the future, might there be déjà vu once again.

Yes, in the 23rd century Captain Smirk will say to Chief Engineer Snoty, I need another address, and Snoty will reply, we've run out!  Then Mr. Smock will note, in the latest IEEE Journal, they've proposed using a 1024 bit address space - so we will never run out, again!  ; )

Gopinath_Pigili
Spotlight
Spotlight

Hello krzysztofmaciejewskiit ,

The 802.1Q also defines one special VLAN ID on each trunk as the native VLAN (defaulting to use VLAN 1). By definition, 802.1Q simply does not add an 802.1Q header to frames in the native VLAN. When the switch on the other side of the trunk receives a frame that does not have an 802.1Q header, the receiving switch knows that the frame is part of the native VLAN.

Note that because of this behavior, both switches must agree on which VLAN is the native VLAN.

For example, a Cisco switch could be cabled to a switch that does not understand 802.1Q trunking like HUB. The Cisco switch could send frames in the native VLAN—meaning that the frame has no trunking header—so that the other switch would understand the frame.

The native VLAN concept gives switches the capability of at least passing traffic in one VLAN (the native VLAN), which can allow some basic functions, like reachability to telnet into a switch.

Best regards
******* If This Helps, Please Rate *******

KJK99
Level 3
Level 3

Hey @Ramblin Tech, I really like your posts, but I think you should say simply 'data' instead of 'metadata'. Metadata is data about data, like VID to indicate what the number 20 is.

Kris K

Hi @KJK99 . I'm saying "metadata" because it is data about the packet and I do not want to imply that anything is written into the packet itself, as it is written into a packet descriptor structure that is associated with the packet. Examples of this include qos-group and discard-class, which are typically set by an ingress QoS policy and then used as match conditions in egress policies. Neither qos-group nor discard-class are ever written into the packet, but rather a packet descriptor that is associated with the packet.

I take your point, however, that my use of "metadata" might be confusing to some who do not share my own context. Maybe I should just say "packet descriptor" instead?

Disclaimer: I am long in CSCO
Review Cisco Networking for a $25 gift card