03-14-2022 04:15 AM - edited 03-14-2022 04:17 AM
Hi.
We have a LSA topology (running 4.7.x NSOs) and an idea of a onboarding service package where adding network devices to RFS NSOs from CFS NSO would happen. Just adding the device, not storing run configs from them and other stuff.
Plan B is having CFS call RFS NSO via RESTCONF and add device, but I would prefer to do it via LSA as a service so that we have that fancy CRUD being handled by NSO setup on it's own.
I have looked at the NSO Clustering and up to NSO 5.5 it seems it is just the old fashioned precursor to LSA, while 5.7 documentation preparing-the-clustering-of-the-nso-installation explains it in a way that I can't really tell if it is still the old clustering or something new (5.7 is out of the picture for now for us anyway).
My question is, is it possible to do this via LSA somehow without trying to hack together a lsa-ned for devices?
Can I even hack together a lsa-ned for that? In theory I should just grab the NSO yang for devices and work on it a bit.
Solved! Go to Solution.
04-04-2022 04:11 AM
To migrate you will have to update your template to onboard the device directly instead of calling the services instances
/devices/device[rfs-node]/config/devices/device[route]
Can you mark it as solved ?
Thanks
04-01-2022 12:30 PM
Hello,
On NSO 4.x , there is no way to do it directly. You have to develop a service on the RFS that will have all the mandatory leaf to onboard a new device in NSO such as device-name,ip , authgroup , device-type,ned-name , port and trace.
Then once your service is working , you have to generate a LSA-ned for that to be able to declare a new device using your service . The service is going to handle all the CRUD but if you have some service instance referencing the device you won't be able to delete the device. You have to develop a CFS service that will create the device in the specified RFS. You will need a dispatch-map to know every device in which nso-node (RFS) is declared
Once the device is onboarded , you will need to perfom ssh fetch-host-key if it's using SSH or Netconf then a sync-from.
IF you are on NSO 5.X (x<5), you can use the LSA NED tailf-nso-nc-5.x that allow you modify the RFS CDB Directly from the CFS. I think you can access to all NSO internal information .
IF you are on NSO 5.X (x>=5) or later , you can use the LSA NED cisco-nso-nc-5.x that allow you modify the RFS CDB Directly from the CFS. I think you can access to all NSO internal information .
For NSO 5.X , you have only to develop the CFS package and the dispatch-map since you can using the lsa-ned ( cisco-nso-nc or tailf-nso-nc).
04-04-2022 03:06 AM
We have 4.7.X so I solved the issue by, creating a service package and NED for it, like you described as well.
That 5.X -nc thing sounds interesting, will look into it when we migrate.
Thanks.
04-04-2022 04:11 AM
To migrate you will have to update your template to onboard the device directly instead of calling the services instances
/devices/device[rfs-node]/config/devices/device[route]
Can you mark it as solved ?
Thanks
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide