08-10-2017 05:24 PM - edited 03-01-2019 03:57 AM
Hello
I've built a "netconf" ned for Cisco NCS 5001 router (IOS-XR) using the downloaded yang files from here.
Named the built ned package as ncs-iosxr. The device (router) is configured as ncs1 in NSO.
Was able to fetch the ssh-keys and can connect to the Cisco NCS router successfully:
admin@ncs> request devices device ncs1 connect
result true
info (admin) Connected to ncs1 - 172.25.130.94:830
But I get the following error when trying to sync-from device:
admin@ncs> request devices device ncs1 sync-from
result false
info RPC error towards ncs1: unknown_element: ns1:bmp-server-all
Here is the log while sync-from runs:
==> logs/devel.log <==
<DEBUG> 10-Aug-2017::18:14:11.555 kane ncs[24913]: ncs Requestor {'sync-from',103,<0.2601.1>} tries to acquire lock for device <<"ncs1">>
<INFO> 10-Aug-2017::18:14:11.556 kane ncs[24913]: ncs syncing from ncs1...
<DEBUG> 10-Aug-2017::18:14:14.063 kane ncs[24913]: ncs Device <<"ncs1">> is unlocked
<INFO> 10-Aug-2017::18:14:14.065 kane ncs[24913]: ncs syncing from ncs1 error
And here is the device configuration on NSO:
admin@ncs> show configuration devices device ncs1
address 172.25.130.94;
ssh {
host-key ssh-rsa {
key-data "AAAAB3NzaC1yc2EAAAADAQABAAABAQCs5RzADgZ90o7wStPaQ8apZ8V1SWUsbzjxHzlGAMPZ\nGAzzZctOzya936qsNfBbdr/ldyXSSPImt3OJYUN0ewYOGMy/AUNe+oBXUlo7WLM3TMZPjWUx\naQHvttgt9kfueyR3s7a1naxzvvtGV/xkFGuUO9i8wKcl0wknMBR/TftPHutmikRHthR1sfy2\nDAKFldJEgynaDJt6jnycwRsKV5RiulJWLg4Uw8EXisfrvIB6m/UWKJ7yOdaeV9N9CJGnJFS\njxX/CEZzQR7Io5k48rh/TzFMC//puRSa2tfNwAPWbiIIRyAyeAR7pDTHq/cKdYLJuarJ7B6t\nGrakFDGuyykZ";
}
}
authgroup ncs5k;
device-type {
netconf {
ned-id netconf;
}
}
state {
admin-state unlocked;
}
Solved! Go to Solution.
08-11-2017 01:31 AM
Most likely the YANG models on the device do not match exactly the YANG models you downloaded, so NSO is annoyed by "extra content" coming from the device.
A better way to build your NETCONF NED might be to download the YANGs directly from the device, and XR supports this feature. This guarantees that you get the right version. You can easily do that using Pioneer. You'll find Pioneer, and the README explaining what to do, here https://github.com/NSO-developer/pioneer
08-11-2017 01:31 AM
Most likely the YANG models on the device do not match exactly the YANG models you downloaded, so NSO is annoyed by "extra content" coming from the device.
A better way to build your NETCONF NED might be to download the YANGs directly from the device, and XR supports this feature. This guarantees that you get the right version. You can easily do that using Pioneer. You'll find Pioneer, and the README explaining what to do, here https://github.com/NSO-developer/pioneer
08-13-2017 10:06 PM
Thanks Jan. Appreciate your quick response. Is Pioneer Cisco's official tool to pull models off of devices even for production use?
08-14-2017 12:56 AM
There's nothing official about Pioneer, but as far as I can tell, that's the most used approach for building NETCONF NEDs. I can support in case you need some help.
08-15-2017 05:06 PM
Thanks Jan. Here is what I did:
1. followed Pioneer procedure to build the netconf ned. There were couple of errors (see below), so I disabled the offending models (actually disabled entire openconfig models since I have heard they have errors):
yang/cisco-xr-openconfig-interfaces-types.yang:8: error: module 'openconfig-interfaces' not found
make: *** [ncsc-out/.done] Error 1
failure Build failed
yang/tailf-common-monitoring.yang:164: error: the node 'mode' from module 'tailf-confd-monitoring' is not found
make: *** [ncsc-out/.done] Error 1
failure Build failed
2. disabled:
*openconfig*
tailf-confd-monitoring
3. instead of "pioneer yang install-netconf-ned", I simply created a symlink to the built ned directory from the runtime packages directory (because I noticed "pioneer yang install-netconf-ned" actually copies all the files over - please let me know if this is not ok)
4. packages reloaded successfully. Sync-from dry-run successfully shows the dry-run outcome
5. attempted to sync-from device:
admin@ncs% request sync-from
result false
info devices device ncs1 config policy-manager policy-maps policy-map qos QOS-IN policy-map-rule classify-set_cos4 qos service-function-path : the 'must' expression "path-id" failed
[ok][2017-08-15 16:40:13]
I'm assuming this is an error in the yang file?
This is the relevant snippet from that yang file that complains, it needs path-id but in the actual configuration of the device there is no path-id:
container service-function-path {
must "path-id" {
description "path id must be present.";
}
description "Policy action service function path.";
leaf path-id {
type uint32 {
range "1..16777215";
}
must "../index" {
description "index must be set.";
}
description "Service function path id.";
}
leaf index {
type uint8 {
range "1..255";
}
description "Service function path index.";
}
leaf metadata {
type string;
description "Service function path metadata name.";
}
}
and here is the actual configuration on the device from sync-from dry-run (for the section it complains):
<policy-map>
<type>qos</type>
<name>QOS-IN</name>
<policy-map-rule>
<class-name>classify-set_cos7</class-name>
<class-type>qos</class-type>
<set>
<traffic-class>3</traffic-class>
</set>
</policy-map-rule>
<policy-map-rule>
<class-name>classify-set_cos5</class-name>
<class-type>qos</class-type>
<set>
<traffic-class>2</traffic-class>
</set>
</policy-map-rule>
<policy-map-rule>
<class-name>classify-set_cos4</class-name>
<class-type>qos</class-type>
<set>
<traffic-class>1</traffic-class>
</set>
</policy-map-rule>
</policy-map>
08-16-2017 02:31 AM
You did everything correctly. You've just discovered a bug in the YANG for this version of XR. What version of XR are you using? Would it be feasible to upgrade to a newer version? Many bugs like this have been eliminated in recent versions. Or you might try to actually create a path-id in your config as a work around.
If you can't upgrade and or don't find this has been resolved in latest code, I guess you should file a bug report on XR.
I can explain the YANG details here to you or the XR team if it's not obvious. There have been many instances of this particular issue in the older XR versions. "Older" in XR NETCONF/YANG context means IOS-XR 6.1.x and 6.2.x.
08-16-2017 06:28 PM
The IOS-XR running on my NCS 5001 router is 6.2.2.17I. I'm a bit confused - according to Cisco, this is the latest version of XR, but you mentioned 6.2.x is considered "old" in netconf/yang context. Do you mean there are higher XR versions available but maybe for other platforms?
Regarding the workaround you mentioned to create path-id, I haven't found such entity to configure on the router under the QoS section it complains about. So it's a mystery to me why path-id even exist in yang for that QoS section. Perhaps a bug itself?
I also have couple of other questions Jan, if you don't mind:
1. In my previous post I mentioned that I created symlink manually (from runtime packages directory to ned directory) instead of "pioneer yang install-netconf-ned". What is the exact difference between the two? The reason I'm asking is that I noticed the directory that pioneer-install command creates under run directory is about 35M bigger than the built ned directory that I simply created symlink to. Seems like pioneer-install command creates some "extra" stuff in addition to what already exists in the built ned directory?
2. I tried to add another device (called vcv1) in NSO, and as soon as I added its address (before even commit), I saw tons of logs generated in xpath.trace (couple of samples below) and prompt took few seconds to return. Why does NSO walk through all these XR config/yang paths for a new device that it doesn't even know its device-type? I mean at this point the only thing NSO knew about the new device was its mgmt IP address and even that was not committed, so why did it walk through all xpaths of XR (if I'm understanding it correctly anyways):
==> logs/xpath.trace <==
16-Aug-2017::12:54:42.724 Evaluating XPath for: /devices/device[name='vcv1']/config/aaa:
not(../../ncs:module) or ../../ncs:module[ncs:name='Cisco-IOS-XR-aaa-lib-cfg']
get_next(/ncs:devices/device{vcv1}/module) = false
16-Aug-2017::12:54:42.725 XPath for: /devices/device[name='vcv1']/config/aaa returns true
16-Aug-2017::12:54:42.727 Evaluating XPath for: /devices/device[name='vcv1']/config/aaa/aaa-aaacore-cfg:aaa-subscriber:
not(../../../ncs:module) or ../../../ncs:module[ncs:name='Cisco-IOS-XR-aaa-aaacore-cfg']
get_next(/ncs:devices/device{vcv1}/module) = false
08-17-2017 04:56 AM
I'm not the one to ask about which XR versions are available for different platforms, I'm afraid. Recently, I've been testing IOS-XR 6.4.x mostly, and I know 6.5.x exists in development builds. On 6.2.x, I think you're likely to encounter more issues similar to the one you found here before you're finished with your use case.
To fix the problem, here's another work around you can try: In your NED build, remove/comment out that must "path-id" { ... } statement you already found. That statement isn't going to do you any good anyway.
Re question (1): The main difference between making a copy of the NED and making a symlink is that if you make more copies, they will all be independent of each other and the NSO installation. If you make a fix in one copy, it won't show up in/disrupt the other copies.
If you make multiple symlinks to a NED, any modifications you do will show up in all systems using it. If you recompile the NED because you upgrade the NSO runtime to a new version, all other users of a symlink will also see the update. Even if you upgrade your NSO installation, you may not want to upgrade the NED. But now you might be using a NED living in an installation of an old version of NSO, that you may want to remove.
All in all, if you know what you are doing symlinks can certainly save you some space. When I try to show people what to do with their installations, I'll keep using copy, since there are fewer failure modes at the expense of some disk space.
Re question (2): These expressions are the ones checking which device type it is, so as to know what to display and not.
08-18-2017 05:30 PM
Thanks Jan.
Re (1) - yes, that makes sense and I do understand the impact of copies vs. symlinks. However, I need to clarify my question was about the size difference between built NED directory (where you symlink to), and the directory that 'pioneer install-netconf-ned' creates under run directory. I was basically questioning if the two directories are equal "content wise". The directory that 'pioneer install-netconf-ned' created under run directory was ~35M larger than the directory that 'pioneer build-netconf-ned' had built (where I simply symlink'ed to). It seems in "copy" method (using pioneer install-netconf-ned), there are some "extra" files that are created i.e it's not a plain copy of built ned directory to runtime directory.
Re (2) - at this point I only had device address configured (no device-type or anything else defined yet) and even the address was not committed. How is NSO expected to check which device-type it is at this point when nothing is known about the device?
Thanks for your time Jan!
08-22-2017 04:59 AM
Re 1: install-netconf-ned is doing two things. First it's moving+renaming any existing package by the same name to "old-packages/", then it just makes a simple tree copy. Could it be the stuff in old-packages/ you're seeing?
Re 2: At this point NSO will have no clue what device type it is. The YANG expressions that hide/show content based on device type will still be evaluated. They probably won't come to any particularly interesting conclusion, but they will be executed, because they are in the YANG.
08-22-2017 03:38 PM
Thanks Jan.
I can't find any directory named "old-packages". I dug a bit more and found the source of size difference is within /src/ncsc-out/modules.
NED directory that was built using pioneer build-netconf-ned under ncs-directory:
/ncs-4.4.2/packages/neds/ncs1-iosxr/src/ncsc-out/modules# du -h *
1.4M fxs
50M revisions
2.3M yang
NED directory that was built using pioneer install-netconf-ned under ncs-run directory:
/ncs-run-4.4.2/packages/ncs1-iosxr/src/ncsc-out/modules# du -h *
12M fxs
50M revisions
27M yang
Number of files seems to be same in both directories (same files) but with different sizes. Here is one example:
under ncs-directory:
/ncs-4.4.2/packages/neds/ncs1-iosxr/src/ncsc-out/modules# du -h yang/Cisco-IOS-XR-ipv4-pim-cfg.yang
4.0K
under ncs-run directory (that pioneer install-ned created):
/ncs-run-4.4.2/packages/ncs1-iosxr/src/ncsc-out/modules# du -h yang/Cisco-IOS-XR-ipv4-pim-cfg.yang
168K
08-23-2017 02:04 AM
There seems to be a great difference between the files you downloaded from internet, and the ones you downloaded from the device. I would throw away the ones you got from internet, and go with the ones you downloaded using pioneer.
08-23-2017 03:08 PM
Those are actually not the ones I downloaded from Internet. The NED directory under ncs-directory was created with pioneer build-netconf-ned command from the yang files downloaded from the device via Pioneer itself.
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