cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3353
Views
30
Helpful
7
Replies

Yang reference to device platform

tsiemers1
Spotlight
Spotlight

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

1 Accepted Solution

Accepted Solutions

Try the function derived-from-or-self using cisco-ios-cli:cisco-ios-cli as the base, that ought to work.

View solution in original post

7 Replies 7

vleijon
Cisco Employee
Cisco Employee
I would give the ned-ids a second try, you probably want to use something like derived-from-or-self(deref(.)/../ncs:device-type/ncs:netconf/ncs:ned-id, ' cisco-ios-cli: cisco-ios-cli’) but with your own ned-id of course.

For the original question: leafrefs to operational data are a little bit dangerous, since there is no guarantee the operational data won’t change under you, so you do not get the integrity that you want.

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
}

Try the function derived-from-or-self using cisco-ios-cli:cisco-ios-cli as the base, that ought to work.

@vleijon 

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

That was what I meant, yeah. That checks that you are running some version of ios or iosxr ned, without forcing you to a specific one and should be pretty future proof.

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:

  • ncs: In CDM, service YANG models could not have references into device
    YANG models.

(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

Getting Started

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: