LTRSPG 2515 LG

Contents
CONTENTS ....................................................................................................................................................... 2
1 INTRODUCTION:............................................................................................................................................ 4
2 LAB TASK 1-1: BRINGING UP NSO .................................................................................................................. 8
2.1 INSTALLING NSO FROM BINARY DISTRIBUTION: ........................................................................................................ 8
2.2 VIEWING THE INSTALLATION: ................................................................................................................................ 9
2.3 SET UP THE NSO WORKING ENVIRONMENT: .......................................................................................................... 10
2.4 STARTING NSO DAEMON & VERIFYING STATUS: .................................................................................................... 11
2.5 CONNECTING TO NSO USING GUI AND CLI .......................................................................................................... 12
2.5.1 From Remote SSH Client: ..................................................................................................................... 12
2.5.2 Through GUI:........................................................................................................................................ 12
2.5.3 Through CLI: ......................................................................................................................................... 14
2.6 ADDING NSO NED PACKAGES: .......................................................................................................................... 15
2.6.1 Checking currently loaded packages: .................................................................................................. 15
2.6.2 Adding new package:........................................................................................................................... 15
3 LAB TASK 1-2: CONNECTING TO DEVICES .................................................................................................... 18
3.1 CREATING AUTHGROUP FOR DEVICES: ................................................................................................................. 18
3.2 ADDING A NEW ROUTER/DEVICE USING CLI: ........................................................................................................ 18
3.3 CONFIG LOCKS: ............................................................................................................................................... 19
3.3.1 Locked State:........................................................................................................................................ 19
3.3.2 South-bound Locked State: .................................................................................................................. 20
3.4 SYNCING CONFIGURATION FROM DEVICE ............................................................................................................. 21
3.4.1 Comparing NSO config with device: ..................................................................................................... 22
3.4.2 Check-Sync the devices: ....................................................................................................................... 23
3.5 ADDING A NEW DEVICE USING GUI:..................................................................................................................... 23
3.6 ADDING REMAINING DEVICES IN THE TOPOLOGY:................................................................................................... 28
3.7 SYNC DEVICE CONFIGURATIONS:.......................................................................................................................... 30
3.8 CONFIGURE BASIC PARAMETER THROUGH GUI: ..................................................................................................... 32
3.9 CONFIGURE BASIC PARAMETER THROUGH CLI: ....................................................................................................... 36
3.10 CONFIGURE REMAINING INTERFACES: ................................................................................................................ 38
3.11 ROLLBACK CONFIGURATION CHANGES: .............................................................................................................. 39
4 LAB TASK 2-2: CREATING AND IMPLEMENTING SERVICE TEMPLATE ........................................................... 43
4.1 CREATE A BLANK PACKAGE BASED ON TEMPLATE: .................................................................................................. 43
4.2 IDENTIFY THE YANG MODELLING PARAMETERS ...................................................................................................... 43
4.3 USE THE PRE BUILT YANG MODEL FILE ................................................................................................................ 45
4.4 VERIFYING THE YANG MODEL: ........................................................................................................................... 45
4.5 COMPILE THE NEW YANG MODEL:...................................................................................................................... 45
4.6 ADDING XML TEMPLATE: ................................................................................................................................. 47
4.7 USING XML TEMPLATE:.................................................................................................................................... 47
4.8 USING THE SAME SERVICE TEMPLATE FOR CONFIGURING IOS DEVICE: ....................................................................... 48
4.9 VIEWING THE SERVICE TEMPLATE IN GUI: ............................................................................................................ 49
4.10 ADDING 2ND INTERFACE TO EXISTING OSPF PROCESS: ........................................................................................... 53
4.11 COMPLETING OSPF CONFIG FOR REMAINING DEVICES: .......................................................................................... 54
5 BONUS CONTENT ........................................................................................................................................ 59
5.1 ADDITIONAL WAYS TO VIEW THE YANG MODEL USING PYANG: ................................................................................. 59
July 10, 2016 LTRSPG-2515-Using NSO with tail-f
Page 2 of 80
5.1.1 Generating XML view of yang model: .................................................................................................. 59
5.1.2 Generating HTML view of YANG module: ............................................................................................ 60
5.2 USING NETCONF .............................................................................................................................................. 60
5.2.1 Poll Device Config using XML over Netconf: ........................................................................................ 60
5.2.2 Configure (Add and Delete) configuration using XML+Netconf: .......................................................... 63
5.2.3 Close Netconf Session: ......................................................................................................................... 64
5.2.4 Poll Device Config using : ..................................................................................................................... 65
6 APPENDIX ................................................................................................................................................... 66
6.1 CREATING THE OSPF.YANG MODEL STEP BY STEP: .................................................................................................. 66
6.1.1 Create New Variable types as-needed: ................................................................................................ 66
6.1.2 Define the Service point: ...................................................................................................................... 66
6.1.3 Defining various parameters for various OSPF service definitions: ..................................................... 67
6.1.4 Using Containers - Differentiating between IOS and IOS-XR: .............................................................. 69
6.1.5 Defining Router ID, Area ID & Interfaces: ............................................................................................ 70
6.1.6 Defining IOS Parameters: ..................................................................................................................... 71
6.2 BUILDING THE OSPF.XML : .............................................................................................................................. 75
6.2.1 Defining Device name: ......................................................................................................................... 75
6.2.2 Generating sample XML structure: ...................................................................................................... 76
6.2.3 Defining IOS config template: .............................................................................................................. 78
Page 3 of 80
1 Introduction:
 Lab access is provided using dCloud for which cisco anyconnect should be pre-installed if you
find it missing please go to https://dcloud-rtp-anyconnect.cisco.com using credentials provided
to you and install anyconnect.
 Once anyconnect is installed use credentials provided to you to access the POD as follows.
 Once connected Launch Remote desktop and connect to 198.18.133.252 using the password
C1sco12345
 From desktop when you launch Putty shortcut; there you will find “nso vm” and other devices
vty saved sessions.
 Double click “nso vm” to launch it, using the password C1sco12345
LTRSPG-2515-Using tail-f Network Contro System(NSO)
Page 4 of 80
 Launch VM Maestro from shortcut on desktop. (It may take sometime to launch, don’t click
again)
 VIRL Session (VM Maestro) is running for each POD separately where you will find simulated
devices.
Page 5 of 80
 Double Click on NSO_topology.virl on left side to see the topology you will be working on.
 To start the simulation click on Green Play button on Top. (Don’t press this button twice)
 You will notice devices are getting started and loading configs, give it a few minutes to complete
the simulation startup process. You may need to wait couple more minutes for the XR devices
to go to ACTIVE state , as XR devices may take bit longer.
 All devices are pre-configured with management IP address

 To connect to any of the routers, you can use shortcut created under putty for each device or
telnet to Mgmt IP directly or right click on device in VIRL (as shown below) and then telnet to
console or Management port. Make sure you are on the simulation tab (Green).
All the devices are pre-configured with username/password = cisco/cisco

Enable password for IOS devices is ‘cisco’
Page 6 of 80
Device Name Mgmt IP Telnet
CE1_CL16 198.18.1.30 Telnet
PE1_CL16 198.18.1.31 Telnet
P1_CL16 198.18.1.32 Telnet
PE2_CL16 198.18.1.33 Telnet
CE2_CL16 198.18.1.34 Telnet
 Example below shows how to connect from VIRL to console or Mgmt ports
 Example below shows connecting via Mgmt IP to CE1_CL16:

cisco@ubuntu-1:~$ telnet 198.18.1.30
Trying 198.18.1.30...
Connected to 198.18.1.30.
Escape character is '^]'.
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS *
* education. IOSv is provided as-is and is not supported by Cisco's *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any *
* purposes is expressly prohibited except as otherwise authorized by *
* Cisco in writing. *
**************************************************************************
User Access Verification
Password:
Page 7 of 80
2 Lab Task 1-1: Bringing up NSO
2.1 Installing NSO from binary distribution:

Lets start by unpacking the NSO distribution in a target directory “ncs412”:
cisco@ubuntu:~$ ls -al *.bin

-rwxrwxrwx 1 cisco cisco 173431861 Jun 14 22:26 nso-
4.1.2.linux.x86_64.installer.bin
Prerequisite check
If you see below message it means JRE is missing, install it as follows
cisco@ubuntu:~$ java -version

The program 'java' can be found in the following packages:
* default-jre
* gcj-4.8-jre-headless
* openjdk-7-jre-headless
* gcj-4.6-jre-headless
* openjdk-6-jre-headless
Try: sudo apt-get install <selected package>
cisco@ubuntu:~$ sudo apt-get install default-jre
If you see below message it means JRE is installed properly
cisco@ubuntu:~$ java -version

java version "1.7.0_101"
OpenJDK Runtime Environment (IcedTea 2.6.6) (7u101-2.6.6-0ubuntu0.14.04.1)
OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
If you see Python version lower than 2.7.5, then upgrade it as follows
cisco@ubuntu:~$ python -V
Python 2.7.6
cisco@ubuntu:~$ sudo apt-get install python 2.7.6
If you don’t see Ant installed, install it as follows
cisco@ubuntu:~$ ant -v | grep Ant

Apache Ant(TM) version 1.9.3 compiled on April 8 2014
cisco@ubuntu:~$ sudo apt-get -u install ant
Page 8 of 80
Once done please proceed with NSO installation
cisco@ubuntu:~$ ./nso-4.1.2.linux.x86_64.installer.bin ncs412

INFO Using temporary directory /tmp/ncs_installer.1278 to stage NCS
installation bundle
INFO Unpacked ncs-4.1.2 in /home/cisco/ncs412
INFO Found and unpacked corresponding DOCUMENTATION_PACKAGE
INFO Found and unpacked corresponding EXAMPLE_PACKAGE
INFO Generating default SSH hostkey (this may take some time)
INFO SSH hostkey generated
INFO Environment set-up generated in /home/cisco/ncs412/ncsrc
INFO NCS installation script finished
INFO Found and unpacked corresponding NETSIM_PACKAGE
INFO NCS installation complete
2.2 Viewing the installation:

Have a look at the installation directory hierarchy:
cisco@ubuntu:~$ tree -L 2 ncs412

ncs412
├── bin
│ ├── cs2yang
│ ├── erlc
│ ├── ncs
│ ├── ncs-backup
│ ├── ncsc
<snip>
│ └── yanger
├── CHANGES
├── doc
│ ├── api
│ ├── html
│ ├── index.html
│ └── pdf
├── erlang
│ └── econfd
├── etc
│ └── ncs
├── examples.ncs
│ ├── datacenter
│ ├── discovery
<snip>
│ └── web-server-farm
├── include
│ ├── confd_cdb.h
│ ├── confd_dp.h
<snip>
│ └── confd_maapi.h
├── java
│ └── jar
├── lib
│ ├── cs2yang
<snip>
│ └── pyang
├── LICENSE
Page 9 of 80
├── man
│ ├── man1
│ ├── man3
│ ├── man5
│ └── man7
├── ncsrc
├── ncsrc.tcsh
├── netsim
│ └── confd
<snip>
├── support
│ ├── convert-ncs-config.xsl
│ ├── dm
│ ├── junos-xsd2yang
│ ├── junos-xsd2yang.xsl
│ └── pyang-support
├── var
│ └── ncs
└── VERSION
49 directories, 45 files
2.3 Set up the NSO working environment:

Setup the environment variables by sourcing the file “ncsrc” from the directory where NSO binary was
unpacked:
cisco@ubuntu:~$ source ~/ncs412/ncsrc

cisco@ubuntu:~$ echo $NCS_DIR
/home/cisco/ncs412
For the rest of the lab exercise, if at any time you use a different terminal window to execute an
NSO related command, ensure that you first source the “ncsrc” file in that terminal so that the
environment variables are properly setup.
Now, you can setup the NSO working directory by using the “ncs-setup” command. In this lab, we will
use the directory “ncsw” as the working directory:
cisco@ubuntu:~$ ncs-setup --dest ~/ncsw

cisco@ubuntu:~$ ls -al ~/ncsw/
total 44
drwxrwxr-x 7 cisco cisco 4096 Jun 17 11:59 .
drwxr-xr-x 6 cisco cisco 4096 Jun 17 11:59 ..
drwxrwxr-x 2 cisco cisco 4096 Jun 17 11:59 logs
drwxrwxr-x 2 cisco cisco 4096 Jun 17 11:59 ncs-cdb
-rw-rw-r-- 1 cisco cisco 8234 Jun 17 11:59 ncs.conf
drwxrwxr-x 2 cisco cisco 4096 Jun 17 11:59 packages
-rw-rw-r-- 1 cisco cisco 614 Jun 17 11:59 README.ncs
drwxrwxr-x 4 cisco cisco 4096 Jun 17 11:59 scripts
drwxrwxr-x 2 cisco cisco 4096 Jun 17 11:59 state
Note that in the newly created working directory, a configuration file “ncs.conf” has been
placed. This file will be used by the ncs daemon when it starts and tells it what capabilities it
should load.
Page 10 of 80
2.4 Starting NSO Daemon & verifying status:
Lets try to start the NSO daemon. Note that the daemon start command should be invoked while in the
working ncsw directory. So in the example shown below, the first try to start the daemon failed and only
after the directory was changed to the working directory NSO daemon started successfully.
This is because NSO daemon looks for ncs.conf file to know its configuration, and it assumes
this file is in the present working directory. An alternative is to use a command line flag to point
to the ncs.conf file.
cisco@ubuntu:~/ncs412$ pwd
/home/cisco/ncs412
cisco@ubuntu:~/ncs412$ ncs
Bad configuration: /home/cisco/ncs412/etc/ncs/ncs.conf:0: "./state/packages-
in-use: Failed to create symlink: no such file or directory"
Daemon died status=21
cisco@ubuntu:~/ncs412$ cd ~/ncsw
cisco@ubuntu:~/ncsw$ ncs
To verify if the NSO daemon is running and listening to the port 2024 for shell access, run the following
verification steps:
1) Use the command “ncs –status” which will give you full details about the daemon’s running state.
cisco@ubuntu:~/ncsw$ ncs --status

vsn: 4.1.2
SMP support: yes, using 4 threads
Using epoll: yes
available modules: backplane,netconf,cdb,cli,snmp,webui
running modules: backplane,netconf,cdb,cli,snmp,webui
status: started
namespaces: http://tail-f.com/ns/mibs/IANA-ITU-ALARM-TC-MIB/200409090000Z
prefix:IANA_ITU_ALARM_TC_MIB exported to: snmp
<snip>
2) Check in the log directory for information on NSO status, it should report that NSO has successfully
started
cisco@ubuntu:~/ncsw$ pwd
/home/cisco/ncsw
cisco@ubuntu:~/ncsw$ ls
logs ncs-cdb ncs.conf packages README.ncs scripts state
cisco@ubuntu:~/ncsw$ cd logs/
cisco@ubuntu:~/ncsw/logs$ ls
audit.log ncserr.log.1 ncs-java-vm.log netconf.log webui-browser.log
devel.log ncserr.log.idx ncs.log rollback10001 xpath.trace
localhost:8080.access ncserr.log.siz ncs-python-vm.log snmp.log
cisco@ubuntu:~/ncsw/logs$ tail -2 ncs.log
<DEBUG> 17-Jun-2016::12:04:43.334 ubuntu ncs[2169]: - Loading MIB:
/home/cisco/ncs412/lib/ncs/lib/snmp/snmp/priv/mibs/SNMP-VIEW-BASED-ACM-MIB.bin
<INFO> 17-Jun-2016::12:04:48.260 ubuntu ncs[2169]: - NCS started vsn: 4.1.2
Page 11 of 80
3) Verify that port number 2024 is open and NSO is listening to it. Any external connection to this port
will be authenticated by NSO and log into NSO CLI shell:
cisco@ubuntu:~/ncsw/logs$ netstat -pln | grep 2024

(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:2024 0.0.0.0:* LISTEN
2169/ncs.smp
2.5 Connecting to NSO using GUI and CLI

2.5.1 From Remote SSH Client:
By default, the username and password NSO CLI are
Username: admin , Password: admin
Connect to NSO CLI using the ssh session:
cisco@ubuntu:~/ncsw/logs$ ssh -l admin -p 2024 localhost

The authenticity of host '[localhost]:2024 ([127.0.0.1]:2024)' can't be established.
DSA key fingerprint is 2c:96:e2:b1:2b:ff:dc:43:b4:55:78:0d:5d:b5:9e:43.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:2024' (DSA) to the list of known hosts.
admin@localhost's password:
admin connected from 127.0.0.1 using ssh on ubuntu

admin@ncs>
admin@ncs> exit
Connection to localhost closed.
If you run into an error saying that the “REMOTE HOST KEY HAS CHANGED”. Then use the
following command to clear it and then try above step again…
cisco@ubuntu:~/.ssh$ ssh-keygen -f "/home/cisco/.ssh/known_hosts" -R [localhost]:2024
# Host [localhost]:2024 found: line 2 type DSA
/home/cisco/.ssh/known_hosts updated.
Original contents retained as /home/cisco/.ssh/known_hosts.old
cisco@ubuntu:~/.ssh$
2.5.2 Through GUI:

Chrome browser is available on the desktop and can be used to connect to the NSO gui interface.
To connect to NSO GUI, you can point your browser to the server running NSO daemon (in this case,
it’s 198.18.134.28) port 8080. i.e. : http://198.18.134.28:8080/
Page 12 of 80
This URL will take you to the NSO login screen .You can login using the default credentials
Username: admin
Password: admin
Once you login, the GUI’s dashboard will appear. Click on the top left circle icon with three bars:
Page 13 of 80
The following menu will appear, which can be used to browse the different sections of the GUI:
“Models”, “Views”, “Services”
2.5.3 Through CLI:

NSO provides a direct way to access the command line interface using a built-in command as shown
below:
cisco@ubuntu:~/ncsw/logs$ ncs_cli
pod connected from 198.18.133.252 using ssh on ubuntu

pod@ncs>
Once in the NSO command line mode, by default NSO starts with JUNOS CLI mode.
admin@ncs> show configuration

aaa {
authentication {
users {
user admin {
uid 1000;
gid 1000;
password $1$h/w8ZSw6$ETUTPoiGOnbzJ1g0nKyge/;
ssh_keydir /var/ncs/homes/admin/.ssh;
homedir /var/ncs/homes/admin;
}
Before proceeding with rest of the tasks, switch to Cisco style use switch command shown here:
admin@ncs> switch cli
admin@ncs# show running-config

aaa authentication users user admin
uid 1000
gid 1000
password $1$h/w8ZSw6$ETUTPoiGOnbzJ1g0nKyge/
ssh_keydir /var/ncs/homes/admin/.ssh
homedir /var/ncs/homes/admin
Page 14 of 80
!
<snip>
admin@ncs# exit
cisco@ubuntu:~/ncsw/logs$
2.6 Adding NSO NED Packages:

2.6.1 Checking currently loaded packages:
Check if any packages were loaded by the daemon at the startup. You can verify using the “ncs –
status” command (its easier to look for specific name to find if a package is loaded), alternatively you
can look at the CLI and use the ‘show packages’ command as shown below:
cisco@ubuntu:~/ncsw$ ncs --status | grep xr

cisco@ubuntu:~/ncsw$ ncs --status | grep ios
cisco@ubuntu:~/ncsw$
cisco@ubuntu:~/ncsw$ ncs_cli -C
admin connected from 198.18.133.252 using ssh on ubuntu
admin@ncs# show packages package

% No entries found.
admin@ncs#
As the above outputs show, there isn’t any package/NED that is loaded at this point. To load the
package, refer to the subsequent section.
Note the use of “-C” flag in the above ncs_cli command. This option takes you directly to the
cisco command line mode.
2.6.2 Adding new package:

Some of the NED packages were already included in the NSO binary that we uncompressed earlier.
We can browse to the directory (~/412/) where we have uncompressed the binary file, and view the
packages that were included:
cisco@ubuntu:~/ncsw$ ls ~/ncs412/packages/neds/
a10-acos cisco-ios cisco-iosxr cisco-nx dell-ftos juniper-junos
These packages are still in the installation directory, and need to be added to our working directory, i.e.
~/ncsw. We will use the following set of steps to load these packages:
2.6.2.1 Adding packages to working directory:
You can add a package by using the “ncs-setup” command again and specifying the package using the
–ned-package option. Lets load the IOS package using this method:
Note that if you use a separate new terminal window to execute the commands, then that
session will need to have the environment variables set as shown in section 2.3
Page 15 of 80
Now lets use the ncs-setup command to load these packages to the working directory we had
previously created:
cisco@ubuntu:~/ncsw$ ls ~/ncsw/packages/
cisco@ubuntu:~/ncsw$ << package directory is empty
cisco@ubuntu:~/ncsw$ ncs-setup --dest ~/ncsw --ned-package cisco-ios
cisco@ubuntu:~/ncsw$ ls ~/ncsw/packages/
cisco-ios
cisco@ubuntu:~/ncsw$ ncs-setup --dest ~/ncsw --ned-package cisco-iosxr
cisco@ubuntu:~/ncsw$ ls packages/
cisco-ios cisco-iosxr
2.6.2.2 Load the packages into the NSO Daemon trough Command Line
Interface:
Though the package are in the working directory now, they will not be automatically loaded into the
daemon which was already running (we started it in the previous section) . Use the below commands to
validate this:
cisco@ubuntu:~/ncsw$ ncs --status | grep ios

cisco@ubuntu:~/ncsw$ ncs --status | grep xr
<< so still not loaded in daemon, but added to file structure
To load the packages, we will use the following set of steps:
cisco@ubuntu:~/ncsw/logs$ ncs_cli -C
admin connected from 198.18.133.252 using ssh on Ubuntu
admin@ncs# show packages package

% No entries found.
admin@ncs# packages reload
>>> 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 cisco-ios
result true
}
reload-result {
package cisco-iosxr
result true
}
Use the following command to check the version of packages that was loaded. Note that the NED
package version can upgraded without changing the NSO version that you are running, using same set
of steps that were described in the above section.
Page 16 of 80
admin@ncs# show packages package package-version
PACKAGE
NAME VERSION
----------------------
cisco-ios 3.0
cisco-iosxr 3.0
Page 17 of 80
3 Lab Task 1-2: Connecting to Devices
3.1 Creating Authgroup for Devices:

Before adding devices into NSO you have to create authentication group first:
cisco@ubuntu:~/ncsw/logs$ ncs_cli -C
admin connected from 198.18.133.252 using ssh on Ubuntu
admin@ncs#
admin@ncs # show running-config devices authgroups
devices authgroups group default
umap admin
remote-name admin
remote-password $4$wIo7Yd068FRwhYYI0d4IDw==
!
umap oper
remote-name oper
remote-password $4$zp4zerM68FRwhYYI0d4IDw==
!
!
devices authgroups snmp-group default
default-map community-name public
umap admin
usm remote-name admin
usm security-level auth-priv
usm auth md5 remote-password $4$wIo7Yd068FRwhYYI0d4IDw==
usm priv des remote-password $4$wIo7Yd068FRwhYYI0d4IDw==
admin@ncs # conf
admin@ncs(config)# devices authgroups group CL-default
admin@ncs(config-group-CL-default)# default-map remote-name cisco
admin@ncs(config-group-CL-default)# default-map remote-password cisco
admin@ncs(config-group-CL-default)# default-map remote-secondary-password
cisco
admin@ncs(config-group-CL-default)# top
admin@ncs(config)# show configuration
devices authgroups group CL-default
default-map remote-name cisco
default-map remote-password $4$wocla9w68FRwhYYI0d4IDw==
default-map remote-secondary-password $4$wocla9w68FRwhYYI0d4IDw==
!
admin@ncs(config)# commit
Commit complete.
admin@ncs(config)#
3.2 Adding a New Router/Device Using CLI:

Once the authentication groups defined, devices can be added to the NSO:
admin@ncs(config)# devices device CE1_CL16

admin@ncs(config-device-CE1_CL16)# address 198.18.1.30
admin@ncs(config-device-CE1_CL16)# authgroup CL-default
admin@ncs(config-device-CE1_CL16)# device-type cli ned-id ?
Page 18 of 80
Possible completions:
cisco-ios cisco-ios-xr
Note that both NEDs that were added earlier, are available as possible choices. We will choose
cisco-ios since this router is an IOS device.
admin@ncs(config-device-CE1_CL16)# device-type cli ned-id cisco-ios

admin@ncs(config-device-CE1_CL16)# device-type cli protocol telnet
admin@ncs(config-device-CE1_CL16)# top
admin@ncs(config)# show config

devices device CE1_CL16
address 198.18.1.30
authgroup CL-default
device-type cli ned-id cisco-ios
device-type cli protocol telnet
config
no ios:service pad
no ios:ip domain-lookup
no ios:ip http secure-server
ios:ip source-route
!
!
3.3 Config Locks:

State Description
Locked Device’s configuration changes are not allowed in CLI
South-bound Configuration changes can be made in the Tail-f, however these changes
Locked can not be pushed out and committed to the device
Unlocked Configuration changes can be made in Tail-f and can be pushed to the
device
Go to NSO GUI, if you click on the admin state of desired device, it will show the three options from
drop down, choose desired state save and commit
3.3.1 Locked State:

To lock the device from GUI either use above method or click on device name and then move to status
tab and select admin-state as locked and commit the change from top Commit button. Lets try to make
changes to the device while its locked:
Page 19 of 80
Alternatively to lock from CLI and then try to make changes
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# devices device CE1_CL16 state admin-state locked
admin@ncs(config-device-CE1_CL16)# commit
Commit complete.
admin@ncs(config-device-CE1_CL16)# config ios:hostname CE1_CL16_TEST
admin@ncs(config-config)# commit
Aborted: Device CE1_CL16 is locked
admin@ncs(config-config)#
3.3.2 South-bound Locked State:

Now lets change our device to “southbound lock”. You shall now be able to make changes in NSO
configuration, however these changes will not be able to propagate to the device:
admin@ncs(config)# devices device CE1_CL16 state admin-state southbound-

locked
Commit complete.
admin@ncs(config)# show configuration commit changes
!
! Created by: admin
! Date: 2016-06-17 13:51:19
! Client: cli
!
state admin-state southbound-locked
config
ios:hostname CE1_CL16_TEST
Page 20 of 80
!
!
At this point, the changes are committed in the NSO config. Lets now try to push the change to the
device:
admin@ncs# devices device CE1_CL16 sync-to

result false
info Device CE1_CL16 is south bound locked
admin@ncs#
3.4 Syncing Configuration From Device

The router CE_CL16 already has some configuration in it. Before we start configuring it using NSO, we
should ensure that the device config and the NSO configuration are in sync. Use the following steps to
achieve that:
admin@ncs(config)# devices device CE1_CL16 state admin-state ?

Possible completions:
[southbound-locked]
locked Device is locked for config and southbound traffic
southbound-locked Device is locked for southbound traffic
unlocked Device is open for config and southbound traffic
admin@ncs(config)# devices device CE1_CL16 state admin-state unlocked
Commit complete.
admin@ncs(config)# do show running-config devices device CE1_CL16
address 198.18.1.30
state admin-state unlocked
config
no ios:service pad
ios:ip source-route
!
!
admin@ncs(config)# end
admin@ncs # devices device CE1_CL16 sync-from
result true
admin@ncs # show running-config devices device CE1_CL16

address 198.18.1.30
config
ios:version 15.6
Page 21 of 80
no ios:service pad
ios:service timestamps debug datetime msec
ios:service timestamps log datetime msec
ios:hostname CE1_CL16
ios:enable password cisco
ios:username cisco secret 5 $1$KAnx$lhtc4rTzd97/qSn9AVGv9.
ios:vrf definition Mgmt-intf
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!
ios:ip cef
no ios:ip domain lookup
ios:ip domain name virl.info
ios:ip forward-protocol nd
no ios:ip http server
ios:ip route vrf Mgmt-intf 0.0.0.0 0.0.0.0 198.18.1.1
ios:ip source-route
ios:ipv6 unicast-routing
ios:ipv6 cef
ios:interface GigabitEthernet0/0
media-type rj45
duplex full
speed auto
description OOB Management
vrf forwarding Mgmt-intf
ip address 198.18.1.30 255.255.255.0
exit
ios:interface GigabitEthernet0/1
media-type rj45
duplex full
speed auto
description to iosxrv-1
ip address 192.168.12.1 255.255.255.0
<snip>
3.4.1 Comparing NSO config with device:

If you are not sure if the device and NSO configs are in sync, you can check it using “compare config”.
In our case, these two should be not be in sync (since hostname was changed on NSO side in 3.3.2) if
all previous steps were followed.
We can see the details of this configuration difference by comparing the config:
admin@ncs# devices device CE1_CL16 compare-config

diff
devices {
device CE1_CL16 {
config {
- ios:hostname CE1_CL16_TEST;
+ ios:hostname CE1_CL16;
}
Page 22 of 80
}
}
admin@ncs#
3.4.2 Check-Sync the devices:

Sync the config from device again and run check-sync to make sure everything is in sync
admin@ncs# devices device CE1_CL16 sync-from

result true
admin@ncs# devices device CE1_CL16 check-sync
result in-sync
admin@ncs#
admin@ncs# show devices device state
OPER
OPER STATE TRANSACTION
NAME STATE ERROR TAG MODE LAST TRANSACTION ID
------------------------------------------------------------------------------
CE1_CL16 enabled - ned 2cfe64be060abb2c415db86c10905af1
3.5 Adding a new device using GUI:

Lets try to add a new device using the NSO GUI interface. Connect to the GUI using the browser as
shown in previous section. Notice that the CE1_CL16 device that we had added, would already be
visible now in the GUI, as shown here:
To add the 2nd device using GUI instead of CLI , follow the steps below:
1) Click on “+” option from the Devices menu:
Page 23 of 80
2) Use the GUI options to define the device parameters listed in the table below.
State Description
Name PE1_CL16
Address 198.18.1.31
Port <leave blank>
Device Type CLI
NED ID cisco-iosxr
Protocol telnet
Authgroup CL-default
3) Click “OK”
Your basic device configuration is complete at this point. However, this configuration is still not
committed. It will therefore not be visible in the CLI:

OPER
STATE
OPER ERROR TRANSACTION
NAME STATE TAG MODE LAST TRANSACTION ID
--------------------------------------------------------------------------
admin@ncs#
Page 24 of 80
4) To complete the process of this device addition we need to commit,
View the changes that your new configuration is going to make (equivalent of “show config” from the
CLI menu):
Validate the changes before trying to commit, pop-up shall appear on the top right corner of the browser
screen:
5) Finally click commit
Page 25 of 80
You can now view the committed changes in the CLI

OPER
STATE
OPER ERROR TRANSACTION
NAME STATE TAG MODE LAST TRANSACTION ID
--------------------------------------------------------------------------
PE1_CL16 disabled - - -
admin@ncs# show running-config devices device PE1_CL16

devices device PE1_CL16
address 198.18.1.31
port 23
description ""
device-type cli ned-id cisco-ios-xr
config
no ios:service pad
ios:ip source-route
!
6) Make sure device is in Unlock state. To Unlock the device from GUI click on the admin state of
desired device, it will show the three options from drop down, choose unlock save and commit
Page 26 of 80
7) To Sync the config from the device, Click on device name and click on sync-from under
device tab.
Followed by clicking “Invoke sync-from” at next window and wait for it to display the result
Page 27 of 80
To return to the main device list from the sync-from menu option, use the following sequence of steps:
3.6 Adding Remaining Devices in the Topology:

Add the remaining three devices using the information in the table below. You can use the “load
configuration” command to load the pre-defined configuration for these devices as show below.
admin@ncs# config
admin@ncs(config)# load merge /home/cisco/content/add_devices.txt

Loading.
874 bytes parsed in 0.06 sec (9.29 KiB/sec)
devices device P1_CL16

address 198.18.1.32
description "P1 for CiscoLive POD"
device-type cli ned-id cisco-ios-xr
config
no ios:service pad
Page 28 of 80
ios:ip source-route
!
!
devices device PE2_CL16
address 198.18.1.33
description "PE2 for CiscoLive POD"
config
no ios:service pad
ios:ip source-route
!
!
address 198.18.1.34
description "CE2 for CiscoLive POD"
config
no ios:service pad
ios:ip source-route
!
admin@ncs(config)#commit
The above steps added the remaining devices with the below configuration:
State Description
Name P1_CL16
Address 198.18.1.32
NED Type CLI
NED ID cisco-iosxr
Protocol SSH
State Description
Name PE2_CL16
Address 198.18.1.33
NED Type CLI
NED ID cisco-ios
Protocol Telnet
Page 29 of 80
State Description
Name CE2_CL16
Address 198.18.1.34
NED Type CLI
NED ID cisco-ios
Protocol Telnet
If you are using the GUI to add these new devices, the device table above can be used to look at the
parameters prior to committing.
3.7 Sync device configurations:

After unlocking all the newly added devices, sync the configs “from” the existing routers. You can easily
unlock the device by clicking Admin state of particular device in Device menu and select unlock
followed by save and commit.
Ensure that the devices are in “unlock” state.
You can do sync-from all the devices in one go using CLI or GUI as shown below:
Select all the devices from menu, and choose the “Action” menu option “sync-from”:
Wait for couple minute to complete the sync-from process to be finished, Once sync is done, you will
see it reflected result as “True” in the GUI.
Page 30 of 80
Note: The CLI method of performing a global device sync would be to use the following
command:
admin@ncs# devices sync-from
Only one of the above two methods (CLI or GUI) is sufficient.
On the CLI, the following command can be used for checking IOS device sync:
admin@ncs# devices sync-from

sync-result {
device CE1_CL16
result true
}
sync-result {
device CE2_CL16
result true
}
sync-result {
device P1_CL16
result true
}
sync-result {
device PE1_CL16
result true
}
sync-result {
device PE2_CL16
result true
}
Page 31 of 80
admin@ncs# devices check-sync
sync-result {
device CE1_CL16
result in-sync
}
sync-result {
device CE2_CL16
result in-sync
}
sync-result {
device P1_CL16
result unsupported
}
sync-result {
device PE1_CL16
result unsupported
}
sync-result {
device PE2_CL16
result in-sync
}
admin@ncs#
3.8 Configure basic parameter through GUI:

The example below shows the interface IP address configuration steps for P1_CL16 using GUI.
1) Click on the device P1_CL16 from the “devices” menu, then select interface under config tab.
2) Choose the interface Gigabit Ethernet, followed by the interface number 0/0/0/0, and then
select the “IPv4 Address” options:
Page 32 of 80
3) Enter the address and mask:
Page 33 of 80
Validate the changes by looking at the output of “View changes” (from the commit button drop down
menu)
4) Perform a “Commit Dry Run” To see exactly the changes that will be made as a result of the
above steps:
Page 34 of 80
5) Commit the config changes and confirm
6) Ensure the interface is not in shutdown state. Click Back button from Browser and un-shut it
from GigabitEthernet tab and uncheck the “shutdown” option:
Page 35 of 80
7) Validate this change by looking at the commit dry run:
Note that when a config is deleted, commit dry run output shows it in RED, instead of GREEN
for a config that is added.
8) You can now validate the above changes by logging into the device and checking the actual
router config (Note: perform the below command from the Linux shell prompt)
cisco@ubuntu:~$ telnet 198.18.1.32
RP/0/0/CPU0:P1_CL16#show run int gigabitEthernet 0/0/0/0

interface GigabitEthernet0/0/0/0
ipv4 address 192.168.23.3 255.255.255.0
!
3.9 Configure basic parameter through CLI:

Below example shows the interface IP address configuration steps for P1_CL16 using CLI
1) Login in to NSO CLI, and enter the device configuration mode:

cisco@ubuntu:~/ncsw/packages$ ncs_cli -C
cisco connected from 198.18.133.252 using ssh on ubuntu
admin@ncs# config
admin@ncs(config)# devices device P1_CL16 config
admin@ncs(config-config)#
Page 36 of 80
2) Configure the new interface ip address :
admin@ncs(config-config)# cisco-ios-xr:interface GigabitEthernet 0/0/0/1

admin@ncs(config-if)# ipv4 address 192.168.34.3 255.255.255.0
admin@ncs(config-if)# no shutdown
admin@ncs(config-if)# top
admin@ncs(config)#
3) Validate the changes by using “Show config”, as well as the commit dry run information:

config
cisco-ios-xr:interface GigabitEthernet 0/0/0/1
ipv4 address 192.168.34.3 255.255.255.0
no shutdown
exit
!
!
admin@ncs(config)# commit dry-run
device P1_CL16
config {
cisco-ios-xr:interface {
GigabitEthernet 0/0/0/1 {
ipv4 {
address {
+ mask 255.255.255.0;
+ ip 192.168.34.3;
}
}
- shutdown;
}
}
}
admin@ncs(config)#
admin@ncs(config)# do show running-config devices device P1_CL16 config

cisco-ios-xr:interface GigabitEthernet
config
shutdown
exit
!
!
admin@ncs(config)#
4) Commit the changes:
Commit complete.
admin@ncs(config)# do show running-config devices device P1_CL16 config
cisco-ios-xr:interface GigabitEthernet
Page 37 of 80
config
ipv4 address 192.168.34.3 255.255.255.0
exit
!
!
admin@ncs(config)#
5) You can also validate the changes on the Router itself, as well as a on the GUI:
RP/0/0/CPU0:P1_CL16#show run int gigabitEthernet 0/0/0/1
Fri May 22 23:57:07.914 UTC
ipv4 address 192.168.34.3 255.255.255.0
!
3.10 Configure Remaining interfaces:

The remaining interfaces on all devices are pre-configured. Optionally we could have used load config
method to load pre defined config in bulk.
The full topology view of the interfaces and IP addresses is like this:
G0/0/0/1 G0/0/0/1
192.168.12.2 192.168.23.2 192.168.34.3 192.168.45.4
G0/0/0/0
PE1_CL16 - P1_CL16 - PE2_CL16
G0/2
XR XR 192.168.34.4
-IOS
192.168.23.3
G0/0/0/0 G0/1
192.168.12.1
G0/1 192.168.45.5
G0/1
CE1_CL16 -
IOS CE2_CL16
-IOS
Optionally Use the load config option as shown below:
admin@ncs# config
admin@ncs(config)# load merge /home/cisco/content/add_interfaces.txt
Loading.
701 bytes parsed in 0.09 sec (7.12 KiB/sec)
You can also review config at ~/content/add_interfaces.txt
Page 38 of 80
3.11 Rollback Configuration Changes:
To show Rollback of configuration changes we will change Hostname
1) Go to the devices and click on P1_CL16, and change the hostname under the “config“
tab as follows to something different:
2) Commit the change
3) You can now view this change on the device directly:
RP/0/0/CPU0:P1_CL#show configuration commit changes last 1

Tue Jun 21 02:19:53.760 UTC
Building configuration...
!! IOS XR Configuration 6.0.1
hostname P1_CL
end
4) Click on the rollback on left side under Views and then on right side click on topmost
row you will see the changes rollback script going to make in bottom pan.
Page 39 of 80
Note that both GUI changes and CLI changes can be rolled back through this option. A
similar list is also available for rollback in the CLI:
admin@ncs# show configuration commit list

2016-06-20 22:28:07
SNo. ID User Client Time Stamp Label Comment
~~~~ ~~ ~~~~ ~~~~~~ ~~~~~~~~~~ ~~~~~ ~~~~~~~
1007 10072 admin webui 2016-06-20 22:26:13
1007 10071 admin webui 2016-06-20 22:18:59
1007 10070 admin cli 2016-06-20 22:01:05
1006 10069 admin webui 2016-06-20 21:57:33
5) Perform the rollback, by choosing the “load rollback<id>” option from this page and choose
“selective”. A rollback confirmation will be shown in the information pop-up:
Page 40 of 80
6) Just like other confirmation changes, this config change due to rollback is still local to
the GUI and now needs to be pushed to the device. A commit dry run will show the
changes:
7) Commit the changes to the device, and verify on the device:
RP/0/0/CPU0:P1_CL#
RP/0/0/CPU0:P1_CL16#show configuration commit changes last 1
Tue Jun 21 02:25:49.396 UTC
Page 41 of 80
hostname P1_CL16
end
Note that to perform rollback operation from the CLI, the command to rollback is under the
config mode:
admin@ncs# conf
admin@ncs(config)# rollback configuration
Page 42 of 80
4 Lab Task 2-2: Creating and Implementing Service
Template
The service template requires that a new service package be created. To create that, you need to make
a YANG model for your service and an XML template.
YANG model is created to define all the parameters, which will be defined as part of the config for this
template. XML template is needed for translating those data values into a CLI that can be passed to
the device
4.1 Create a Blank Package Based on Template:

Login in the POD, and using the “ncs-make-package” command, create a blank template in the
~/ncsw/packages/ directory giving it the name “ospf”
You will have to source the ~/ncs412/ncsrc file if using new terminal session
cisco@ubuntu:~$ source ~/ncs412/ncsrc

cisco@ubuntu:~$ cd ~/ncsw/packages
cisco@ubuntu:~/ncsw/packages$ ncs-make-package --verbose --service-skeleton
template-based ospf
Using skeleton from /home/cisco/ncs412/src/ncs/package-skeletons
Wrote package to ospf
cisco@ubuntu:~/ncsw/packages$
You can view the tree structure created by using the “tree” command:
cisco@ubuntu:~/ncsw/packages$ tree ospf

ospf
├── load-dir
├── package-meta-data.xml
├── src
│ ├── java
│ │ └── src
│ │ └── com
│ │ └── example
│ │ └── ospf
│ │ └── namespaces
│ ├── Makefile
│ └── yang
│ └── ospf.yang
└── templates
└── ospf.xml
10 directories, 4 files
4.2 Identify the YANG modelling parameters

Since purpose of the exercise is to demonstrate the process, we will keep our YANG model simple to
achieve the basic task.
The key parameters that required to define an OSPF routing instance will be:
Page 43 of 80
Neighbor
OSPF Router ID OSPF Area Informatio
Process n
Name or
Number IP Address Integer IP address IOS XR IOS
Address
IOS XR IOS Neighbor
Family
Address
Type
Name Number Interface

Mask
Name
Lets determine the type of each of these variables:
Variable Variable Type Predefined?

OSPF Process Name or Number String Yes
Router ID Type IP Address ietf-inet-types
OSPF Area Integer OR IP Address No
Address Family (Hardcoded and using only IPv4) N/A
Interface Name From Device N/A
Neighbor Address IP Address ietf-inet-types
Go to the directory ~/ncsw/packages/ospf/src/yang and view the ospf.yang file in it. This file is a basic
structure that the previous step’s command created. We will now have to populate it with our required
yang parameters:
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$ more ospf.yang
module ospf {
namespace "http://com/example/ospf";
prefix ospf;
import ietf-inet-types {
prefix inet;
}
import tailf-ncs {
prefix ncs;
}
augment /ncs:services {
list ospf {
key name;
<<< snip >>>
Notice the following values in this file:

- Module : This will be name of the package when imported into NSO
- Prefix : Any reference to this YANG module will be prefixed by this keyword
Page 44 of 80
- Import : These are modules which are being imported to build on top of. In this case, we
are importing basic NSO module, and IEFT-INET-TYPE module
- Augment: This is the config section that this YANG module will add to. In this case, we are
augmenting on the “services” keyword in the NSO CLI
4.3 Use the Pre Built YANG model file

The yang model to deploy this service configuration is already built and ready to be used. Use the steps
below to copy it to the appropriate location:
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$ cp ~/content/ospf.yang
~/ncsw/packages/ospf/src/yang/ospf.yang
The Appendix section walks through the complete set of steps involved in building this yang file.
You can refer to this section and follow the steps there to build your model step by step.
4.4 Verifying the YANG model:

To validate the yang model we just created, we can use the syntax check tool that’s built into NSO
installation – called “PYANG”
“Pyang” is written in Python, hence the “P”. There are other tools available like Jyang – written
in Java
Save the file, and from the prompt, run PYANG as shown below:
cisco@ubuntu:~/ncsw$ cd ~/ncsw/packages/ospf/src/yang
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$ ls -al ospf.yang
-rw-rw-r-- 1 cisco cisco 2217 May 28 16:16 ospf.yang
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$ pyang ospf.yang
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$
Since we didn’t get any error, this means that everything is fine. However, if there are any sytax errors,
then those will need to be addressed before processed.
4.5 Compile the new YANG model:

A Makefile is already in place by the hierarchy created earlier. Run the “make” command as shown
below:
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$ cd ~/ncsw/packages/ospf/src
cisco@ubuntu:~/ncsw/packages/ospf/src$ make
<below is the o/p after make command execution>
/home/cisco/ncs412/bin/ncsc `ls ospf-ann.yang > /dev/null 2>&1 && echo "-a

ospf-ann.yang"` \
--yangpath yang -c -o ../load-dir/ospf.fxs yang/ospf.yang
Page 45 of 80
Congratulations! You have now completed the model development. You can refer to Appendix for some
optional changes you can make this model a bit more interesting.
Load the package in CLI:

Since our YANG model is ready, we can potentially load it in the CLI now. This will still not fully usable
since we still need to define the XML template, however, the CLI keywords are defined through the
yang model and would therefore be available:

PACKAGE
NAME VERSION
----------------------
cisco-ios 3.0
cisco-iosxr 3.0

reload-result {
package cisco-ios
result true
}
reload-result {
package cisco-iosxr
result true
}
reload-result {
package ospf
result true
}
PACKAGE
NAME VERSION
----------------------
cisco-ios 3.0
cisco-iosxr 3.0
ospf 1.0
admin@ncs# show packages package ospf

packages package ospf
package-version 1.0
description "Skeleton for a template-based resource facing service"
ncs-min-version [ 3.0 ]
directory ./state/packages-in-use/1/ospf
templates [ ospf ]
oper-status up
Note that the CLI will be configurable, but there will be no way to translate it to a format that can
be understood by the device (i.e. IOS-XR CLI syntax). That part (translation from yang model
based CLI, to IOS-XR CLI) is done through the XML template. So lets define the XML template.
Page 46 of 80
4.6 Adding XML Template:
We have pre-built the XML file and ready to be used. It can be copied to the appropriate location using
the below steps.
The details and full set of steps to build this XML file are included in Appendix section, and you
are encouraged to try that out if time permits during the session or later.
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$ cp ~/content/ospf.xml
~/ncsw/packages/ospf/templates/ospf.xml
4.7 Using XML Template:

Lets reload the package again so that it can load the XML template we just created:

reload-result {
package cisco-ios
result true
}
reload-result {
package cisco-iosxr
result true
}
reload-result {
package ospf
result true
}
Now we can define the service and convert to CLI. To view the translated version to CLI before you
commit, use “Commit dry-run”:
admin@ncs# config
admin@ncs(config)# services ospf PE1_CL16 process-id 1 iosxr router-id
2.2.2.2 area-id 0 interface-name Giga0/0/0/1
admin@ncs(config-interface-name-Giga0/0/0/1)# top
services ospf PE1_CL16
process-id 1
iosxr router-id 2.2.2.2
iosxr area-id 0
interface-name Giga0/0/0/1
!
!
!
admin@ncs(config)# commit dry-run outformat cli
device PE1_CL16
config {
cisco-ios-xr:router {
+ ospf 1 {
+ router-id 2.2.2.2;
Page 47 of 80
+ area 0 {
+ interface Giga0/0/0/1;
+ }
+ }
}
}
On the PE1_CL16 router, you can see the changes of the last commit:
RP/0/0/CPU0:PE1_CL16#sh config commit changes last 1

router ospf 1
router-id 2.2.2.2
area 0
!
!
!
end
4.8 Using the Same Service Template for Configuring IOS

Device:
admin@ncs(config)# services ospf CE1_CL16 process-id 1 ios router-id 1.1.1.1

network 192.168.12.0 0.0.0.255 area 0
admin@ncs(config-network-192.168.12.0/0.0.0.255)# top
services ospf CE1_CL16
process-id 1
ios router-id 1.1.1.1
ios network 192.168.12.0 0.0.0.255
area [ 0 ]
!
!
device CE1_CL16
config {
ios:router {
+ ospf 1 {
+ non-vrf {
+ network 192.168.12.0 0.0.0.255 {
+ area 0;
+ }
+ }
+ }
}
Page 48 of 80
}
The impact of this change can be seen on the CE_CL16 device:
CE1_CL16#show run | b ospf

router ospf 1
router-id 1.1.1.1
network 192.168.12.0 0.0.0.255 area 0
!
<snip>
Our template and yang models are now complete! Lets try applying these through the GUI in the next
section
4.9 Viewing the Service Template in GUI:

You can now go the GUI, and view the service that we just created:
You can Add a new service using the “+” option and provide device name “P1_CL16” (make sure you
type device name correct)
Page 49 of 80
Once you add the device name, Click on device-name to provide parameters for this device:
Enter the process ID “1” as shown above, and for the remainder of the XR specific config, go to the
“IOSXR” section. Provide the router ID “3.3.3.3”
add (+) the area-id 0 and then interfaces Gig0/0/0/0 and Gig0/0/0/1 in area 0 :
Page 50 of 80
Hit Back button from Browser once and then add other interface Gig0/0/0/1 as well.
Page 51 of 80
Before committing the changes, do a dry run, and if everything looks ok, then go ahead and commit that
will push the config to the device P1_CL16:
RP/0/0/CPU0:P1_CL16#sh ospf neighbor

Tue Jun 28 22:24:56.175 UTC
* Indicates MADJ interface

# Indicates Neighbor awaiting BFD session up
Neighbors for OSPF 1
Neighbor ID Pri State Dead Time Address Interface

2.2.2.2 1 FULL/DR 00:00:37 192.168.23.2
GigabitEthernet0/0/0/0
Neighbor is up for 00:00:11
Total neighbor count: 1
Page 52 of 80
4.10 Adding 2nd Interface to existing OSPF process:
So far we have added interface and area in one shot. Lets check if our model and template work fine
when there are the service stays intact when additional interfaces or area is added on top of the existing
service.
We will work on PE1_CL16 for this example. The currently configured service for this device is:
admin@ncs# show running-config services ospf PE1_CL16

process-id 1
iosxr area-id 0
interface-name Giga0/0/0/1
!
!
!
Lets add an additional interface and area to this device:
admin@ncs# config
admin@ncs(config)# services ospf PE1_CL16 process-id 1 iosxr router-id

2.2.2.2 area-id 0 interface-name gig0/0/0/0
admin@ncs(config-interface-name-giga0/0/0/0)# show config

iosxr area-id 0
interface-name Gig0/0/0/0
!
!
!
Commit complete.
admin@ncs(config)# end
admin@ncs# show running-config services ospf PE1_CL16

process-id 1
iosxr area-id 0
!
!
!
!
Page 53 of 80
4.11 Completing OSPF config for remaining devices:
G0/0/0/1 G0/0/0/1
192.168.12.2 192.168.23. 192.168.34 192.168.45.4
G0/0/0/0
PE1_CL16 2
P1_CL16
.3
PE2_CL
G0/2
- XR - XR 192.168.316 -IOS
192.168.23
4.4
.3
G0/0/0/0 G0/1
192.168.1
2.1 G0/1 G0/1
192.168.
45.5
CE1_CL1
6 - IOS CE2_CL
16 -IOS
Complete the configuration for OSPF on the remaining devices: PE2_CL16, CE2_CL16 using the
following information:
Device Process ID Router ID Area Interface Network Mask

CE1_CL16 1 1.1.1.1 0 X 192.168.12.0 0.0.0.255
PE1_CL16 1 2.2.2.2 0 Giga0/0/0/0 X X
PE1_CL16 1 2.2.2.2 0 Giga0/0/0/1 X X
P1_CL16 1 3.3.3.3 0 Giga0/0/0/0 X X
P1_CL16 1 3.3.3.3 0 Giga0/0/0/1 X X
PE2_CL16 1 4.4.4.4 0 X 192.168.34.0 0.0.0.255
PE2_CL16 1 4.4.4.4 0 X 192.168.45.4 0.0.0.255
CE2_CL16 1 5.5.5.5 0 X 192.168.45.0 0.0.0.255
Lets configure PE2 first, below are the steps you would need to take to configure PE2, and validate that
config changes before committing:
admin@ncs(config)# services ospf PE2_CL16 process-id 1 ios router-id 4.4.4.4

network 192.168.34.0 0.0.0.255 area 0
admin@ncs(config)# services ospf PE2_CL16 process-id 1 ios router-id 4.4.4.4
network 192.168.45.0 0.0.0.255 area 0
process-id 1
ios router-id 4.4.4.4
ios network 192.168.34.0 0.0.0.255
area [ 0 ]
!
ios network 192.168.45.0 0.0.0.255
area [ 0 ]
!
!
device PE2_CL16
config {
Page 54 of 80
ios:router {
+ ospf 1 {
+ non-vrf {
+ network 192.168.34.0 0.0.0.255 {
+ area 0;
+ }
+ network 192.168.45.0 0.0.0.255 {
+ area 0;
+ }
+ }
+ }
}
}
Commit complete.
admin@ncs(config)#
Let’s do the last router CE2_CL16 using the GUI:
If you want to configure this device using CLI as well, you can use:
services ospf CE2_CL16 process-id 1 ios router-id 5.5.5.5 network 192.168.45.0 0.0.0.255 area
0
Go the “OSPF” section in the “services” menu:
Choose the “add(+)” option, and enter the device name CE2_CL16.
Add the device, and after clicking on device name on the subsequent screen, enter process ID 1 and go
to the IOS section. In the IOS section, and enter the router-id as 5.5.5.5 and then network
(192.168.45.0) and mask (0.0.0.255) as follows
Page 55 of 80
Page 56 of 80
After the above steps, the commit dry run option can be used to view the changes being committed:
This completes our OSPF configuration end to end. Lets checkout the OSPF routes at the CE1_CL16
device, and see if you can ping CE2_CL16 interface:
CE1_CL16#show ip route ospf

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
Page 57 of 80
ia - IS-IS inter area, * - candidate default, U - per-user static
route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
Gateway of last resort is not set
O 192.168.23.0/24 [110/2] via 192.168.12.2, 00:16:09, GigabitEthernet0/1

CE1_CL16#
CE1_CL16#ping 192.168.45.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.45.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 14/30/89 ms
CE1_CL16#
Page 58 of 80
5 Bonus Content
5.1 Additional ways to view the yang model using PYANG:

5.1.1 Generating XML view of yang model:
The YANG model can also be viewed or put-together in XML like format. That is called “YIN”. Pyang
can be used to generate a YIN representation of our OSPF model
cisco@ubuntu:~$ cd ~/ncsw/packages/ospf/src/yang
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$ pyang -f yin ospf.yang
<?xml version="1.0" encoding="UTF-8"?>
<module name="ospf"
xmlns="urn:ietf:params:xml:ns:yang:yin:1"
xmlns:ospf="http://com/example/ospf"
xmlns:inet="urn:ietf:params:xml:ns:yang:ietf-inet-types"
xmlns:ncs="http://tail-f.com/ns/ncs"
xmlns:tailf="http://tail-f.com/yang/common">
<namespace uri="http://com/example/ospf"/>
<prefix value="ospf"/>
<import module="ietf-inet-types">
<prefix value="inet"/>
</import>
<import module="tailf-ncs">
<prefix value="ncs"/>
</import>
<import module="tailf-common">
<prefix value="tailf"/>
</import>
<typedef name="ospf-area">
<type name="union">
<type name="uint32"/>
<type name="inet:ipv4-address"/>
</type>
</typedef>
<augment target-node="/ncs:services">
<list name="ospf">
<uses name="ncs:service-data"/>
<ncs:servicepoint id="ospf"/>
<key value="device-name"/>
<leaf name="device-name">
<mandatory value="true"/>
<type name="leafref">
<path value="/ncs:devices/ncs:device/ncs:name"/>
<<<< snipped >>>>
</container>
<tailf:callpoint id="ncs-rfs-service-hook">
<tailf:transaction-hook value="subtree">
<tailf:invocation-mode value="per-transaction"/>
</tailf:transaction-hook>
</tailf:callpoint>
</list>
</augment>
</module>
Page 59 of 80
5.1.2 Generating HTML view of YANG module:
One of the other fancy things PYANG can do is to generate an HTML view of any yang file. You can do
that and place the HTML file in the web browser directory and view using the browser. Steps are shown
below:
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$ pyang -f html ospf.yang >

ospf.html
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$ sudo cp ospf.html
/var/www/html/ospf.html
You can now point your browser to http://198.18.134.28/ospf.html
5.2 Using Netconf

5.2.1 Poll Device Config using XML over Netconf:
The following commands are needed to enable netconf agent on IOS XR:
RP/0/0/CPU0:PE1_CL16(config)#xml agent tty
RP/0/0/CPU0:PE1_CL16(config)#netconf agent tty
RP/0/0/CPU0:PE1_CL16(config)#commit
RP/0/0/CPU0:PE1_CL16(config)#end
Enabling Crypto keys so that we can ssh to the device
RP/0/0/CPU0:PE1_CL16#crypto key generate rsa
Fri Jul 1 18:58:46.786 UTC

The name for the keys will be: the_default
Choose the size of the key modulus in the range of 512 to 4096 for your
General Purpose Keypair. Choosing a key modulus greater than 512 may take a
few minutes.
Page 60 of 80
How many bits in the modulus [2048]:
Generating RSA keys ...
Done w/ crypto generate keypair
[OK]
Once the agent is enabled, you can use ssh netconf mode to communicate to the device using netconf:
cisco@ubuntu:~$ ssh cisco@198.18.1.31 netconf format

cisco@10.254.1.3's password: cisco
Tue May 26 21:00:26.198 UTC

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
<capability>
urn:ietf:params:netconf:capability:candidate:1.0
</capability>
<capability>
urn:ietf:params:netconf:capability:notification:1.0
</capability>
</capabilities>
<session-id>
285212672
</session-id>
</hello>
]]>]]>
To get Config of all Gige Interfaces paste the below text after above ssh o/p

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter>
<Configuration>
<InterfaceConfigurationTable>
<InterfaceConfiguration>
<Naming>
<Active>act</Active>
<InterfaceName Match="GigabitEthernet.*"/>
</Naming>
</InterfaceConfiguration>
</InterfaceConfigurationTable>
</Configuration>
</filter>
</get-config>
</rpc>
]]>]]>
Page 61 of 80
You can find the full text in the file ~/content/get-gige-xml.txt . You can use this file to copy
the lines and paste in your session.
The Reply will look like below:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<Configuration>
<InterfaceConfigurationTable MajorVersion="5" MinorVersion="4">
<Naming>
<Active>
act
</Active>
<InterfaceName>
</InterfaceName>
</Naming>
<IPV4Network MajorVersion="6" MinorVersion="5">
<Addresses>
<Primary>
<Address>
192.168.23.3
</Address>
<Netmask>
255.255.255.0
</Netmask>
</Primary>
</Addresses>
</IPV4Network>
<Naming>
<Active>
act
</Active>
<InterfaceName>
</InterfaceName>
</Naming>
<IPV4Network MajorVersion="6" MinorVersion="5">
<Addresses>
<Primary>
<Address>
192.168.34.3
</Address>
<Netmask>
255.255.255.0
</Netmask>
</Primary>
</Addresses>
</IPV4Network>
</Configuration>
</data>
</rpc-reply>
Page 62 of 80
]]>]]>
5.2.2 Configure (Add and Delete) configuration using XML+Netconf:

The below exercise shows how you can add or remove a loopback interface configuration using
“merge” operation in netconf:

<edit-config>
<target>
<candidate/>
</target>
<config>
<Configuration>
<InterfaceConfigurationTable operation="merge">
<Naming>
<InterfaceName>Loopback111</InterfaceName>
</Naming>
<InterfaceVirtual>true</InterfaceVirtual>
<IPV4Network>
<Addresses>
<Primary>
<Address>
192.168.100.3
</Address>
<Netmask>
255.255.255.0
</Netmask>
</Primary>
</Addresses>
</IPV4Network>
</Configuration>
</config>
</edit-config>
<commit/>
</rpc>
]]>]]>
A copy of the above XML command snippet is saved in ~/content/create-loopback-xml.txt for

your convenience. You can use that to paste instead of typing out.
The reply from the device should look like:

<ok/>
<ok/>
</rpc-reply>
Page 63 of 80
]]>]]>
You can now verify from the device if this config took place:
RP/0/0/CPU0:PE1_CL16#show ipv4 int brief | in 111

Loopback111 192.168.100.3 Up Up
To delete this Loopback, use the “delete” operation keyword:
A copy of the above XML command snippet is saved in ~/content/delete-loopback-xml.txt for

your convenience. You can use that to paste instead of typing out.

<edit-config>
<target>
<candidate/>
</target>
<config>
<Configuration>
<InterfaceConfigurationTable operation="delete">
<Naming>
<InterfaceName>Loopback111</InterfaceName>
</Naming>
</Configuration>
</config>
</edit-config>
<commit/>
</rpc>
]]>]]>
Reply
<ok/>
<ok/>
</rpc-reply>
]]>]]>
5.2.3 Close Netconf Session:

You can now gracefully close the netconf session as shown below:
<?xml version="1.0"?>
<close-session/>
</rpc>
]]>]]>
Page 64 of 80
<?xml version="1.0"?>
<ok/>
</rpc-reply>
]]>]]>
5.2.4 Poll Device Config using :

To enable Netconf Yang agent, make the following config changes:
RP/0/0/CPU0:PE1_CL16(config)#show configuration
Tue May 26 21:41:34.459 UTC
!! IOS XR Configuration 5.3.1.30I
no xml agent tty
no netconf agent tty
netconf-yang agent
ssh
!
end
Uncommitted changes found, commit them before exiting(yes/no/cancel)?
[cancel]:yes
You can now connect to the device using ssh:
cisco@ubuntu:~$ ssh cisco@198.18.1.31 -s netconf
cisco@198.18.1.31's password:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-
monitoring?deviation=cisco-xr-netconf-monitoring-deviations</capability>
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-
error:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:confirmed-
commit:1.1</capability>
<capability>http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-lib-
cfg?module=Cisco-IOS-XR-aaa-lib-cfg&revision=2015-11-09</capability>
<capability>http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-locald-admin-
cfg?module=Cisco-IOS-XR-aaa-locald-admin-cfg&revision=2015-11-
09</capability>
……………….
</capabilities>
<session-id>2476810085</session-id>
</hello>
]]>]]>
Page 65 of 80
6 Appendix
6.1 Creating the OSPF.yang model step by step:

6.1.1 Create New Variable types as-needed:
You can start using any of your favorite editor (vim/vi/nano) to edit following sections.
One of the parameters (OSPF Area) doesn’t have a pre-defined type, since it can take up various type
of values. We will use this as an example of defining a new variable type as shown below:
import tailf-common { prefix tailf; }

typedef ospf-area { type union {
type uint32;
type inet:ipv4-address; }
}
The new defined type “ospf-area” can take any integer value (32 bit) or an IPv4 value. Note that the
IPv4 type is pre-defined in the module we imported “ietf-inet-type”
In the next few steps, we will build the yang file step by step. However, a copy of the final yang
model is available at ~/content/ospf.yang, If you want to do a comparison with this file or use it
instead of typing out each step, you can reference it. (Take care about extra line breaks if you
paste the contents into a new file)
6.1.2 Define the Service point:

First Remove all red lines shown below as they are placeholder values as part of the template, and we
will define these parameters based on our requirements
list ospf {
key name;
uses ncs:service-data;
ncs:servicepoint "ospf";
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 {
Page 66 of 80
type inet:ipv4-address;
}
}
Note that the brackets marked in blue are enclosing the OSPF definition, and both of these
should be kept in place.
Since we are augmenting the “service” keyword, we are defining a new keyword “ospf” under it, the
following two lines will be required to allow this to work,these should already be present in the yang file.
list ospf {
Our YANG model file looks like below at this point:
cisco@ubuntu:~/ncsw/packages/ospf/src/yang$ more ospf.yang

module ospf {
prefix ospf;
prefix inet;
}
import tailf-ncs {
prefix ncs;
}

type uint32;
}
list ospf {
}
}
}
6.1.3 Defining various parameters for various OSPF service

definitions:
Augument services: This has to be a parameter that will be unique for each instance of the service.
Since each define can have multiple neighbors , multiple areas, and even multiple instances of OSPF,
none of these are suitable as unique variables. We will therefore choose the device name as the most
unique value: This value (“device-name”) however now has to be defined as a leaf value because the
key has to be of type “leaf.”
Page 67 of 80
Augment
Services
OSPF
Device Name Process ID IOS-XR IOS

Process ID
Router-ID Area-ID Router-ID

Area-ID
Interface Network IP,

Interface
Number Network
Mask & AreaIP,
Number Mask & Area
/// Let’s define our first Leaf and it’s value in this YANG mode
list ospf {
key "device-name";
leaf device-name {
mandatory true;
type leafref {
}
}
/// Let’s define the OSPF process ID as well
leaf process-id {
mandatory true;
type string;
}
Page 68 of 80
6.1.4 Using Containers - Differentiating between IOS and IOS-XR:
Containers are meant to group a set of values. A conditional statement can be added to the container
definition to define when this container will be applicable and when it should be omitted.
In our case, since the parameters being defined for IOS versus those defined for IOS-XR are slightly
different, we will use containers to group these values separately. Copy/paste below section in
continuation to last section.
Augment
Services
OSPF

Process ID

Area-ID

Interface
Number Network
Mask & AreaIP,
Number Mask & Area
/// Let’s define container to differentiate between iosxr and ios
container iosxr {
when "/ncs:devices/ncs:device[ncs:name=current()/../device-
name]/ncs:device-type/ncs:cli/ncs:ned-id = 'cisco-ios-xr-id:cisco-ios-xr'"
{
// tailf:dependency "../device-name";
// tailf:dependency "/ncs:devices/ncs:device/ncs:device-type";
}
Note that the brackets marked in red spread over sections 4.6 & 4.7 are enclosing the container
iosxr.
Note that in the above container selection, we are using the condition defined in “when”.
Here we are referencing the current device’s parameters (using:
/ncs:devices/ncs:device[ncs:name=current() ) and then referencing its OS type, and checking if its
defined as “cisco-ios-xr-id:cisco-ios-xr”.
You can get a good view of the defined hierarchy by using the following command as an example in the
NSO CLI:
Page 69 of 80
admin@ncs# show running-config devices device P1_CL16 | display xpath
/
/devices/device[name='P1_CL16']/device-type/cli/ned-id cisco-ios-xr
admin@ncs# show running-config devices device CE1_CL16 | display xpath

/
/devices/device[name='CE1_CL16']/device-type/cli/ned-id cisco-ios
6.1.5 Defining Router ID, Area ID & Interfaces:

Define the variables for “router-ID”, “Area-ID” and Interfaces under the IOS XR container:
Augment
Services
OSPF

Process ID

Area-ID

Interface
Number Network
Mask & AreaIP,
Number Mask & Area
// Let’s define the Router ID
leaf router-id {
tailf:info "OSPF XR Router ID";
mandatory true;
}
// Let’s define the Area ID
Page 70 of 80
list area-id {
tailf:info "OSPF XR Area ID";
key "area";
leaf area {
mandatory true;
type ospf-area;
}
// Let’s define the Interface
list interface-name {
key "interface-number";
leaf interface-number {
tailf:info "IOS-XR OSPF interface" ;
type string;
}
}
}
}
Notice the following fine points about this step:

- “tailf:info” keyword is being used. This prefix (tailf) is from the earlier import, and the defined
value gets reflected in the iteractive help when this variable is being defined in CLI or GUI
- Area-ID is being defined a “LIST” and not as a “LEAF”. This is because the Area-Id
definition in IOS XR contains the information about neighbors within that area. Hence it’s
not a single value, but contains multiple parameters in it.
- Interface-name is being defined as a list, again because multiple interfaces can be part of
one area.
- The interface numbers are being defined as a free-form string. However, in a more
accurate model, the choices should be pulled from the device’s database. This will be
described as an optional exercise; refer to Appendix for how to make that happen.
6.1.6 Defining IOS Parameters:

Using the same idea as described for IOS-XR, we can now define the parameters for IOS as well. To
make that choice applicable, we will once against a “when” condition in the IOS container to ensure that
this part of the model applies to a device that is of type IOS CLI.
Page 71 of 80
Augment
Services
OSPF

Process ID

Area-ID

Interface
Number Network
Mask & AreaIP,
Number Mask & Area
/// Let’s define container to differentiate between iosxr and ios
container ios {
name]/ncs:device-type/ncs:cli/ncs:ned-id = 'ios-id:cisco-ios'" {
}
// Let’s define the Router ID
leaf router-id {
tailf:info "OSPF Router ID";
mandatory true;
}
// Let’s define the Area ID, Network and mask
list network {
tailf:info "OSPF Area ID";
key "ip mask";
leaf-list area {
type ospf-area;
}
leaf ip {
mandatory true;
tailf:info "IOS OSPF network" ;
}
leaf mask {
mandatory true;
tailf:info "IOS OSPF network mask";
Page 72 of 80
}
}
}
}
}
}
Note that the brackets marked in red are enclosing the container ios.
For your convenience, here is the full YANG model:
module ospf {
prefix ospf;
prefix inet;
}
import tailf-ncs {
prefix ncs;
}

// import tailf-ned-cisco-ios-xr { prefix cisco-ios-xr; }

type uint32;
}
// Section 4.5
list ospf {
key "device-name";
leaf device-name {
mandatory true;
type leafref {
}
}
leaf process-id {
mandatory true;
type string;
}
// Section 4.6
container iosxr {
Page 73 of 80
name]/ncs:device-type/ncs:cli/ncs:ned-id = 'cisco-ios-xr-id:cisco-ios-xr'"
{
// tailf:dependency "/ncs:devices/ncs:device/ncs:device-
type";
}
// Section 4.7
leaf router-id {
tailf:info "OSPF XR Router ID";
mandatory true;
}
list area-id {
tailf:info "OSPF XR Area ID";
key "area";
leaf area {
mandatory true;
type ospf-area;
}
list interface-name {
key "interface-number";
leaf interface-number {
tailf:info "IOS-XR OSPF interface" ;
type string;
}
}
}
}
// Section 4.8
container ios {
name]/ncs:device-type/ncs:cli/ncs:ned-id = 'ios-id:cisco-ios'" {
}
leaf router-id {
tailf:info "OSPF Router ID";
mandatory true;
}
list network {
tailf:info "OSPF Area ID";
key "ip mask";
leaf-list area {
type ospf-area;
}
leaf ip {
mandatory true;
tailf:info "IOS OSPF network" ;
}
leaf mask {
mandatory true;
Page 74 of 80
tailf:info "IOS OSPF network mask";
}
}
}
}
}
}
6.2 Building the OSPF.XML :

Go the directory for XML template, and edit the file:
cisco@ubuntu:~/ncsw/packages/ospf$ cd ~/ncsw/packages/ospf/templates/
cisco@ubuntu:~/ncsw/packages/ospf/templates$ ls -al
total 12
drwxr-xr-x 2 cisco cisco 4096 May 27 15:04 .
drwxrwxr-x 5 cisco cisco 4096 May 27 15:04 ..
-rw-rw-r-- 1 cisco cisco 732 May 27 15:04 ospf.xml
cisco@ubuntu:~/ncsw/packages/ospf/templates$ vim ospf.xml
From the existing file, remove the comment lines, which will leave you with the following starting
template:
<config-template xmlns="http://tail-f.com/ns/config/1.0"
servicepoint="ospf">
<devices xmlns="http://tail-f.com/ns/ncs">
<device>
<name>{/device}</name>
<config>
</config>
</device>
</devices>
</config-template>
6.2.1 Defining Device name:

We will start the process of mapping the variables defined in the YANG model , and map them to a
format the structures these values into a CLI acceptable format. To first one will the device name.
Notice that in the XML template, the device name is assumed to be represented by the variable
“device”.
<device>
<name>{/device}</name>
Make this change the XML file that you are editing:
Page 75 of 80
<device>
<name>{/device-name}</name>
<config>
</config>
</device>
</devices>
</config-template>
6.2.2 Generating sample XML structure:

Next, we need to populate the <config> section of the XML template.
To achieve this, we will need to define the tags based on how config is done on a device. We can
make the task easier by taking help from NSO since XML can present us the XML translation of a
configuration. That translation can be used to construct the template by replacing the values with the
variables we have defined.
To generate that translation, lets configure OSPF on one of our XR devices..and see the translation.
We do not need to commit this change, as our intent is only to get the XML view:
admin@ncs# config
admin@ncs(config)# devices device PE1_CL16 config
admin@ncs(config-config)# cisco-ios-xr:router ospf 1
admin@ncs(config-ospf)# router-id 3.3.3.3
admin@ncs(config-ospf)# area 0
admin@ncs(config-ospf-ar)# interface Giga0/0/0/0
admin@ncs(config-ospf-ar-if)# exit
admin@ncs(config-ospf-ar)# interface Giga0/0/0/1
admin@ncs(config-ospf-ar-if)# top
admin@ncs(config)# commit dry-run outformat xml
device PE1_CL16
<router xmlns="http://tail-f.com/ned/cisco-ios-xr">
<ospf>
<name>1</name>
<router-id>3.3.3.3</router-id>
<area>
<id>0</id>
<interface>
<name>Giga0/0/0/0</name>
</interface>
<interface>
<name>Giga0/0/0/1</name>
</interface>
</area>
</ospf>
</router>
admin@ncs(config)#
Lets look closely at the tags above… and match them with the values in the YANG model:
Page 76 of 80
Leaf Name XML Tag
process-id <ospf><name> … </name>
router-id <router-id> … </router-id>
area-id/area <area><id>…</id>………</area>
interface-name/interface-number <interface><name>…</name></interface>
Using these mappings, lets fill in the <config> section of the XML template. Since all the mappings are
for IOS-XR config, we will comment this section accordingly.
The config template will now look like:
<device>
<name>{/device-name}</name>
<config>

<router xmlns="http://tail-f.com/ned/cisco-ios-xr">
<ospf>
<name>{/process-id}</name>
<router-id>{/*/router-id}</router-id>
<area>
<id>{/*/area-id/area}</id>
<interface>
<name>{interface-name/interface-number}</name>
</interface>
Page 77 of 80
</area>
</ospf>
</router>
</config>
</device>
</devices>
</config-template>
6.2.3 Defining IOS config template:

So far we have defined the template for IOS-XR only. However, we also have IOS devices in the
network and XML template should contain the structure for IOS command as well.
We will use the same steps as before:
First define the config in NSO CLI, and take an XML output as a sample:
admin@ncs(config)# devices device CE1_CL16 config ios:router ospf 1

admin@ncs(config-router)# router-id 1.1.1.1
admin@ncs(config-router)# network 192.168.12.0 0.0.0.255 area 0
admin@ncs(config-router)#
admin@ncs(config-router)# top
config
ios:router ospf 1
router-id 1.1.1.1
network 192.168.12.0 0.0.0.255 area 0
!
!
!
admin@ncs(config)# commit dry-run outformat xml
device CE1_CL16
<router xmlns="urn:ios">
<ospf>
<id>1</id>
<non-vrf>
<network>
<ip>192.168.12.0</ip>
<mask>0.0.0.255</mask>
<area>0</area>
</network>
</non-vrf>
</ospf>
</router>
admin@ncs(config)#
Now create a section in the template file right after the </router> tag (belonging to IOS XR section) and
add the above config, as well as add a comment to indicate the separation ….A snippet of the modified
template is shown below, with the changes in bold
<<< snipped >>>

</area>
</ospf>
</router>
Page 78 of 80

<ospf>
<id>1</id>
<non-vrf>
<network>
<ip>192.168.12.0</ip>
<mask>0.0.0.255</mask>
<area>0</area>
</network>
</non-vrf>
</ospf>
</router>
</config>
</device>
</devices>
<<< snipped >>>
Lets map these template tags to the IOS container variables we have in YANG model:
Leaf Name XML Tag

process-id <ospf><id> … </id>
router-id <router-id> … </router-id>
area-id/area <network><area>…</area></network>
network <network><ip>…</ip></network>
mask <network><mask>…</mask></network>
And finally, use this mapping to change the templates explicit values to the YANG variables instead:
The changed content will look like this:


<ospf>
<id>{/process-id}</id>
<non-vrf>
<router-id>{/*/router-id}</router-id>
<network>
<ip>{/*/network/ip}</ip>
<mask>{/*/network/mask}</mask>
<area>{/*/network/area}</area>
</network>
</non-vrf>
</ospf>
</router>
</config>
Page 79 of 80
Now lets reload the package in the CLI

reload-result {
package cisco-ios
result true
}
reload-result {
package cisco-iosxr
result true
}
reload-result {
package ospf
result true
}
Page 80 of 80

LTRSPG 2515 LG

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LTRSPG 2515 LG

Uploaded by

Copyright:

Available Formats

Contents

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

LTRSPG-2515-Using tail-f Network Contro System(NSO)

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

 All devices are pre-configured with management IP address

All the devices are pre-configured with username/password = cisco/cisco

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

 Example below shows connecting via Mgmt IP to CE1_CL16:

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

2.1 Installing NSO from binary distribution:

cisco@ubuntu:~$ ls -al *.bin

If you see below message it means JRE is missing, install it as follows

cisco@ubuntu:~$ java -version

cisco@ubuntu:~$ sudo apt-get install default-jre

If you see below message it means JRE is installed properly

cisco@ubuntu:~$ java -version

cisco@ubuntu:~$ sudo apt-get install python 2.7.6

If you don’t see Ant installed, install it as follows

cisco@ubuntu:~$ ant -v | grep Ant

cisco@ubuntu:~$ sudo apt-get -u install ant

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

cisco@ubuntu:~$ ./nso-4.1.2.linux.x86_64.installer.bin ncs412

2.2 Viewing the installation:

cisco@ubuntu:~$ tree -L 2 ncs412

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

2.3 Set up the NSO working environment:

cisco@ubuntu:~$ source ~/ncs412/ncsrc

cisco@ubuntu:~$ ncs-setup --dest ~/ncsw

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

cisco@ubuntu:~/ncsw$ ncs --status

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

cisco@ubuntu:~/ncsw/logs$ netstat -pln | grep 2024

2.5 Connecting to NSO using GUI and CLI

Connect to NSO CLI using the ssh session:

cisco@ubuntu:~/ncsw/logs$ ssh -l admin -p 2024 localhost

admin connected from 127.0.0.1 using ssh on ubuntu

2.5.2 Through GUI:

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

2.5.3 Through CLI:

pod connected from 198.18.133.252 using ssh on ubuntu

admin@ncs> show configuration

admin@ncs> switch cli

admin@ncs# show running-config

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

2.6 Adding NSO NED Packages:

cisco@ubuntu:~/ncsw$ ncs --status | grep xr

admin connected from 198.18.133.252 using ssh on ubuntu

admin@ncs# show packages package

2.6.2 Adding new package:

2.6.2.1 Adding packages to working directory:

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

cisco@ubuntu:~/ncsw$ ncs --status | grep ios

<< so still not loaded in daemon, but added to file structure

To load the packages, we will use the following set of steps:

admin connected from 198.18.133.252 using ssh on Ubuntu

admin@ncs# show packages package

admin@ncs# packages reload

>>> System upgrade is starting.

July 10, 2016 LTRSPG-2515-Using NSO with tail-f

July 10, 2016 LTRSPG-2515-Using NSO with tail-f