Cisco Discovery Protocol Configuration Guide, Cisco IOS Release 15M&T
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Book Title
Cisco Discovery Protocol Configuration Guide, Cisco IOS Release 15M&T
Secure Cisco Discovery Protocol
View with Adobe Reader on a variety of devices
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
View on Kindle device or Kindle app on multiple devices
Results
Chapter: Secure Cisco Discovery Protocol
Secure Cisco Discovery Protocol
The Cisco Discovery Protocol does not possess inherent security mechanisms and is vulnerable to attacks. The Secure Cisco Discovery Protocol feature allows users to select the type, length, value (TLV) fields that are sent on a particular interface to filter information sent through Cisco Discovery Protocol packets.
- Finding Feature Information
- Feature Information for Secure Cisco Discovery Protocol
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for Secure Cisco Discovery Protocol
The Cisco software image must support basic Cisco Discovery Protocol functions.
Restrictions for Secure Cisco Discovery Protocol
Blocking the type, length, value (TLV) fields on one device can affect the functionality of clients on other devices where Cisco Discovery Protocol packets with blocked TLV fields are received because different clients use different TLV fields.
Information About Secure Cisco Discovery Protocol
Secure Cisco Discovery Protocol
The Cisco Discovery Protocol does not possess inherent security mechanisms and is vulnerable to attacks. The Secure Cisco Discovery Protocol feature provides security by allowing users to select the type, length, value (TLV) fields that are sent on an interface to filter the fields in Cisco Discovery Protocol packets.
This feature supports the following functions:
TLV lists can be configured globally and also at the interface level, but only one TLV fields list can be configured globally.
A TLV list configured on an interface is given a higher precedence.
All TLVs except the Device-ID TLV and the Application TLV can be blocked.
Information about the Cisco Discovery Protocol TLV list configured on an interface is stored in each Cisco Discovery Protocol interface subblock.
All TLVs are blocked on the sending side.
The show cdp tlv-list and show cdp interface commands display information about the TLV list.
Supported Type, Length, Value Fields
Contains a list of device network-layer addresses. If a device uses Simple Network Management Protocol (SNMP), the first address is an address at which the device receives SNMP messages.
The device may advertise all of its addresses and may optionally advertise one or more loopback IP addresses.
Identifies the device type. The device type indicates the functional capability of the device, for example, a switch.
Class of service TLV
Describes the Layer 2 class of service (CoS) value in a Cisco Discovery Protocol packet. All Cisco Discovery Protocol packets received on an untrusted port are marked with a CoS value by a switching device that cannot classify individual packets.
This TLV is used only in a Cisco Discovery Protocol packet that contains an Extended Trust TLV, which indicates the absence of extended trust with a CoS TLV that is one byte in length.
Specifies the default state of the configuration.
Allows devices to recognize if a point-to-point Ethernet interface is running in full-duplex or in half-duplex mode. Network problems are caused if two ends of a link are in different modes.
The TLV value is one byte in length with its least significant bit indicating the mode. A 1 indicates full-duplex and a 0’indicates half-duplex.
Exits current configuration.
External Port Id TLV
Identifies the physical connector port on which a Cisco Discovery Protocol packet is transmitted.
This TLV is used in devices with optical ports in which signals from multiple hardware interfaces are multiplexed through a single physical port.
The value of this TLV must be the same as the MIB object ifName for the ifTable entry for the external port.
Specifies that a particular protocol has asked Cisco Discovery Protocol to piggyback its “hello” messages within transmitted Cisco Discovery Protocol packets.
The value of this TLV protocol is greater than or equal to 5 and lesser than or equal to 32 bytes. The first 5 bytes are the protocol’s 5-byte Subnetwork Access Protocol (SNAP) value, which contains three bytes of organizationally unique identifier (OUI) followed by two bytes of protocol ID.
A Cisco Discovery Protocol packet may contain multiple protocol-hello TLVs, each for a different protocol.
IP Network Prefix TLV
Describes a list of stub network prefixes to which the sending stub device can forward IP packets. These packets are used by On-Demand Routing (ODR).
Each network prefix is formatted as a 4-byte IP address followed by a 1-byte network mask length. Thus, the length of the value sent by a stub device is a multiple of 5 bytes.
Delivers location-based information to endpoint devices through switches, routers, or access devices using the Cisco Discovery Protocol. The Location TLV can send the following types of information:
Custom location—Provides the location and attributes of the endpoint device.
Civic location information—Provides the civic address information and postal information; for example, street address, road name, and postal community information.
ELIN location information—Provides the location information of a caller. The location is determined by the emergency location identifier number (ELIN), which is a phone number that routes an emergency call to the local public safety answering point (PSAP). The PSAP uses this information to call back.
You must configure the location TLV on the device before Cisco Discovery Protocol can deliver location-based information to the endpoint devices.
Provides a mechanism for location servers to transfer the required information to the neighbor devices.
Management Address TLV
Contains a list of network layer addresses encoded similarly to the Address TLV.
This TLV contains a list of all the addresses at which the device accepts SNMP messages.
Native VLAN TLV
Indicates the Inter-Switch Link (ISL) number of the native interface VLAN on which the Cisco Discovery Protocol packet is sent, as well as whether the VLAN is enabled on the link and whether the link is a trunk or a host/edge port.
Describes the hardware platform of the device. Encoded as an ASCII character string. The TLV length determines the length of the string.
Identifies the port on which the Cisco Discovery Protocol packet is sent. This is encoded as an ASCII character string.
The value of this TLV is the same as the MIB object ifName for the ifTable entry on which the Cisco Discovery Protocol packet is sent.
Power Available TLV
Specifies the information transmitted by all switch interfaces. This information permits a device that needs power to negotiate and select an appropriate power setting. The Power Available TLV includes four fields:
Discovers neighbor devices, communicates and negotiates power-related parameters with Cisco end devices such as an IP phone and access point.
Extended Trust TLV
Specifies that the trust from the larger switch port is extended to other (external) ports of the simple switching device without explicitly configuring the trust on the simple switching device.
Extending trust allows a network administrator to trust a host/server to mark the packets and the port on which this host/server is connected. Packets received on a trusted port are not marked again.
The TLV value is one byte in length with its least significant bit indicating the trust mode. A 1 indicates extended trust and a 0 indicates the absence of extended trust. All other bits of the TLV value should be set to 0 on transmission and ignored on receipt.
A Cisco Discovery Protocol packet without this TLV indicates the absence of extended trust.
Contains information about the Cisco software image version the device is running. This is in the form of a character string. The TLV length determines the length of the string. This information is displayed in the output of the show version command.
VTP Management Domain TLV
Specifies the name of the VLAN Trunking Protocol (VTP) management domain for a device running the VTP on the particular interface on which the Cisco Discovery Protocol packet is sent.
The length of this TLV determines the length of the VTP management domain name. A length of zero indicates that a device is running VTP but has no management domain name assigned to it.
Appliance VLAN-ID TLV
Indicates the setting of the local configuration when a local 802.1Q interface has been configured to send and receive VoIP and related packets on a particular VLAN.
Devices receiving this TLV may adjust their configuration to match this setting.
The Address TLV and Device ID TLV are mandatory TLVs and they cannot be blocked. Hence, they are not available in the Cisco software image for user configuration.
How to Configure Secure Cisco Discovery Protocol
Configuring a TLV List and Adding TLVs to the List
2. configure terminal
3. cdp tlv-list tlv-list-name
4. ip-prefix
5. hello-protocol
7. show cdp tlv-list tlv-list-name
Enables privileged EXEC mode.
Enter your password if prompted.
Enters global configuration mode.
Configures the type, length, value (TLV) list that allows users to select TLVs and enters TLV list configuration mode.
Adds the IP prefix TLV to the TLV list.
Adds the Protocol-Hello TLV to the TLV list.
In TLV list configuration mode, enter the CLI help ( ? ) command to view a list of TLVs that are not added to the TLV list.
Exits TLV list configuration mode and returns to privileged EXEC mode.
Displays information about the TLVs in a TLV list.
Applying TLV List Configurations at the Interface Level
2. configure terminal
3. interface type number
4. cdp filter-tlv-list tlv-list-name
6. show cdp tlv-list tlv-list-name
Enables privileged EXEC mode.
Enter your password if prompted.
Enters global configuration mode.
Specifies an interface type and enters interface configuration mode.
Applies a TLV list on an interface.
Exits interface configuration mode and returns to privileged EXEC mode.
Displays information about the TLVs in a TLV list.
Applying TLV List Configurations at the Global Level
SUMMARY STEPS
2. configure terminal
3. cdp filter-tlv-list tlv-list-name
5. show cdp tlv-list tlv-list-name
Enables privileged EXEC mode.
Enter your password if prompted.
Enters global configuration mode.
Applies a TLV list globally.
Exits global configuration mode and returns to the privileged EXEC mode.
Displays information about the TLVs in a TLV list.
Configuration Examples for Secure Cisco Discovery Protocol
Example: Configuring a TLV List and Adding TLVs to the List
The following example shows how to create a TLV list, group2 and add TLVs to the list:
The show cdp tlv-list * command displays all configured Cisco Discovery Protocol TLV lists.
Example: Applying TLV List Configurations at Interface Level
The show cdp interface command displays Cisco Discovery Protocol TLV lists on all interfaces.
The following example shows how to apply Cisco Discovery Protocol type, length, value (TLV) lists on an interface:
Example: Applying TLV List Configurations Globally
The show cdp interface command displays Cisco Discovery Protocol TLV lists on all interfaces.
Additional References for Secure Cisco Discovery Protocol
Related Documents
Cisco IOS commands
Cisco Discovery Protocol commands
SNMP configuration tasks
Configuring SNMP Support
On-Demand Routing configuration tasks
Configuring On-Demand Routing
Standards and RFCs
To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:
Technical Assistance
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.
Feature Information for Secure Cisco Discovery Protocol
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Secure Cisco Discovery Protocol
The Secure Cisco Discovery Protocol feature allows you to select what information is sent in Cisco Discovery Protocol packets and block sensitive information.
The following commands were introduced or modified: cdp filter-tlv-list , cdp tlv-list , show cdp interface , show cdp tlv-list .
Протокол CPD (Cisco Discovery Protocol)
Давайте рассмотрим достаточно распространённую тему — протокол CDP. Что же о нём можно сказать, если о нём всё известно? Однако некоторые механизмы работы, позволяющие упростить работу сетевого инженера, знают не все. О них и поговорим.
Протокол CPD (Cisco Discovery Protocol) – проприетарный протокол компании Cisco, работающий на 2 уровне модели OSI, который позволяет сетевым устройствам (и не только сетевым) анонсировать в сеть информацию о себе и принимать такие анонсы от своих соседей.
Протокол достаточно полезный, так как он может показать, что за устройство (версия ПО, номера портов, платформа и ещё много другой информации) подключено в сеть. Это может быть удобно для составления карты сети, ведения документации и мониторинга сети. Однако также это облегчает атаку на сеть. В связи с этим протокол CDP в большинстве случаев отключают.
В интернете огромное количество информации по данному протоколу. Например, как посмотреть соседние устройства командой show cdp neighbors :
Как видим из вывода, видны description, порты, платформа соседнего устройства. Также можно посмотреть и более детальную информацию о соседнем устройстве с помощью show cdp neighbors detail :
Тут уже видны и IP адреса и версия ПО, что достаточно удобно для документирования неизвестной сети.
Логика работы
Логика работы протокола CDP достаточно простая и в общих чертах механизм работы следующий: 1. Устройство посылает multicast-сообщение на MAC-адрес 01:00:0C:CC:CC:CC (по умолчанию каждые 60 секунд на порты Ethernet). 2. Принимающее устройство сохраняет эти сообщения в CDP-таблицу. Если спустя 180 секунд (3 анонса CDP) устройство не прислало ни одного сообщения, – удаляется из базы CDP.
Однако несмотря на все минусы и плюсы протокола в качестве мониторинга за сетевым оборудованием, CDP имеет и дополнительные возможности для управления сетевыми устройствами.
В CDP существует механизм объединения сетевых устройств в кластер, которым можно управлять с одного устройства – CDP Cluster.
Когда такой функционал может потребоваться?
Например, вы случайно или не случайно потеряли доступ к оборудованию через ssh/telnet, а до устройства физически сложно добраться. В таком случае единственное что требуется – включенный протокол CDP.
Настройка
Настройку CDP cluster рассмотрим на коммутаторах 2960: 1. Заходим на доступный коммутатор и включаем CDP cluster:
- Проверяем устройства в сети, которые можно подключить к настроенному кластеру:
- Из предыдущего вывода берём MAC-адрес и добавляем удалённый коммутатор SW10 в CDP cluster.
- Всё. Теперь можем подключиться к удалённому коммутатору командой SW1#rcommand 1 . И попадаем на удалённый коммутатор SW10# . Теперь можно делать любые настройки, что могут потребоваться.
Чтобы отключить кластер, необходимо удалить всех cluster member из него и только потом отключить сам кластер:
Посмотреть кластер можно командой show cluster .
В итоге имеется полезный и удобный протокол для мониторинга и управления сети на устройствах Cisco, однако из-за отсутствия встроенных механизмов безопасности CDP может нести угрозу внутренней сети предприятия. Поэтому решение об использовании или отключении протокола принимать вам.
Протокол CDP — самое интересное
Cisco Discovery Protocol (CDP) – разработка компании Cisco Systems, которая позволяет коммутаторам Cisco обнаруживать устройства, подключенные к их интерфейсам. По умолчанию, CDP активирован на Cisco коммутаторах. Так же, CDP активирован по умолчанию на IP — телефонах Cisco. Протокол CDP особенно полезен для VoIP (Voice over IP), так как он позволяет коммутатору обнаружить IP – телефон и установить оптимальные для взаимодействия параметры. Параметры команды show cdp neighbors detail приведены на картинке ниже.
Установление метки VLAN
Коммутатор, к которому подключен IP – телефон, по протоколу CDP устанавливает соединение, которое позволяет телефону отправлять VoIP пакеты в отдельном VLAN (голосовом, то есть только для телефонов). Это позволяет изолировать трафик IP – телефонов от трафика сети Интернет.
Установление параметров CoS
Благодаря протоколу CDP, коммутатор может установить тип устройства и определить метку CoS (Class of Service) для него. Значение по умолчанию это CoS нулевого уровня, а максимальное значение CoS уровня 5.
Подключение компьютера в Cisco IP – телефон
В рамках удобства офисного пространства, существует возможность подключения компьютера пользователя напрямую в PC порт IP – телефона. Сам IP – телефон включается в порт доступа (access port) коммутатора. Сетевой интерфейс компьютера функционирует в специальном VLAN, предназначенном для сети интернет. По умолчанию, все полученные от компьютера пакеты, Cisco IP Phone маркирует меткой CoS 0 — эта опция может быть отдельно настроена в настройках телефона, а так же в конфигурации самого коммутатора. Телефон Cisco взаимодействует с коммутатором по протоколу CDP, чтобы установить параметры доверия (trusting/nontrusting) трафику, получаемому с PC порта телефона:
Configuring and Troubleshooting CRL Distribution Points (CDP) and Authority Information Access (AIA)
CDP and AIA Points can sometimes be confusing but are the most important pillars of a functional PKI environment. Configuration of proper CDP and AIA points can result in a better and healthy PKI environment, and debugging those issues can be equally tricky. This article intends to be a way to stop any CDP/AIA issues that one may face during the PKI configuration and debugging stages.
Configuration of CDP/AIA Points
Proper configuration of CDP and AIA points can be tricky. It involves proper permission of where CRL needs to be published and where they would be accessed.
Improper configuration of CDP can result in two scenarios
- CRL fails to be published, or
- CRLs cannot be accessed
Similarly, if AIA is not configured properly, then certificates of root and issuing CAs cannot be accessed.
In both of the scenarios, PKI fails to function properly.
Configuration of AIA
AIA is the easiest to configure. If OCSP is used, the AIA decimal point may include 34; otherwise, it’s always 2.
| Display Name | Decimal Value |
|---|---|
| Publish at this location | 1 |
| Include in the AIA extension of issued certificates | 2 |
| Include in the Online Certificate Status Protocol (OCSP) extension | 32 |
Decimal Value 1 is included when publishing in the %windir%\System32\certsrv\CertEnroll location. It can also be included to publish directly onto the AIA location if proper permissions are provided.
[Note: If the location is behind a load balancer, the CA cannot access both servers and may cause failure. Please do not publish on those locations; instead manual copy is recommended]
Decimal Value 2 is included when the URL is to be added to the issued certificates. These URLs act as the AIA points from where the certificates can be extracted.
Here, we provide a local CertEnroll folder with decimal value 1, as it is where the AIA would be published. The HTTP location has a decimal value of 2, where we won’t publish the certificates, but it will act as an AIA location from where other clients can access its certificate.
Configuration of CDP
Configuration of CDP can depend on how the CA is configured, how the CRLs are published and accessed, and if Delta CRLs are published.
| Display Name | Description | Decimal Value |
|---|---|---|
| Publish CRLs at this location | Used by the CA to determine whether to publish base CRLs to this location | 1 |
| Include in the CRL Distribution Point (CDP) of issued certificates | Used by clients during revocation checking to find base CRL Location | 2 |
| Include in [base] CRLs | Used by clients during revocation checking to find delta CRL location from base CRLs | 4 |
| Include in all CRLs | An offline CA can use it to specify the LDAP URL for manual publishing CRLs. You must also set the explicit configuration container in the URL or the DSConfigDN value in the registry. certutil -setreg CA\DSConfigDN CN= |
8 |
| 16 | ||
| 32 | ||
| Publish Delta CRLs to this location | Used by the CA to determine whether to publish Delta CRLs to this location | 64 |
Decimal values are used accordingly based on how the CDP needs to be configured.
Decimal Value 1 is mostly used to publish CRLs to %windir%\System32\certsrv\CertEnroll location or to those locations where CA has proper permissions to access. If Delta CRLs are also published, 65 (1+64) is used.
[Note: If the location is behind a load balancer, the CA cannot access both servers and may cause failure. Please do not publish on those locations; instead manual copy is recommended]
Decimal Value 2 includes the URL or location and lets it act as a CDP location from where base or delta CRLs are accessed.
Decimal Value 79 = CRLs are published at that location (1) + Location is added to CDP (2) + Delta CRL location (4) + Include in all CRLs (8) + Publish Delta CRL at this location (64)
Decimal Value 65 = Publish CRL at this location (1) + Publish Delta CRL at this location (64)
Decimal Value 6 = Location is added to CDP (2) + Delta CRL location (4)
CRL Replacement Tokens
In the above examples, you may have noticed %1, %3, %4, %8, and %9. This represents how the CA is configured and what the file’s name should be. If the files are renamed, the AIA and CDP points may fail as the naming convention doesn’t match.
| Token Name | Description | Map Value |
|---|---|---|
| ServerDNSName | The DNS name of the CA Server | %1 |
| ServerShortName | The NetBIOS name of the server | %2 |
| CAName | The name of the CA | %3 |
| Cert_Suffix | The renewal extension of the CA | %4 (as per Windows 2000 mapping) |
| CertificateName | %4 (as per Windows 2003 mapping | |
| ConfigurationContainer | The location of the Configuration container in AD | %6 |
| CATruncatedName | The “sanitized” name of the CA | %7 |
| CRLNameSuffix | The renewal extension of the CRL | %8 |
| DeltaCRLAllowed | If Delta CRL is allowed, + is added at the end of the file to indicate a delta crl | %9 |
| CDPObjectClass | %10 | |
| CAObjectClass | %11 |
Based on the mapping value, the AIA and CDP points are given a naming convention to find the correct file from those locations.
Debugging CDP/AIA location issues
If the CDP/AIA locations are properly configured, these steps will temporarily help resolve the issues. For example, we will use AIA issues, which will also work for CDP issues.
After we open and check PKIView.msc, we can see where the issue is. We can copy the URL to a notepad for further investigation.
The AD doesn’t have our certificate if the issue is on the LDAP location. This is quite an easy fix.
Certificates retrieved via LDAP are retrieved from Domain Controller. If we open Domain Controller and ADSIEdit.msc, then we can navigate to Services > Public Key Services > AIA and check the present certificates. Since our Issuing CA Certificate is absent, the PKI environment cannot retrieve the certificate from that location.
To resolve this, we navigate to our issuing CA and run the command
certutil -dspublish -f <path to certificate> SubCA
Once the command runs successfully, we can refresh our PKIView.msc to check if the issue is resolved, and we should see a clean slate
However, if the AIA location #2, or the HTTP location is causing errors, this error is because the certificate isn’t present at that server endpoint.
To resolve this, we copy the certificate from %windir%\System32\certsrv\CertEnroll location to our web server, which hosts our certificate.
This would resolve our issue, which we can check on PKIView.msc again.
Conclusion
Issues with CDP and AIA locations can be tricky. Misconfiguration can often cause issues, which can be harder to track. With this guide, we hope to make the configuration of CDP/AIA points much easier with debugging steps to support any technical issues.
If you need help with your PKI environment, feel free to email us at [email protected] .
Datasheet of Public Key Infrastructure
We have years of experience in consulting, designing, implementing & migrating PKI solutions for enterprises across the country.