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.
... View more
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 ?
... View more
I was given a WS-C3560E from a Eng program to configure and redeploy to a new test environment. The switch has not been under maintenance for at least 2 years. I got the switch configured and decided to upgrade the IOS From 12.2.44 to Cisco’s recommended 12.2.55 I thought the IOS copied to flash correctly. I modified the boot record to try first the new IOS, then the old. The boot record updated properly. When I performed the reload the POST went well but when the IOS load was to begin nothing happened for over 5 minutes. I attempted to break-in, but could not and cannot. Less than 30 seconds after a power cycle the Status light stays amber – even when the mode button is depressed and/or powered on overnight. Is the any recourse to modify the boot record to just the old IOS ?
... View more