(Another) Native VLAN tagging question..

Answered Question
Mar 29th, 2009

I have completed CCNA 3 course and am in 4 right now. I am still confused about VLAN native commands such as

sw tr na vl xxx

When this is on a trunk port, what does it mean?

Thanks....

I have this problem too.
0 votes
Correct Answer by glen.grant about 7 years 8 months ago

Another reason if you are one of the people who like to force trunks "on" you better make sure you have the native vlans correct on each end . This won't happen when the trunk is negotiated because it will not create the trunk if the natives don't match . When you force on trunks it will say its trunking as long as you have a layer 1 physical link on the port though the trunk may not be working or working incorrectly.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
jimmysands73_2 Sun, 03/29/2009 - 10:27

I guess to clarify my question...if I have one sw1 on management VLAN 30, then another sw2 on management VLAN 40....sub ints setup (such as router on a stick theory) on a rtr,

SW1---SW2---RTR

On SW1 would I need on the trunk port to SW2

sw tr na vl 30

or am I thoroughly confused?

thx

jimmysands73_2 Sun, 03/29/2009 - 11:42

From the above link it said :

If a frame arrives on that trunk from an attatched device and it has no

802.1q tag embeded in the frame, the switch puts the frame into the native

VLAN which is configured on a port by port basis. Often used on IP phones

wgere the grames fro the phone itself are put into the voice VLAN but the

data frames (untagged) from the attatched PC are out into the native VLAN.

----

So does that mean that before the packet goes onto the trunk link it is put into the native VLAN then when it exits the trunk link (on the other side) it is stripped of the VLAN info?

thx

Joseph W. Doherty Sun, 03/29/2009 - 12:17

"So does that mean that before the packet goes onto the trunk link it is put into the native VLAN then when it exits the trunk link (on the other side) it is stripped of the VLAN info? "

No, what your prior quotation decribed is what a switch should do with untagged frames received on a port defined as a VLAN trunk.

The VLAN tags informs the switch what VLAN a frames belongs to when it is received on a VLAN trunk port, but without such a tag, how does the switch know the intended VLAN? It doesn't, from the frame itself. So, we can often configure a trunk port to place any untagged frames into one VLAN of our choice. In theory, once we define what VLAN untagged frames will be considered a member of, tagged frames, for that VLAN could also be accepted. Both should be treated the same by the receiving switch.

As for a switch sending packets out a VLAN trunk, normally you would expect all packets to be VLAN tagged although a switch might support sending one particular VLAN frames without tags to support a device, such as the PC described in your quotation, that doesn't understand how to process, or expect, tagged frames.

If you're wondering how this all comes to be, consider a PC that knows nothing about VLAN tags is connected to an IP phone which does (which connects to the network) and you want to place the two devices on different VLANs. As the PC traffic transits the phone could, in theory, wrap/unwrap the PC traffic with VLANs tags when working with the network switch. However, if the phone fails, you can design the IP phone hardware to keep the link good from PC to the network, but then the IP phone PC VLAN processing would be lost. So for that reason, and the reason, we might want to add/remove an IP phone "in front" of the PC, we want to continue to support untagged frames to/from the PC.

Altough the frames to the PC are untagged, since we can configure what VLAN untagged frame should be considered per port, we can have different PCs (on different ports) in different VLANs on the switch. (This is very similar to port based VLANs, but instead of being limited to one logical VLAN per port, we're limited to one untagged VLAN per port but can have multiple tagged VLANs per port.)

adamclarkuk_2 Sun, 03/29/2009 - 12:19

Hi Jimmy

The easiest way to explain 802.1q's native VLAN is to say that if a frame arrives at the trunk link and belongs to the native VLAN, then NO TAG is inserted into the frame. So to answer your question :-

"when it exits the trunk link (on the other side) it is stripped of the VLAN info?"

No, the switch will not strip the tag because there is no TAG to strip, and as there is no TAG the switch knows that this frame belongs to the native VLAN that is configured for this port. The default native VLAN is 1 so unless you have changed it, then this is where the frame will be passed.

This is one of the reasons it is so important to have native VLANS match on both sides of the trunk link. As stated in your output above, the native VLAN is configured on a per port basis.

If your native VLAN was 10 on one side of the link and 20 on the other, you have in effect, bridged those VLANs together with a simple misconfig, ( thankfully, the switches will complain constantly about a native VLAN mismatch if you did this, aslong as you have CDP enabled ;-).

Correct Answer
glen.grant Sun, 03/29/2009 - 13:35

Another reason if you are one of the people who like to force trunks "on" you better make sure you have the native vlans correct on each end . This won't happen when the trunk is negotiated because it will not create the trunk if the natives don't match . When you force on trunks it will say its trunking as long as you have a layer 1 physical link on the port though the trunk may not be working or working incorrectly.

Actions

This Discussion