12-03-2019 10:09 AM
Trying to use the device platform to do leafref to the device loopbacks for a service. After adding the following Yang, I am getting the following warnings:
yang/SR-enable.yang:58: warning: the node is config, but refers to a non-config node 'platform' defined at yang/SR-enable.yang:49 yang/SR-enable.yang:65: warning: the node is config, but refers to a non-config node 'platform' defined at yang/SR-enable.yang:49
leaf platform { config false; tailf:link "/ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:platform/ncs:name"; type leafref { path "/ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:platform/ncs:name"; } } leaf loopback-XE { when "current()/../platform = 'ios-xe'"; type leafref { path "/ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:config/ios:interface/ios:Loopback/ios:name"; } } leaf loopback-XR { when "current()/../platform = 'ios-xr'"; type leafref { path "/ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:config/cisco-ios-xr:interface/cisco-ios-xr:Loopback/cisco-ios-xr:id"; } }
Is this the correct way to do this or will it lead to problems down the road? We were using the ned-id instead of the platform but found that it is causing problems when trying to migrate to a new ned in version 5.
Thanks
Solved! Go to Solution.
12-03-2019 12:25 PM
Try the function derived-from-or-self using cisco-ios-cli:cisco-ios-cli as the base, that ought to work.
12-03-2019 11:24 AM
12-03-2019 11:49 AM
I'll work on the ned_id again, we currently have a tac case going for this. When using the ned-id we are failing to upgrade NEDs with the 'migrate' command in NSO 5.2.1. Was trying to find a solution in yang to constrain items with something that can be versatile and not depending on changing ned ids when the device uses a new ned.
leaf deviceType { when "current()/../device-name"; type leafref { path /ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:device-type/ncs:cli/ncs:ned-id; } } leaf loopback-XE { when "contains(current()/../deviceType, 'cisco-ios-cli')"; type leafref { path "/ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:config/ios:interface/ios:Loopback/ios:name"; } }
Results in errors when trying to migrate:
admin@labncs# devices migrate device [ LAB920 ] new-ned-id cisco-ios-cli-6.38 migrate-result { device LAB920 result false info illegal reference SR-enable LAB920 deviceType }
12-03-2019 12:25 PM
Try the function derived-from-or-self using cisco-ios-cli:cisco-ios-cli as the base, that ought to work.
12-03-2019 01:20 PM - edited 12-03-2019 03:15 PM
Updating Post.
I think I was able to figure out what you were saying about using the derived, I just wasn't importing the correct module into the yang.
This works when I import the following
import cisco-ios-cli { prefix cisco-ios-cli; } import cisco-iosxr-cli { prefix cisco-iosxr-cli; }
Full Yang
module SR-enable { namespace "http://example.com/SR-enable"; prefix SR-enable; import ietf-inet-types { prefix inet; } import tailf-common { prefix tailf; } import tailf-ncs { prefix ncs; } import tailf-ned-cisco-ios { prefix ios; } import tailf-ned-cisco-ios-xr { prefix cisco-ios-xr; } import cisco-ios-cli { prefix cisco-ios-cli; } import cisco-iosxr-cli { prefix cisco-iosxr-cli; } description "Base Enable of SR on router"; revision 2019-10-03 { description "Initial revision."; } list SR-enable { description "This is an RFS skeleton service"; key device-name; uses ncs:service-data; ncs:servicepoint SR-enable-servicepoint; leaf device-name { type leafref { path "/ncs:devices/ncs:device/ncs:name"; } } leaf loopback-XE { when "derived-from-or-self(/ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:device-type/ncs:cli/ncs:ned-id, 'cisco-ios-cli:cisco-ios-cli')"; description "Make sure NED is of type cisco-ios-cli"; type leafref { path "/ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:config/ios:interface/ios:Loopback/ios:name"; } } leaf loopback-XR { when "derived-from-or-self(/ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:device-type/ncs:cli/ncs:ned-id, 'cisco-iosxr-cli:cisco-iosxr-cli')"; description "Make sure NED is of type cisco-iosxr-cli"; type leafref { path "/ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:config/cisco-ios-xr:interface/cisco-ios-xr:Loopback/cisco-ios-xr:id"; } } leaf custom-sid { when "current()/../loopback-XE != 0 or current()/../loopback-XR != 0"; type uint16; } } }
Is this a more future proof way of doing it? It seems to have worked with doing a device migration as well.
Thanks for the help
12-03-2019 07:42 PM
04-06-2020 02:58 PM
Hi, I am using 5.2.0.3 and have not been able to leafref from a service into a NED config as shown above. I understood that there was a known limitation in NSO 5 due to CDM. I am working on a port to NSO 5.3.1.1 and saw this in changes:
(ENG-21618)
I have been trying to replicate the above but I don't seem to be having any luck. I keep getting:
yang/slf-loadbalancers.yang:221: error: the node 'interface' from module 'tailf-ned-cisco-ios' (in node 'config' from 'tailf-ncs') is not found
The code is quite similar. The code is:
type leafref {
path "/ncs:devices/ncs:device[ncs:name=current()/../name]/ncs:config/ios:interface/ios:Loopback/ios:name";
}
Can you do me a favor and confirm whether ENG-21618 does what I was hoping it would or if I'm doing something obvious, I'd really appreciate a pointer. The PDF for CDM Migration for NSO 5.3.1.1 does not have an example of this.
Thanks in Advance,
Jim
04-07-2020 01:38 PM
I moved this to its own Discussion. Solved at.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the NSO Developer community: