Preventing NSO service from removing config

[tcragg1]

Hi team,

I have a python service template in NSO that builds BGP VRFs on IOS-XE routers. The code creates the BGP address family object, using "root.devices.device[service.hostname].config.router.bgp[local_as].address_family.with_vrf.ipv4['unicast'].vrf.create(vrf_name)", and then performs the rest of the necessary configuration.

Unfortunately, some of the VRFs have had BGP network statements added in manually after they were provisioned, and if I do a service re-deploy dry-run, NSO wants to remove these manually added statements. Is there a way with a python template to tell the service not to delete any pre-existing configuration within the BGP VRF? Re-writing the service logic to include the network statements isn't really an option.

[hazad]

There is unfortunately no way to achieve this in templates as far as I know. You need to reconcile the service in this case, with the "keep-non-service-config" flag, so that NSO can see that something has been added to the list item after it was created by the service, and bump the refcount of the list item to 2.

[tcragg1]

Unfortunately this isn't an ideal solution for this situation. This service creates BGP VRFs and all the associated configuration. If someone adds manually configured prefix limits or network statements to the VRF and I do a "service re-deploy reconcile { keep-non-service-config }", if the service instance later gets deleted NSO will not delete most of the BGP config, as it believes the manually configured pieces need to be left in place.

Is it not possible to read the config that is in place on the target router and store the relevant config as variables in the python service script, then use that to modify the service configuration (so if max-prefix statements or network statements exist within the BGP VRF, they can effectively be mirrored in the service config)?

[hazad]

It would probably be possible to open another read transaction within the service callback, read the data on the device, and expand the service config based on that. But then you'd have to figure out a way to keep track of service vs oob config, which would complicate things. A "hack" that I don't see as ideal.

[rogaglia]

Hi, we are adding a wider set of capabilities on how to deal with these brownfield environments in NSO6.5. We should have a session in May's developers day. Please join us in Stockholm in May.

In the mean time, what can you do? For sure you can create an action as stated below to "check-sync" to identify those services that have this situation. When you do that you have two options:

- Perform the service re-deploy with the option "keep-non-service-config", which will increase the refcount as stated. One point is that the extra config will never be deleted.

- Create a small "auxiliary" service with a simple template that only creates the VRF and apply a service instance to the target device. With this auxiliary service, the refcount is also moved up and the original configuration will be deleted when you delete the auxiliary service instance.