Using 802.1q trunks between switches is simple but not obvious. If ISL trunks encapsulate all data, 802.1q trunks allows traffic to flow untagged for a specific VLAN: the native one. There are many questions about native VLAN:
- Which type of traffic always use native VLAN?
- Is there any special traffic which uses a special VLAN?
- Is removing VLANs safe?
- What happen if native VLAN is tagged?
Tests has been made using both ISL and 802.1q trunks. 802.1q has been configured tagging and untagging native vlan. CDP, DTP, UDLD, VTP and ICMP traffic have been analyzed through ISL, 802.1q with tagged native and 802.1 with untagged native.
The following lab has been used to analyze traffic between two switches:
SPAN ports have been configured using the “replicate” options.
Few tests have been made to identify if any special protocol exists (all traffic was tagged):
- CDP and VTP always use VLAN1;
- DTP and UDLD always use native VLAN;
- PVST and RAPID PVST use all VLANs: both PVST and RAPID PVST send a 802.1d compatible BPDU through the native VLAN;
- MST uses native VLAN;
- data (ICMP) is sent using native VLAN or tagged VLAN, depending by the source/destination VLAN (of course).
The most important questions is now: what happen if VLAN1 or native VLAN is removed from the trunk? After removing both native VLAN and VLAN1, seems that switches manage special protocols before VLAN filter:
- CDP, VTP, DTP and UDLD work even if native VLAN or VLAN1 are removed from the trunk: it’s supposed that VLAN filtering happens after CDP/VTP/UDLD/DTP processing;
- 802.1d compatibility BPDU is not sent if native VLAN is removed from the trunk;
- MST BPDUs are sent using native VLAN, even if it’s removed from the trunk.
Previous tests has been executed using ISL trunks or 802.1q trunks with native VLAN tagged:
vlan dot1q tag native
Traffic has been always tagged, even if native VLAN has been used.
The following tests have been executed with native VLAN untagged:
- traffic sourced by SW1 showed as tagged from SW1’s SPAN port;
- traffic sourced by SW1 showed as untagged from SW2’s SPAN port;
- traffic sourced by SW2 showed as tagged from SW2’s SPAN port;
- traffic sourced by SW2 showed as untagged from SW1’s SPAN port.
Another lab has been prepared to analyze that behavior:
Because an hub is a L1 device, it is more accurate than a SPAN port. Latest tests have been repeated, and native traffic always flows untagged.
Cisco reports the following:
For local SPAN, outgoing packets through the SPAN destination port carry the original encapsulation headers—untagged or IEEE 802.1Q—if the encapsulation replicate keywords are specified. If the keywords are not specified, the packets are sent in native form. For RSPAN destination ports, outgoing packets are not tagged.
By the way using a “replicate” SPAN port, the native self-sourced traffic redirected to the SPAN port has been altered adding a 802.1q tag. Received traffic has not been altered. Newest IOSes have not been tested, maybe that behavior depends by a bug already solved.