CCNA v2.0: CDP, LLDP, and Network Documentation

Cisco has already announced the next version of the CCNA exam, but the timing matters. As of October 2026, the current 200-301 exam is still v1.1 and remains available through February 2, 2027. Version 2.0 begins testing on February 3, 2027. One of the clearest additions in the new blueprint is the requirement to validate the accuracy of network documentation by using Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP).

That wording changes the level of thinking expected from a candidate. It is not enough to recognize that CDP is Cisco-specific and LLDP is standards-based, or to memorize a command that displays neighbors. The useful skill is comparing what the network says about itself with what the diagram, inventory, port record, or implementation plan claims should be true. In other words, discovery output becomes evidence.

This is a practical direction for the CCNA because documentation is rarely perfect for long. Switches are replaced, uplinks move, access points are relocated, interface descriptions drift, and temporary changes become permanent. A network engineer who can reconcile live neighbor information with a documented topology is better prepared to troubleshoot the environment than someone who treats documentation and device output as separate study topics.

Documentation validation is an evidence problem

A topology diagram is a model of the network, not the network itself. The first question should therefore be: what assertions does the documentation make that can be tested? A diagram may claim that Switch-A connects from a particular local interface to a specific interface on Switch-B. An inventory may claim that a device with a particular hostname and management address occupies a given rack. A handoff document may list the intended upstream neighbor for an access switch. Each of those statements can be compared with live discovery information.

The most valuable habit is to separate confirmed facts from assumptions. If a diagram says a switch uplinks to a distribution device and CDP or LLDP shows that same neighbor on the expected interface, that part of the documentation gains confidence. If the remote port differs, the mismatch is not automatically a fault; it is a signal to investigate whether the cabling changed, the drawing is stale, a port-channel member was moved, or the interface record was entered incorrectly.

This is why the new objective fits naturally within Cisco certifications rather than being a trivia addition. Discovery protocols give an engineer a quick, local way to interrogate Layer 2 adjacency. Documentation gives the expected state. The engineering task is to reconcile the two without jumping to conclusions.

CDP and LLDP expose the local neighborhood from different standards positions

CDP is a Cisco protocol used by Cisco devices to advertise information about themselves to directly connected neighbors. LLDP is based on IEEE 802.1AB and provides a vendor-neutral mechanism for neighboring devices to exchange identity and interface information. Many Cisco platforms can participate in both, which makes the protocols especially useful in mixed environments.

Depending on platform, software, and configuration, discovery information can include a device identifier, the local interface, the neighbor’s port identifier, device capabilities, platform information, and a management address. The exact fields matter less than the reasoning pattern: identify the neighbor, identify the two ends of the link, determine what the neighbor claims to be, and compare those facts with the expected topology.

The protocols are local in scope. They help establish directly connected relationships; they do not replace routing tables, MAC address tables, controller data, configuration management, or an asset inventory. If a candidate tries to turn CDP or LLDP into a complete network-management system, the interpretation has gone too far. Their strength is fast adjacency evidence that can be combined with other sources.

Start with a small set of documentation claims

Validation is easier when the document is broken into testable claims. For a switch-to-switch link, the claims might be that the two device names are correct, the physical interfaces match, the device roles are plausible, and the management identity belongs to the expected asset. For an access point or IP phone, the relevant claim may simply be that the endpoint is attached to the documented edge switch and port.

A good comparison does not demand that every label be identical. Real organizations use naming conventions that evolve. A documentation system may store a fully qualified domain name while discovery output shows a short hostname. An asset system may refer to a chassis by serial number while the neighbor protocol identifies the operating system hostname. Candidates should learn to decide whether two pieces of evidence refer to the same device rather than assuming that cosmetic differences prove an error.

Interface mapping deserves similar care. The local device knows which of its ports received the advertisement, while the neighbor advertises its own port identifier. That pairing is often enough to confirm or challenge a cable map. When the pair does not match the drawing, the next step is to collect more evidence, not immediately change the network to match the document.

Mismatches usually point to change, not mystery

Consider a diagram showing an access switch connected to Distribution-1, while discovery output identifies Distribution-2. Several explanations are possible: a resilience change moved the uplink, the original distribution device failed and was replaced, the cable was repatched during maintenance, or the diagram simply predates the current topology. The useful response is to verify current operational state and then decide which artifact is wrong.

A remote-port mismatch is equally instructive. If the documented remote port is TenGigabitEthernet1/1 but discovery shows another port, the network may still be healthy. Check whether the link is part of an EtherChannel, whether the remote chassis changed, whether an intermediate device was introduced, and whether interface descriptions or inventory records support the new relationship.

These examples make the objective more than a command-output exercise. It tests whether a candidate can reason from observed evidence. That aligns with the broader direction of the Cisco tracks, where operational validation and troubleshooting increasingly matter alongside configuration knowledge.

Mixed-vendor networks make LLDP especially important

CDP can be extremely convenient inside a Cisco-heavy environment, but documentation rarely stops at a single vendor boundary. Servers, hypervisors, storage systems, IP phones, wireless infrastructure, firewalls, and third-party switches may participate in the same physical topology. LLDP gives operators a common discovery mechanism across many of those systems.

That does not mean LLDP always produces richer or more trustworthy information than CDP. The useful question is which protocol is supported, enabled, and appropriate on the two endpoints. In some locations both may be enabled; in others policy may permit only one. Candidates should be able to interpret the evidence that exists rather than assume every link must advertise the same fields.

A mixed environment also illustrates why documentation should record relationships, not merely vendor-specific command output. A durable network record should capture the device, interface, role, and expected connection. CDP and LLDP then become independent ways to validate those relationships instead of becoming the documentation themselves.

Discovery creates useful visibility and a security trade-off

Neighbor discovery is valuable precisely because devices reveal information about themselves. That visibility can also expose details that an organization does not want advertised on every interface. Device names, platform information, management addresses, and topology clues can help an administrator, but they can also help an unauthorized observer who has access to the local segment.

The correct lesson is not to disable discovery everywhere. Operators need to balance operational value against exposure. Infrastructure links and managed access layers may benefit from discovery because it accelerates inventory, troubleshooting, and voice or endpoint integration. Interfaces facing untrusted or unnecessary segments may have a weaker reason to advertise. Policy, platform capabilities, automation, and support requirements should determine the choice.

This trade-off is a good CCNA-level example of why a feature cannot be evaluated in isolation. The operational team may want maximum visibility; the security team may want minimum information disclosure. A mature design decides where discovery is useful, limits it where it is not, and documents the decision so that absence of neighbor information is not mistaken for a fault.

Validate the network in both directions

A single neighbor entry can confirm a local observation, but stronger validation comes from checking the relationship from both sides when possible. If Switch-A reports Switch-B on one interface, Switch-B should normally provide compatible evidence for the reverse relationship. The two devices may format names differently, but the physical and logical story should make sense.

Bidirectional verification helps expose documentation errors and operational problems. A one-sided observation may indicate that the protocol is disabled in one direction, filtered by interface configuration, unsupported on the neighbor, or simply not being interpreted correctly. It may also reveal that the engineer is looking at the wrong interface or device. The point is not to force symmetry; it is to explain the evidence.

This habit transfers well beyond discovery protocols. Good network troubleshooting continually compares independent sources: interface state, forwarding tables, neighbor relationships, routing information, logs, controller telemetry, and the expected design. CDP and LLDP are simply two accessible sources for the Layer 2 neighborhood.

Practice with a diagram, an inventory, and imperfect output

The strongest preparation for this objective is not a list of protocol facts. Start with a small topology that includes device names, interface labels, roles, and management addresses. Then compare it with representative CDP and LLDP neighbor output. Introduce realistic discrepancies: a renamed switch, a moved uplink, a wrong remote port, an unexpected third-party device, or an interface on which discovery has been intentionally disabled.

For each discrepancy, state what is known, what remains uncertain, and which additional evidence would settle the question. That forces the candidate to treat neighbor information as part of an investigation rather than as a magic answer. It also reduces the common mistake of assuming the document is correct merely because it is written down.

Anyone studying before the February 2027 change should keep the version distinction visible in the study plan. The existing v1.1 exam remains the target until its final testing date; the documentation-validation objective belongs to v2.0. Once v2.0 becomes active, candidates should be prepared to use CDP and LLDP as tools for proving whether the recorded topology reflects the network that is actually running.