we have an IP telephony network with CM in the central node and some IP Phones in remote branches. In the remote branches, the router acts as a DHCP server for the IP phones. In one of the branches the first 26 IP Phones get their IP address from the router but we installed two more that could not take their IP address- and the rest of things- from the router. These IP Phones had to be configured statically 9with DHCP disabled) to get IP adddr., TFTP server addr. etc. From the logs on the router, I can see that the router, acting as DHCP server, communicates with the IP Phones (that are DHCP enabled) and vise versa. But the IP Phones do not get their IP address and do not boot.This is quite inconvenient for the customer, as you can understand. Does anyone have an idea?
the router has an SRST IOS. I have tried several -and non SRST- but had same results.
I have not seen this problem before. Did you look at a sniffer trace to insure the phone was sending the DHCP discover? Does the phone get a DHCP offer back? What type of switch are the phones plugged into? Are you doing auxiliary vlans for phone ports?
What version of SRST code are you running? How many phones work and how many phones don't work?
I get this output during router debug:
Jan 15 21:44:56: DHCPD: broadcasting BOOTREPLY to client 0006.772a.eb19.ggi
Jan 15 21:45:00: DHCPD: DHCPDISCOVER received from client 0100.0677.2aeb.19 on interface FastEthernet0/0.20.
Jan 15 21:45:00: DHCPD: Sending DHCPOFFER to client 0100.0677.2aeb.19 (192.168.12.33).
Jan 15 21:45:00: DHCPD: child pool: 192.168.12.33 / 255.255.255.0 (PHONE_1)
Jan 15 21:45:00: DHCPD: pool PHONE_1 has no parent.
The IP phones are plugged into a 3524 Catalyst with a voice Vlan configured (ports are configured as dot1q trunks, with a data vlan and a voice vlan). The router now runs with 12.2(2)XB2 IOS, so it is SRST v1.
Previously I had a non-SRST version because I could not find a version of IOS supporting SRST and at the same time having the faxes connected to FXS ports of the router working normally (that is another bitter story...)
The first 26 IP Phones had no DHCP problems, the last two had.
Do you have a router debug from a successful dhcp. I am not familar with these messages. I did some searchs in our database but did not come up with anything. Also the config of the router may be helpful.
this output was the result of the three debug commands "ip dhcp events/packet/linkage". The "child pool" and "pool PHONE_1 has no parent" is the result of debug "ip dhcp linkage", as I found out in CCO. So everything seems normal. Unfortunately, I do not have debugs from a correct operation. The configuration of the router for each IP Phone is:
ip dhcp pool PHONE_1
host 192.168.12.33 255.255.255.0
option 150 ip 192.168.43.55
The ports of the catalyst that IP Phones are connected are configured as dot1q trunks:
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport mode trunk
switchport voice vlan 20
I have the same configuration for all IP Phones in this branch and in other branches too. I do not have this problem anywhere else (other branches have fewer phones though...)
I am not using the SRST IOS but I have a similar problem with 3 of 27 phones at a site. They are connected to a 3524 and I can power cycle the switch and the same 3 phones will not connect. Doesn't seem to matter if I change ports, patch cords, etc. In the past I have been able to manually configure the required fields and have it connect. Once connected I configure it to use DHCP and it works properly on reconnect. No luck with that this time.
Here is a snippet I just pulled off the router from
DEBUG IP DHCP SERVER PACKET
Jan 17 13:49:58.086: DHCPD: BOOTREQUEST from 0100.06d7.aa8a.06 forwarded to 10.10.125.10.
Jan 17 13:49:58.170: DHCPD: forwarding BOOTREPLY to client 0006.d7aa.8a06.
Jan 17 13:49:58.170: DHCPD: broadcasting BOOTREPLY to client 0006.d7aa.8a06.
Jan 17 13:50:14.087: DHCPD: setting giaddr to 10.10.95.1.
Are these new phones that have never registered with callmanager. Did you notice the load on the phone when you where having the dhcp problem?
the phones right now are registered with CM and they are working. They just could not get their IP address from the branch router and we had to configure each IP Phone manually -and disable DHCP-. I am wondering why this happens with the last two phones as it did not happen with the rest 26 phones.
the DHCP address lease is a Class C dedicated to the voice VLAN of this branch.