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

James Bensley jwbensley at gmail.com
Tue Jun 20 06:27:49 EDT 2017


On 4 May 2017 at 08:24, James Bensley <jwbensley at gmail.com> wrote:
> On 3 May 2017 at 17:09, Nick Hilliard <nick at foobar.org> wrote:
>> James Bensley wrote:
>>> We are generating a full device config using Jinja2 templates.
>>
>> slightly off topic, but did you try feeding this into napalm and seeing
>> what happens?  This works extremely well on arista kit (and I believe
>> XR, junos and nx-os too), as eos allows config merge to be performed
>> before commit.
>>
>> Regarding your question, I'm not currently using config management on
>> any denali devices.
>
>
> Hi Nick,
>
> Yeah this fails through NAPALM, I've read through the code and I
> perform the same process by hand so that I may debug it with more
> verbosity: SCP config file to device, run "configure replace
> flash:candidate_config.txt revert....".
>
> Seem this is CSR1000v/IOS-XE specific.

This is still on going, TAC and the BU aren't being very helpful.
After two months they tried to fob me off with CSCvd31118 but having
retested on a CSR1000v/IOS-XE version with that bug fixed the problem
persists.

So far I have tested and confirmed that config-replace is not working
on 3.16.4aS, 16.3.3, 16.3.4 and 16.4.2 (which is all the version I
have tested).

I have "tidied" the Jinja template as best I can so that the config we
feed to the CSR1000v is as close as I can get it to what one sees in
"show run". For example, I was using lower case letters in IPv6
addresses and IOS displays them as uppercase, that sort of thing which
"should" be irrelevant.

After executing "config replace flash:candidate_config.txt revert
trigger error" the CLI still reports the replace operation has failed,
it also tries to roll-back 5 times and then claims the rollback has
also failed. However, the config replace has worked more or less, this
is the diff after the config replace operation:


! show archive config incremental-diffs flash:candidate_config.txt ignorecase
vm-vrtr-002#$e config incremental-diffs flash:candidate_config.txt ignorecase
!List of Commands:
interface GigabitEthernet1
 no shutdown
interface GigabitEthernet3
 no shutdown
interface GigabitEthernet2
 no shutdown
interface BDI506
 no shutdown
interface BDI504
 no shutdown
interface BDI505
 no shutdown
interface BDI503
 no shutdown
interface Loopback0
 no shutdown
crypto key generate rsa modulus 4096
ip ssh dh min size 4096
snmp-server user myuser mygroup v3 auth sha abcdef priv aes 256 ghijkl
snmp-server ifindex persist
end

So the only commands that are different between the candidate config
and running config are commands that do not show in "show run" like
"no shutdown". So the config has applied exactly as we would like but
the router still claims it has failed and tries to roll-back 5 times
which also fails.

So one can’t programmatically tell if the configure replace operation
was a success or failure (without running a manual diff again) and if
one wanted to actually roll-back again it can’t be relied upon and
verification requires an additional manual diff.

Is any body else pushing config to CSR1000v automagically and having
problems, or is it working just fine for you? Is anyone using an API
instead of the CLI?

Cheers,
James.


More information about the cisco-nsp mailing list