Mitel 5000 - prevent DHCP leases to PCs

[Rishi]

Over the past few weeks it seems that some of the PCs in the office have been grabbing IPs from the Mitel 5000 DHCP instead of the desired DHCP servers. Are there any settings on the 5000 that I can adjust so that it only responds to Mitel phone DHCP requests, or do I need to reconfigure my network?

[cholzhauer]

You'll need to reconfigure your network.  You should use a VLAN to separate your phones from your PCs.  If you want to use the 5000 to hand out DHCP for your phones, OK, but I wouldn't use it for your computers because of its limitations.

[Tech Electronics]

Rishi,

I am not saying that cholzhauer is incorrect, because in reality you should have the voice and data networks separated. With that being said the built-in DHCP server is capable of only providing DHCP to the Mitel Phones that send the correct ID.

Under System > IP Settings > DHCP Server Settings > IP Address Range > [range value]

look for Client's Vendor Class ID Must Match Name: and set it to Yes. If it already set to yes then the phone systems built-in DHCP server is not handing out addresses to your PCs.

Thanks,

TE

[cholzhauer]

TE is of course correct on the Mitel side, but from a pure networking standpoint, I'd reconfigure.

I've heard of Mitel refusing to help if this isn't done...YMMV.

[acejavelin]

Reconfiguration of the network into VLANs is the proper way to do it, or let the Mitel hand out ALL DHCP (it handles it quite well actually), having two DHCP servers in the same subnet, even with Vendor Class ID option, is a recipe for disaster (well, problems at least).

[Tech Electronics]

Rishi,

As I stated before I totally agree with cholzhauer on this subject and if you do decide to make that change then making the following changes to the network.

VLAN Data:Keep as your native VLAN

VLAN Voice: turn on LLDP-MED or CDP whichever you switches support; make sure that L2P is 5 or higher and DSCP is 46 or trusted.

Set all the ports as Untagged for the Data VLAN and tagged for the Voice VLAN, except the one the MiVO-250 is plugged in set it to Untagged for the Voice VLAN.

Make sure whatever is handling Layer 3 on your network knows of the Voice VLAN and will route traffic between the two.

Thanks,

TE

[Rishi]

Thank you. I completely agree that I should properly configure the VLANs, but that is a much larger project that I will need some more preparation to handle.

Tech Electronics, with regard to your comment, I read in another thread in this forum that I also need to set the Name to ipphone.mitel.com (It's currently blank). Is that correct, or do I just need to do the step you listed?

[lowradiation]

In the IP Address Ranges folder, set the Protocol to DHCP only (default is BootP or DHCP)
I have found that occasionally PCs will get IP addresses when BootP is enabled (even though "Client's Vendor Class ID Must Match Name" is set to Yes)

[Tech Electronics]

Rishi,

Are you using an external DHCP server or the one built into the 5000? If it is external then the string ipphone.mitel.com is necessary for it to work properly as that is the same as option 130 when it is broke out into individual options.

If you are using the built-in DHCP server this is already configured and setup by default.

Thanks,

TE

[Rishi]

So I changed Client's Vendor Class ID Must Match Name to YES, restarted as it suggested and then only some of my IP phones (mostly the original ones purchased) were able to connect, with the rest stuck in Discovery mode. I even added ipphone.mitel.com to the name, but that didn't help.

At this point, I turned back off the Client ID setting, restarted again and my phones are all connected. Any idea what configuration setting I probably missed on some of these phones?

Thanks.

[acejavelin]

So I changed Client's Vendor Class ID Must Match Name to YES, restarted as it suggested and then only some of my IP phones (mostly the original ones purchased) were able to connect, with the rest stuck in Discovery mode. I even added ipphone.mitel.com to the name, but that didn't help.

At this point, I turned back off the Client ID setting, restarted again and my phones are all connected. Any idea what configuration setting I probably missed on some of these phones?

Thanks.

This is the problem with running multiple DHCP servers in the same subnet, if the "other" DHCP server is faster than yours, then it will hand out the addresses first and your devices get the wrong IP address or options... Separate the VLANs or use a single server.

[Tech Electronics]

Rishi,

When you say that the "original" phones get an IP Address and the rest don't.

What style are the remaining phones?

Are all of your phones Mitel 53xx series phones?

Thanks,

TE

[Rishi]

Rishi,

When you say that the "original" phones get an IP Address and the rest don't.

What style are the remaining phones?

Are all of your phones Mitel 53xx series phones?

Thanks,

TE

All are Mitel 5324s. When I say original, I mean that the vendor I work with may have customized them (perhaps in the 5000) before shipping to me, whereas most of the others were shipped direct to me. IIRC, with the original phones, I had the option to enter the controller IP and it would then work fine. I couldn't locate that option when trying to resolve the issue with these other phones.

I'm also not fully clear why the phones would stop working by changing the Client ID setting to YES, unless the relevant Mitel info isn't reaching the 5000 (due to bad VLAN config)? In one instance tho', 4 phones are connected to the same HP PoE switch, that does have the voice VLAN settings set up. Two of these phones worked when I made the client ID change, two didn't (again the older phones worked.)

Thanks.

[Tech Electronics]

Rishi,

Do the older phones have any manual settings setup in them. Hold down the Blue Application key while the phone boots up and it will bring you into it configuration. Then look under Networking Settings or QoS depending on what firmware version they are. Maybe they have the Voice VLAN manually tagged if you don't have LLDP setup on your HP Switches.

Thanks,

TE