New Site Rollout: TFTP Timeout and Unprovisioned Phones
Riverside is a new site with 140 unprovisioned phones (120 8845s, 20 7821s) 350 miles from the headquarters cluster. A local Layer 3 switch runs DHCP; option 150 points to 10.20.0.10, the address of a Subscriber that was rebuilt last month and now runs at 10.20.0.11. The Publisher is 10.10.0.10. Riverside phones are in device pool Riverside-DP, whose CM group lists HQ-Sub1 first and the Publisher second. On cutover, about 90 phones reach "Registering" and then sit at "Registration Rejected" with no extension, while 50 never leave "Configuring IP" and end at "TFTP Timeout". Auto-registration is disabled cluster-wide, and the cluster runs in mixed mode with a CTL and ITL already installed.
1. Separate the two failure groups and explain why the CM group ordering does not help the 50 phones that fail at TFTP.
Read the worked answer
These are two distinct stages of phone startup.
Group A (50 phones, TFTP Timeout): before a phone can use a CM group it must download its configuration. It only knows where to ask from DHCP: option 150 here points to 10.20.0.10, an address that no longer hosts a TFTP server after the Subscriber rebuild. The phone retries, times out, and never gets far enough to try a CM group. The CM group is irrelevant at this stage - it tells the phone which call-processing nodes to register to, not where to fetch files.
Group B (90 phones, Registration Rejected): these phones reached a TFTP server (plausible if they had a cached address or got the corrected scope) and downloaded a config, but CUCM refused the registration because auto-registration is disabled and no device or DN exists for their MAC addresses.
Fix group A by correcting DHCP option 150 to live TFTP servers (ideally the Publisher plus a Subscriber, so there is no single point of failure). If you use DNS SRV instead, the phones need a valid domain name and a search domain in the scope - otherwise option 150 is the simpler, more deterministic choice. Then verify with show ctl-equivalent phone diagnostics or the CUCM "Device > Phone" find that the MAC actually appears.
2. The 90 phones must come up without hand-building 90 devices. Compare enabling auto-registration with self-provisioning for this site, and list every object that must exist for the chosen path to produce a working phone (dial tone, internal calls, local PSTN).
Read the worked answer
Auto-registration is fastest but crude: CUCM assigns the next free DN from the cluster's auto-registration range and drops the phone into the auto-registration device pool. It is cluster-wide in the sense that you nominate one CUCM server to serve auto-registration, and you get devices named SEP with no user association, no correct device pool, and no line CSS unless you pre-build it.
Self-provisioning is the better answer for 140 phones at a new site: the user signs in on the phone, CUCM applies a Universal Device Template and Universal Line Template, and the phone lands with the right device pool, CSS and DN pattern. It requires the templates, a user profile, users with the right roles, and a phone security profile that allows the login.
Objects that must exist either way before the phone is genuinely usable:
- A DN and a partition/line CSS that can reach internal patterns and the local PSTN route pattern.
- A device pool with the correct region (codec), location (CAC), date/time group and CM group.
- A route pattern/route list for 9 (or 0) access that points at the Riverside gateway, and a 911 pattern scoped to Riverside phones, otherwise all emergency calls go out the HQ gateway.
- The phone security profile consistent with mixed mode, so the phone can complete its TLS handshake and download the ITL. Also confirm the auto-registration or self-provisioning device pool is not the cluster default; leaving phones in Default device pool is how new sites end up with HQ dial tone rules.
3. Three weeks later, during a maintenance window, HQ-Sub1 is taken down. Riverside users report that calls fail for about 40 seconds before service returns. Is this a misconfiguration, and what would you change?
Read the worked answer
This is largely expected behavior, not a fault. A registered SCCP/SIP phone holds a TCP keepalive to its active node; when the node disappears, the phone must notice the loss (keepalives are on the order of tens of seconds) and then walk down its CM group in order, attempting registration to the next node. The 40-second gap is the detection interval plus re-registration, and users experience it as failed or unanswered call attempts.
What to check and change:
- Confirm both nodes are actually in Riverside-DP's CM group and that the Publisher is listed, not just HQ-Sub1. A CM group with a single node turns a maintenance window into an outage.
- Confirm the phones are not in the cluster default device pool, whose CM group may not include the node you expect.
- Confirm the network path from Riverside to the Publisher works, including any firewall rules for SIP/SCCP and TFTP - failover is useless if the second node is unreachable from that subnet.
- For the WAN-loss case (not node loss), failover timers do not help at all; that is what an SRST reference in the device pool is for. Also use "Cisco Unified Reporting / Device > Phone" to confirm which node each phone actually registered to before the window; phones that quietly failed over weeks earlier will behave differently than you expect.