1 Cisco Discovery Protocol and Link Layer Discovery Protocol

In a perfect world, all networks would be perfectly documented, with up-to-date network diagrams and other documents detailing the routers, switches, firewalls, and other devices that make up the network infrastructure, how they are connected, their IP addresses, etc. In reality, that’s often not the case: people cut corners, changes go undocumented, or perhaps the network was never properly documented in the first place.

In either case, the result is often that the network documentation doesn’t accurately reflect the current state of the network; this is not an ideal state of affairs. Fortunately, Layer 2 discovery protocols—the topic of this chapter—can help you remedy this situation. Layer 2 discovery protocols, such as Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP), enable devices to share information about themselves with their directly connected neighbors. Using this information, you can map out the network by identifying the devices in the network, their hardware models, how they are connected to each other, their IP addresses, and other information.

Layer 2 discovery protocols are CCNA exam topic 2.3: Configure and verify Layer 2 discovery protocols (Cisco Discovery Protocol and LLDP). This is one of the more straightforward CCNA exam topics. In this chapter, we will primarily examine some show commands that allow you to view the information that devices share with CDP/LLDP, as well as some basic configuration commands to enable, disable, and fine-tune the protocols.

1.1 Cisco Discovery Protocol

CDP is a Cisco-proprietary Layer 2 discovery protocol that runs on Cisco network devices such as routers and switches. CDP is enabled by default; unless you want to modify the default settings, you don’t need to do any configuration to use CDP in your network. Using CDP, devices periodically send advertisement messages out of their interfaces, informing directly connected neighbors about various aspects of the local device. They also listen for similar advertisements from those same neighbors. Figure 1.1 illustrates this: R1 and SW1 exchange CDP advertisements with each other.

CDP messages are sent to the multicast MAC address 0100.0ccc.cccc. However, when a switch receives a CDP message, it does not flood the message like it would with regular multicast frames; the switch receives the frame for itself. Using figure 1.1’s example, SW1 will receive R1’s CDP message and add R1 to its CDP neighbor table.

1.1.1 Viewing CDP neighbors

When using CDP, the show command you are most likely to use is show cdp neighbors; this command lists basic information about each of the device’s CDP neighbors—devices from which it has received CDP messages. In the following example, I use the command on R1:

After a legend listing the different codes that can appear in the Capability column, there is a table listing the device’s CDP neighbors—neighbors from which the device has received CDP messages. The Device ID column lists the hostname of each neighbor; in our example, R1 has one neighbor: SW1.

The Local Intrfce column lists the interface on the local device that the neighbor is connected to. The value of Gig 0/0 in this column means that SW1 is connected to R1 G0/0. Don’t confuse this with the final column, Port ID, which lists the interface of the neighboring device. The value of Gig 0/1 here means that R1 is connected to SW1 G0/1.

The third column is Holdtme, which states the current holdtime—how long until R1 will remove SW1’s entry from the neighbor table. The default timer is 180 seconds; each time the device receives a CDP advertisement from the neighbor, this time is reset to 180 and starts counting down. The value of 158 in this column means that 22 seconds have elapsed since R1 received a CDP message from SW1. If this counts down to 0, R1 will remove SW1’s entry from the CDP neighbor table. We’ll cover this timer more in the next section.

The fourth column is Capability, which identifies the type of device. S means Switch, as indicated in the Capability Codes at the top of the output; SW1 is a switch. However, it also has the R code (for Router), because it has some Layer 3 capabilities, and I (for IGMP), meaning it supports the Internet Group Management Protocol—a topic beyond the scope of the CCNA exam.

The next column is Platform, which indicates the hardware model of the neighbor. WS-C2960C is a model in the Catalyst 2960 series of switches, which is no longer being manufactured (but is a great option if you want a switch for a home lab at a low price).

However, the output of show cdp neighbors lists only a fraction of the information learned from the neighbor. To view even more information about each neighbor, you can use show cdp neighbors detail. In the following example, I show the output of the command and highlight the same information we saw previously in show cdp neighbors. Take a look through the rest of the output to get an idea of what information is conveyed, but focus on the main information shown at the top of the output:

1.1.2 Mapping a network with CDP

As an exercise in reading the CDP neighbor table, let’s practice mapping a network using CDP. This is not just an arbitrary exercise—you may have to do this in the real world at some point. Imagine that you have entered a networking role at an organization with less-than-ideal documentation. Although you don’t have physical access to the devices, you have remote access to the CLI of several devices via Secure Shell—the topic of chapter 5. However, you don’t have access to an up-to-date network diagram. Your task is to fix that, and CDP is a great tool for doing so.

The following five examples show the output of show cdp neighbors on five devices. Grab a pen or pencil, and try to draw out the network using the information in the Local Intrfce and Port ID columns of this output:

Figure 1.2 shows the network diagram. Don’t worry if the arrangement of the devices in the network you drew is different (i.e., R1 on the right instead of the left); it’s how the devices are connected that matters.

1.1.3 Configuring and verifying CDP

As mentioned previously, CDP is enabled by default. You can confirm that CDP is enabled on the device with show cdp. If it is enabled, you will see output like in the following example:

In addition to confirming that CDP is enabled on the device, the output gives us three pieces of information. The line Sending CDP packets every 60 seconds shows the CDP advertisement timer—how often the device sends CDP messages out of each interface—which is 60 seconds by default.

The second line, Sending a holdtime value of 180 seconds, indicates the holdtime, which is 180 seconds by default. The CDP holdtime determines how long the neighbor will keep this device (R1) in its CDP neighbor table after ceasing to receive CDP messages from this device. A value of 180 seconds means that R1 is telling SW1, “If you don’t get a CDP message from me for 3 minutes, remove me from your neighbor table.”

The final line, Sending CDPv2 advertisements is enabled, indicates that R1 is sending CDP version 2 messages. The differences between CDPv1 and CDPv2 are outside of the scope of the CCNA exam, and unless the neighboring device is very old and only supports version 1, you can leave version 2 enabled. Although there is usually no reason to change the advertisement timer, holdtime, and version, in the following example, I demonstrate the commands to modify them:

If you wish to disable CDP on the device, you can do so with the no cdp run command in global config mode. In the following example, I use the command on R1; notice how the output of show cdp changes:

no cdp run disables CDP globally—on the entire device. However, you can also disable CDP on a per-interface basis with the no cdp enable command. This prevents the specific interface both from sending CDP advertisements and from processing CDP advertisements it receives—it will discard them. In the following example, I reenable CDP on R1, use no cdp enable on one of R1’s interfaces, and confirm with a new command:

To reenable CDP on the interface, use cdp enable. I do so in the following example and then confirm with show cdp interface g0/0 once again; notice how the output of the command changes:

One final CDP show command that can be helpful is show cdp traffic, which displays statistics about how many CDP messages the device has sent and received. The following example shows the output of the command on R1:

In sections 1.1.1 and 1.1.2, we’ve covered plenty of CDP configuration and verification commands. Table 1.1 summarizes the verification (show) commands we covered; make sure you’re familiar with how to read the output of these commands.

Table 1.2 summarizes the configuration commands. In general, CDP is a fairly hands-off protocol; you can leave it at the default settings in most cases. However, I recommend being familiar with the configuration commands we covered for the CCNA exam.

1.2 Link Layer Discovery Protocol

The Link Layer Discovery Protocol (LLDP) was developed by the IEEE as a vendor-neutral equivalent to CDP (and other vendor-proprietary Layer 2 discovery protocols). Defined in IEEE 802.1AB, LLDP serves a similar purpose as CDP, but as an industry standard, it can be freely implemented by any vendor. This includes Cisco; Cisco routers and switches support both CDP and LLDP. Figure 1.3 shows a Cisco router and switch sharing information about themselves using LLDP.

Whereas CDP messages are sent to the multicast MAC address 0100.0ccc.cccc, LLDP messages are sent to the multicast MAC address 0180.c200.000e. However, like a CDP message, when a switch receives an LLDP message, it does not flood the message; the switch receives the frame for itself.

1.2.1 Configuring and verifying LLDP

Although Cisco network devices support LLDP, it is not enabled by default. For that reason, let’s first look at how to configure LLDP before analyzing the information that devices share via LLDP. In the following example, I use show lldp to confirm that LLDP is disabled on R1, enable LLDP with lldp run, and then confirm that it is enabled:

After enabling LLDP, show lldp displays similar information about LLDP as show cdp does about CDP. The default LLDP advertisement timer is 30 seconds—half that of CDP. The default holdtime is also shorter: 120 seconds. As with CDP, this is the holdtime that the local device is telling neighbors to use; R1 is telling its neighbor SW1, “If you don’t get an LLDP message from me for 2 minutes, remove me from your neighbor table.” The commands to modify these timers are similar to CDP’s—just replace cdp with lldp: lldp timer seconds and lldp holdtime seconds.

LLDP has one additional timer shown in the previous output: the reinitialization delay, which is 2 seconds by default. This means that after LLDP is activated on an interface, the device will wait 2 seconds before starting to send LLDP messages. This is beneficial in situations where an interface is bouncing (alternating) between up and down states due to an unstable connection or other problem. This delay provides time for the port to stabilize before sending LLDP messages. You can configure this timer with lldp reinit seconds, but in most cases, the default is fine.

Like CDP, you can also enable/disable LLDP on a per-interface basis. However, there is a major difference: whereas CDP uses only one command ([no] cdp enable), LLDP uses two commands: [no] lldp transmit and [no] lldp receive. This allows you to control the transmission and reception of LLDP messages separately. For example, an interface with transmission enabled but reception disabled will send LLDP messages but will discard any LLDP messages it receives. Likewise, an interface with transmission disabled but reception enabled will not send LLDP messages but will process any LLDP messages it receives and update the LLDP neighbor table as appropriate.

LLDP’s equivalent to show cdp interface is show lldp interface. In the following example, I use the command to view the status of R1 G0/0. If LLDP is globally enabled, LLDP transmission and reception will be enabled on all interfaces by default. If needed, you can then disable them on an interface with no lldp transmit and/or no lldp receive:

The final LLDP verification command we’ll look at in this section is show lldp traffic, which is equivalent to show cdp traffic. It can be handy when troubleshooting to verify whether the device is actually sending and receiving LLDP messages. The following example shows the output of this command:

1.2.2 Viewing LLDP neighbors

Now that we’ve enabled LLDP and checked out some of its settings, here’s the most important part: the LLDP neighbor table. The commands are the same as in CDP, replacing cdp with lldp. The following example shows the output of show lldp neighbors on R1:

The top of the output shows a legend of the different codes that can be used in the Capability column. The codes B,R in SW1’s entry indicate that it has both routing and switching capabilities—B for Bridge is equivalent to CDP’s S for Switch. The Local Intf and Port ID columns are the same as in show cdp neighbors; this output means that R1’s G0/0 interface is connected to SW1’s G0/1.

You can view more detailed information about all LLDP neighbors with show lldp neighbors detail. The following example shows the output of that command on R1, highlighting the same information we saw in the previous example. This command shows plenty of additional information, not all of it relevant to the CCNA exam; just make sure you can identify the highlighted information:

Table 1.3 summarizes the LLDP show commands we covered in this section. Make sure you can interpret the output of these commands for the CCNA exam.

Table 1.4 summarizes the LLDP configuration commands we covered. In most cases, enabling LLDP with lldp run is sufficient, but there are cases in which you might want to fine-tune LLDP with the other commands.

Summary