On 4 April 2017 at 12:35, Saku Ytti <[email protected]> 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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
