Stuck (Vol.1 2.6 CUCM DHCP)
I am stuck trying to complete task 2.6. UCM, 3750, and R1 are all configured according to specification. The phones at HQ acquire DHCP, register, and all is well. Where I am stuck is br1. br1 is configured according to the solution but the phones (two 7965) will not acquire DHCP from UCM. I temporarily moved an HQ phone that successfully registers at HQ to the HWIC-ESW on br1 and it will not acquire DHCP.
I realize there is a massive amount of check-list items. I can ping from br1 vlan 11 to the server at HQ which means the WAN is working fine. I have triple checked the DHCP config for br1 on UCM and it contains the appropriate information for br1's IP network. Below are output from br1. Are there any debugs or other tools I can use to see what is happening when the phones boot?
interface FastEthernet0/1/0
description == BR1 IP Phone
switchport access vlan 12
switchport mode trunk
switchport voice vlan 11
spanning-tree portfast
!
interface FastEthernet0/1/1
description == BR1 IP Phone
switchport access vlan 12
switchport mode trunk
switchport voice vlan 11
spanning-tree portfast
!
r2-br1#ping 177.1.10.10 source vlan 11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 177.1.10.10, timeout is 2 seconds:
Packet sent with a source address of 177.2.11.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
r2-br1#trace 177.1.10.10 source vlan 11
Type escape sequence to abort.
Tracing the route to 177.1.10.10
1 177.0.101.1 8 msec 4 msec 8 msec
2 177.1.10.10 4 msec 8 msec 4 msec
Comments
description == BR1 IP Phone
switchport access vlan 12
switchport mode trunk
switchport voice vlan 11
spanning-tree portfast
Although I don't think that your configuration will neccessarily have problems, but it is not standard method. Here is the configuration:
description == BR1 IP Phone
switchport mode trunk
swtchport trunk native vlan 12
spanning-tree portfast
Hello Mark,
As Jordan indicated, when using the HWIC switch module in R2, you should use the switchport trunk native vlan syntax. This should resolve your issue. If not, please let us know.
Thanks!
That didn't seem to make any difference. I'm running out of ideas at this point. Do you guys have any other suggestions? I posted my br1 config here. I actually do not think it is specific to DHCP. If I move one phone to HQ and let it auto register then move it back to br1, it boots and because it cannot acquire DHCP it tries to use the previously assigned DHCP address and is stuck 'Registering'. This tells me that both DHCP and TFTP are not working correctly from br1. This is strange, because I can ping pub/sub fine from 177.2.11.1.
interface FastEthernet0/1/0
description == BR1 IP Phone
switchport trunk native vlan 12
switchport mode trunk
switchport voice vlan 11
spanning-tree portfast
!
interface FastEthernet0/1/1
description == BR1 IP Phone
switchport trunk native vlan 12
switchport mode trunk
switchport voice vlan 11
spanning-tree portfast
!
I executed tshark on the Linux server running VMWare and it looks like the DHCP requests are arriving from br1 phones towards UCM but there is no response from the server. I removed the DHCP subnet and added it again but that did not make a difference. I am pulling hairs at this point.
[[email protected] ~]# tshark udp port bootps
Capturing on eth0
0.000000 177.2.11.1 -> 177.1.10.10 DHCP DHCP Discover - Transaction ID 0x565f
23.615495 177.2.11.1 -> 177.1.10.10 DHCP DHCP Request - Transaction ID 0x5686
32.001650 177.2.11.1 -> 177.1.10.10 DHCP DHCP Discover - Transaction ID 0x565f
87.620370 177.2.11.1 -> 177.1.10.10 DHCP DHCP Discover - Transaction ID 0x5686
91.614048 177.2.11.1 -> 177.1.10.10 DHCP DHCP Discover - Transaction ID 0x5686
While the two br1 phones were continuing their attempt to acquire an IP I rebooted an HQ phones. I noticed the HQ router sends a DHCP request and there is an immediate ACK from PUB. Why would br1 send DHCP Discover constantly? It sends a DHCP request periodically as well and it seems as if UCM just ignores it.
0.000000 177.2.11.1 -> 177.1.10.10 DHCP DHCP Discover - Transaction ID 0x14bf
8.948138 177.2.11.1 -> 177.1.10.10 DHCP DHCP Discover - Transaction ID 0x565f
12.947827 177.2.11.1 -> 177.1.10.10 DHCP DHCP Discover - Transaction ID 0x565f
17.399485 177.1.11.1 -> 177.1.10.10 DHCP DHCP Request - Transaction ID 0x5686
17.406133 177.1.10.10 -> 177.1.11.1 DHCP DHCP ACK - Transaction ID 0x5686
17.406157 177.1.10.10 -> 177.1.11.1 DHCP DHCP ACK - Transaction ID 0x5686
20.948189 177.2.11.1 -> 177.1.10.10 DHCP DHCP Discover - Transaction ID 0x565f
23.606405 177.1.11.1 -> 177.1.10.10 DHCP DHCP Request - Transaction ID 0x5686
Can you post a screenshot of the HQ subnet that works properly?
Here are the screenshots. I did execute 'utils csa disable' but that did not solve my issue. I'm brainstorming as much as I can but I think I will call it quits until tomorrow morning. [:|]
Changing the last to octet from .1 to .0 does not fix it. The Configuration guide shows .1 and it works for HQ. I have followed the guide word for word and tried the task on both CUCM 7.0 and 7.1.3 and end up with the same results. I may be overlooking something but at this point I am wondering if there is something missing either from one of the configs or in CUCM, although I have checked CUCM against the task configuration many times and it matches.
Is it possible for someone from INE to perform the task configuration and do a sanity check to make sure it does work?
Jordon,
The configuration for the task shows "switchport access vlan 12" as the appropriate switch port config for br1. I realize using the native vlan statement is preferred but by the time I could not get DHCP to work for br1 I decided to match the task's configuration to be sure I wasn't doing anything incorrectly. Thanks for the recommendation.
Hey Mark,
I'm sure that you've already tried this, but have you confirmed that the phone is in fact looking for DHCP, and does not have a static address? Also, have you tried shutting the port down, leaving it for a little while, then bringing it back up, and checking the status messages on the phone?
Finally, you may want to try using R2 as a temporary IOS dhcp server, allowing the phone to get an IP, then checking to ensure that you can ping that phone from the CUCM server.
HTH
Josh,
I am absolutely 100% certain the phones are looking for DHCP. The tshark packet capture on the 3750 (port mirror) shows the phones from br1 sending their DHCP request to PUB (DHCP Discover, DHCP Request, coming from 177.2.11.1). I can physically move the phones from br1 to HQ's 3750 switch and they come up fine. I've done factory resets, erase network config, you name it and I've tried it.
At this point I am going to move on to the next lab. I am confident at some point I will come across something that uncovers the mystery. I appreciate everyone's time.
here is your sanity check: you're not alone.
i even had the same problem when i changed to using IOS dhcp
if you do debug ip dhcp packets/events on r2 you will see that the phone just keeps sending requests (not even discovers, as it already has an address and it wants to renew).
even when R2 is the dhcp server it will NOT reply.
2 ways i got past this:
1. factory reset the phone (since you are using internetworkexpert racks, just ask support go in and do it)
2. this one is very tedious but it worked:
--i used IOS dhcp on r2
--then made a reservation (basically a pool with only 1 address that references the phones MAC)
--phone is happy, it gets the address
--then i delete the pool
--phone gets sent a NACK and loses its lease
--phone then behaves like a good phone and communicates normally, no matter which dhcp you use.
not sure if creating a 1-cleint subnet in CUCM DHCP is possible or even works the same, but this is how i won this war.
Aquabrown, thanks for sharing. At least I know it isn't just me. I moved my br1 phones over to my CME router and configured them as ephones and they came up right away. The problem seems isolated to phones that need DHCP from CUCM over the WAN, but I'm not sure where the real source of the issue resides. What model phones are you using? I am using 7965's.
This was all on the internetworkexpert racks.
Aquabrown,
I moved on to lab 2.7 and I did not have any problems when br1 is configured with IOS DHCP. My phones auto registered with PUB very quickly. I had the lab knocked out within minutes. I am not going to give up on isolating the root cause of the DHCP problem. Not sure when I'll get around to it though.
Thanks, Jordan. I had two DHCP subnets in UCM PUB from the very start. It's something beyond the scope of this discussion since Aquabrown appears to have experienced the same problem. I appreciate your input and I'm sure I could use your help for upcoming tasks as well. Thanks again!
Glad you didn't face any additional issues there. I dont know what got into my phones then!!
At any rate we've all picked up lots of other "little things" to be on the lookout for.
Hope you get to the bottom of it soon !