Comware

I've got a big dilemma I'm having trouble fixing.

We have a Procurve network split into around 50 location specific vlans. On top of this we have 2 voice vlans (each 512 addresses in size) split across the network 50/50. The voice vlan subnets are used for Mitel IP Telephones. Currently each data subnet/vlan has an option in its DHCP scope (Option 125) which tells the IP phones which voice vlan they should boot into. This works fine however we're starting to run out of addresses. We can add a third voice vlan but phones being deployed to existing areas will still fail to boot because, as far as I know, you can only set one vlan in option 125 per data subnet.

Is there a way of specifying multiple vlans in DHCP which are tried in order until a suitable address is returned?

I thought about not specifying any vlan, letting the phones obtain addresses from the data vlan and using DSCP for QoS. However our client subnets are all class c or less address spaces and would not have enough spare to accomodate the phones.

Mitel haven't been very helpful so far and seem unable to even tell us if we could push the phone vlans above 512 active devices. We haven't tried this due to the convention of not exceeding this number of devices in a broadcast domain.

This can be a problem. What you can do is to setup a second dhcp server and both with a part of the scope. Place on the first dhcp server the first vlan number and then the other dhcp server with the other vlan options.

Is more a workaround then a perfecct solution.

Goodluck

Maybe you could consider using LLDP-MED (802.1AB) instead of the dual boot solution.

After the initial booth the Phone will auto discover the voice vlan which is set on the switch. You don't need to use option 125 anymore.

Thanks Sietze, I'll investigate and try that in our test lab. Presumably then even for a geographical area the phone would only pick the voice vlan that is tagged on its link, allowing us to use multiple voice vlans in one switch cabinet?

I've tested LLDP-MED this morning and it worked well. This means we can solve our problem by rolling out new IPT vlans to specific switches or specific ports and do away with the DHCP options which were restricting us in the past.

Thank you very much.

(sorry messed up the points scoring)