Methods for overriding configuration based on dhcp-option

gustavolsson · ‎09-04-2014

We have a scenario where certain SPA112/SPA122's are placed in a specific voice VLAN. For units in this VLAN, we want to change some provisioning parameters, such as SIP registrar, which is only available in the voice VLAN but not from the outside or public internet. To avoid having to change this for every account via the configuration fetched from the regular Profile_Rule, we'd like to be able to "detect" units belonging in this VLAN and server them some additional, specific, configuration so as to override the general configuration provided by the file fetched via Profile_Rule.

Some ways I've thought of:

1. Use DHCP option 150 or 159 in the voice VLAN and then fetch the "overrides" that apply to this VLAN. However it is my understanding that the configuration in Profile_Rule overrides parameters set via option 150/159?

2. Via option 150/159 in the dhcp, fetch a file that only sets Profile_Rule_B to something like "https://example.com/voice-vlan.xml" and that file, in turn, only contains the settings specific to the voice VLAN and hence overrides the settings fetched via Profile_Rule.

Would option 2 work or am I missing the obvious solution here?

Dan Lukes · ‎09-04-2014

DHCP-supplied parameters are used if and only if no Profile_Rule has been configured yet. So [1] seems not to be possible.

If multiple profile rules are configured, they are fetched in order. Profile_Rule_B is fetched only if Profile_Rule has been successfully fetched and applied. In advance, it's not allowed to set same option in more than one profile file, so you can't set a option to some value in Profile_Rule and override it to other value in Profile_Rule_B.

But there is natural solution for such kind of configuration.

Specific voice VLAN is using a known range of IP adress, so use request IP to identify the requests from such VLAN. Respond with appropriate configuration to them, respond with other configuration to requests originated from others IP.

gustavolsson · ‎09-08-2014

Hi Dan, thanks for sharing your knowledge.

The provisioning manual reads

"If the Open format profile contains multiple occurrences of the same
parameter tag, the last such occurrence overrides any earlier ones. To avoid
inadvertently overriding configuration values for a parameter, it is
recommended that at most one instance of a parameter be specified in any
one profile."

So it should work, however it adds complexity and hides some of the parameters to the support personel. I think your idea (with a twist :-) is better; the units use 172.16/16 and are NAT:ed (for all non-SIP traffic) out a single IP so we'll check the public IP instead and if matching, change the proxy address. This change is reflected in the administration portal and hence visible to support personnel as well. This also rids the ambiguity that would arise if we looked at the $EXTIP parameter since many customers might place their unit behind their firewall in their home. This consideration of course comes down to our specific deployment and might not be relevant for others.

Dan Lukes · ‎09-08-2014

If the Open format profile contains multiple occurrences of the same parameter tag, the last such occurrence overrides any earlier ones. To avoid inadvertently overriding configuration values for a parameter, it is recommended that at most one instance of a parameter be specified in any one profile.

True. But change of most parameters value will trigger phone's reboot. Your phone will reboot anytime the configuration become be loaded unless the behavior has been changed with latest firmware. Just try it ...