A network service refers to a collection of configurations across devices on a network.
NSO Services are used to create instances of services to deploy across your network.
You can define any set of configuration templates and sets of variables for those templates.
NSO will keep track of the service instances and only update or remove services.
Services can be a customer, tenant, site id, or anything you want to define.
Services provide assurance and verification that prove the intended outcome on the network before applying the configuration into a production environment. Services can be used along side other applications or workflow engines.
Creating the Service Package
NSO uses a built in package management system to handle NEDs and custom service packages.
ncs-make-package is a CLI tool that will auto generate a skeleton structure of files needed for creating the service package.
The tree is a tiny, cross-platform command-line program used to recursively list or display the content of a directory in a tree-like format. It outputs the directory paths and files in each sub-directory and a summary of a total number of sub-directories and files.
Review the contents of the loopback-service.yang and loopback-service-template.xml files using cat to output to the terminal.
Launch the ncs_cli
Create a loopback interface with an IP schematic.
go to the top directory and verify the pending configuration changes.
Output the changes using XML formatting and copy the interface configuration section between the </config> tags
Using a text editor such as gedit, nano, vi, vim or whatever you are comfortabl with paste in the XML configuration you copied between the </config> tags
rename the IP address and give it a variable of {/dummy}
Save the configuration after verifying the config contents are proper.
make the package
Get back into the ncs_cli
reload the packages in ncs.
Creating a Service Instance
From configuration mode in the NSO CLI use the new loopback-service command.
Name the instance test and add variables for the device and IP scheme.
Create a device template that we will apply to all devices inside of our IOS_DEVICES group. You will begin to see the benefit of automation by the end of this post.
We will select our IOS 6.42 NED as the device driver. We will enter into configuration mode and then enter the commands needed to setup name servers on the IOS devices.
We can use show configuration to see our pending changes before we commit the template to NSO.
With our final command we can see that our single line of text wil apply our template to every device in our device group.
We can also use the commit dry-run to see all configuration changes that will be applied to the device’s once we commit the template.
The last step now that we have confirmed we in fact want these changes to take place on the IOS devices is to commit the changes.
NSO can read the current configuration and easily update the configurations across your network.
Reading Device Configurations
We can review the full device configuration with the following commands for c0.
We can use the de-select keyword to filter out elements of our returned data. In this example we are excluding the config data and should be returned with the config used to add the device into the NSO inventory. Think of this as the vanilla config.
Next let’s create an SVI for vlan 2 on the c0 device and then verify the configuration all through the ncs_cli.
As you can see we can create many different types of interfaces to mimic that of most devices.The alarm sates c0’s device is out of sync
To fix this we can either re-sync the device to NSO or commit and ignore the sync check for the commit.
Finally we can run our show command for the C0 device and parse out only the interface information we’re looking for. All from the same CLI.
Repeat this process creating a vlan for the SVI, an access port for that vlan and other configuratios. Then you can verify with show commands parsing data after the commits.
NSO supports * wildcarding so you can pull configuration data from multiple ‘modules’ at once.
We have now explored connecting to an IOS device, Creating configurations on the device and verifying for sanity using show commands all from the NSO developer box.
Using postman we can sent get/put/post and other requests using RESTCONF to NSO to test requests before we implement them into a python script and bring the automation full circle to devices that other wise don’t have an API we can call (like IOS devices).
We need to use basic Auth (this will be our username and password we use to get into the NSO_CLI.
Also make sure to disable the original Accept and Content-Type headers and create new ones with the proper data models.
After we send the request we can see NSO has replied with a response that has a body giving all the information about the current devices due to our tailf-ncs:devices request.
Another example can be gather the loopback interface from device a0 that we created with our service instance.
We can continue testing get/put/post/del commands for sanity before implementing into our python scripts.
Python can be integrated with NSO to automate NSO’s actions. Our simple script will login to NSO and retrieve all of the currently running devies with management information.
Start netsim and use the cli-i c1 command to console to the device c1. From here you can use normal IOS commands. We can even see the pre-populated commands in the running configuration.
Next we exit out of the IOS CLI and hop into the NSO CLI. This is where the benefit of NSO comes into play. Through NSO we are able to see structured YANG data from the IOS devices.
Populating the NSO Instance
Now that NSO is running you need to add the devices we created into the NSO inventory. This will allow NSO to read and write data. For this to work we will need an authgroup so we can setup credentials for the devices.
NOTE: -C specifies ‘cisco style’ CLI because the default is a ‘Juniper style’, -u admin allows us to login as the admin user.
Setup a new authgroup called labadmin This group will use a default credentials: cisco:cisco for devices, with a secondary pass of cisco.
After staging the configuration you must commit it to the system with the ‘commit’ command. BEFORE you commit make sure to use the top command and review the configuration changes that are staged by using ‘show config’.
After you have verified the pending changes are correct you can commit them with the ‘commit’ command.
Adding Devices into NSO
To add a device you will need: The devices IP address or FQDN. SSH/Telnet protocol and port used to connect to the device. The authgroup needs to exist. The NED used to connect to the device (Device Driver).
From config mode on the ncs_cli we will add the device c0 using the IP address 127.0.0.1, the protocol will be telnet. We will use the cisco-ios-cli-6.42 device driver to connect to c0.
Verify you are in the proper directory associated for the device we want NSO to connect with. NOTE: You will get an error stating that the device is locked. This is the default mode for devices as a safety mechanism so NSO will not change a device until the administrator is ready. Unlock the device by changing the admit state to unlocked and commit the change.
Once this is completed you can connect to the device using the connect command.
Now we will add the other 2 devices C1 and C2 to the labadmin group. For the sake of doing it another way we will do this VIA the web GUI. Click on each device from the device manager page.
Select the labadmin authgroup under the authgroup dropdown. Repeat this process for the C2 device.
You can also verifiy conection VIA the ncs_cli
NOTE: This step is not needed as we already know we connected VIA the web GUI.
Learning the Current State of the Network
We have verified the connectio to the device but we have not let NSO learn the current configuration state of these network devices. First we verify no real device level configurations have been made with show commands.
Device Grouping
NOTE: This step is not required but it a good practice to follow and will help make management and scalability easier. We will create device groups and organize the device into a logical group. The group will be paired by devices which take the same style of configuration. ex: IOS devices in a group, NXOS devices in another group, ASA in a seperate group, etc.
Next we can verify our newly created IOS-DEVICES group using a show command on the ncs_cli.
We now have IOS devices we can connect and begin configuring with NSO using the ncs_cli. (NSO and NCS are interchangeable and both refer to Network Services Orchestrator).
39 days left to get the DEVNET Associate!Verifying Ubuntu version used for installation process
For personal use Cisco NSO is FREE to use. You can download the trial version at https://developer.cisco.com/ . Login with your CCO account.
Move nso-5.3 bin file to the home directory.
Unpack the file to a directory.
The source command is used in order to evaluate the file passed as an argument in the context of the current execution.
Create the ncs-run directory for the end location of the ncs-setup command.
Change directory to ncs-run and verify the version..
Next download the newer NEDs from the https://developer.cisco.com/docs/nso/#!getting-nso/ site.
Extract the tarballs for the nx, ios, and asa then verify.
You now have the newest NEDs and a running installation of the Cisco Network Services Orchestrator.
I ran into issues with device manager not seeing the packages so I created a new directory and began again. After stopping the ncs services, removing the original ncs directory and creating a new one I was able to see the devices in Device manager.
Execute ncs and then verify the service is running.
Navigate to http://localhost:8080 to access the web UI.
The default credentials are admin : admin
From here you can explore the different modules that the GUI has to offer.
from ncclient import manager
import xmltodict
import xml.dom.minidom
# Create an XML filter for targeted NETCONF queries
netconf_filter = """
<filter>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface></interface>
</interfaces>
</filter>"""
with manager.connect(
host="10.0.30.151",
port="830",
username="cisco",
password="cisco",
hostkey_verify=False
) as m:
netconf_reply = m.get_config(source = 'running', filter = netconf_filter)
print(xml.dom.minidom.parseString(netconf_reply.xml).toprettyxml())
# Parse the returned XML to an Ordered Dictionary
netconf_data = xmltodict.parse(netconf_reply.xml)["rpc-reply"]["data"]
# Create a list of interfaces
interfaces = netconf_data["interfaces"]["interface"]
for interface in interfaces:
print("Interface {} enabled status is {}".format(
interface["name"],
interface["enabled"]
)
)
Error:
C:\Users\ge\Git\CodeSamples>C:/Users/ge/AppData/Local/Microsoft/WindowsApps/python.exe c:/Users/ge/Documents/Python/DEVNET/cisco.py
Traceback (most recent call last):
File "c:/Users/ge/Documents/Python/DEVNET/cisco.py", line 20, in <module>
netconf_reply = m.get_config(source = 'running', filter = netconf_filter)
File "C:\Users\ge\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\ncclient\manager.py", line 226, in execute
return cls(self._session,
File "C:\Users\ge\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\ncclient\operations\retrieve.py", line 166, in request
return self._request(node)
File "C:\Users\ge\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\ncclient\operations\rpc.py", line 360, in _request
raise self._reply.error
ncclient.operations.rpc.RPCError: {'type': 'protocol', 'tag': 'unknown-element', 'app_tag': None, 'severity': 'error', 'info': '<?xml version="1.0" encoding="UTF-8"?><error-info xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"><bad-element>filter</bad-element>\n</error-info>\n', 'path': '\n /rpc/get-config\n ', 'message': None}
version affected:
csr1000v#sh ver
Cisco IOS XE Software, Version 17.03.01a
Cisco IOS Software [Amsterdam], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 17.3.1a, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2020 by Cisco Systems, Inc.
Compiled Wed 12-Aug-20 00:16 by mcpre
Add the new image definition in CML (only fill in ID, Label and description): Tools -> Node and Image Definitions:
Select ‘IMAGE DEFINITIONS’ tab and choose ‘ADD’:
Add the new image definition in CML (only fill in ID, Label and description)
Open a lab in CML and drag the CSR 1000v image onto your CML workshop and under the simulate tab select the new image definition you created:
allow the image time to boot then proceed to enable netconf:
username cisco priv 15 sec 0 cisco
ip domain name ge.lab
int gi 1
ip add dhcp
exi
crypto key gen rsa mod 1024
ip ssh ver 2
line vty 0
logg syn
line vty 0 14
trans in ssh
login local
netconf ssh
netconf-yang
NOTE: You will receive an error about “%DMI-3-NETCONF_SSH_ERROR: F0: ncsshd_bp: NETCONF/SSH: error: Trustpoint does not have a cert“
This issue appears to be a result of self-signed certificates on IOS/IOS-XE platforms expiring on Jan 1st 2020: