cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3420
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