Search Forums

DHCP issue when using option 156

January 11, 2013 11:32 AM PST
Chris Watson
Layer 3 Communications LLC
We are having a strange problem when we switched over to using option 156 for phones. I will say that it doesn't happen on all the phones, but it is starting to spread. When we add the vlan tagging options the phone boots,you see"reconfiguring network", it reboots and then hangs and never pulls an IP in the VLAN.

This again is only at specific sites, and not all phones at those sites have this issue. They are using a DHCP server cluster running in VM. We have double checked our router setting and the DHCP relays are there. Scopes are there, etc...

Not sure if this could be an issue with VM where the packets are getting lost in translation and don't know how to get back to the phone.
January 31, 2013 11:29 AM PST
Rob Bush
EJ Usa Inc aka East Jordan Iron Works
Sounds like you need to narrow this down to DHCP vs. a VLAN issue first. If it were me, I'd take a port on the switch and put it on a layer 2 VLAN of the Shoretel VLAN and then put my laptop on it and see if I get the correct DHCP address for a device on the Shoretel VLAN. If you don't, then you know it has nothing to do with Shoretel and everything to do with network switching/routing and/or a VMWare/DHCP issues. If you DO get an address, then you should be able to put a phone on that same port and boot it up and also receive a valid DHCP address of the Shoretel VLAN without the option 156 set (turn off 802.1q VLAN tagging on the phone as you won't need to tag the packets since you'll be in a layer 2 VLAN anyway.) If the phone works correctly at that point, then you either have an issues with VLAN tagging or your option code.

We use Option 156 in our environment and it works every time. We have DHCP servers running in VM environment at multiple locations. We have a Cisco 4500 series switch that is acting as a layer 3 router between our production VLAN and our Shoretel VLAN and it handles the DHCP relay option for phones that are dumped into that VLAN via 802.1q VLAN tagging. All is working well. I'd be happy to help in any other way, but I'd need to know more about the networking environment. What switch gear is being used? What 802.1q settings do you have on your ports? What device is acting as router between VLAN networks? Etc. etc.

Oh, one other thing, make sure that LLDP isn't screwing you up. LLDP allows a Cisco switch to broadcast VoIP VLAN ID's SUPER fast so that phones boot immediately into the correct VLAN. If you're running Cisco switches and LLDP is turned on and configured and you don't know it, you may be fighting the wrong VLAN ID settings coming from LLDP and not even realize it. You can turn of LLDP on the Shoretel phone's to rule this out as an issue during testing though.
January 31, 2013 1:20 PM PST
Chris Watson
Layer 3 Communications LLC
Thanks Rob. When I went onsite myself I discovered some interesting things. I had been getting second hand info, so I was guessing their to be an issue with the DHCP or VM server. Turns out, after doing some basic testing (connecting my laptop to the port...) I found that I couldn't get an IP either. Someone had deleted the LAG group in an IDF and not on the core router which caused the ARP table to go to hell. Fixed that and it resolved the issue.
March 15, 2014 1:20 PM PDT
Lixin Chen
Optimal Payments fka Neovia Financial
Hi Rob,
I have exactly same issue now, was working before.
I was trying to follow your trouble step above, so I removed the scope 156 in DHCP, changed the switch port to access port(was trunk port and tag phone and untag data), I can get an phone IP using a laptop, but I can't get an IP using the shoretel phone(cleared all setting, manually setup without tag, without 802.1x, without LLDP), any idea how this happened?

Reply to Post

To reply to this post please Sign In