Phones Not Receiving DHCP IP

Answered Question
Mar 10th, 2010

Hello Experts -

We recently replaced our Call Manager servers, jumping from 4.1 to 7.1 after successfully running DMA backup/restore.

Most everything is working fine except when I've had to add a new ip phone to our system. The problem is that it cannot receive a DHCP ip address from the server.

I've checked all the settings that I can possibly find and everything looks like it is configured correctly. If I manually assign an ip to a phone (we are using mostly 7940's and 7960's), then the phone will boot and register fine and works like it should after flashing its image and getting the correct load and firmware.

Rebooting an existing phone in our environment (phones that were online when we had CM 4.1) will boot up more slowly, but it will finish and come online, so apparently it is caching that info from before.

The problem is with a new phone and the only way for me to get it to work is to manually assign the ip. No other changes were made to our environment, so I don't think it would be useful to try to capture any switch packets. I'm wondering if there is something I've missed with our DHCP setup.

Any advice would be appreciated. My TAC engineer basically gave up on me :-(

I have this problem too.
0 votes
Correct Answer by Adam Thompson about 6 years 8 months ago

Aaron,

You are correct, it should be 10.0.0.0. Hopefully changing this and then restarting the DHCP monitor service will get this working.

Thanks,

Adam

Correct Answer by Aaron Harrison about 6 years 8 months ago

Hmmm... can't believe we all missed that one!

Well - maybe I'm still being a bit slow, but shouldn't the IPV4 Subnet Address be 10.0.0.0? Since the subnet mask is 255.255.0.0, the address 10.0.1.0 is actually a valid host address, not the subnet address.

I suspect the input validation on this config page is either not good or doesn't exist, but the back-end DHCPD service will be rejecting the config.

Set the subnet address to 10.0.0.0 and restart DHCP monitor. Then if it doesn't work... on my system events relating to the DHCPD are in syslog/messages, maybe monitor that for errors when you restart DHCP Monitor.

Regards

Aaron

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.1 (16 ratings)
Loading.
Brandon Buffin Wed, 03/10/2010 - 10:37

If you look in the phone settings when it is booting, does it get the correct VLAN?

Brandon

bergquist Wed, 03/10/2010 - 10:43

Yes it does. The LCD shows "Configuring VLAN" before it goes to "Configuring IP" where it gets stuck and hangs.

Looking at the DHCP settings under Network Config just shows 255.255.255.255 and nothing for TFTP Server or Default Router.

bergquist Wed, 03/10/2010 - 10:58

Yes it is set to the same VLAN id as the others that are working and boot up fine. It bombs out when trying to get an IP, so CUCM DHCP is not running properly but the scope is set and the services are running and activated.

bergquist Wed, 03/10/2010 - 11:28

Yes, just tried it again and still no joy.

I saw in web doc (for an earlier version of CUCM) about DNS settings. Our previous 4.1 CM did not utilize DNS and our current ip phones boot up fine with DHCP enabled, but again, they seem have the required info cached.

I'm wondering if DNS is necessary?

I have to leave for an appt. but will be back later this afternoon and appreciate the help Brandon.

bergquist Wed, 03/10/2010 - 11:33

Thank you, but I'm not sure what you mean by reset sequence? I've unplugged and reconnected the LAN cable which reboots the phone. I cannot perform any sequence to the device via CUCM as the phone is not registered.

bergquist Wed, 03/10/2010 - 12:44

That did not work. I don't think the problem is on the phone side, but rather something to do with the CUCM server itself, namely the Publisher as it

is the one running DHCP.

Paolo Bevilacqua Wed, 03/10/2010 - 12:59

For a try, disable DHCP there, enable it on a router.

Do not worry about conflicting addresses, as router pings before assign.

Adam Thompson Fri, 03/12/2010 - 07:14

Have you taken a look at your system syslog? Launch RTMT and take a look. It will tell you if you have any scope conflicts or issues with the DHCP monitor service.

What is the IP address/mask of your publisher? What is the scope that you have defined?

I ran into a situation where I had my CUCM in the same class C address space as the DHCP scope that I was planning on using for the phones. After I added the scope, the phones would not pull an IP. When I took a look at the system syslog I saw the following error

Error Mesage: Warning: subnet 10.231.51.128/28 overlaps subnet 10.231.51.0/24

I am not sure why it was complaining about the 10.231.51.0/24 subnet when my CUCM cluster was in the 10.231.51.32/28 subnet and the DHCP scope was using 10.231.51.128/28.

I don't know if they is expected behavior or if it is possibly a bug within the DHCP server daemon. Since my setup was in a lab, I just changed the DHCP scope to 10.231.53.128/28 and everything was fine.

If this matches something that you are seeing, maybe you can take this to TAC.

Hope this helps,

Adam

Please rate if helpful

bergquist Fri, 03/12/2010 - 09:49

Thanks Adam, that was helpful.

I was able to view the log and see that it was flagging a DeviceTransientConnection error. In fact, I'm getting TONS of these errors. So I've been researching that this morning, but it wasn't as helpful of a clue as I was hoping. Cisco docementation is fairly vague on this and says it could be a database error, or misconfiguration.

As far as our scope, we have a static 10.0.0.50 for our Pub and a scope of 10.0.1.100 - 254 for dhcp clients, so I don't see that overlap is my problem, nor am I getting that error in my logs.

Aaron Harrison Fri, 03/12/2010 - 09:56

Hi

DeviceTransientConnection just means something has opened a connection to CCM, then closed it - you get this (for example) a lot if you lost a remote site link, and the phones come up and register to one server before realizing a higher-order CCM is available etc... lots of scenarios generate this, so if you have any problems at all you are liable to see them...

I think at this stage with your problem I would be doing one (or both) of these and looking at the output:

1) Packet capture of the phone

2) Packet capture on the CCM (you can run a packet capture on the server using utils network capture and pull the file using RTMT)

The server cap may be very busy, so keep it short...

Regards

Aaron

Please rate helpful posts...

bergquist Fri, 03/12/2010 - 10:35

Thanks Aaron. The TAC tech and I did run a capture on the phone, but I'll get on on the server end and see if that helps. I'll post an update when/if I ever find a resolution to this.

If any other ideas, please let me know. Thank you.

Aaron Harrison Fri, 03/12/2010 - 10:41

Hi

What did the phone capture show you?

You presumably see a request go out; do you see anything come back?

Aaron

bergquist Fri, 03/12/2010 - 10:47

According to Cisco TAC, it showed that there was no response which indicated a problem with DHCP, but the exact problem from the capture was apparently inconclusive. I'll try to get one on the server this afternoon to see what I can find.

Aaron Harrison Fri, 03/12/2010 - 10:50

Hi

Yeah, sounds like the way forward - no reply from the server means:

1) didn't reach server

2) server didn't like the request (i.e. didn't match scope)

3) server response didn't get there

A cap should fill you in...

Aaron

bergquist Fri, 03/12/2010 - 13:14

This is the capture we got from the Publisher:

7709    142.424216    0.0.0.0    255.255.255.255    DHCP    DHCP

Discover - Transaction ID 0x7fae8ceb

The phone will also show the 255.255.255.255 for it's DHCP server. Not sure what to make of it.

Adam Thompson Fri, 03/12/2010 - 13:26

Would it be possible to post some screenshots of you DHCP server and scope configurations?

Thanks,

Adam

Adam Thompson Mon, 03/15/2010 - 12:21

It looks to me that your DHCP scope is setup incorrectly.

In the screenshot that you supplied, you have 255.255.0.0 in the 'Subnet IPv4 Address' field. That field is where you are supposed to enter the network address for your DHCP scope. Example: 10.0.1.0

I have attached what your scope should look like.

Thanks,

Adam

Please rate if helpful

Attachment: 
bergquist Mon, 03/15/2010 - 14:15

Thanks Adam, that was a good catch. Cisco is the one that set that up, but you're right, it doesn't make sense so I changed it. However, my phone is still not pulling an IP and I restarted the DHCP service as well as erased the config on the phone, yet again.

Correct Answer
Aaron Harrison Mon, 03/15/2010 - 17:25

Hmmm... can't believe we all missed that one!

Well - maybe I'm still being a bit slow, but shouldn't the IPV4 Subnet Address be 10.0.0.0? Since the subnet mask is 255.255.0.0, the address 10.0.1.0 is actually a valid host address, not the subnet address.

I suspect the input validation on this config page is either not good or doesn't exist, but the back-end DHCPD service will be rejecting the config.

Set the subnet address to 10.0.0.0 and restart DHCP monitor. Then if it doesn't work... on my system events relating to the DHCPD are in syslog/messages, maybe monitor that for errors when you restart DHCP Monitor.

Regards

Aaron

Correct Answer
Adam Thompson Tue, 03/16/2010 - 05:27

Aaron,

You are correct, it should be 10.0.0.0. Hopefully changing this and then restarting the DHCP monitor service will get this working.

Thanks,

Adam

bergquist Tue, 03/16/2010 - 08:47

Aaron / Adam -

That did it! You guys are awesome man! Thanks so much for your help on this (and everyone else too). I thought we had to be missing something fairly basic, but Cisco TAC is the one who originally assisted with the config of the DHCP in the first place...

You guys should let Cisco know if you need a job. I'll put in a good word for you

Aaron Harrison Tue, 03/16/2010 - 08:50

Cisco? Wouldn't want to work there

Have to say it's a bit naughty of Cisco to throw a /16 subnet in for a CallManager, given that it will cave in if there are > 1024 devices on the subnet...

Good to hear it's working, credit to Adam for actually reading the screen grab properly!

bergquist Tue, 03/16/2010 - 08:59

I selected both your answers as the corect one so I hope that is refected in your

points/feedback properly.

Really, a big thanks once again guys.

-Brian

Aaron Harrison Fri, 03/12/2010 - 13:30

Can you post the actual capture file?

That's basically a headline, doesn't show the detail enough...

Aaron Harrison Fri, 03/12/2010 - 13:56

Hi

I meant the packet cap from the server.

The tftp logs will only be of use once the basic IP config is set on the phone, so that's a step too far ahead.

Cheers

Aaron

Aaron Harrison Fri, 03/12/2010 - 14:14

Hi

So that packet 7709 that you listed - this appears to be a phone on the local server subnet, as there is no DHCP relay agent information associated with it (this would be an IP associated with whatever device is configured with ip helper-address)

Either that - or your phone isn't in the VLAN you think it is. I see repeated DHCP Discovers from this phone, so if you create a DHCP scope on the server for the subnet that the CCM is in, you should see it pick up an address.

Can you confirm the MAC address of a problem phone?

Thanks

Aaron Harrison Fri, 03/12/2010 - 14:25

In fact, scratch that - it's 2230 here, getting sloppy...

So your phones and server are on the same VLAN, it's a class B.

Can you verify that your server has the correct subnet mask? That's the only thing that springs to mind that would prevent the scope that you screen grabbed from handing out an address in response to a local broadcast. If that's not right, server would not see the interface that receives the request as being in the subnet related to that scope.

Regards

Aaron

bergquist Fri, 03/12/2010 - 14:59

The only thing that looks funny to me (I did not do the config on this upgrade, might have been helpfull...) is the subnet mask has 255.255.000.000, instead of 255.255.0.0. but it does have that under the network>ip settings. Not totally familiar with the management gui yet. We went from 4.1 (Windows) to 7.1, but successfully ran a DMA backup/restore, or so I'm told.

When I first became of aware of this issue and it became my problem, DHCP was not even configured...but even after configuring it (and restarting the service) it still have not worked. We have not restarted that actaully Call Manager service or the servers themselves yet and I would think that would not be necessary.

We also are not using DNS, but we were not using it on our last CM's either.

tholemu84 Fri, 03/12/2010 - 12:08

  What model phone is it and did the phone go through any sort of upgrade hen you connected it?  What version of firmware is that phone running compared to the other ones?

-Matt Bowler

bergquist Fri, 03/12/2010 - 13:11

We're using 7940's and 60's and getting the issue on both.

The firmware upgrades to the current version 8.1 (1.0) when I manually assign an ip to a phone so that it can register with CUCM. But then when I configure the phone back to DHCP, it still goes back to the same issue and hangs on configuring IP.

I was also thinking that there could be some kind of firmware mismatch with the older phones and a newer CUCM, but I've not found anything that says that nor did Cisco TAC mention it.

tholemu84 Fri, 03/12/2010 - 13:19

  I know that some of the phones I tested were unable to recieve IP's, or it appeared so.  Sounds too simple, but have you tried going to the erase configuration option, selecting 'yes' and letting it reset?  I don't understand exactly what the problem could be if it is able to retrieve firmware upgrade.  This would appear to tell me that the MAC was entered correctly and your DHCP is working to some extent.  What are you using to direct the TFTP address to the phone?  For testing purposes, we don't use the DHCP server on the actual CME server, but rather use DHCP built into the router with an 'option 150.'


  When you open the status messages under settings on the phone is there anything out of the ordinary showing up?

-Matt Bowler

bergquist Fri, 03/12/2010 - 13:41

Yes that was one of the first things we tried which didn't help.

The reason its getting the firmware upgrade is I manually give the phone a static ip, at which point it can then register correctly with the server and get the correct load config and firmware (or it does that before registering). It works fine with static, so at the very least, I can still swap out a broken phone if need be.

Someone else mentioned about using DHCP with our gateway router, but I'm not familiar with that config setup.

After the phone has successfully registered, I see the SEP(MAC)cnf.xml file listed. There is nothing listed in Status when the phone is in it's stuck, "Configuring IP" state.

Paolo Bevilacqua Fri, 03/12/2010 - 13:47

It can also be an issue with switch firmare (CDP things).

So for example downgrading to 8.0(10) would be a safe choice.

tholemu84 Fri, 03/12/2010 - 14:52

Manually setting up a DHCP server on a router requires a few steps..

  -Setup IP Address Exclude List

ip dhcp excluded-address

  -Create DHCP Pool

ip dhcp pool


   network
   default-router
   dns-server
   option 150 ip

Actions

This Discussion

Related Content