Warning: Longish, network nerd content. Look away now if not interested.

DHCP. Wonderful thing, it is. You connect a device to a network, it automagically configures itself and starts working. We all use it (nearly) every time we turn on our laptop, tablet, smartphone, PC, or indeed Internet-connected fridge (FFS).

One company I do work for has started using Avaya IP phones- 1600-series ones, with an Avaya IP PBX, which will gradually replace a network of several over 10 year old Nortel PBXs. To make things easier, the phones will be configured with DHCP, a fairly well documented process.

The central site, with a larger network, has seperate VLANs for voice and data, with one DHCP server on the data VLAN. This is not a problem: the Cisco switches are configured with their interfaces having these two lines in:

switchport access vlan 20
switchport voice vlan 30

Which means untagged traffic will use vlan 20, and voice traffic needs be tagged with vlan 30. The DHCP to do this is easyish too;
in the normal DHCP scope that relates to the data vlan, we add an option 242, with the value

L2Q=1,L2QVLAN=30,VLANTEST=0

The phone will boot into the untagged data vlan 20, and read this option in the DHCP offer it receives. It will then know that it needs to tag it’s traffic with vlan 30, and request an address tagged with that. The router for the voice VLAN then has a

ip-helper [address of DHCP server]

statement to forward on the request. In the voice VLAN, we add option 242 again:

MCIPADD=[a.b.c.d],MCPORT=1719,HTTPSRVR=[a.b.c.d],VLANTEST=0

This actually tells the phone how to find the PBX.

This was all well and good, and indeed working well. Get a brand new phone out, plug it into a configured port, and away it goes.

But…

Smaller offices don’t have the seperate Voice VLAN; it just gets mixed in with the data traffic, and they need some of the new phones. No problem. In fact, this should be easy; we can dispense with all that tedious VLAN nonsense, so we can miss out the Cisco config above, miss out the second DHCP scope, and miss out the first instance of option 242, just adding an option 242 to the local DHCP like this:

MCIPADD=[a.b.c.d],MCPORT=1719,HTTPSRVR=[a.b.c.d]

Yes, it’s not the recommended config, but it is documented around the web, and the previous Nortel IP phones managed.

So, a colleague tries it, taking a working phone to a remote site where I’ve configured the server in just that way. The phone fails to boot. Static addressing fails too, with a odd “failed router” message. Trying to emulate the multiple VLAN setup fails too, and breaking out Wireshark (always the last resort, but the most wonderful tool for free) showed no DHCP requests reaching the server, and testing the server with a laptop works just fine.

Much head-scratching and a full day of testing and debate the next day reproduces the fault at the main site, and a bit more googling reveals that what the PBX engineer told us about not being able to reset the phones unless they register with a PBX is just wrong, though there’s many different suggestions of how to do it, depending on firmware. A reset to factory produces a phone requesting configuration in either the single-VLAN or dual-VLAN operation and booting correctly.

The problem here is that the phone here is very much misunderstanding the Dynamic part. It should, as all the devices I mentioned at the start do, check in with the DHCP server at each boot, and thereby cope with moving site or a network change. It doesn’t. It caches configuration data, trying to use it even when the network around it has changed substantially.

To me, this is just broken behaviour, and here’s the point of the post: if your Avaya 1608/1616 IP phone doesn’t seem to be taking any notice of your DHCP server, then the answer is here: from the linked blog:

Plug phone in.

"Clear all values?" will show. Press # and # again to confirm.