validate the usage of VRF on a group of devices

[amardkum]

Need to provision devices w.r.t. new VRF but as a part of pre-caution to not affect any existing configuration,
I want to validate if the provided VRF value is already in use or not.

Manually we first check using below CLI:
IOS-DEVICE#show running-config vrf v1988
% No VRF named v1988

If "No VRF", continue with the service else abort/complain.

Wondering, if there's a way/example/reference available, where a parameter like VRF can be checked on a group of Devices before pushing it into each of them?

[yfherzog]

Not sure if you're looking for something to do via NSO CLI or in some sort of programmatic way.

If it's CLI, then you can run this query for multiple devices at the same time. If it exists on any of them, then you get it on the output. Otherwise, you'd get a message that the vrf doesn't exist:

admin@ncs# show running-config devices device ios* config ios:vrf definition foo 
devices device ios-0
 config
  ios:vrf definition foo
  !
 !
!
devices device ios-1
 config
  ios:vrf definition foo
  !
 !
!
admin@ncs# show running-config devices device ios* config ios:vrf definition bar
% No entries found.

You mentioned "group" of devices. Not sure if you mean group as in devices/device-groups. If that is the case, then the answer is not directly.

You can have code (e.g. Python) extract the list of devices in a group and then run the relevant query per each device.

For both CLI and Python, you might also be able to come up with an xpath expression to search for VRF in certain devices instead of repeating the same check per each device.

One last thing. If you want to make this check as part of your service creation code, there are some caveats to take into account. You need to keep in mind that the service create code is running when the service is created and also each time the service is modified.

The way Fastmap works, it removes the service outcomes in-memory upon re-deploy and then calculates them again and sends the diff to the devices.

If the service is the only one configuring anything under the VRF, then the VRF will be removed in-memory, and your check for the VRF existence will be successful.

However, if anything else configured anything under this VRF (another service, out of band changes, etc.), then those configurations will not be removed in-memory, which means the VRF is still going to be in-place when your code runs the check, and it will fail.

Might be a bit confusing, but bottom line is that you need to consider carefully before incorporating checks into a service for in-existence of configs your service is about to create (one approach can be to move the check to pre-modification callback, and only run them on service creation, and not on modification).

[amardkum]

@yfherzog Thank you for your response. I am looking for programmatic way to validate if provided VRF is already in use or not.

Yes, I meant devices/device-group. What I have in plan is to group the devices that would require this test.

Then as you suggested, iterate on the list of devices fetched from the device-group to test for VRF.

We would be adding whole VRF specific config including the VRF. So if it already exists, the underneath config will get overridden. That's where I initiated this discussion.

"

For both CLI and Python, you might also be able to come up with an xpath expression to search for VRF in certain devices instead of repeating the same check per each device.

"

Are you suggesting to make use of XPATH in XML or YANG or the main.py script itself?

[KJ Rossavik]

What if you put a tags="nocreate" on the vrf name leaf in hte xml template? Then the transaction would fail if a VRF with the same name exists.

[amardkum]

@KJ Rossavik Thank you for the pointer. I believe, you were suggesting to have "create" tag and not "nocreate".

With "nocreate" tag at VRF leaf, it is no complaining. However when I used "tags=create", as per its definition - "

Creates a node. The node can not already exist.", it did complain.

admin@ncs# show running-config devices device NSO1-ENTMON01 config ios:vrf definition v1988
devices device NSO1-ENTMON01
config
ios:vrf definition v1988
description CUST01
rd 1988:1988
address-family ipv4
exit-address-family

With "tags='create'";            <vrf xmlns="urn:ios" tags="create">, 

admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# load merge /ncs-run/packages/cc-nso-service/test.config
Loading.
2.17 KiB parsed in 0.12 sec (16.94 KiB/sec)
admin@ncs(config)# commit dry-run outformat native
Aborted: Python cb_create error. item already exists (2): Create of /ncs:devices/device{NSO1-ENTMON01}/config/ios:vrf/definition{v1988} failed because: path already exists
admin@ncs(config)# exit

[yfherzog]

I was suggesting the use of xpath inside the python code.

However, if the number of devices in a group is not huge, it's probably going to be easier if you just iterate that list.

Anyhow, be careful with putting this validation code inside your create() method.

If after you deploy an instance that creates a VRF, anyone adds anything to the VRF not using the service instance (either directly on the device or through NSO), then in case you modify/redeploy the service, I believe your validation is going to fail.

[randreetta]

Hi all,

can you share how (and if) you have solved the issue ? I am trying to understand how NSO works, more in general.

In this specific case, the potential problem could be that of overwriting configurations of an existing vrf, thus adding address-families, unnecessary route-targets and so on. If you have chosen a name for a new vrf, you should check on EVERY PE that it's new. Gathering the output could be a long task, and on a real network people can configure stuff since this check and up to the time you configure your new vrf.

All of this is valid in general, also if you consider physical interfaces (I don't believe NSO checks for an already existing ip address, speed or whatever ... )

Probably it's easier to check this 'manually' from a local configuration database. It's very fast to search for a regular expression on a list of files, filtering for example by name: for example you have 5000 routers/switches but you only search on files containing "_PE_".

In any case, consistency checks should be the real added value for what is called automation.

One other doubt: suppose that you have a DIFFERENT rd value for every PE, even if the vrf is the same (this is to have redundant routes announced by two PEs propagated by all RR to all remote PEs, otherwise this is not guaranteed), how do you manage such a deploy with NSO ? how can you manage a variable that is specific for every PE ?

There should be a solution for this kind of problems. Deploying the same set of cli commands on many PEs is automation but real life is sometimes more complex. And inserting the required variables for EVERY node is NOT automation at all.

It would be easier to deploy standalone python scripts, rather than developing things based on NSO ? or are there solutions for this ?