Tracing Cables with CDP

Information Technology has become such an important part of our lives that not even a single facet of our life has been left untouched by it. The field is so vast and deep that it is not possible for one person to know everything. Every Specialty requires a specialist and some times a single person is expected to know more than one specialties. There are programmers, networkers, database admins, network and information security officers, voice admins, etc who look into managing their respective domain. There is a segment which is oft ignored and assigned to people who are reluctant on taking the responsibility or to unskilled staff. This segment is cable management.

When a new network is provisioned, all the equipments and cables are most likely to be put neatly and this is the easiest part as we can play around with the cables as the network is still down. When the network is functional and grows, since it is a standard these days to provide 99.9% uptime, you just cannot touch the cables for management. Every cable you put is permanent, even the temporary ones you put between racks because you will not be allowed to remove it later on. Eventually the cables become so messed up that you cannot even see the switch chassis. These thick cable mess have even become abode for snakes (green ones) in one of the Data Center I have worked in. Now if we have to troubleshoot the network and it comes down to Layer 1 of the OSI model, the only option is cable tracing. Just how can we trace a cable when we can’t even see the switch chassis? If we pull aside all the bulk of cable to see the chassis and add or remove cable as required, we then must take the responsibility of any network cable inadvertently coming out and causing more outages. If the last part goes well, then comes the tracing over a vast area of a Data Center which could even span floors. There are many times when this is not possible and it is more feasible to lay a new cable.

Depending upon what the Data Center is hosting, there are 2 types of Data Center. The first is an Enterprise data center in which the end hosts are presumed to be static and no cable changes are required during the whole operation. These Data Centers are expected to have neat and clean cabling and they do. The other type of Data Center is what is run by ISPs to host customer servers. In these Data Centers, the cabling needs to be changed every time there is an addition or removal of a customer. This leads to an eventual mess of cables we were talking about. The below snap found over the Internet rightly depict cabling managed properly.Managed Cabling

The following image partially depicts the ground reality of an ISP cabling as still many of the ports are unused. You must use your imagination as to how the cabling will look when all ports are utilized. I wasn’t able to retrieve an actual image of the cabling I described above. You can help me with it by posting it.unmanaged cabling

We will not talk about Cable Management in this post as I do not have enough understanding of it and also because as some people say “Cable management is an art” and I don’t understand this art. In this post, we will discuss how we can trace cable for troubleshooting a network made primarily out of Cisco equipments by using CDP by moving away from the cabling mess at switch side to the server side where there are far less cables.

What is CDP?

The Cisco Discovery Protocol (CDP) is a proprietary Data Link Layer protocol used to share information about other directly connected Cisco equipment, such as operating system version, hostname, every address (i.e. IP address) from all protocol(s) configured on the port where CDP frame is sent, the port identifier from which the announcement was sent, device type and model, duplex setting, VTP domain, native VLAN, power draw (for PoE devices), and other device specific information. Cisco devices send CDP announcements to the multicast destination address 01-00-0c-cc-cc-cc, out each connected network interface. These multicast packets may be received by Cisco switches and other networking devices that support CDP into their connected network interface. By default, CDP announcements are sent every 60 seconds on interfaces that support Subnetwork Access Protocol (SNAP) headers, including Ethernet, Frame Relay and Asynchronous Transfer Mode (ATM). Each Cisco device that supports CDP stores the information received from other devices in a table that can be viewed using the show cdp neighbors command. Given below is the Packet capture of a typical CDP packet.

cdp packet capture

Why CDP?

Throughout the definition and explanation above, it is quite clear that CDP is Cisco proprietary and it is meant for networked Cisco devices and devices that support CDP, so how are we going to utilize it for tracing cable to a host? The answer to it lies in the way CDP works. If we see the definition once again, we will know that CDP packets are sent out all ports which are up regardless of whether a Cisco equipment or a server is connected on the other end. This information can be sniffed by a packet capture on the host by filtering CDP packets. It is not advisable and in some cases possible to run Packet capture on a network for over a minute (this is required because CDP packets are sent every 60 seconds) as it might overwhelm the server due to the bulk of data to be captured and then sifting out CDP packet. The solution for this is using CDPR.


Cisco Discovery Protocol Reporter (CDPR) is a software which will tell you which switch and port your device is plugged into. It is known to compile and run on Solaris, Linux, HP-UX, AIX and Windows (using pcap). In verbose mode, it decodes the entire CDP packet including information such as native VLAN, device capabilities, etc.

Output of CDPRcdpr on windows

Requirement of Using CDPR

The first and only requirement for using CDPR is that the switchport has to be up and this is also the biggest advantage for using it.

Cases in which CDPR can be used

Cables interchanged at server end: These days one server has multiple NIC cards and multiple network cables. Quite a lot of time after routine maintenance, cables are plugged into wrong ports or NIC cards are configured with wrong ip addresses. Using CDPR, you can come to know which switchport a particular cable is connected to and on which switch. Using this information you can login to the relevant switch and verify whether the server side NIC has been configured with the correct ip address and on the correct NIC card.

Wrong VLAN configured on the switch: There are many times when there are configuration error on the switch side and it is assumed that the server side is faulty OR the cable is connected on the wrong port on the switch with a different VLAN. Connectivity can only establish if the cable is connected to a port with correct VLAN so that it can communicate with its subnet and the gateway. Using CDPR, we can come to know which switchport and switch the cable is connected to and whether the interface has proper VLAN configuration.

Wrong ip address: In order to establish Layer 3 connectivity, ip address on the server should be in the same subnet as that of Router/Switch. Using CDPR, the server NIC connecting to the Router/Switch port can be determined and which network equipment it is connecting to. This information can then be utilized to verify that both the ends have ip addresses and in the same subnet.

Obtaining, installing and running CDPR


The Windows Graphical executable can be obtained from here and the Command line executable can be obtained from here. Just run the Windows executable and you should get the relevant details within 2 minutes. The output of this is as shown above. For running through Command Line, go to DOS and go to the location where you have saved the cdpr.exe and type cdpr. Enter the interface number and you should get what switch and switchport you are connected to.

cdpr – Cisco Discovery Protocol Reporter Version 1.0.7
Copyright (c) 2002 –

1. \Device\NPF_{5DF63EFA-1214-47CF-B98E-3E0E595F032E} (Intel(R) 82579LM Gigabit
Network Connection)
2. \Device\NPF_{7F57A97E-116D-428F-BC61-EE5F44DA30BB} (Microsoft)
3. \Device\NPF_{B56EDBCD-3585-46ED-86D2-6806FE520B8B} (Microsoft)
4. \Device\NPF_{9013D957-C09C-412F-91E0-9A3875F0C998} (Microsoft)
Enter the interface number (1-4):1
Using Device: \Device\NPF_{5DF63EFA-1214-47CF-B98E-3E0E595F032E}
Waiting for CDP advertisement
(default config is to transmit CDP packets every 60 seconds)
Device ID
value: Switch
Port ID
value: FastEthernet0/4


For installing on a *nix, follow the procedure mentioned below

sudo apt-get install cdpr

After installation, type the below command to run it and select the Ethernet interface from the list

sudo cdpr

Wait for a minute or so for the output. Given below is the Sample output.

cdpr – Cisco Discovery Protocol Reporter
Version 2.4
Copyright (c) 2002-2010 –

1. eth0 (No description available)
2. nflog (Linux netfilter log (NFLOG) interface)
3. lo (No description available)
Enter the interface number (1-3):1
Using Device: eth0
Waiting for CDP advertisement:
(default config is to transmit CDP packets every 60 seconds)
Device ID
value: Switch
Port ID
value: FastEthernet0/4

I hope my post has been helpful in your life but the only guide which can help you in the hereafter is the Qur’an. You can download the English translation of the Qur’an here.

2 thoughts on “Tracing Cables with CDP

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.