CDP - Cisco discovery protocol...

 

A protocol that runs on Layer 2 which means it doesn't give a damn which layer 3 protocol is running on the interface! The basic concept from our point of view with CDP is that it can obtain information related to device name, interface, management IP and more!

 

A tiny bit of theory that isn't really required for the CCNP level is what CDP runs on. Medias must support Subnetwork access protocol (SNAP). Essentially this is a frame format which follows the common 802.3 ethernet frame and adds a header (with some new fields) which provides some information regarding what type of information is in our next header (similar to the old Ethernet frame format with the EtherType). The LLC header in our 802.3 frame would have 2 fields (DSAP and SSAP which are normally the same value, 0xAA in hex meaning a SNAP header will follow the LLC header in our frame.

 

In the SNAP header below, we have 2 fields: OUI (Organizational Code) which indicate a registered hex value for Cisco (0 x 00 00 0C) and the PID Protocol ID which in our case will be CDP (0 x 20 00):

 

SMXLL

 Also, notice that we have a MAC multicast address to a well known address not only for CDP but other cisco protocols such as VTP,DTP etc..

 

If we move more over to the CDP message itself, take a look at a capture below:

 

SLXLM

 We can see information that can be advertised via CDP such as:

 

Version, TTL (aka holdtime), the name of the device, VTP domain and more! A key thing with CDP is that it isn't a 2 way communication. Devices that originate CDP advertisements will just send them and have a care in the world what happens after that!

 

This CDP advertisement was sent from R2 to R1 so lets have a look what we can find in R1's CDP neighbor table by using the show cdp neighbors command.

 

SMXLL

 Without any topology map or someone telling us, we can now conclude that on R1, we have a device called 'R2' which sent out a CDP advertisement that we received from our Fa0/0. The problem is that a switch could actually be between our routers so we can't fully depend on CDP and come to a conclusion that we our Fa0/0 is directly connected to R1's F0/0.

 

Now for some more theory before tweaking! CDP by default is enabled on cisco devices and has a few default parameters such as:

 

Advertisement is every 60s

Hold timer is 180s

By default, v2 advertisements are enabled (v1 pretty much doesn't send VTP management domain)

and finally by default, CDP is enabled globally and on every interface

 

So these are pretty much the only tweaks we can do with CDP. We can change the advertisement/hold timers, change the version of CDP we advertise and disable it globally (or per interface)

 

Globally enabling/disabling:

cdp run

no cdp run

 

Interface level:

cdp enable

no cdp enable

 

Changing the timers in global config:

cdp timer 20

cdp holdtime 60

 

Advertise v2 / don't

cdp advertise-v2

no cdp advertise-v2

 

Another option we can configure with CDP is to alert us if CDP detects a duplex mismatch (since the duplex parameter of the interface is sent in the CDP message)

 

SMLXL

 We can enable this logging in global config by:

cdp log mismatch duplex

 

The concern with CDP is that people find it shares too much information in the message so they either: globally disable it or disable it on specific interfaces such as edge ports, ports facing ISP router/internet etc.. This is because a bit of information that people can obtain can easily do a few searches for vulnerabilities for a specific IOS version etc..

 

You can also perform CDP spoofing to the multicast address with different values in each message and pretty much 'overflow' the CDP table with hundreds of CDP entries, a tool is included in the Kali linux distribution to generate CDP messages as well as others such as BPDUs and more!

 

Here is a youtube video that substitutes this post... Excuse my explanation on SNAP during the video, I was a bit over the place!