ktbyers
commented
5 years ago @jesk78 If I am understanding you correctly,you are misunderstanding the behavior of NAPALM + IOS and a merge operation.
NAPALM + IOS does the following
-
secure copy a configuration file you created and transfer that to the remote device (onto flash:/bootflash:). The file name will be named:
merge_config.txt. This will also be the case for configurations, you do inline in NAPALM (i.e. a /tmp file will be created on your NAPALM control system and that file will be transferred via SCP). -
On commit_conifg() operation, the merge_config.txt is merged into running config using
copy flash:/merge_config.txt running-config. It may or may not beflash:, but you get the idea. -
The line you referenced above
show archive config incremental-diffsis only used for generating a best-effortdiff(and it realistically is not very good). The configuration that is applied is what is specified in your merge configuration changes.
Note, many of the issues you mentioned above go away if using a full-configuration replace. This includes problems with the quality of the diff.
Let me know if I misunderstood what you were asking--though.
xtxerr
network-shark
Hi,
I would like to understand some design decision making behind ios.py:
I do wonder about the use of "show archive config incremental-diffs" to mimic a commit operation in config_merge, which ends up in applying only the differences between the config supplied by the user and what already exists in running config. Precisely the code in https://github.com/napalm-automation/napalm/blob/develop/napalm/ios/ios.py#L406 fishs out supplied configuration lines.
Consider the following in a running config: "ntp server 192.0.2.1"
When rolling out this same ntp server to multiple devices now, where some have this config already and some others do not, then you could just roll out the following snippet to get every device to the same state/configuration: "no ntp ntp 192.0.2.1"
These exemplary two lines of configuration could deal with a heterogenous state in the network, where different ntp settings are applied and are also unknown and one would just like to get everything to the same configuration state.
But hat will happen now is that a device that has already "ntp 192.0.2.1" in it's running config will lose it after the commit, because only "no ntp" is going to be applied (same thing will happen with anything which needs to be removed and applied again eg. router xxx, access-list, etc.).
To deal with this behavior one could try to find out all occurrences of a configuration line on a device which shouldn't exist after a merge operation and remove them individually. Not only is this very hard to do, it's also unintuitively being forced to not use block based configuration abilities.
In another case where you need to remove a whole configuration block or a line and afterwards you need to re-apply it (think of removing a whole ACL and then adding it again with different content) then I cannot think of a way of making this work other than applying the commands in multiple operational steps. which leads to unnecessary long downtimes of the configuration you are working on (between the iterative operations of scp and copy - single transaction with ios.py is at least somewhere around ~15s).
My ultimate question is now: is it really the desired behavior that ios.py interfere with the configuration the user submits by fishing out lines already existing somewhere in running config?