cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
524
Views
0
Helpful
3
Replies

Unique Native VLAN for Each Trunk

CiscoNutt
Level 1
Level 1

I was wondering if there is are any arguments for or against configuring a different native VLAN on each trunk instead of having just a single native VLAN which is configured and not used anywhere else in the network?  i would think this would be a massive waste of VLANs.  I had a discussion with someone that this method prevents VLAN hopping better than konfiguring the same native VLAN everywhere.

Would like to get some other perspectives on this.

Thanks in advance.          

3 Replies 3

daniel.dib
Level 7
Level 7

That sounds like overkill to me. I think it's enough have one dummy VLAN used as native VLAN for protective measures. It's also possible to tag the native VLAN as well.

I usually have a dummy VLAN for native and a parking VLAN for unused ports and also make sure those ports are shutdown.

Daniel Dib
CCIE #37149

Daniel Dib
CCIE #37149
CCDE #20160011

Please rate helpful posts.

Yes that is what I normally do also.  But according to the person I had the discussion with, there was study conducted and the result of that study indicated that if a VLAN was used for native VLAN on more than one trunk on the same switch, then a certain attack could be used for VLAN hopping.  I have yet to find any info on this study so I am still a bit sceptic.  Before this discussion I though tagging the native vlan was enough, but according to this guy it is not.

Will let you know if I find anything on the study.

VLAN hopping is only possible if the attacker can form a trunk with the switch. This is possible if you leave your ports as switchport mode dynamic desirable. If you hardcode them to access then there is no issue with VLAN hopping.

VLAN hopping also only works in one direction from the attacker to the victim. This is bad enough but bidirectional traffic is not possible. VLAN hopping is kind of an overexaggerated risk and quite easy to protect against if you deploy the correct configuration.

Daniel Dib
CCIE #37149

Daniel Dib
CCIE #37149
CCDE #20160011

Please rate helpful posts.