Configuration Changes

[ks]

Hello,

I developed a fairly simple Loopback interface service. If I create a service instance the configuration is applied to the router. If I change the configuration of the device via NSO cli the configuration will change after the commit and the sync check of the Loopback service will fail as I expected. I would like to prevent that somebody will break a service due to missconfiguration. Unfortunately there will be manual and service configurations in my case .

Is it possible to lock certain Parts of the configuration for manual changes?

Is there a easy way to see which parts of the configuration is managed by a service? I found that this is possible via displaying the refcount in the configuration.

Kind regards,

Knut

[alam.bilal]

Hi There,

Would check-sync/deep-check-sync at the service instance level help here?

Below an example for a te-srv service instance "volvo":

admin@ncs(config)# te-srv volvo deep-check-sync outformat

Possible completions:

  boolean  Returns if the service is in sync or not.

  cli      The CLI config that would have to be applied to the device(s) in order

            for the service to become in sync with the network.

  xml      The XML (NETCONF format) that would have to be applied to the device(s)

            in order for the service to become in sync with the network.

admin@ncs(config)# te-srv volvo deep-check-sync outformat

[ks]

Hi Bilal,

this is what I did. Do a sync check on the service. But I guess this would be done during night.

It would be realy cool if NSO says on a commit "caution the part of the configuration you try to change was created by service x. Do you realy want to commit?"

[alam.bilal]

Ah, I see your question now.

Generally, having two systems (operator and NSO here) doing overlapping configuration is not a good idea. There should be clear demarcation of the configuration space that is being touched by each.

Sometimes the operators may have to scribble stuff to resolve highly critical issues and they might have very short time to get things working.. This is when, after the fact, NSO can help check which service instances have gone out-of-sync and help with the reconciliation. Bring service configs back into policy.

You could explore NACM rules and have different users for service/manual configuration. Not sure if that will help. However, best to have clear demarcation of the config space.