Provisionning is overwriting the DNS parameter on SPA122 when it should leave it alone

[benjaminlawetz]

I've been updating our provisionning scripts to use the new SPA122 formats, and I've come accross an issue. The provisionning manual states that:

An empty element tag can be used to prevent the overwriting of any user-supplied values during a resync operation.

This works fine on the parameters I checked, but the DNS parameters gets ovewritten with 0.0.0.0 as primary and secondary DNS. I manually set the primary DNS to 8.8.8.8 and the secondary DNS to 8.8.4.4 and the DNS Order to Manual and then use the following provisionning file:

<?xml version="1.0" encoding="UTF-8"?>

<flat-profile>

  <router-configuration>

    <Internet_Option>

      <DNS />

      <DNS_Order>2</DNS_Order>

    </Internet_Option>

  </router-configuration>

</flat-profile>

(The DNS_Order is there to verify that the file was treated properlly)

After the file is applied, the DNS Order is set to DHCP-Manual and the primary DNS is set to 0.0.0.0 and secondary DNS is set to 0.0.0.0

The DNS options should not be changed as per the documentation. Anyways to fix this (Yes, I know I can just not put the DNS parameter, but some parameters we need to change the "ua" without changing the value so the empty parameter was ideal)?

THank you.

[Patrick Born]

Hi Benjamin,

The Provisioning Guide is in error in this case. I've alerted the Documentation Team in order to have it corrected.

Here's how the configuration parameters work:

   Assume a fictitious parameter called myParam is set to “fred” by the user.

   An admin updates the config file and the device resyncs:

• if admin did not include myParam in the config file, then the myParam parameter retains the value of “fred” set by the user
• if admin includes , then the myParam parameter is set to “” [null, empty]
• if admin includes sally,  then the myParam parameter is set to “sally”

I suggest you do not bother with manually setting DNS, just set the values you need in the configuration file.

If you need to change a parameter, remember that an empty parameter is clearing out the value. The only way to leave a value alone, is to not include it in your configuration file.

Regards,

Patrick

----------

[benjaminlawetz]

Hi Patrick,

  the problem is that it doesn't always work like that. The way it has always worked (even way back in the Sipura days) is that:

- fred sets the parameter to "fred" (overriding what was there)

- sets and empty value to "myParam" parameter (overriding what was there)

- does not modify the value of "myParam"

- Not including any "myParam" parameters does not modify the value of "myParam"

Here's the thing, it still works that way for other parameters (tested with ).

So there are different ways of working here. Here's my theory on this (and if Patrcik or anybody else can confirm this):

- The old-style that I described still works that way for all the old parameters

- The new-style that you've described applies to all the new parameters Cisco has added to the Sipura profile in the

- the "ua" attribute that specifies if the user account has read-only, read-write or no access to the parameter only works with the old-style parameters. Anything in the router-configuration ignores the "ua" parameter

Is this correct?

Thank you,

Ben