Table of Contents
NSO YANG data model also gives us also the capability to model more complex data and data types.
In this section we see different data types supported by Cisco NSO in a slightly more advanced scenario.
NSO YANG Data Model
To see a slightly more advanced yang data model in NSO service template, in this section we prepare a yang data model to store the access list configuration data components.
This example is from the Cisco Developer site, but I’ve modified a bit to make it easier.
To configure the access list, we need to provide some configuration parameters of different type, like rule number, action to permit or deny traffic, protocol which can be mainly “tcp”, “udp” or “icmp”, Source/destination IP and also destination port.
access-list data model
To start the configuration, we first need to generate a service template skeleton as we did in the previous sections. We configure a service skeleton with the name of „acl“.
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 acl
Our target is to prepare a Yang data model. Therefore, we ignore the template file and only focus on the Yang data model.
This is the yang data model that I have copied from cisco developer website with a few changes.
majid@majid-ubuntu:~/nso-instance/packages$ cat acl/src/yang/acl.yang
module acl {
namespace "http://com/example/acl";
prefix acl;
import ietf-inet-types {
prefix inet;
}
import tailf-ncs {
prefix ncs;
}
import tailf-common {
prefix tailf;
}
typedef port-type {
type union {
type uint16 {
range "0..65535";
}
type enumeration {
enum "ssh" {value 22;}
enum "telnet" {value 23;}
enum "https" {value 443;}
enum "http" {value 80;}
enum "ftp" {value 21;}
enum "pop3" {value 110;}
enum "smtp" {value 25;}
enum "tftp" {value 69;}
enum "domain" {value 53;}
enum "ntp" {value 123;}
}
}
}
typedef portocol-type {
type enumeration {
enum "tcp";
enum "udp";
enum "icmp";
}
}
container acl {
description
"Access Control Lists";
leaf acl-description {
type string {
length "0..64";
pattern "[0-9a-zA-Z]*";
}
description "Purpose of ACL";
}
leaf-list device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
list entry {
key "number";
leaf number {
type uint16;
}
description "Sequence number of an ACE";
uses ncs:service-data;
ncs:servicepoint "acl";
leaf action {
type enumeration { // for the action, there are only two fixed options available so an enumeration will be used
enum permit;
enum deny;
}
description "Action to take with the packet";
}
leaf source-ip {
type inet:ipv4-address {
tailf:info "source IP address";
}
description "Source IPv4 address.";
}
leaf destination-ip {
type inet:ipv4-address;
description "Destination IPv4 address.";
}
leaf protocol {
type portocol-type;
}
leaf destination-port {
type port-type;
}
}
}
}
yang data model deep inspection
namespace/prefix
We will go through the Yang data model to better understand the components and also see the new Yang data types.
# yang data model acl example
After module name, in the first two lines, “namespace” and “prefix” uniquely identify the module and they are mandatory. “namespace” is a URI address and is used when encoding data in the XML format, while “prefix” can be used to refer to this module from other YANG data models.
tailf-common / tailf:info
In addition to the „tailf-ncs“ module present in the default generated Yang data model, I’ve added „tailf-common“, which I use to add help information for each service parameter.
As an example, I used “tailf:info“; for the “source-ip” parameter. If you use a question mark to specify the source-ip parameter when creating an instance of the service, this information is displayed to the user which helps the user to understand the parameter easier.
leaf source-ip {
type inet:ipv4-address {
tailf:info "source IP address";
}
description "Source IPv4 address.";
}
some other types in YANG data model
Then a container is defined with the name of “acl”. The container itself has no value. But It can contain any number of child nodes of any type.
In the container we have a description section to describe the node. Description does nothing but It’s a good idea to have a description for all nodes.
Then a leaf node with the name of „acl-description“ is configured. With this node, we configure the name of the access-list.
A leaf node contains simple data such as an integer or a string. It has exactly one value of a particular type and no child nodes.
The type of the “acl-description” node is a string with a length of 64 characters and the allowed characters are defined with the keyword “pattern“.
The list of devices is generated by default in the Yang data model with the type „leaf-list“ and with the type „leafref“ that references another Yang data model that lists existing devices configured in Cisco NSO.
Each access list can have multiple rules. And each rule can permit or deny a set of traffic with specific source IP, destination IP, protocol and port number.
To do this, a node with the name of “entry” and the type “list” is defined, which displays the list of rules.
Each entry has a “number“, which is also a key node, so it must be unique. It is of type 16-bit unsigned integer or uint16.
For each rule a node is configured with the name “action” and the type of enumeration, since only this node can have two values, “permit” or “deny“.
The “source-ip” and “destination-ip” nodes are of type “inet:ipv4-address”. The prefix “inet” is already imported at the beginning of this module.
The “protocol” node is of the type of the custom and user-defined “protocol-type” configured at the beginning of the module.
New types are configured with the “typedef” keyword. The type of enumeration and the values “tcp“, “udp” or “icmp” are defined for “protocol-type“.
The type enumeration could be defined directly in the “protocol” node. But just to show you how we can create a new type, I created a new node data type.
The last parameter in the access list is “destination-port” with the type of the user-defined “port-type“. The new type, “port-type” is defined at the beginning of the module.
The type of „port-type“ is „union“, which represents a value corresponding to one of its member types. It can be one of the services defined by enumeration such as “ssh”, “telnet” … or an unsigned integer value in the range 0 to 65535.
Compared to the previous section, we have seen a slightly more advanced Yang data model with a few more data types. However, it is still not complex enough and a more complicated Yang data model can be represented in Cisco NSO.
In the example of access list, destination port is only required if the protocol is “TCP” or “UDP” and if the protocol is defined as “ICMP”, the destination port should not be an option.
This and more complex examples can be also represented in the Cisco NSO Yang data model, but they are not shown here.
Cisco NSO YANG Data Types
The following are standard data types that can be configured in cisco nso yang data model and it is taken from cisco developer website.
test access-list YANG Data model
just to make sure that it works, let’s configure a new access-list in a sample device to check the parameters and their values if they are s we have configured in yang data model.
First we have three options, acl-description or the name of the access-list, the device on whch the access-list must be applied and the rule number.
Then for each rule, we have the options to permit or deny traffic with action parameter.
If you remember for teh parameter “source-ip”, we have activated “tailf:info” which shows a quick help for each command entry.
admin@ncs(config)# acl ?
Possible completions:
acl-description device entry
admin@ncs(config)# acl acl-description acl1 device ios0 entry 10 ?
Possible completions:
action destination-ip destination-port protocol source-ip <cr>
admin@ncs(config)# acl acl-description acl1 device ios0 entry 10 action permit protocol ?
Possible completions:
icmp tcp udp
admin@ncs(config)# acl acl-description acl1 device ios0 entry 10 action permit protocol tcp source-ip ?
Possible completions:
<source IP address>
admin@ncs(config)# acl acl-description acl1 device ios0 entry 10 action permit protocol tcp source-ip 1.1.1.1 destination-ip 2.2.2.2 destination-port ?
Possible completions:
<unsignedShort, 0 .. 65535> domain ftp http https ntp pop3 smtp ssh telnet tftp
admin@ncs(config)# acl acl-description acl1 device ios0 entry 10 action permit protocol tcp source-ip 1.1.1.1 destination-ip 2.2.2.2 destination-port http
admin@ncs(config-entry-10)# top
admin@ncs(config)# show configuration
acl acl-description acl1
acl device [ ios0 ]
acl entry 10
action permit
source-ip 1.1.1.1
destination-ip 2.2.2.2
protocol tcp
destination-port http
!
admin@ncs(config)# commit dry-run
cli {
local-node {
data acl {
+ acl-description acl1;
+ device [ ios0 ];
+ entry 10 {
+ action permit;
+ source-ip 1.1.1.1;
+ destination-ip 2.2.2.2;
+ protocol tcp;
+ destination-port http;
+ }
}
}
}