DHCP on phones

Unanswered Question
Mar 26th, 2009
User Badges:

I have a few phones at a site that are pulling IP address from both the VG and from the server. I checked the phones and CM, both show the right address. I did a ping on the odd addresses and they all time out. I have also deleted the address out of DHCP, but they show back up. Anybody seen this before and know of a solution?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
htarra Wed, 04/01/2009 - 15:18
User Badges:
  • Bronze, 100 points or more

CallManager version? Which VG you are using?


17roush Mon, 04/20/2009 - 05:13
User Badges:

CallManager 6.1(1) and my VG is a 2821.

17roush Mon, 03/08/2010 - 07:38
User Badges:

Hey everyone,


I am reposting this question as I have still not found a solution to my problem.  I have since upgraded to CUCM 6.1(3) and my gateway is still a 2821.  Can anyone out there give me some direction as to where I need to look?


Thanks.

Aaron Harrison Mon, 03/08/2010 - 08:25
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

Hi


Your original post isn't very clear.


Can you clarify exactly what the problem is?


Aaron

17roush Mon, 03/08/2010 - 08:40
User Badges:

Aaron,


After reading my orginal post, I was not very clear, sorry.  So I will try again to best describe my issue.  I have 6 or 7 out of 30 phones that are pulling an IP from both the VG and from DHCP on a Windows 2003 server that is designated for just computers.  The phones are only to be pulling IPs from the voice gateway.  When I try to ping the address that are on the 2003 server, they time out.  I have tried deleting the phones from both CUCM and out of the DHCP on the 2003 server and recreating them in CUCM, but they show back up in DHCP.  If all the phones were experiencing this problem, I might be able to chalk it up to a problem with DHCP on the 2003 server.  But since it is only happening on a handful of phones I am stumped.  Hope I am clearer on my problem.


Thanks.

Wes Sisk Mon, 03/08/2010 - 08:47
User Badges:
  • Cisco Employee,

There are several known conditions such as CSCsr22771 where phones may perform DHCP in both the data and voice vlan.  It's not a 'problem' other than it may deplete the address space for your data vlan.  Best fix is to correct the phone load and switch configuration so phones only DHCP to the voice vlan.  Other workarounds include shortening DHCP lease duration for data vlan so leases timeout; note phones will not renew those leases. Another workaround is to configure the DHCP server to ignore DHCP requests from phones.  All phones include "Cisco Systems" in the the options list provided to DHCP server.  DHCP servers such as Network Registrar can key off this to avoid issuing addresses to those clients.

Aaron Harrison Mon, 03/08/2010 - 08:49
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

Hi


OK - so you have two VLANs (data/voice) per site, and you are expecting the phones to get DHCP from the router in the VVLAN?


I've seen this happen before, and it seems to be that the phones connect to the data VLAN first, and then when they get the VVLAN assignment from the switch (as per the 'voice vlan x' command) they switch to the voice VLAN, and get an address from there.


So they request an address from the data VLAN, then switch to the voice VLAN, at which point they no longer have the data VLAN address - though your DHCP server will have assigned an address for whatever your lease period is.


Is it actually causing you any problems?


Aaron


Please rate helpful posts...

17roush Mon, 03/08/2010 - 12:53
User Badges:

Aaron,


It's not causing any "problems", I would just like to clean up DHCP and have more leases available for computers.

17roush Mon, 04/12/2010 - 13:17
User Badges:

Hey everyone,


Just a little update on my issue, I noticed today that all the phones that are grabbing IP addresses from both data and voice vlans are also not updating their firmware.  I looked around, but I could not find a document on how to either manually update the firmware or completely wipe it clean and start over from scratch.


Load : P00307010200 (should be P00308010200)

Version: 7.1(2.0) (should be 8.1(2.0))



Thanks....

Aaron Harrison Mon, 04/12/2010 - 13:29
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

Hi


Try adding option 150 to both subnets (data/voice) or at the server level. This way as long as the phone get an address and have reachability to the CCM TFTP server (i.e. you don't have ACLs/firewalls preventing the TFTP access) they should get the new firmware.


Maybe after the update they'll behave more as you expect.


Regards


Aaron


Please rate helpful posts..

17roush Mon, 04/12/2010 - 20:00
User Badges:

Took the phone to main office where my callmanager is located and tried to "force" the firmware upgrade with no luck.  I went as far as deleting the phone and re-creating it.  I am truely at a loss as to what I should try next.  Oh also, when I do a cold boot, it does tell me "Version error" before displaying the extenstion.  I am able to use the phone with no problems.

Aaron Harrison Tue, 04/13/2010 - 00:06
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

Hi


The other thing you can try is reconfiguring the switch port to avoid the VLAN 'oddity'... remove the 'voice vlan' command or set it to the same VLAN as the data VLAN. If you have Option 150 set on the data VLAN, the phone should reboot to that VLAN.


If that doesn't work, change the access vlan to the voice VLAN and remove the voice VLAN command. This should mean the phone on that port will boot straight to the voice VLAN. Might pick up the firmware that way.


As I say, shouldn't be necessary to do any of this... do you have a standard edge port config? Maybe post it up in case you've got something odd there...



Aaron

Wes Sisk Tue, 04/13/2010 - 07:19
User Badges:
  • Cisco Employee,

The configuration in CM has nothing to do with the network configuration.  Your phone is not initializing into the correct vlan.  Most networks only provide TFTP access information (DHCP option 150 or DNS) and TFTP access (bascially open all UDP ports) from phone subnets to the CallManager TFTP server.  You willl need to go back to basics at the phone and at the switch:

  1. What is the switch port configuration?  Do you have abnormal CDP configuration or possibly CDP disabled?  Or, are you using LLDP?  There are several ways for phones to get VVLAN from manual config to CDP to LLDP to hard coding the access vlan to the voice vlan.  What is your design and is that working?  You can attempt to hard code the VVLAN on the phone, has this been done  or are you using dynamic config?  Once the phone can get on the network correctly if problems remain then proceed to troubleshoot the phone.
  2. What is the configuration on the phone device itself?  How does the phone identify the TFTP server to use?  http://www.cisco.com/en/US/customer/docs/voice_ip_comm/cucm/admin/3_0_1/p1devsup.html .  Some of those methods are recnetly deprecated for newer model phones:CSCee33745    Remove support for CiscoCM1. You can also have security applied that restricts the phone to only authenticated TFTP servers.  Attempting download from any other TFTP server will be rejected.  If you are attempting to use an alternate TFTP server(or cm cluster) then you must update the CTL file on the original TFTP server or delete the CTL file from the phone.   It is also possible you have a dev signed phone or dev load applied on the server.  Those phones are supposed to be used internal to Cisco or in EFTs only.  Dev signed phones cannot run release signed loads and vise versa.


Perhaps a better place to start is:

  1. What model phone is this?
  2. The console log from the phone - what errors are reported?
  3. Get a packet capture either from the back of the phone or by spanning the switch port
James Hawkins Tue, 04/13/2010 - 11:10
User Badges:
  • Blue, 1500 points or more

From the name of the loads you provided it looks like the phones are 7940/7960.


It might be worth trying resetting the phones to factory defaults using the process below. In step 4 choose option 2. This should get rid of any static configuration entries that may be causing you a problem.


  1. Unplug the power cable from the phone, and then plug in the cable             again.

    The phone begins its power up cycle.

  2. Immediately press and hold # and while the Headset, Mute, and             Speaker buttons begin to flash in sequence, release #.

    The Headset, Mute, and Speaker buttons flash in sequence in order             to indicate that the phone waits for you to enter the key sequence  for the             reset.

  3. Press 123456789*0# within 60 seconds after the             Headset, Mute, and Speaker buttons begin to flash.

    If you repeat a key within the sequence, for example, if you press             1223456789*0#, the sequence is still accepted and the phone resets.

    If you do not complete this key sequence or do not press any keys,             after 60 seconds, the Headset, Mute, and Speaker buttons no longer  flash, and             the phone continues with its normal startup process. The phone does  not reset.

    If you enter an invalid key sequence, the buttons no longer flash,             and the phone continues with its normal startup process. The phone  does not             reset.

    If you enter this key sequence correctly, the phone displays this             prompt:

    Keep network cfg? 1 = yes             2 = no

  4. In order to maintain the current network configuration settings for             the phone when the phone resets, press 1. In order to reset             the network configuration settings when the phone resets, press 2.

    If you press another key or do not respond to this prompt within 60             seconds, the phone continues with its normal startup process and  does not             reset. Otherwise, the phone goes through the factory reset process.

17roush Mon, 04/19/2010 - 14:53
User Badges:

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

Hi everyone,


First off I would like to thank Aaron, Wes, and James for all their help.  I solved both of my issues with DHCP on the phones and a version error that I was receiving on a few 7960s.


  1. The first issue turned out to be a simple fix.  I went back over each line of the configuration on my switches.  I discovered that the port that the data server was plugged into had an access statement that pointed to both the voice vlan as well as the data vlan.  After removing the voice command and deleting the phones out of the DHCP lease ont the dtat side, the phones were only handed out an IP from the voice router.
  2. The second issue was a little tougher to fix, but here is how I got my updates to work (there might be an easier way, if so I would like to know).  I downloaded a firmware version that was in between 7.1.2 and 8.1.2 (I used version 8.0.6).  Next I created 3 files for the phones to use a) XMLDefault.cnf.xml, b) DISTINTIVERINGLIST.cnf.xml, and c) RINGLIST.cnf.xml.  Next I downloaded the configuration file of each of the phones from Callmanager (ex.SEP.cnf.xml).  I even set up a second TFTP server that contained the configuration files and the firmware update files.  Then I edited the file for each of the phones to point to the correct load name for the update (ex. P00308000600).  Next I pointed option 150 on the DHCP scope of the voice router to the second TFTP server I setup.  I then went to each phone and set it back to factory default. I repeated this for each phone that  was affected.  The phones then updated to version 8.0.6 successfully.  Finally I changed option 150 back to the original TFTP server, rebooted the affected phones, and they updated to the version that was on the Callmanager (version 8.1.2).  Again this might not be the best solution, but it was that one that worked for me.


Again thanks to everyone that helped me solve this issue.


17Roush


Message was edited by: 17roush

Actions

This Discussion