cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
546
Views
6
Helpful
2
Replies

IOS NED /devices/devices/config augment

sbraicu
Cisco Employee
Cisco Employee

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

1 Accepted Solution

Accepted Solutions

Jan Lindblad
Cisco Employee
Cisco Employee

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.

View solution in original post

2 Replies 2

Jan Lindblad
Cisco Employee
Cisco Employee

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.

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!