07-24-2017 01:49 AM - edited 03-01-2019 03:56 AM
Trying to have a leafref to the list of existing/configured GigabitEthernet interfaces from a device (IOS). However, it seems that the IOS NED does not augment the /devices/device/config container. (NSO 4.4.2, cisco-ios 5.2.6)
Is there any reason why this is not done?. I was hopping something like that should work, but maybe I am missing something:
path "/ncs:devices/ncs:device[name=‘CPE1']/ncs:config/ios:interface/ios:GigabitEthernet/ios:name"
For ios-xr it works, the /ncs:devices/ncs:device/ncs:config is augmented.
Thanks
Solved! Go to Solution.
07-24-2017 02:14 AM
The YANG model for every device (i.e. both IOS and IOS-XR) describes a tree that has nothing to do with /ncs:devices/... On IOS, the interfaces are under /ios:interface/... On JunOS, it's /junos:interfaces/... If you think about it, it makes sense. Devices cannot, should not and will not know which manager/orchestrator they will be used by, and will hence not publish a model that is adapted to any specific one.
On the other hand, NSO cannot just bring in the model as it is published by each device unchanged. The top level YANG tree in NSO would be very bewildering, and how would you know which device's /ios:interfaces/... that was on the top level in NSO? So to resolve this, the NSO NED compilation *rewrites* the device YANG modules, so that they augment /ncs:devices/... before they are loaded into NSO.
When your NSO application code needs to access the YANG tree of a device, it's therefore important that it uses this rewritten version of the YANG. Every NED has this YANG in the same directory, and this is the directory you need to reference in the --yangpath in your Makefiles etc: <your-NED>/src/ncsc-out/modules/yang/ . Note that this directory is only populated when the NED has been built.
So if you update your application IOS Makefile yangpath, the path statement above should start working.
07-24-2017 02:14 AM
The YANG model for every device (i.e. both IOS and IOS-XR) describes a tree that has nothing to do with /ncs:devices/... On IOS, the interfaces are under /ios:interface/... On JunOS, it's /junos:interfaces/... If you think about it, it makes sense. Devices cannot, should not and will not know which manager/orchestrator they will be used by, and will hence not publish a model that is adapted to any specific one.
On the other hand, NSO cannot just bring in the model as it is published by each device unchanged. The top level YANG tree in NSO would be very bewildering, and how would you know which device's /ios:interfaces/... that was on the top level in NSO? So to resolve this, the NSO NED compilation *rewrites* the device YANG modules, so that they augment /ncs:devices/... before they are loaded into NSO.
When your NSO application code needs to access the YANG tree of a device, it's therefore important that it uses this rewritten version of the YANG. Every NED has this YANG in the same directory, and this is the directory you need to reference in the --yangpath in your Makefiles etc: <your-NED>/src/ncsc-out/modules/yang/ . Note that this directory is only populated when the NED has been built.
So if you update your application IOS Makefile yangpath, the path statement above should start working.
07-24-2017 02:36 AM
Thanks Jan. Yes, it perfectly makes sense, and I was already referring to the rewritten yang. However I was still having the original yang imported in the Makefile and that's why it did not work:
So this was not working:
YANGPATH += ../../cisco-ios/src/ncsc-out/modules/yang ../../cisco-ios/src/yang
while this is OK:
YANGPATH += ../../cisco-ios/src/ncsc-out/modules/yang
Thanks again!
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