md5auth
asked on
Cisco IP phones unable to reach DHCP server from a particular subnet/vlan.
DHCP server is normally responding to the request made by IP phones residing in all vlans, but when a DHCP request is coming from one particular block of subnets let suppose 192.168.208.1/22 and 192.168.216.1/22 and 192.168.224.1/22, the DHCP is unable to respond or IP phones are failing to reach the dhcp sever.
For reachability we did some pinging from those troubled subnets, pings are reaching easily the DHCP server, placed a laptop in those troubled subnets to check if it was getting an IP address and the laptop did get an IP, but why only phones are are unable to get an IP address and is stuck in "Registering" mode .
Any clue ?
For reachability we did some pinging from those troubled subnets, pings are reaching easily the DHCP server, placed a laptop in those troubled subnets to check if it was getting an IP address and the laptop did get an IP, but why only phones are are unable to get an IP address and is stuck in "Registering" mode .
Any clue ?
If the phones display "Registering" on screen, they are definitely not having DHCP issues. They have gotten an IP already, and are effectively trying to register.
Grab one of those and:
- Open the Settings menu > Go to Network Settings > IPv4 > check the IP/subnet/gateway values received, and most important, check the TFTP value provided, this is the IP from which they obtain their configuration files
- If everything is good, then open the Settings menu > Status > Status messages and try to make sense about the entries the phone is logging
- If the phone has an IP, and if the phone has its Web Access enabled (something you tell the phone to have from the Callmanager config page, and through the XML configuration file), then try opening the phone IP on your web browser. If you can reach it, then go to the left menu, and click on Console logs. Download the last 2 or 3 logs and try to make sense out of the entires, or put them here so I can take a look.
Remember that "Registering" means that the phone is using a specific type of traffic now, pinging is not going to prove if SCCP traffic or SIP traffic are effectively allowed between the phones and the callamanager.
Grab one of those and:
- Open the Settings menu > Go to Network Settings > IPv4 > check the IP/subnet/gateway values received, and most important, check the TFTP value provided, this is the IP from which they obtain their configuration files
- If everything is good, then open the Settings menu > Status > Status messages and try to make sense about the entries the phone is logging
- If the phone has an IP, and if the phone has its Web Access enabled (something you tell the phone to have from the Callmanager config page, and through the XML configuration file), then try opening the phone IP on your web browser. If you can reach it, then go to the left menu, and click on Console logs. Download the last 2 or 3 logs and try to make sense out of the entires, or put them here so I can take a look.
Remember that "Registering" means that the phone is using a specific type of traffic now, pinging is not going to prove if SCCP traffic or SIP traffic are effectively allowed between the phones and the callamanager.
ASKER
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
yeah i did, and this problem is with multiple phones, is there any working utility that can perform a batch erase on all faulty ITLs ?
> or IP phones are failing to reach the dhcp sever.
ever tried to use a sniffer to listen the incoming and outgoing traffic on the DHCP server's subnet in order to determine what's going on there underneath?