DHCP Discovery...Not working

[super6]

We have all of our VOIP setup a a specific VLAN and all the routing is setup correctly.  At some point after the initial install the phone would no longer pick up an IP address from the DHCP server.  The switches are setup with an IP helper of teh DHCP server but that doesn't help.   The only thing that has really changed is that our 5000 was upgraded to the newest version of the software.  It seems that since that any new phones we install can only work if I hard set the IP info. If I hook up a Laptop to a port that is on that vlan it does get a valid IP address on that VLAN but the phones will not.  I'm having a heck of a time getting any assistance from my vendor without them charging me for it.  Anyone have any thoughts on this or has anyone seen this issue?  Any help is appreciated.  Thanks

[mattybrownuk]

Hi super6,

If you can get an IP address on your laptop connected to your Voice VLAN, that proves that your DHCP server is handing out IP addresses to devices on that VLAN, but I wonder if the DHCP options that the new firmware utilises have changed?

We're on 5.0 SP1 and the DHCP options we've configured are...

128 (TFTP) = 192.168.?.?
129 (ICP) = 192.168.?.?
130 (Mitel ID) = MITEL IP PHONE

Where 192.168.?.? is the IP address of our Mitel 5000 and the values in brackets are the DHCP option names.

When we had our system installed, we found that Mitel 5330e handsets got their IP configuration from DHCP without a hitch, but 5312's were stuck in a loop getting their DHCP configuration.  The only thing that fixed this was to set the TFTP server (firmware location) manually and for the phones to be upgraded.  The firmware the phones updated to from the Mitel 5000 corrected this issue.

Going back to what I said about 5312's, I wonder if your handsets might just be stuck on an old firmware and you're having the same problem as we had?  It seems unlikely that the DHCP options have changed from one firmware to the next - and if they did, it would be mentioned in the release notes.  The firmware for our phones are all 5.1.0.x.  I think the firmware that our 5312's were stuck on was 2.x.x.x.

Good luck and don't reconfigure anything without being 110% sure of what you're doing first.

Matty Brown.

[super6]

Thanks for the reply Matty!   Believe me I am never 110% sure of anything...especially this phone system.  We had the older version of the 533- phones and one thing that I did notice was that it did work one time on a phone that the firmware was on version 4.?.?.?.  Once the phone got connected and upgraded to the latest firmware then i would not pick up an IP address. My thoughts are that something changed when the upgrade was made and we never got a chance to read the release notes.  There may be something in the vendor options that changed as well but i'm guessing NO.  Trying to get help from the vendor without paying for it is tough.  I will continue to gather info and hopefully will get this.  Thanks again for the help!!

[sarond]

As asked by Matty,

What is your current DHCP options for your VLAN.
I would be inclined to use option 43 or 125.
Also what is serving DHCP (Windows/Linux/Router etc..)

[super6]

It's option 43

[acejavelin]

Make sure in your second DHCP offer (from the voice VLAN's scope) that there is no VLAN ID or L2 QoS parameters, they should only be in the initial DHCP offer.

So, first DHCP offer's Option 43 in default VLAN:

id:ipphone.mitel.com;sw_tftp=192.168.200.201;call_srv=192.168.200.201;vlan=6;l2p=6;dscp=46

Then the same option in the DHCP offer of VLAN 6's scope:

id:ipphone.mitel.com;sw_tftp=192.168.200.201;call_srv=192.168.200.201  <Note: no vlan, l2p, or dscp variables)

Some other things to try are default the phone via the Tools&Features menu, and manually put the phone in the voice VLAN via the menus and see if the phone boots, this can also help determine if the initial or second DHCP offer is the problem.

[super6]

Ace,

Thanks for teh reply.  Are you telling me that we need to have Both scopes active and the second should NOT have those inputs?? We have always only had one DHCP server scope for that VLAN.  I have tried to default the phone a number of times and even tried with and without the vlan tag.  I'm not sure where it's at but for some reason the phone system only sees one DHCP server.  Is that because there is only one scope or because of a setting somewhere??  I will turn on both scopes and modify the settings like you suggest.  Anything else let me know.  Thanks for the post!!

[ralph]

Are you using the same DHCP server for both your native vlan and your voice vlan?
If not here's something to check quick:
Look at the dataswitch port connected to your DHCP server.   Be sure it only has the native vlan assigned.

I've seen this on a 3300.   The DHCP server was plugged into a data switch port that was trunked with the voice vlan.
The DHCP server was handing out IP address on the initial request, the phone would switch vlans and request again and both the DHCP server and the 3300 responded.  The server responded 1st and locked the phone up.

Ralph

[super6]

Yes,  using the same servers.  We are getting closer...When I made the change to the OPtion 43 so that the VLan and L@ QOS are gone then the phone picks up an IP address.  However, once I disconnect that phone again and try to plug it back in i am back to the same issue I had...DHCP:Discovery  Using Option 43 and it's stuck.   Grrrrrrr.

[ralph]

Any chance you can post a wiseshark capture at the phone when it boots?

Ralph

[acejavelin]

Ace,

Thanks for teh reply.  Are you telling me that we need to have Both scopes active and the second should NOT have those inputs?? We have always only had one DHCP server scope for that VLAN.  I have tried to default the phone a number of times and even tried with and without the vlan tag.  I'm not sure where it's at but for some reason the phone system only sees one DHCP server.  Is that because there is only one scope or because of a setting somewhere??  I will turn on both scopes and modify the settings like you suggest.  Anything else let me know.  Thanks for the post!!

That is exactly what I am telling you... the default data VLAN scope should have the VLAN/QoS variables in option 43/125/128+ (whichever method you are using, not all three methods) and the phone VLAN scope should not, it will get the VLAN/QoS variables from the initial offer and that is all it needs... Recent set firmware has changed so that if the phone receives these variables in the DHCP offer it will release the DHCP lease, change to tagging it's packet's in the VLAN defined in Option 43/125/128+ and request a new DHCP offer, and continue with that cycle until it receives an offer without it. (To my knowledge this has not been "fixed" yet, actually I don't know if it was done purposely by design for some reason or it is a mistake that will be corrected eventually)

Also, since you are using a single DHCP server and DHCP helper settings to get other networks to that server, make sure only the default data VLAN touches the DHCP server. Make sure the switch port that the DHCP server is connected to only has one, untagged VLAN and no tagged VLANs, and it is not a switch trunk, otherwise it may respond to a broadcast message from another VLAN and hand out a DHCP offer from the incorrect scope.

[super6]

Are you saying that my other 4 scopes need teh option 43 and NOT the VIOIP VLAN?? Do i need to add 125 and 128 as well?  If so they have never been there.   

[acejavelin]

Are you saying that my other 4 scopes need teh option 43 and NOT the VIOIP VLAN?? Do i need to add 125 and 128 as well?  If so they have never been there.

No, that is not what I am saying, I think I got too complicated, let me try to simplify a little with some examples...

VLAN 1 - Native data VLAN (10.0.0.0/24) Default untagged VLAN on end-user switch ports
VLAN 3 - Dedicated Public WiFi VLAN (172.16.0.0/24) Dedicated switch ports for dual SSID AP's
VLAN 6 - Voice VLAN (192.168.0.0/24) Allowed as tagged traffic only on all end-user switch ports, 5000 is at .2

When the phone is connected to LAN initially it will request DHCP in the untagged VLAN, a proper Option 43 in the scope of 10.0.0.0/24 (the native data VLAN) would look like this:

id:ipphone.mitel.com;sw_tftp=192.168.0.2;call_srv=192.168.0.2;vlan=6;l2p=6;dscp=46

Now the phone will accept and then release this DHCP offer to the DHCP server because it got a valid string with vlan variable information, and it will start adding a VLAN6 tag with L2Priority set to 6 to all of it's packets and make a new DHCP request. Your IP HELPER settings and appropriate routing should present the request to your DHCP requesting an IP address from the 192.168.0.0/24 scope (Voice VLAN 6), it should respond with this as a proper Option 43:

id:ipphone.mitel.com;sw_tftp=192.168.0.2;call_srv=192.168.0.2

The phone now knows it is in the correct VLAN since there is no vlan variable in Option 43, it will continue to use VLAN6 and L2Prio 6 and attempt to contact the server at 192.168.0.2, assuming all routing and provisioning is correct the MiNET link and all communication should come up to the phone.

The scope for VLAN 3 could contain an Option 43, if for some reason a phone would do it's initial request in that VLAN, and it would contain the same information as VLAN1's option 43, if a phone will never boot in that VLAN then there is no reason to have Option 43 defined in that scope.

You only need ONE type of optioning in DHCP for the Mitel phones, either 43, 125, or 128-132, not all of them. You potentially could use Option 43 in one VLAN, Option 125 in another, and Options 128-132 in a different one,  but you should not use multiple types of optioning in the same scope.

Note that in older versions of software and firmware, the VLAN/L2P variables were checked against the phones current settings, and if they were the same the phone would ignore them, so for a long time techs made the Mitel provisioning DHCP options the same in all scopes, this changed in newer phone firmwares and system software releases.

[sarond]

I might just step back a little.

How is your switch port programmed that you are connecting these phones to, I think everyone is assuming they are tagged for voice vlan and untagged for data.
From a previous statement you said you plugged a laptop in and received an IP address from the voice network, this says to me that port is untagged voice vlan.

Even if the above is true, what Ace is saying will still work as the switch port will already have the phone in the correct vlan and won't need the vlan to be defined in the DHCP option.

[v2win]

Can you post your switch configuration?