@RedNectar Great question. Couple reasons.
- 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.
- 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.)
- 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.
