2.3 Network Infrastructure Services: DNS, NTP, DHCP & LDAP

Network Infrastructure Services: DNS, NTP, DHCP & LDAP

Cisco Unified Communications Manager (CUCM) and its associated endpoints do not operate in isolation. They depend on fundamental IP network services to locate resources, synchronize database transactions, obtain configuration files, and negotiate physical link parameters. A failure or misconfiguration in DNS, NTP, DHCP, or link discovery protocols immediately undermines call processing stability.

---

Domain Name System (DNS) Requirements in Cisco Collaboration

DNS is critical across all phases of collaboration deployment, from initial node installation to runtime service discovery.

Forward and Reverse DNS Records

Every server node in a Cisco Collaboration cluster—including CUCM Publisher, CUCM Subscribers, dedicated TFTP nodes, IM and Presence nodes, Unity Connection, Cisco Expressway, and CUBE routers—must have matching Forward (A/AAAA) and Reverse (PTR) DNS records:

• Installation Pre-Check: The CUCM operating system installation wizard performs mandatory forward and reverse lookups against configured DNS servers. If reverse PTR lookups fail or return mismatched hostnames, the installation aborts.
• Certificate Validation: During TLS handshakes, endpoints compare the server's Presented Identifier (Common Name or Subject Alternative Name) against the resolved DNS name. Missing PTR records trigger hostname resolution delays and security verification failures.

DNS Service (SRV) Records (RFC 2782)

DNS SRV records enable automatic service discovery by mapping an abstract service name to specific target server FQDNs and port numbers. The RFC 2782 syntax is defined as:

_service._proto.name. TTL Class SRV Priority Weight Port Target

• Priority: A 16-bit integer where the lowest numerical value has the highest priority. Clients always attempt to contact the target with the lowest priority number first.
• Weight: A 16-bit integer used for load balancing among servers with identical priority numbers.
• Port: The TCP or UDP port number hosting the service.
• Target: The canonical FQDN of the destination host.

Key Collaboration SRV Records

CUCM CLI Troubleshooting Commands for DNS:
=========================================================================
admin: utils network dns lookup cucm-pub.example.com
Resolving cucm-pub.example.com...
IP Address: 10.10.20.10

admin: utils network dns lookup 10.10.20.10
Resolving 10.10.20.10...
Host Name: cucm-pub.example.com

admin: utils network dns hosts show
127.0.0.1       localhost
10.10.20.10     cucm-pub.example.com cucm-pub
=========================================================================

---

Network Time Protocol (NTP) Stratum Hierarchy

Time synchronization is crucial in CUCM clusters. Call detail records (CDRs), audit logs, certificate validity windows, and—most importantly—Informix Dynamic Server (IDS) database replication require synchronized timestamps across all cluster nodes.

+---------------------------------------------------------------------------------------------------------+
|                                 CUCM Hierarchical NTP Stratum Architecture                              |
+---------------------------------------------------------------------------------------------------------+
|  [External Stratum 1 / 2 NTP Server] (e.g. Dedicated Appliance, Core Router GPS / Atomic Clock)         |
|                                                 |                                                       |
|                                                 v Synchronizes over NTP (UDP 123)                       |
|  +---------------------------------------------------------------------------------------------------+  |
|  |                                       CUCM Publisher Node                                         |  |
|  |                         (Stratum n+1, e.g. Stratum 2 or Stratum 3)                                |  |
|  +---------------------------------------------------------------------------------------------------+  |
|                   |                                 |                                 |                 |
|                   v (Exclusively Synced)            v (Exclusively Synced)            v                 |
|  +---------------------------------+  +---------------------------------+  +-----------------------+  |
|  |         CUCM Subscriber 1       |  |         CUCM Subscriber 2       |  |    Dedicated TFTP /   |  |
|  |   (Stratum n+2, e.g. Stratum 3) |  |   (Stratum n+2, e.g. Stratum 3) |  |   IM&P Nodes (Sub)    |  |
|  +---------------------------------+  +---------------------------------+  +-----------------------+  |
+---------------------------------------------------------------------------------------------------------+

Mandatory Hierarchy Rules

1. Publisher Synchronization: The CUCM publisher must synchronize to a reliable external NTP server that is not part of the cluster, ideally a low-stratum enterprise source such as a core router or dedicated time appliance. Cisco does not support Windows NTP servers for CUCM; Linux, Cisco IOS, and NX-OS NTP sources are acceptable.
2. Subscriber Synchronization: ALL Subscriber nodes in the cluster (including dedicated call processing subscribers, TFTP servers, and IM&P nodes) MUST synchronize EXCLUSIVELY to the CUCM Publisher.
3. Why Subscribers Must Not Sync Externally: If Subscribers synchronize to different external NTP servers, subtle network route delays or clock drift between external sources will create clock skew among cluster nodes. Because Informix database replication relies on sequence timestamps to order database transactions, clock skew causes replication desynchronization (dbreplication failure), resulting in corrupted device configurations and stale call routing data.

Verifying NTP

• Run utils ntp status on each node. The publisher should show its external reference with a reasonable stratum and small offset; subscribers should show the publisher as their source.
• During installation the publisher checks that its NTP server is reachable, and subscribers take their time from the publisher. A publisher that cannot reach NTP, or a clock that drifts, shows up as NTP alarms in RTMT and can break database replication.

admin: utils ntp status
ntpd (pid 14210) is running...

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.10.10.1      .GPS.            1 u   42   64  377    0.412   -0.082   0.024

synchronised to NTP server (10.10.10.1) at stratum 2
   time correct to within 12 ms
   polling server every 64 s

Current time in UTC is : Tue Oct  6 10:14:22 UTC 2026
=========================================================================

---

Dynamic Host Configuration Protocol (DHCP) for Voice Endpoints

When a Cisco IP phone boots, it initiates a standard four-step DHCP exchange (Discover, Offer, Request, Acknowledge — DORA). In addition to obtaining an IP address and default gateway, collaboration endpoints require specific DHCP Options to locate call control and configuration servers:

DHCP Option 150 vs. Option 66 Precedence

• Option 150 (Preferred): Supplies an ordered list of TFTP server IPv4 addresses, normally the cluster's primary and secondary TFTP servers. If the primary TFTP server is unreachable or fails to respond, the Cisco IP phone automatically attempts to download its configuration from the subsequent IP addresses in the list.
• Option 66: Supports only a single TFTP server entry. If Option 66 contains an FQDN, the endpoint depends on DNS resolution before it can begin contacting the TFTP server.
• Precedence Rule: If both DHCP Option 150 and DHCP Option 66 are present, Cisco IP phones use Option 150; RFC 5859 says clients should prefer Option 150 over Option 66. IPv6 phones instead use the TFTP Server Addresses sub-option of Cisco's vendor-specific DHCPv6 option.

---

Link Layer Discovery Protocols: CDP and LLDP-MED

Cisco IP phones contain an internal three-port 10/100/1000 switch: a network port that connects upstream to the access switch, an internal port that connects to the phone's own processor, and a PC (access) port for a colocated workstation.

Voice VLAN Discovery (Auxiliary VLAN ID)

To isolate voice and data traffic, enterprises deploy separate VLANs on the access switch port: a Data (Access) VLAN and an Auxiliary (Voice) VLAN. The phone discovers its Voice VLAN using layer 2 discovery protocols:

• Cisco Discovery Protocol (CDP): Cisco proprietary link layer protocol enabled by default on Cisco enterprise switches.
• Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED, ANSI/TIA-1057): Vendor-neutral open standard protocol used when deploying third-party IP phones or multi-vendor switching infrastructure.

During link establishment, the switch transmits CDP or LLDP-MED packets advertising the Voice VLAN ID. The phone reads this advertisement, configures its internal switch, and begins tagging all voice and signaling traffic with an IEEE 802.1Q tag containing the Voice VLAN ID and 802.1p Class of Service (CoS) value 5. Data traffic from the colocated PC passes through the phone untagged and is placed into the Access (Data) VLAN by the switch.

Power over Ethernet (PoE) Dynamic Negotiation

Switches negotiate power delivery using hardware resistance sensing followed by software-level protocol negotiation:

1. Hardware Classification: When a cable is plugged in, the switch senses resistance across the twisted pairs to determine the IEEE class (IEEE 802.3af Class 1-3 up to 15.4 W; IEEE 802.3at PoE+ Class 4 up to 30.0 W). The switch initially allocates the maximum power for that class.
2. CDP / LLDP-MED Power Negotiation: Once the phone boots its operating system, it transmits a CDP or LLDP-MED Power-via-MDI TLV indicating its exact power consumption (for example, a Cisco 8845 phone with camera disabled may require only 7.5 W). The switch adjusts its internal PoE power budget downward from 15.4 W to 7.5 W, allowing the remaining power to be allocated to other switch ports.

Cisco IOS XE Switch Port Configuration for Cisco IP Phone and Colocated PC:
=========================================================================
interface GigabitEthernet1/0/15
 description IP_Phone_8845_with_Colocated_Workstation
 switchport mode access
 switchport access vlan 10          ! Data VLAN for PC (Untagged)
 switchport voice vlan 20           ! Voice VLAN for Phone (Tagged 802.1Q / CoS 5)
 spanning-tree portfast             ! Bypasses 802.1D listening/learning states
 power inline auto                  ! Enables dynamic PoE/PoE+ negotiation
 no shutdown
=========================================================================

---

LDAP Connectivity Troubleshooting (Blueprint 1.5.c)

CUCM uses LDAP for directory synchronization and, optionally, for authenticating user passwords (Section 5.3). Network-level LDAP problems look like failed syncs or failed sign-ins:

• LDAPS certificate trust: For LDAPS, upload the directory server's root (and any intermediate) CA certificate to the CUCM tomcat-trust store, and configure the LDAP server by the FQDN that appears in its certificate. Pointing CUCM at an IP address that is not in the certificate causes TLS failures.
• Synchronization: The Cisco DirSync service must be activated on the publisher. Wrong manager (bind) DN credentials, a search base that excludes the users, or a filter that matches nothing produce empty or partial syncs.
• Authentication: When LDAP authentication fails, web, Self-Care, and Jabber sign-ins fail, but telephony PINs still work because PINs are always stored in CUCM.
• Global Catalog: Use ports 3268/3269 when users are spread across several domains in one forest; a single domain controller on 389/636 sees only its own domain.