1.0 Problem Summary

Network administrators may observe an issue where Cisco IP Phones (e.g., 7900 series, 8800 series) fail to register with Cisco Unified Communications Manager (CUCM). The primary symptoms include the phone’s screen being perpetually stuck on a “Processing Request” or similar status message after acquiring an IP address. Concurrently, network monitoring tools and DHCP server logs reveal that the affected phones are generating an abnormally high volume of DHCP requests, sometimes hundreds per minute.

This behavior indicates the phone is entering a continuous boot-loop cycle. It successfully completes the initial DHCP phase but fails at a subsequent critical step, causing it to abandon its IP lease and restart the network initialization process from the beginning. The root cause is most often a network connectivity failure between the IP phone and its designated TFTP server.

2.0 Root Cause Analysis: The IP Phone Boot-Up Process

To effectively troubleshoot this issue, it is essential to understand the standard boot-up and registration sequence for a Cisco IP Phone:

1. Power On & VLAN Discovery: The phone powers on and loads its internal firmware. It then uses Cisco Discovery Protocol (CDP) or Link Layer Discovery Protocol (LLDP) to learn the Voice VLAN ID from the connected switch port. The phone tags its subsequent traffic for this VLAN.
2. DHCP Request: The phone broadcasts a DHCP DISCOVER message on the Voice VLAN. It receives a DHCP OFFER from a server and proceeds to request and acknowledge the IP address lease. This DHCP exchange provides the phone with its essential IP configuration:
   • IP Address
   • Subnet Mask
   • Default Gateway
   • DNS Server(s)
   • TFTP Server Address (via DHCP Option 150 or Option 66)
3. TFTP Configuration Download: This is the most critical and common point of failure for the issue described. Using the TFTP server address acquired from DHCP Option 150, the phone attempts to contact the server to download its specific configuration file. This file is typically named SEP<MAC_Address>.cnf.xml. This XML file contains all the necessary information for registration, including the list of CUCM servers (CUCM Group), device security profile, and firmware load information.
4. CUCM Registration: After successfully parsing the .cnf.xml file, the phone attempts to establish a connection with the primary CUCM server in its defined CUCM Group using either SCCP (Skinny) or SIP protocol.
5. Registration Complete: The phone successfully registers and becomes operational.

The “Processing Request” loop occurs when Step 3 fails. The phone obtains an IP address and knows the location of its TFTP server, but it cannot reach it to download its configuration file. The phone’s internal logic interprets this failure as a critical network problem. It assumes the network information it received might be invalid or transient. As a result, it releases its DHCP lease and re-initiates the entire process, starting from a new DHCP DISCOVER. This creates the observed DHCP storm.

The most frequent reason for this TFTP communication failure is a network security policy, such as a firewall rule or an Access Control List (ACL), blocking the traffic.

3.0 Diagnostic and Verification Steps

Follow this systematic approach to isolate and confirm the root cause.

Step 1: Verify DHCP Configuration
Ensure the DHCP scope for the Voice VLAN is correctly configured. Specifically, confirm that DHCP Option 150 is configured with the correct IP address(es) of your CUCM TFTP server(s). An incorrect TFTP server IP will guarantee failure.

Step 2: Isolate and Test Network Connectivity (Crucial Step)
The most effective way to diagnose this issue is to simulate the phone’s network path.

1. Prepare a Test Device: Connect a laptop or PC to a switch port that is configured for the same Voice VLAN as the failing IP phones.
2. Manual IP Configuration: Manually assign the laptop an unused static IP address, subnet mask, and default gateway from the Voice VLAN’s IP range.
3. Gateway Ping Test: Open a command prompt or terminal and attempt to ping the default gateway address.
   • ping <default_gateway_ip>
   • A successful ping confirms basic Layer 2 and Layer 3 connectivity within the local segment is functional.
4. TFTP Server Ping Test: This is the definitive test. Attempt to ping the IP address of the TFTP server that was identified in Step 1.
   • ping <tftp_server_ip_from_option_150>
   • If this ping fails, you have confirmed a network path issue. The phone is experiencing the exact same failure. The traffic from the Voice VLAN is being blocked before it can reach the CUCM/TFTP server.

4.0 Solution Implementation

Once the connectivity failure has been confirmed via the ping test, the issue must be resolved on the intermediary network device(s).

1. Identify the Blocking Device: Trace the network path from the Voice VLAN subnet to the CUCM server subnet. The most common culprits are:

   • Firewalls: The most likely cause, especially in segmented networks where voice and server traffic are on different security zones.
   • Router/Layer 3 Switch ACLs: Access Control Lists applied to the Voice VLAN’s Switched Virtual Interface (SVI) or routed interfaces can block the required traffic.

2. Modify Security Policies: Engage your network security team to implement the necessary rule changes. The phone requires access to several services on the CUCM server for a complete registration. At a minimum, the following must be permitted:

   • TFTP: Allow traffic from the Voice VLAN Subnet (source) to the CUCM Server IP (destination) on UDP port 69. This is required for the initial configuration file download and is the direct fix for the “Processing Request” loop.
   • Registration Protocol (SCCP or SIP):
     • For SCCP (Skinny), allow traffic on TCP port 2000.
     • For SIP, allow traffic on TCP/UDP port 5060 (non-secure) or TCP 5061 (secure).
   • Real-time Transport Protocol (RTP): For the actual media stream (the voice conversation), a wide range of UDP ports (typically 16384-32767) must also be permitted between the phones and other endpoints/gateways.

3. Verification:

   • After the firewall/ACL rules have been updated, repeat the connectivity tests from Section 3.0, Step 2. Both the gateway and the TFTP server should now be reachable via ping.
   • You can perform a more advanced test using a TFTP client on the test laptop to attempt to download a file from the CUCM TFTP server.
   • Finally, power cycle one of the affected IP phones. Observe its boot-up sequence. The phone should now successfully download its configuration file, proceed past the “Processing Request” stage, and register with CUCM. The excessive DHCP traffic will cease immediately.

By following this structured approach, you can efficiently diagnose and resolve this common but often frustrating IP phone registration issue, restoring service and stabilizing the network environment.