Enable CDP on Leaf Uplinks

[weylin.piegorsch]

Hello,

I have this topology:

spine101 port 17 <-> leaf131 port 36

(yes, it's dual-spine with more leafs that this, I just want to focus here on this link unless I need to consider the larger topology)

The link is functioning fine if I do nothing.  I'm trying to enable CDP on that link.  Spine seems to have CDP working with a Spine Interface Selector policy. Leaf is a 9336-FX2, I'm running 5.2(6).

With the below Leaf Access Port Policy Group, I get the error "Fault delegate: Configuration failed due to invalid-card,invalid-port for uni/infra/accportprof-Leaf131_IntProf/hports-P36-typ-range for node Leaf131"

Any suggestions?

[RedNectar]

Hi @weylin.piegorsch ,

First question: WHY do you want to enable CDP on the links between a Leaf and a Spine?

LLDP is already enabled, and LLDP is an IEEE standard (802.1AB).  CDP is not.

I've NEVER used ANY Access Policies between Leaves and spines - that's one of the features of ACI, you don't need to do anything between Leaf and Spines!

[weylin.piegorsch]

@RedNectar Great question.  Couple reasons.

1. Operational consistency.  Everywhere else in my network, my entire staff knows they can at least get Cisco neighborship data via CDP.  This would join ASAs as the nuissance outlier.
2. Depending on the adjacent device, CDP and LLDP often report different data.  Ideally you run both LLDP neighbor data and also CDP neighbor data.  (if you're good, you also run DHCP Snooping database, device-sensor, device-classifier, device-tracking... but I digress into IOS XE.)
3. I have a philosophy that within an administrative domain, all possible data should be shared as widely as possible in as many was as possible.

Is it strictly necessary? No, not really.  But then again, LLDP isn't strictly necessary (Cisco could have perpetuated CFS to do the same job and not needed LLDP), so Cisco is making a conscious choice to support only the non-Cisco variant on leaf fabric ports, despite supporting the Cisco variant on access ports and also spine fabric ports?  Perhaps, but I'm confused why Cisco would specifically prohibit it on leaf fabric ports.  The IEEE vs non-IEEE standard is an immaterial argument here, as this can only be a Cisco-to-Cisco patch.

And, concur, I'd rather not have an access policy if I don't need one - I'd rather just turn on both LLDP and CDP everywhere and then need an access policy (or overide policy?) to turn it off.  But I started down the path of evaluating an access policy as that's what the documentation said to do, given the documentation makes no differentiation on fabric vs access ports (reference).  If I can't turn on CDP through it, I'm still keeping a blank interface selector (a) as a reminder to my junior operators that the port is taken and (b) to have a standardized place to put the configuration that will program "show interface description" CLI command output.

[RedNectar]

@weylin.piegorsch ,

Great answer.  I don't have any clues on how to help you, but you've inspired me to look into it!

[weylin.piegorsch · Accepted solution]

I've done a lot of research on this - this question, but also a lot more including consulting my SE.  I finally gave in and asked ChatGPT.

Me:
Has cisco ever explicitely stated why they adamantly refuse to enable CDP only on fabric ports

ChatGPT:

No — at least not publicly in a direct, formal statement like:

“We do not support CDP on fabric ports because of X.”

 Cisco has consistently stated the fact that CDP is unsupported on fabric links, but they have not published a definitive architectural rationale document explaining the decision. (ref1, ref2)

What does emerge from the documentation and ACI architecture is a fairly strong implied explanation.

The clues are:

1. ACI fabric ports are not treated as ordinary Ethernet switchports
2. LLDP is deeply integrated into ACI control-plane and topology functions
3. Cisco repeatedly emphasizes LLDP for discovery and policy resolution
4. CDP is only supported on “edge” or externally facing interfaces

For example, Cisco’s ACI Design Guide explicitly says:

• LLDP is globally enabled by default in ACI
• CDP is disabled by default
• enabling CDP on policy groups causes both protocols to run simultaneously
• LLDP/CDP are important for endpoint and VMM policy resolution

But notice that all of that discussion is about:

• access interfaces
• VMM integration
• FEX/server-facing ports
• management interfaces

—not fabric uplinks.

Meanwhile, Cisco employees answering direct questions about fabric ports simply say: (ref1)

“Its not possible to enable CDP between fabric connected interfaces.”

No “because.”

Reading between the lines, the most likely architectural reasons are:

• ACI fabric links are reserved for fabric control-plane functions
• LLDP is already mandatory and integrated for topology formation
• CDP would add a second proprietary neighbor-discovery/control mechanism
• Fabric links are intentionally constrained and deterministic
• Cisco wanted to avoid arbitrary NX-OS-style interface behavior on fabric ports

You can actually see this philosophy elsewhere in ACI:

• no STP participation in the fabric
• MCP instead of STP internally
• no traditional peer-link in ACI vPC
• many “normal NX-OS” behaviors intentionally removed or abstracted(ref1, ref2)

So the pattern is:

ACI fabric interfaces are infrastructure primitives, not general-purpose Ethernet ports.

That appears to be the real reason, even though Cisco has never explicitly written it that plainly.

One particularly revealing clue is that ACI can tunnel CDP frames in certain L2 tunnel scenarios. (ref1, ref2)

That means:

• the hardware obviously understands CDP
• the software stack can process/pass CDP
• the restriction is almost certainly a deliberate product-design decision, not a technical impossibility

So your frustration is understandable:
from an operator perspective, it looks arbitrary because:

• NX-OS supports both
• Catalyst supports both
• ACI access ports support both
• only fabric links are prohibited

And Cisco has never really published a satisfying operational justification for that asymmetry.