Table of Contents
Cisco NSO service template gives the capability to enable a service across devices and device types without giving any commands and just specifying the parameters of the service.
cisco nso service template fundamental
What is a service template and what are the benefits of the service template? To understand it better, let’s go through an example.
Suppose we want to configure OSPF over the network with different types of devices including iOS, iOS XR and Junos devices.
As you can see, the configuration syntax is different for each device type. Here OSPF is configured differently for different device types.
The advantage of configuring a service template is that configurations and data models for different device types are configured behind the scenes and in advance.
And at the time of service instance creation, you just give the name of device or devices to which the service is to be applied, and only the configuration data which is required to configure the service.
In our example, the OSPF process-id, area-id, and interfaces to be added in the area are the configuration data that needs to be specified for each device, without noticing how it is actually configured in the background.
In other words, we prepare beforehand the configuration template for each device type, with variables instead of configuration data. We also prepare a data model that specifies which variables have which data types and whether they are mandatory or optional for this service.
All configurations are applied behind the scenes based on the configuration template and data given at service creation time.
service template minimum requirements
In summary, to prepare a service template, we need to prepare at least two components, configuration template in the format of XML and YANG data model.
The configuration template may include different device types participating in the service. we use variables instead of configuration data in the configuration template.
YANG data model specifies the format of each variable used in configuration template.
cisco nso service template example
To create a service template, we start by creating “service-skeleton” using the “ncs-make-package” command in the “packages” folder in the NSO instance folder.
We create a service with the name of “loopback-service” to create loopback interface in ios devices.
It is a very simple service template taken from cisco documents just to show you the components that we need to create a service template.
majid@majid-ubuntu:~/devnet/cisco_nso$ source $HOME/nso-6.0/ncsrc majid@majid-ubuntu:~/devnet/cisco_nso$ cd ~/nso-instance/packages/ majid@majid-ubuntu:~/nso-instance/packages$ ncs-make-package --service-skeleton template loopback-service
You can then check the structure of the service skeleton using the “ls” command.
A new folder is created with the name of the service template. Inside this folder are two important folders.
The folder “templates” where you can keep the configuration template for different device types. And the folder “src” and then “yang”, where you keep data model and, in a few minutes, we will learn how to create them.
majid@majid-ubuntu:~/nso-instance/packages$ ls cisco-asa-cli-6.16 cisco-ios-cli-6.88 cisco-iosxr-cli-7.43 cisco-nx-cli-5.23 juniper-junos-nc-3.0 loopback-service majid@majid-ubuntu:~/nso-instance/packages$ ls loopback-service/ package-meta-data.xml src/ templates/ test/
Inside “templates” folder, there is already an XML file with the name of service template.
majid@majid-ubuntu:~/nso-instance/packages$ cat loopback-service/templates/loopback-service-template.xml <config-template xmlns="http://tail-f.com/ns/config/1.0" servicepoint="loopback-service"> <devices xmlns="http://tail-f.com/ns/ncs"> <device> <!-- Select the devices from some data structure in the service model. In this skeleton the devices are specified in a leaf-list. Select all devices in that leaf-list: --> <name>{/device}</name> <config> <!-- Add device-specific parameters here. In this skeleton the service has a leaf "dummy"; use that to set something on the device e.g.: <ip-address-on-device>{/dummy}</ip-address-on-device> --> </config> </device> </devices> </config-template>
If you look at the XML file, you will see a section between the <config> and </config> tags. Configuration templates for different device types are added between these tags.
There is also a section between <device> and </device>. Here you can add the list of devices to which configuration templates need to be applied. However, we usually leave it untouched since we specify the list of devices at the time the service instance is created.
If you look at the yang data model inside the “packages/src/yang” folder, you will see a variable with the name of service and the type of list, “list loopback-service”, which means that you can create many instances of this service.
majid@majid-ubuntu:~/nso-instance/packages$ cat loopback-service/src/yang/loopback-service.yang
module loopback-service {
namespace "http://com/example/loopbackservice";
prefix loopback-service;
import ietf-inet-types {
prefix inet;
}
import tailf-ncs {
prefix ncs;
}
list loopback-service {
key name;
uses ncs:service-data;
ncs:servicepoint "loopback-service";
leaf name {
type string;
}
// may replace this with other ways of refering to the devices.
leaf-list device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
// replace with your own stuff here
leaf dummy {
type inet:ipv4-address;
}
}
}
Under the service template variable, there is a “leaf name” variable of the type “string” which is also a key variable. This means that each service instance must have a unique name. leaf means a single end entity. The name of service must be given at the time of service instance creation.
There is another variable, “leaf-list device” with the type of “leafref” with the reference to the path “/ncs:devices/ncs:device/ncs:name”, in which the detail are defined.. the leaf-list means a list of end entities and here means the list of devices that you give at the time service instance creation.
These two variables are always in yang data model. But other variables are what you have already defined in the configuration template.
A “leaf dummy” variable wit the type of “inet:ipv4-address” is already created. But you can add your interesting variables based on your configuration template.
prepare configuration template and yang data model for loopback service template
Now it is the time that we create our configuration template and data model in the first service template.
As you know our service template is just to create loopback interface in ios devices. It is very easy but a good start just to show you how we create service configuration template and yang data model.
We start with configuration template. Configuration template must be in the format of XML.
To prepare the configuration template, it is enough that we configure a loopback interface in a sample iOS device and then get the XML version of the configuration. Then we add the configuration in XML format betwenn <config> and </config> tags inside the default configuration template.
Let’s try it together.
majid@majid-ubuntu:~/nso-instance/packages$ ncs_cli -C -u admin
admin@ncs# config t Entering configuration mode terminal admin@ncs(config)# devices device R1 config interface Loopback 150 admin@ncs(config-if)# ip address 1.1.1.1 255.255.255.255 admin@ncs(config-if)# top admin@ncs(config)# show configuration devices device R1 config interface Loopback150 ip address 1.1.1.1 255.255.255.255 no shutdown exit ! !
admin@ncs(config)# commit dry-run outformat xml
result-xml {
local-node {
data <devices xmlns="http://tail-f.com/ns/ncs">
<device>
<name>R1</name>
<config>
<interface xmlns="urn:ios">
<Loopback>
<name>150</name>
<ip>
<address>
<primary>
<address>1.1.1.1</address>
<mask>255.255.255.255</mask>
</primary>
</address>
</ip>
</Loopback>
</interface>
</config>
</device>
</devices>
}
}
majid@majid-ubuntu:~/nso-instance/packages$ cat loopback-service/templates/loopback-service-template.xml <config-template xmlns="http://tail-f.com/ns/config/1.0" servicepoint="loopback-service"> <devices xmlns="http://tail-f.com/ns/ncs"> <device> <!-- Select the devices from some data structure in the service model. In this skeleton the devices are specified in a leaf-list. Select all devices in that leaf-list: --> <name>{/device}</name> <config> <interface xmlns="urn:ios"> <Loopback> <name>150</name> <ip> <address> <primary> <address>{/ip_address}</address> <mask>255.255.255.255</mask> </primary> </address> </ip> </Loopback> </interface> </config> </device> </devices> </config-template>
In our example, we can replace the loopback interface number, the ip address of loopback interface and subnet mask with variables in configuration template.
But again just to simplify the process, we ignore loopback interface number and subnet mask and only replace the ip address with a variable “ip_address” in configuration template.
Therefore, for yang data model we need only one variable with the name of “ip_address” which can be used instead of “dummy” variable. The type of this variable is “inet:ipv4-address”.
majid@majid-ubuntu:~/nso-instance/packages$ cat loopback-service/src/yang/loopback-service.yang
module loopback-service {
namespace "http://com/example/loopbackservice";
prefix loopback-service;
import ietf-inet-types {
prefix inet;
}
import tailf-ncs {
prefix ncs;
}
list loopback-service {
key name;
uses ncs:service-data;
ncs:servicepoint "loopback-service";
leaf name {
type string;
}
// may replace this with other ways of refering to the devices.
leaf-list device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
// replace with your own stuff here
leaf ip_address {
type inet:ipv4-address;
}
}
}
add new service template in cisco nso
The new loopback service template is ready. Now we have to compile and add it in cisco nso.
We go inside “packages/loopback-service/src/” folder and with “make” command, we compile and add the new service template in cisco nso.
If there is any error in the service template, you will be noticed in this step and when you give make command.
majid@majid-ubuntu:~/nso-instance/packages$ cd ~/nso-instance/packages/loopback-service/src/
majid@majid-ubuntu:~/nso-instance/packages/loopback-service/src$ make
mkdir -p ../load-dir
/home/majid/nso-6.0/bin/ncsc `ls loopback-service-ann.yang > /dev/null 2>&1 && echo "-a loopback-service-ann.yang"` \
--fail-on-warnings \
\
-c -o ../load-dir/loopback-service.fxs yang/loopback-service.yang
majid@majid-ubuntu:~/nso-instance/packages/loopback-service/src$
If it is successful, you enter nso cli environment and reload the packages. Therefore, the new service template will be added in the list of packages.
majid@majid-ubuntu:~/nso-instance/packages/loopback-service/src$ ncs_cli -C -u admin
admin@ncs# packages reload force >>> System upgrade is starting. >>> Sessions in configure mode must exit to operational mode. >>> No configuration changes can be performed until upgrade has completed. >>> System upgrade has completed successfully. ... reload-result { package loopback-service result true } admin@ncs#
admin@ncs# show packages package package-version
PACKAGE
NAME VERSION
--------------------------------
cisco-asa-cli-6.16 6.16
cisco-ios-cli-6.88 6.88
cisco-iosxr-cli-7.43 7.43
cisco-nx-cli-5.23 5.23.6
juniper-junos-nc-3.0 3.0.14.2
loopback-service 1.0
add a new service instance
Now you have the name of service template as a new command in the list of commands in cisco nso.
With this command you can create a new instance of the service, with specifying the name of the service, device or devices in which the service must be applied and the configuration data.
In our example we add a new loopback interface in router R1 with the IP address 1.1.1.1.
admin@ncs(config)# loopback-service ? % No entries found Possible completions: <name:string> admin@ncs(config)# loopback-service LPservice1 ? Possible completions: check-sync Check if device configuration is according to the service deep-check-sync Check if device configuration is according to the service device get-modifications Get the data this service created ip_address log re-deploy Run/Dry-run the service logic again reactive-re-deploy Reactive re-deploy of service logic touch Mark the service as changed un-deploy Undo the effects of the service <cr> admin@ncs(config)# loopback-service LPservice1 device R1 ? Possible completions: ip_address <cr> admin@ncs(config)# loopback-service LPservice1 device R1 ip_address ? Possible completions: <IPv4 address> admin@ncs(config)# loopback-service LPservice1 device R1 ip_address 1.1.1.1 ? Possible completions: <cr> admin@ncs(config)# loopback-service LPservice1 device R1 ip_address 1.1.1.1 admin@ncs(config-loopback-service-LPservice1)# top admin@ncs(config)# show configuration loopback-service LPservice1 device [ R1 ] ip_address 1.1.1.1 ! admin@ncs(config)# commit Commit complete. admin@ncs(config)#
Then we check the router R1 to make sure that the new loopback interface is created.
R1#show ip int brief Interface IP-Address OK? Method Status Protocol GigabitEthernet1 192.168.2.91 YES NVRAM up up GigabitEthernet2 unassigned YES NVRAM administratively down down GigabitEthernet3 unassigned YES NVRAM administratively down down Loopback100 4.5.6.7 YES NVRAM up up Loopback150 1.1.1.1 YES manual up up R1#
un-deploy service instance
We are allowed to un-deploy and re-deploy any service instance with “un-deploy” and “re-deploy” parameters.
After giving “un-deploy” command, we check the router R1 to make sure that loopback interface is deleted.
admin@ncs(config)# loopback-service LPservice1 un-deploy admin@ncs(config)# System message at 2023-07-18 22:28:15... Commit performed by admin via ssh using cli. admin@ncs(config)#
R1#show ip int brief Interface IP-Address OK? Method Status Protocol GigabitEthernet1 192.168.2.91 YES NVRAM up up GigabitEthernet2 unassigned YES NVRAM administratively down down GigabitEthernet3 unassigned YES NVRAM administratively down down Loopback100 4.5.6.7 YES NVRAM up up
re-deploy service instance
After giving “re-deploy” command, we check again the router R1 to make sure that loopback interface is again created.
admin@ncs(config)# loopback-service LPservice1 re-deploy admin@ncs(config)# System message at 2023-07-18 22:29:07... Commit performed by admin via ssh using cli. admin@ncs(config)#
R1#show ip int brief Interface IP-Address OK? Method Status Protocol GigabitEthernet1 192.168.2.91 YES NVRAM up up GigabitEthernet2 unassigned YES NVRAM administratively down down GigabitEthernet3 unassigned YES NVRAM administratively down down Loopback100 4.5.6.7 YES NVRAM up up Loopback150 1.1.1.1 YES manual up up
you can download loopback service template example from github source community.