Announcement

Collapse
No announcement yet.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Conundrum : ST-230 and DHCP

    Hello all,

    I am at a bit of a loss today. The short and the sweet of it is this. We are moving our offices and as a result the IP scheme for both the Data VLAN and the Voice VLAN have changed. I set up a small test lab with the following:
    • VLAN (A) = Data
    • VLAN (B) = Voice
    • Our DHCP server has the appropriate Option 156.
    • We are now using Cisco Cat 2690-48PST-L's.
    • Trunking is set with Native VLAN (A)

    Here is where it gets interesting. If I take a 230 and move it to the test bench, it hangs on DHCP. I take the same phone and interrupt the booting process and do a "Clear All Values" (i.e., interupt boot with password and go through the menu, without setting anything) ... it boots like champ -- pulls a DHCP address on VLAN (A) then gets the Option 156 settings and "Reconfigures Network" and then boots to VLAN (B) with the appropriate IP. All is happy at this point.

    I take this phone back to the production network and it grumbles at the DHCP step and basically stops because it can not get an IP. I interrupt the boot and do a "Clear All Values" and it does the right things and is now back in production.

    Further I have noticed that during the boot process it says "DHCP xx Seconds" then after a few moments it reports that it is "Using Cached Lease". At this point it boots correctly and all is happy again.

    I have to admit I am a bit confused. Since it boots correctly and I can see the DHCP leases get updated. I can make calls that originate from the Voice VLAN. The computer that is directly connected gets to the Data VLAN and recieves its IP from the DHCP server just fine. This basically tells me that I should be comfortable that DHCP is functioning appropriately and the switch is doing its trunking/VLAN thing correctly.

    So, the conundrum is: why then, does it apparently completely ignore the DHCP server and use its cached lease? One would think, that it would behave just like any other IP device and pull the next available IP and go about its business. I have also noted that the phone does not seems to renew its DHCP lease on the Voice VLAN/subnet either. Any thoughts are greatly appreciated.

    The goal of course is to have the users pack their desks including their phones and move to the new building, plug in and start the day. If only it would be that simple.

    Many thanks in advance,
    James
    Last edited by [email protected]; 05-19-2009, 08:49 PM.

  • #2
    Not sure, but we've had similar problems. I've had issues where I took 30 phones, NEW, out of the box and plugged them in, and 50% of them booted up correctly and downloaded the firmware, and then other 50% got stuck at the DHCP count-up. If we did the clear command, they would eventually come around, OR, if we just left them all night, they would eventually boot correctly and pull down the firmware.

    We also have the issue where we config a phone at HQ (to get the latest firmware, make sure the extension is assigned correctly, etc.) and then ship to a remote location, and it does not come up. Have to have the user issue the clear command before it boots correctly.

    Again, go figure.

    Comment


    • #3
      Your description is what I've seen, too. We actually have multiple VLANs accross our company, and occasionally staff move from one VLAN to another. So we've had to clear values multiple times. (You can also get it to request a new IP after the phone is booted by pressing mute 25327 pound. 25327 spells clear.)

      My take is that this is by design since booting with the cached lease is faster than going through the multiple boots required if it actually sends a DHCP request each time. Based on my experience, most of the time (I would guess above 95%) when the phones cylce, they haven't changed their VLAN. And, most of us would not be satisified with the cycle time if it always requested a new IP.

      Comment


      • #4
        I've seen that happen on a lot of installs where there were seperate VLANs involved. Generally speaking clearing the values (enter the password, then clear all values). If that does not, reset, go into setup, clear all values, go through all the options, leave them default. When the phone resets and just starts to come back up, right before it tries to get an IP address, unplug it, then plug it back in.

        Seems like simply clearing it out is not always enough, but the above trick works 99% of the time in my experience. The 1% of the time it doesn't seem to work is generally a network problem (bad drop usually) or you need to do a factory reset on the phone itself. Generally have to call Shoretel and get them to tell you how to do it.

        Comment


        • #5
          It also depends on the firmware on the phones. There was an actual bug related to this and a lot of the phones ship with firmware that is quite dated.

          Comment


          • #6
            Originally posted by cburgy View Post
            It also depends on the firmware on the phones. There was an actual bug related to this and a lot of the phones ship with firmware that is quite dated.
            I agree, I saw this on an older build of 7.5 but it doesn't seem to happen in the latest one.

            Comment


            • #7
              If you need to hard reset it... type rramos#, enter phone password, when you see the setting to Factory....... type clear#, unplug phone. when it boots its back to factory defaults meaning no cache, no history of ip settings. I've got a customer that has a screwed up dhcp server and i used that to wipe one of their phones clear to prove it wasn't the phone.

              Comment


              • #8
                Stp

                Believe it or not, Spanning Tree can also cause problems that would look "somewhat" similar.

                If you had spanning tree on in your production environment (good switches) but not on your test bed (more often cheap switches) you could see this kind of problem.

                STP will block all traffic on a port for X seconds. If STP is set to block for 60 seconds, the dhcp request will never really go anywhere. It may not be that the phone is ignoring the DHCP server, it may be that the switch is blocking the traffic. The switch on your testbed would have had its link up for more than 60 seconds, and therefore, would not be affected by the STP on the main switch.

                I have seen STP set at 60 seconds, and a phone that tries to get DHCP lease for 60 seconds. Depending on timing, sometimes it works, sometimes it doesn't.

                You will normally see this manifest itself with workstations being SLOW to get an address. They will get one, it just takes a while. You should get an address on a workstation in a few seconds at most. If it takes 15-30 seconds then STP is probably on..........................

                Highly unlikely, but possible.

                Comment


                • #9
                  Does anyone know if it's possible to clear the cached settings on a phone via telnet? Having the same problem with a couple hundred phones and am trying to avoid making rounds to clear# said phones manually.

                  Comment


                  • #10
                    spanning tree

                    try enabling portfast on the individual E ports on the cisco switch.

                    Comment


                    • #11
                      I have recently came accross this issue with our ShoreTel system which is currently being installed - When phone was plugged in, it would get IP straight away, reboot on the voice VLAN, and then download files.

                      Then after the next reboot, it was taking up to 180 seconds to get an IP address. phone ports were already in edge mode (in 3Com terms stp edged-port..Cisco terms is portfast)

                      I spent time looking at the DHCP transactions in Wireshark; the phone was sitting doing DHCP REQUEST to get it's old IP back; it then gave up and started to use DISCOVER again...and eventually got an IP. At no point did the phone just use it's cached address.

                      Our supplier had a look into the problem and suggested that LLDP could be causing this...

                      I disabled LLDP globally on the 3Com switch stack (4800G) that the phones are connected to...and that instantly solved the problem. Phone rebooted, displayed "using cached address" and was back on the network.

                      Perhaps this may help someone...

                      Comment

                      Working...
                      X