An airport authority must inventory mixed-vendor cameras on access ports and wants standards-based neighbor discovery rather than a Cisco-only protocol. Which approach fits?
Select an answer to reveal the explanation.
Short Explanation
Mixed-vendor gear is a multilingual lobby—Cisco-only CDP is one dialect. LLDP is the common language on the doorplate. Turn it on at the access edge when cameras and other non-Cisco gear must announce who they are.
Full Explanation
LLDP (IEEE 802.1AB) is the standards-based neighbor discovery protocol and works across vendors that implement it. For an airport authority inventorying mixed-vendor cameras on access ports, enabling LLDP lets non-Cisco endpoints advertise identity and capability TLVs without depending on a proprietary dialect. Keep CDP where Cisco-centric visibility still helps, but prefer LLDP when the explicit requirement is multi-vendor, standards-based discovery at the access edge.
Relying only on CDP fails because many camera vendors do not implement Cisco Discovery Protocol; a Cisco-only protocol cannot inventory devices that never speak it. Disabling all discovery protocols and mapping cameras solely from DHCP leases yields addresses and maybe hostnames, not Layer-2 adjacency, chassis ID, or capability TLVs that LLDP/CDP provide on the wire. Using UDLD aggressive mode as a substitute for neighbor inventory confuses link-integrity detection with discovery—UDLD does not replace inventory TLVs.
Exam caveat: LLDP and CDP can coexist; disabling one globally is rarely required, and MED extensions are useful for phones and APs but are not mandatory for basic camera identity. Operational check: enable LLDP on access ports facing cameras, confirm show lldp neighbors (or equivalent) lists camera chassis and port IDs, spot-check that CDP-only views miss non-Cisco endpoints, and feed LLDP data into the airport’s inventory workflow.