IP phone instrument test for the voice processor

[btwinem]

Approximately 60 phones are operational on one switch stack; well over 2000 phones are deployed at multiple sites. We have a number of CP-79xx phones that will not register confirmed in CallManager (CM).  To eliminate any DHCP problem IP addresses were reserved after registration failed with leased addresses.  We are running Network Access Control.  Questionable phones provide network connectivity for connected PCs confirmed by ARP tables, authenticated sessions showing PC MAC and IP addresses, response to ping and user functionality confirmation.

The phone instrument in some cases is assigned a DHCP IP address and in others seems to be assigned the reserved address; both cases are confirmed by the authenticated session showing the phone MAC and assigned IP as listed in the Cisco Network Regietrar (CNR) scope.  There is the appropriate arp entry until it ages out, but no response to ping.   In some cases CM list the IP address and Status as unregistered; in other cases the IP and Status are both "none".  In all cases the IP address in the phone's Network Configuration is 255.255.255.255 (IPv4 global broadcast).  All problem phones were reset to default configuration at least twice with the same individual results.  Is the phone's IP address 255.255.255.255 sufficient to conclude that the audio processor is now defective or are there other tests ?

[Leo Laohoo]

So the phones are not getting an IP address?

[btwinem]

You are partially correct; I read the situation as the phones are not ACCEPTING the IP address delivered.

NAC running on a switch stack 4 x C3850-48P relates the MAC an IP address, the ARP table reflects the same relation, CNR identifies an IP address assigned or reserved to the phones with the phone passing device authentication.

After the problem phones were identified on different interfaces on multiple stack member one (1) know interface supporting an operation phone was chosen to run additional test.

The first set of test including attaching the phone checking CNR, Call Manager (CM), ARP, and the NAC authenticated session which provided the results listed above.

Each phone was then reset to defaults and the analysis repeated again; the results did not change. One questionable phone did not register after being reconfigured in CM.

After cycling thru 6 phones (2 good and 4 questionable); the phones were tested one more time. I note this step to emphasize that the MAC and IP learned by the switch ports changed between phones and matched the phone tested.

The question is when the phone is providing layer-2 connectivity for a PC but does not register is there a test other than the phone showing 255.255.255.255 as its IP address to confirm failed audio processing.