Determine if device is Juniper in YANG file

[Johnny Karms Pedersen]

Hi,

In my YANG file I've got several containers for different platforms;

For IOS-XR, I use the when statement to determine if it's an XR device. The NED ID string I can verify in the NED package meta data file:

container iosxr {
  when "/ncs:devices/ncs:device[ncs:name=current()/../device]/ncs:device-type/ncs:cli/ncs:ned-id='cisco-ios-xr-id:cisco-ios-xr'" {
  tailf:dependency "../device";
  tailf:dependency "/ncs:devices/ncs:device/ncs:device-type";
}

For a Juniper device I've used a similar approach based on the netconf type. However, this doesn't work and the Juniper-Junos-example NED doesn't contain a NED-ID tag in the package meta data file so I use the ID from the NSO configuration.

container junos {
  when "/ncs:devices/ncs:device[ncs:name=current()/../device]/ncs:device-type/ncs:netconf/ncs:ned-id='netconf'" {
  tailf:dependency "../device";
  tailf:dependency "/ncs:devices/ncs:device/ncs:device-type";
}

In this case it evaluates as false for a Juniper device. Any pointers?

[uavsec001]

Hey,

show devices device YourDevice module | display xpath

Does this display name='junos' for you (it should)?

[Johnny Karms Pedersen]

It does, thanks. I'll try to see if I can use that :)

/J

[lmanor]

I'm curious why you are putting all this device-type specific code in to the Service model YANG.

Generally, a basic concept of NSO is to make the Service model abstracted from the device type and have the mapping code take care of the device-type specifics - preferably in the template.   In this way the Northbound interaction with the Service model can remain the same even if the underlying device(s) change from one vendor to another - which is handled in the template by just adding a stanza in the template for the new device-specific configuration.

[Johnny Karms Pedersen]

I agree, however in this case one of the things I'm trying to achieve is to set some constraints in the model that prohibits the user from deploying services on interfaces that are used for other purposes than that of the service. For this I read out the information in the interface description.

In a perfect world, this would've been a standardised path to the element I need to collect information about - but it isn't :|

/J

[gmuloche]

Hello,

You can try to have a look at the capability(ies) of the device (with all the caveats mentionned before in the above answers):

admin@ncs devtools true
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# xpath eval /devices/device[name=\"alu-sr-0\"]/capability[uri='http://tail-f.com/ned/alu-sr']
/devices/device[name='neren100']/capability[uri='http://tail-f.com/ned/alu-sr']
admin@ncs(config)# xpath eval /devices/device[name=\"alu-sr\"]/capability[uri='http://tail-f.com/ned/alu-blah']

This should work better for CLI device than checking the CLI NED as in NSO 5.x the NED-ID will be version dependent so you would have to support multiple ned-id in your when statement for instance:

 37     // may replace this with other ways of refering to the devices.
 38     leaf device {
 39       type leafref {
 40         path "/ncs:devices/ncs:device/ncs:name";
 41       }
 42     }
 43
 44     leaf dummy {
 45       when "/ncs:devices/ncs:device[ncs:name=current()/../device]/ncs:capability[ncs:uri='http://tail-f.com/ned/alu-sr']";
 46       type inet:ipv4-address;
 47     }
 48   }