Trunking dependent on VLAN existence?

[vv0bbLeS]

Hello all,

On a given switch, does a VLAN have to exist on the switch in order for that switch to tag that VLAN's traffic on a trunk link?

For example, if Switch-A needs to tag VLAN 100 traffic on a trunk link (switchport trunk allowed vlan 100) , does VLAN 100 have to exist on Switch-A (vlan 100) for it to tag that traffic? If so, why is that?

[Jon Marshall]

Yes it does. 

I assume because tags are added and removed on egress and ingress and while transiting the switch it has to be assigned to that vlan. 

Jon

[MHM Cisco World]

SW-A tag traffic with VLAN 100, 
from where it get this traffic ? from port config with access vlan 100 <- here when enter this command you create VLAN name VLAN100. 
so the story begin in Client access port.

[ashishr]

Hi @vv0bbLeS 

VLAN must be present in VLAN database in switch in order to tag egress packets and untag ingress packets. If a specific VLAN ID is not present in VLAN database then that VLAN will not be in active and forwarding state on trunk port. Try running command 'show interface <interface-id> trunk' without creating VLAN locally on switch.

Without VLAN in local vlan database switch will not be able to put that packet in correct VLAN when received (ingress) on trunk port and it will be dropped.

Thanks,

Ashish

[David Ruess]

Hello,

I would say yes and its probably for best practice to have a standard. However a switch can be configured as Transparent and be independent of VLANs for the given network its attached to but it will still pass other tagged vlan traffic through without that vlan actually existing on that switch. This may be due to the VLAN already being tagged as it comes in and not modified during transit on the switch and just sent out an egress port with the original tag it had.

Like @MHM Cisco World mentioned. I think traffic is tagged at the access switch and port it originated from. So it would have to be present.

That's how I understand it.

-David

[Jon Marshall]

Hi David 

I'm not sure about that. 

A switch in VTP transparent mode will pass VTP advertisements on but I still think you need the vlan in the database for it to forward traffic for that vlan. 

Note some emulators don't follow that rule and will pass without the vlan but I am not aware of any real switches that do it. 

Could be wrong though. 

Jon

[David Ruess]

Hey Jon,

It very well could be. I have not actually tested with live gear as well. I just assumed since the transparent switch could have a vlan database independent of the rest of the network that that was the way is it just forwarded traffic that wasn't meant for it. But I see what you mean about forwarding VTP advertisements vs forwarding actual vlan tagged traffic.

-David

[vv0bbLeS]

Wow thank you all for all the responses! This raises an interesting question of VLAN traffic originating on that switch, vs. simply passing through that switch.

So if we had 2 switches, downstream Switch-D (with clients in VLAN 100) and upstream Switch-U (only trunking vlan 100, no clients), do they behave differently in terms of having to have VLAN 100 on them?

• Switch-D of course would need it b/c it has clients in VLAN 100, but does Switch-U also need VLAN 100 on it? The VLAN 100 traffic was already tagged coming from Switch-D, and Switch-U is just forwarding that tagged traffic along.
  • @Jon Marshall made an interesting point above that perhaps while tagged traffic is transiting a switch, it has to be assigned to that tagged VLAN. I wonder if there are any debugging commands that show what's going on. I'm curious why a switch that's simply passing along already-tagged traffic needs to have that tagged VLAN on it (not that there's anything wrong with that, I just like to learn how the software behaves is all : )  ).

[Jon Marshall · Accepted solution]

I think as I say it has to have the vlan because the frame is not tagged as it transits the switch, it is only tagged when the switch receives the frame on a trunk port and when it leaves on a trunk port (assuming it is not the native vlan). 

So while it is "in" the switch so to speak it has to be assigned to a vlan and that is why it is needed. 

I suppose it could have been done differently in the code but then it would have to be an exception whereas treating a transit switch the same as a switch with access ports in that vlan means less complications. 

Not sure you will find any debugging to show you what is happening within the switch in terms of this. 

Jon

[David Ruess · Accepted solution]

@Jon Marshall and @vv0bbLeS 

After I labbed this up in a L2 environment here is what I got.

3 switches trunked in a line with a PC in vlan 100 off each end switch -1 switch in the middle did not have vlan 100 and I made it transparent vtp mode (end switches I made VTP server/client and part of domain. - see attached picture)

2 things I noticed

1.) The end client switch received vlan info from vtp messages (as you stated) without vlan being configured on middle (transparent switch)

2.) I was unable to ping end to end of devices. Once I added the vlan 100 on the transparent switch I was able to ping. So it looks like vtp messages/mgmt traffic will get through but not so much user/data traffic

I also noticed another thing I forgot to think about. STP. In order for it to be fully effective it needs to be aware of where every vlan traverses. So if vlan 100 is not on a switch, it shouldn't be allowed to transit that switch since STP wont know it can take that path and could cause a loop.

Transparent Switch output

Switch#sh int trunk

Port Mode Encapsulation Status Native vlan
Gi0/0 on 802.1q trunking 1
Gi0/1 on 802.1q trunking 1

Port Vlans allowed on trunk
Gi0/0 1-4094
Gi0/1 1-4094

Port Vlans allowed and active in management domain
Gi0/0 1,100,150
Gi0/1 1,100,150

Port Vlans in spanning tree forwarding state and not pruned
Gi0/0 1,100,150
Gi0/1 1,100,150
Switch#

-David

[Jon Marshall]

Hi David 

Thanks for doing that, good to know what actually happens. 

Jon

[vv0bbLeS]

@David Ruess thanks so much for labbing that up! And excellent point about Spanning Tree - I completely forgot to include that in my thinking. That is definitely a reason to have the vlan exist on the switch, so Spanning Tree can include that VLAN in its calculations and allow it through the switch.

@Jon Marshall that is also a great point that when the packet comes into the switch the ethernet header would be removed, so while the packet is "in" the switch without an ethernet header it needs to be assigned to a VLAN, so you need that respective VLAN to exist on the switch so the packet can be assigned to that VLAN.

Anyway, thank you all again for the help and answers!

[paul driver]

Hello

if you don’t have a end host in that vlan  on the switch then that vlan does NOT need to reside on the switch