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.
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