[c-nsp] IOS(-XE) 'configure replace' robustness

James Bensley jwbensley at gmail.com
Tue Apr 4 07:57:16 EDT 2017


On 4 April 2017 at 12:35, Saku Ytti <saku at ytti.fi> wrote:
> Does anyone regularly use this to replace configuration with new full
> configuration?
>
> e.g. copy config to startup, configure replace nvram:startup-configuration?
>
> I recall trying it when it originally came, and determined that it was
> just breaking everything while going towards the new config, and
> assumed this was by design.
>
> I just tried it on IOS-XE 16.4.1, and I couldn't recreate my original
> problem, what ever changed in the new config, was only thing affected,
> non-changing stuff was not impacted.
> So I'm curious, does someone actually do this in production, and rely
> on it not breaking non-changing config and has had success.

I am working on this right now, I opened a TAC case yesterday and
still warming up the TAC engine at present. Also just a note before,
this is on CSR1000v for me not physical boxes if that makes a
difference.

I opened an issue with NAPALM if you use it, here:
https://github.com/napalm-automation/napalm-ios/issues/21

It's been closed as I didn't have time to look into this further and
engage TAC, but now I finally do so I will be re-opening that issue
soon. Ideally I want the configuration to be locked when doing a full
replace so that no-one else makes a configuration change at the same
time AND automatic rollback MUST also be active so that we have
guaranteed configuration state on the device (either the merge or
replace operation completed 100% without issue or we are 100% as
before the operation started). Otherwise automation is dead at the
door step.

I've been testing with a CSR1000v 3.16.4 image and it seems fucked.
The main issue is that it seems to be applying the config NOT in a
linear order. To clarify;

“copy flash:candidate_config.txt startup-config”
“reload”

This works without issue, no errors during start up. A diff shows no
missing lines from the output of "show run" and what’s in
candidate_config.txt.

If I use "configure replace flash:candidate_config.txt" the operation
fails. If the configuration archive feature is not enabled, the
operation fails and the rollback fails so the devices is left in a
mangled state of useless-ness. Sometimes running the replace operation
a second time will get the device fully configured.

I have also tried “configure replace flash:candidate_config.txt” with
the configuration archive feature enabled and the rollback still
hasn’t worked. I have also tried “configure replace
flash:candidate_config.txt revert trigger error” with the
configuration archive feature enabled and again the rollback hasn’t
worked.

The replace option is failing with the following error:

"Interface GigabitEthernet3's vrf  does not match with cfg vrf mgmt"

Which comes from this line in config:

"logging source-interface GigabitEthernet3 vrf mgmt"

However, as stated above when performing a “copy
flash:candidate_config.txt startup-config” and then reloading the
router the full config is present and working. If I remove the
offending line above something else causes an error, and so on. So it
seems like its trying to apply that line in my candidate_config.txt
file before it has assigned Gi3 to my management VRF? The
candidate_config.txt is ordered similar to the output of “show run” so
I was hoping it would either read the entire file and then apply the
contents in the required or (VRFs first for example) or just apply the
config lines in the order they are listed in candidate_config.txt from
top to bottom, both of these scenarios should work. It seems like XE
is applying the lines at random and it’s failing so TAC case it is for
me.

Cheers,
James.


More information about the cisco-nsp mailing list