topic Re: Lookup for link ID on cisco-ios-xr (xpath problem) in NSO Developer Hub Discussions

Lookup for link ID on cisco-ios-xr (xpath problem)

ron.whitt — Mon, 13 Jul 2020 13:05:57 GMT

Hello experts,

I am trying to look up the link ID for an IOSXR node. Getting error "error: the node 'device' from module 'orlo-vpn' is not found"

Here is the YANG:

module orlo-vpn {
namespace "http://com/example/orlovpn";
prefix orlo-vpn;

import ietf-inet-types {
prefix inet;
}
import tailf-ncs {
prefix ncs;
}
import tailf-ned-cisco-ios-xr {
prefix cisco-ios-xr;
}

list orlo-vpn {
key name;

uses ncs:service-data;
ncs:servicepoint "orlo-vpn";

leaf name {
type string;
}

// Select an endpoint device.
leaf a_device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
// Select the 10 Gig Ethernet port
leaf tenGigPort {
type leafref {
path "/ncs:devices/ncs:device[ncs:name=current()/../../device]/ncs:config/cisco-ios-xr:interface/cisco-ios-xr:GigabitEthernet/cisco-ios-xr:id";
}
}
}
}

I have tried every variant in the [ncs:name=current()/../../device] string.

Here is the full error text when I do a make:

nsoadmin@nso-1D-workshop:~/ncs-run/packages/orlo-vpn/src$ make
/home/nsoadmin/nso-5.2.3/bin/ncsc `ls orlo-vpn-ann.yang > /dev/null 2>&1 && echo "-a orlo-vpn-ann.yang"` \
--yangpath ../../cisco-iosxr/src/ncsc-out/modules/yang -c -o ../load-dir/orlo-vpn.fxs yang/orlo-vpn.yang
../../cisco-iosxr/src/ncsc-out/modules/yang/tailf-ned-cisco-ios-xr.yang:64873: warning: when tailf:cli-drop-node-name is given, it is recommended that tailf:cli-suppress-mode is used in combination. using tailf:cli-drop-nodename in a list child without using tailf:cli-suppress-mode on the list, might lead to confusing behaviour, where the user enters the submode without being able to give further configuration.
../../cisco-iosxr/src/ncsc-out/modules/yang/tailf-ned-cisco-ios-xr.yang:83199: warning: when tailf:cli-drop-node-name is given, it is recommended that tailf:cli-suppress-mode is used in combination. using tailf:cli-drop-nodename in a list child without using tailf:cli-suppress-mode on the list, might lead to confusing behaviour, where the user enters the submode without being able to give further configuration.
../../cisco-iosxr/src/ncsc-out/modules/yang/tailf-ned-cisco-ios-xr.yang:84085: warning: when tailf:cli-drop-node-name is given, it is recommended that tailf:cli-suppress-mode is used in combination. using tailf:cli-drop-nodename in a list child without using tailf:cli-suppress-mode on the list, might lead to confusing behaviour, where the user enters the submode without being able to give further configuration.
yang/orlo-vpn.yang:34: error: the node 'device' from module 'orlo-vpn' is not found
Makefile:26: recipe for target '../load-dir/orlo-vpn.fxs' failed
make: *** [../load-dir/orlo-vpn.fxs] Error 1
nsoadmin@nso-1D-workshop:~/ncs-run/packages/orlo-vpn/src$

Any help or guidance would be appreciated. Thanks

Re: Lookup for link ID on cisco-ios-xr (xpath problem)

lmanor — Mon, 13 Jul 2020 15:43:34 GMT

Hi Ron,

It looks like you are trying the point your xpath to an element 'device' specified in your orlo-vpn module.

From the yang that you've provided there is no yang element tagged 'device', there is an element named 'a_device' inside of your service "list orlo-vpn" which is at the same level from 'leaf tenGigPort'. Presumably this is the device you are trying to use??

That being said maybe something like this is what you are looking for?

leaf tenGigPort {
type leafref {
path "/ncs:devices/ncs:device[ncs:name=current()/../a_device]/ncs:config/cisco-ios-xr:interface/cisco-ios-xr:GigabitEthernet/cisco-ios-xr:id";
}

Re: Lookup for link ID on cisco-ios-xr (xpath problem)

ron.whitt — Mon, 13 Jul 2020 17:39:57 GMT

Hi Imanor,

Thanks for the quick reply. Yeah, I thought was the problem too.

I made the replacement as you keyed it and I get this this:

yang/orlo-vpn.yang:34: error: the node 'a_device' from module 'orlo-vpn' is not found

I also tried [ncs:name=current()/../../a_device] (adding in another level in the ../)

still getting that error.

Re: Lookup for link ID on cisco-ios-xr (xpath problem)

lmanor — Mon, 13 Jul 2020 19:17:50 GMT

Hi Ron,

Not sure where you problem is.. perhaps a control char in your yang file??

This works fine for me:

  list linkid {
    description "This is an RFS skeleton service";
    key name;

    leaf name {
      tailf:info "Unique service id";
      tailf:cli-allow-range;
      type string;
    }
    uses ncs:service-data;
    ncs:servicepoint linkid-servicepoint;

    leaf a_device {
      type leafref {
        path "/ncs:devices/ncs:device/ncs:name";
      }
    }
    // Select the 10 Gig Ethernet port
    leaf tenGigPort {
      type leafref {
        path "/ncs:devices/ncs:device[ncs:name=current()/../a_device]/ncs:config/cisco-ios-xr:interface/cisco-ios-xr:TenGigE/cisco-ios-xr:id";
      }
    }
  }

lmanor@LMANOR-M-24MR:src$ make clean

rm -rf ../load-dir java/src//

lmanor@LMANOR-M-24MR:src$ make

mkdir -p ../load-dir

mkdir -p java/src

/Users/lmanor/NCS/releases/nso-4.7.1.1/bin/ncsc `ls linkid-ann.yang > /dev/null 2>&1 && echo "-a linkid-ann.yang"` \

--yangpath ../../cisco-iosxr/src/ncsc-out/modules/yang -c -o ../load-dir/linkid.fxs yang/linkid.yang

../../cisco-iosxr/src/ncsc-out/modules/yang/tailf-ned-cisco-ios-xr.yang:75622: warning: when tailf:cli-drop-node-name is given, it is recommended that tailf:cli-suppress-mode is used in combination. using tailf:cli-drop-nodename in a list child without using tailf:cli-suppress-mode on the list, might lead to confusing behaviour, where the user enters the submode without being able to give further configuration.

../../cisco-iosxr/src/ncsc-out/modules/yang/tailf-ned-cisco-ios-xr.yang:95922: warning: when tailf:cli-drop-node-name is given, it is recommended that tailf:cli-suppress-mode is used in combination. using tailf:cli-drop-nodename in a list child without using tailf:cli-suppress-mode on the list, might lead to confusing behaviour, where the user enters the submode without being able to give further configuration.

../../cisco-iosxr/src/ncsc-out/modules/yang/tailf-ned-cisco-ios-xr.yang:96897: warning: when tailf:cli-drop-node-name is given, it is recommended that tailf:cli-suppress-mode is used in combination. using tailf:cli-drop-nodename in a list child without using tailf:cli-suppress-mode on the list, might lead to confusing behaviour, where the user enters the submode without being able to give further configuration.

admin@ncs% show devices device xr-0 config cisco-ios-xr:interface TenGigE
TenGigE 0/0/1;

admin@ncs% set linkid lid1 a_device
Possible completions:
alu-0 alu-1 asr-0 asr-1 asr-2 asr-3 asr-4 asr-5 asr-6 asr-7 asr-8 asr-9 dcs-0 dcs-1 ios-0 ios-1 j-0 j-1 xr-0 xr-1

admin@ncs% set linkid lid1 a_device xr-0 tenGigPort ?
Possible completions:
0/0/1

admin@ncs% set linkid lid1 a_device xr-0 tenGigPort 0/0/1
[ok][2020-07-13 15:16:21]

[edit]
admin@ncs% commit
Commit complete.
[ok][2020-07-13 15:16:31]

[edit]
admin@ncs% show linkid
linkid lid1 {
a_device xr-0;
tenGigPort 0/0/1;
}

Re: Lookup for link ID on cisco-ios-xr (xpath problem)

ron.whitt — Tue, 14 Jul 2020 12:54:17 GMT

Hi Imanor,

yep, must have been some kind of unseen control character... (go figure..)

I've posted the working YANG and Template files. (for future reference)

I tried making the package as a Python and as a Template based package, works for both.

This is an unfinished model, just used for troubleshooting.

Here is the working YANG

module or2 {
namespace "http://com/example/or2";
prefix or2;

import ietf-inet-types {
prefix inet;
}
import tailf-common {
prefix tailf;
}
import tailf-ncs {
prefix ncs;
}
import tailf-ned-cisco-ios-xr {
prefix cisco-ios-xr;
}

list or2 {
key name;

uses ncs:service-data;
ncs:servicepoint "or2";

leaf name {
type string;
}

leaf a_device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
// Select the 10 Gig Ethernet port
leaf tenGigPort {
type leafref {
path "/ncs:devices/ncs:device[ncs:name=current()/../a_device]/ncs:config/cisco-ios-xr:interface/cisco-ios-xr:TenGigE/cisco-ios-xr:id";
}
}
}
}

Here is the working template

<config-template xmlns="http://tail-f.com/ns/config/1.0"
servicepoint="or2">
<devices xmlns="http://tail-f.com/ns/ncs">
<device>
<name>{/a_device}</name>
<config>
<interface xmlns="http://tail-f.com/ned/cisco-ios-xr">
<TenGigE>
<id>{/tenGigPort}</id>
<ipv4>
<address>
<ip>10.1.3.3</ip>
<mask>255.255.255.0</mask>
</address>
</ipv4>
<transceiver>
<permit>
<pid>
<all/>
</pid>
</permit>
</transceiver>
<cdp/>
</TenGigE>
<GigabitEthernet-subinterface>
<GigabitEthernet>
<id>0/0/0/5.100</id>
<mode>l2transport</mode>
<encapsulation>
<dot1q>
<vlan-id>100</vlan-id>
</dot1q>
</encapsulation>
</GigabitEthernet>
</GigabitEthernet-subinterface>
<Loopback>
<id>1</id>
<ipv4>
<address>
<ip>10.0.0.3</ip>
<mask>255.255.255.255</mask>
</address>
</ipv4>
</Loopback>
</interface>
<router xmlns="http://tail-f.com/ned/cisco-ios-xr">
<ospf>
<name>L1-L3-LAB</name>
<router-id>10.0.0.3</router-id>
<area>
<id>0</id>
<interface>
<name>Loopback1</name>
<passive>
<mode>enable</mode>
</passive>
</interface>
<interface>
<name>TenGigE0/0/2/3</name>
</interface>
</area>
<mpls>
<ldp>
<sync/>
<auto-config/>
</ldp>
</mpls>
</ospf>
</router>
<l2vpn xmlns="http://tail-f.com/ned/cisco-ios-xr">
<bridge>
<group>
<group-name>L1-L3-LAB</group-name>
<bridge-domain>
<bridge-domain-name>ACME</bridge-domain-name>
<interface>
<name>GigabitEthernet0/0/0/5.100</name>
</interface>
<vfi>
<name>ACME</name>
<neighbor>
<address>10.0.0.1</address>
<pw-id>13</pw-id>
</neighbor>
</vfi>
</bridge-domain>
</group>
</bridge>
</l2vpn>
</config>
</device>
</devices>
</config-template>