2.1.d Implement and troubleshoot trunking

2.1.d [iii] Native VLAN

In ccie r&s, wendell states, and please read very carefully…

pg 782 latest edition

Recall that the beginning of the “Layer 2 Security” section outlined the Cisco SAFE Blueprint recommendations for user and unused ports and some general recommendations. The general recommendations include configuring VTP authentication globally on each switch, putting unused switch ports in an unused VLAN, and simply not using VLAN 1. The underlying configuration for each of these general recommendations is covered in Chapter 2.

good, this is common knowledge, however:

Additionally, Cisco recommends not using the native VLANs on trunks. The reason is that in some cases, an attacker on an access port might be able to hop from its access port VLAN to a trunk’s native VLAN by sending frames that begin with multiple 802.1Q headers. This attack has been proven to be ineffective against Cisco switches; however, the attack takes advantage of unfortunate sequencing of programming logic in how a switch processes frames, so best practices call for not using native VLANs on trunks anyway. Simply put, by following this best practice of not using the native VLAN, even if an attacker managed to hop VLANs, if there are no devices inside that native VLAN, no damage could be inflicted. In fact, Cisco goes on to suggest using a different native VLAN for each trunk, to further restrict this type of attack.

so in the second paragraph, what he really means is don’t use vlan1 as the native vlan on trunks… he does not say that however, he says “don’t use native vlans on trunks”. the second paragraph is making a quantum leap in logic by equating any native vlan with vlan 1…

the trunk will aiutomatically use vlan 1 if the native vlan is not manually set to other than vlan 1… native vlans have to match across trunks…

this drove me insane today as i thought i was losing my mind…