Why does CDP keep working if I don't allow the native VLAN across a trunk?

[DaniloB]

Hi all,

note that this is not a real life scenario, I'm just tinkering with my home lab.

SWA_C2950_24P#show interfaces trunk

Port Mode Encapsulation Status Native vlan
Fa0/11 on 802.1q trunking 1
Fa0/12 on 802.1q trunking 1
Fa0/21 on 802.1q trunking 1
Fa0/22 on 802.1q trunking 1

Port Vlans allowed on trunk
Fa0/11 10,20,30
Fa0/12 10,20,30
Fa0/21 10,20,30
Fa0/22 10,20,30

Port Vlans allowed and active in management domain
Fa0/11 10,20,30
Fa0/12 10,20,30
Fa0/21 10,20,30
Fa0/22 10,20,30

Port Vlans in spanning tree forwarding state and not pruned
Fa0/11 10,20,30
Fa0/12 10,20,30
Fa0/21 10,20,30
Fa0/22 10,20,30

SWA_C2950_24P#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone

Device ID Local Intrfce Holdtme Capability Platform Port ID
SWC_C3550_24P Fas 0/21 169 S I WS-C3550-2Fas 0/21
SWC_C3550_24P Fas 0/22 169 S I WS-C3550-2Fas 0/22
SWB_C2950_48P Fas 0/12 179 S I WS-C2950G-Fas 0/22
SWB_C2950_48P Fas 0/11 179 S I WS-C2950G-Fas 0/21

Question is, how does CDP keep collecting infos from the peers? Isn't CDP supposed to use the native VLAN?

[Joseph W. Doherty]

If I remember correctly, CDP is always sent untagged, and isn't really considered part of the untagged (native) VLAN, as it's a Cisco proprietary communication between Cisco devices. For example, the receiving Cisco device doesn't forward the received CDP frame to all its other same "native" VLAN ports, as it would for all other "normal" "native" VLAN frames. It instead generates its own CDP frame, and sends it out on all its other ports, which has CDP enabled, even non-trunk access ports.

[DaniloB]

Oh. Well, that makes sense. I'm studying for the CCNP SWITCH exam and all Q&A tests give much emphasis on how neighboring devices can't talk anymore via CDP [or VTP] if the native VLAN is not allowed on the trunk. Look at this one:

https://ciscoexam.online/CCNP/300-115/1488

Here the accepted correct answer is "The native VLAN is not present on the trunk."

However, my tests show that both CDP and VTP keep working as usual even if I don't allow the native VLAN through the trunk. CDP information is still received and VLANs are still propagated to VTP clients.

Actually I haven't found any mention of this behavior on my study material, it's just that pretty much any tests collection you may find around will always tell you that both CDP and VTP rely on the native VLAN to operate properly. It looks like this isn't really the case though.

[Georg Pauwen · Accepted solution]

Hello,

Even if you don't specifically allow Vlan 1 on the trunk, it is still passing through the trunk. You cannot remove it from the trunk.

[DaniloB]

After a few more digging I came up with this out of the official cert guide for the Switch exam:

"Although maintenance protocols such as Cisco Discovery Protocol (CDP), Port Aggregation Protocol (PAgP), and Dynamic Trunking Protocol (DTP) normally are carried over the native VLAN of a trunk, they will not be affected if the native VLAN is removed or manually pruned from the trunk. They still will be sent and received on the native VLAN as a special case even if the native VLAN ID is not in the list of allowed VLANs."

I guess I wasn't paying enough attention the first time I read the chapter.

[Joseph W. Doherty]

Yea, and notice it says CDP, and the noted others, are sent on the native VLAN, not VLAN 1. It says, these maintenance protocols are sent even if the native VLAN is "removed".

Again, these protocols are always being sent untagged, which is what we consider a "native" VLAN on a trunk, but, again, these frames are not really part of any VLAN.

What's a bit confusing, for security purposes, you want to get "normal" traffic off VLAN 1 (or the native VLAN), this so "VLAN 1" (or the native VLAN) doesn't mix these frames with user/data frames.

[Joseph W. Doherty]

Georg, from the documentation quote OP posted, it might be more accurate to say CDP is always sent untagged, and so will "look" like a native VLAN frame, i.e. which may not be VLAN 1.