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