Tagging

[parthrawat979]

I read that CDP, VTP, and PAgP updates are always forwarded on trunks with a VLAN 1 tag. 
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/24330-185.html
But what I saw in the capture that these updates(I just checked cdp yet) goes without any tag.
It also says that On an 802.1Q trunk, DTP packets are sent on the native VLAN
But in the capture the I saw just reverse the DTP packet sent with a dot1q tag of the native vlan??

[Richard Burts]

You do not give us much detail to work with. So my first question is that the link you provide is for 6500 switches. Is your issue on a 6500 switch? If not, then what model of switch is it? And what version of code is it running? And is the interface on this switch a trunk? or an access port?

[parthrawat979]

I am using iol on eve. The interface is trunk. And I even changed the native vlan from default.

[Richard Burts]

I will repeat my first question "the link you provide is for 6500 switches. Is your issue on a 6500 switch?"

Then I will add an observation: when using an emulator and not real hardware, then behaviors that do not match the standard can be expected. Perhaps this is one of those.

[Martin L]

Yes, it is confusing but first of all, this document is old and written when Cisco ISL was being used. Hence, your line "CDP, VTP, and PAgP updates are always forwarded on trunks with a VLAN 1 tag" could refer to ISL which tags all frames;  Unlike 802.1Q's native VLAN concept, ISL tagged every frame, including native VLAN traffic, adding overhead but simplifying trunk configuration . Note: you could force to tag vlan 1 and move "native vlan" to other number. 

Alternative explanation is that "tag" does not mean actually "tagging" vlan but rather "classification  or "identification" or "marking" of vlan.  Plus, switches do "marked" vlans internally before frames they leave on cables.

So, 802.1Q trunk carry all control traffic (CDP, VTP, and PAgP, DTP) on vlan 1 which happens to be Native Vlan by default.  In other words, the native VLAN is the untagged VLAN on an 802.1Q trunk. 

Note that later in document it says "With the use of dot1q (802.1Q) encapsulation, these control frames are tagged with VLAN 1 if the switch native VLAN is changed. If dot1q trunking to a router and the native VLAN is changed on the switch, a subinterface in VLAN 1 is necessary in order to receive the tagged CDP frames and provide the CDP neighbor visibility on the router."

Regards, ML
**Have fun labbing!!!***
***Please Rate All Helpful Responses ***

[Cristian Matei]

Hi,

    In order for it to make sense, you have to first ask yourself. Which control-plane protocols have any kind of dependency with the concept of a VLAN?

1. ARP is one protocol that has VLAN dependency. As ARP packet travels from one switch to another, you want the receiving switch to associate that ARP request packet with a specific VLAN, so that it known in which ports is allowed to forward it; thus ARP packets will be either untagged (if traveling across access ports), either untagged (if travelling across trunk ports but packet belongs to the native vlan), either tagged (if travelling across trunk ports but packet does not belong to the native vlan).

2. STP, if running 802.1d or 802.1w, as Cisco runs one STP instance for each VLAN, result being the STP port role and state is per VLAN, thus there needs to be STP packets being sent for each VLAN and the receiving switch needs to associate each of the received BPDU's with the correct VLAN, based on STP packets being untagged or tagged with correct tag number; in which case STP packets will either untagged (if traveling across access ports), either untagged (if travelling across trunk ports but packet belongs to the native vlan), either tagged (if travelling across trunk ports but packet does not belong to the native vlan); e.g on a trunk port with VLAN's 1,100,200 allowed and native vlan being 1, STP packets for VLAN 1 will be untagged, STP packets for VLAN's 100 and 200 will be tagged

All other layer 2 control-plane packets are untagged, always, regardless of the port type (access or trunk) and regardless which VLAN's are allowed or not for the trunk type, as these protocols serve functions and scopes that have no dependency with the concept of a VLAN.

Lots of documents make lots of statements. However, reality is that untagged layer 2 packets have nothing to do with native VLAN, as those layer 2 packet are not VLAN dependent, are just being sent over the interface, regardless of what the native VLAN is or if the native VLAN is allowed or not.

Thanks,

Cristian.