01-14-2021 05:47 AM
Hi there,
I'm trying to setup a cml cicd pipeline using this example from Joe Clark: https://github.com/CiscoDevNet/cml-cicd
I have noticed that he created a vlan-service and a switch-topology service in NSO 5.4 so I have recompiled the service to regenerate the .fxs files on my NSO 5.3 changing the minimum version in the package-meta-data.xml file to 5.3
I then reload the ncs service with the --with-package-reload option and I see these services in the ncs_cli (see below) but when I try to run the populate_nso.py script to populate the NSO instance I receive this error:
_ncs.error.Error: bad keyref (14): illegal reference /switch-topology:switch-topology{headquarters}/switch{sw-core}/downlink-trunk
This is what I see on the ncs_cli:
admin@ncs# show packages package vlan-service packages package vlan-service package-version 1.0 description "Generated Python package" ncs-min-version [ 5.3 ] python-package vm-name vlan-service directory ./state/packages-in-use/1/vlan-service templates [ trunk-port-template vlan-service-template ] component main application python-class-name vlan_service.main.Main application start-phase phase2 oper-status up
admin@ncs(config-switch-sw-core)# exit admin@ncs(config-switch-topology-headquarters)# switch sw-core ? Possible completions: downlink-trunk uplink-trunk <cr> admin@ncs(config-switch-topology-headquarters)# switch sw-core
admin@ncs(config)# show configuration switch-topology headquarters switch sw-core downlink-trunk [ 0/1 ] ! !
If I try to commit the changes directly through the ncs_cli I receive a similar error:
admin@ncs(config)# commit Aborted: illegal reference 'switch-topology headquarters switch sw-core downlink-trunk'
The hq_topology file that the script uses to populate NSO is simple:
topology: headquarters devices: - name: sw-core address: 192.168.10.207 ned_id: cisco-ios-cli-3.8:cisco-ios-cli-3.8 os: ios downlink_trunks: - "0/1" - name: sw-dist address: 192.168.10.208 ned_id: cisco-ios-cli-3.8:cisco-ios-cli-3.8 os: ios uplink_trunk: "0/1" downlink_trunks: - "0/2" - name: sw-access address: 192.168.10.191 ned_id: cisco-ios-cli-3.8:cisco-ios-cli-3.8 os: ios uplink_trunk: "0/1"
Solved! Go to Solution.
01-14-2021 06:23 AM
** Disclaimer I have not use the repo you mention **
bad keyref (14): illegal reference error
means that you are not fulfilling a leafref constrain of the YANG model.
following you error message it leads me to:
So in theory you should verify that you have whichever interface you are trying to refer to on the device in your NSO CDB. This means that you mean to make sure the interface exist on the device and that you have sync-from the configuration from the device so that it appears in your NSO CDB. In theory if you execute the test it is done at this step: https://github.com/CiscoDevNet/cml-cicd/blob/master/tests/populate_nso.py#L46.
You should verify that your device configuration in NSO (the CDB view) when trying to deploy the service contains an interface GigabitEthernet 0/1.
In NSO you can check with:
show running-config devices device sw-core config interface
Hope that helps.
01-14-2021 06:23 AM
** Disclaimer I have not use the repo you mention **
bad keyref (14): illegal reference error
means that you are not fulfilling a leafref constrain of the YANG model.
following you error message it leads me to:
So in theory you should verify that you have whichever interface you are trying to refer to on the device in your NSO CDB. This means that you mean to make sure the interface exist on the device and that you have sync-from the configuration from the device so that it appears in your NSO CDB. In theory if you execute the test it is done at this step: https://github.com/CiscoDevNet/cml-cicd/blob/master/tests/populate_nso.py#L46.
You should verify that your device configuration in NSO (the CDB view) when trying to deploy the service contains an interface GigabitEthernet 0/1.
In NSO you can check with:
show running-config devices device sw-core config interface
Hope that helps.
01-14-2021 07:50 AM - edited 01-14-2021 07:51 AM
Hi @gmuloche ,
thank you for your input. It was indeed a reference to an interface still not present in the NSO CDB!
The main issue was that NSO wasn't able to reach the device to perform a synch-from due a special character in the password (the script used to create the authgroup doesn't include the quotes) so I had to change that script and now everything is working ad expected!
Thank you very much for your help on this!!
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