Create one single template service that configures loopback99 on either IOS-XE or IOS-XR.
The YANG module should only allow one device per service.
The loopback should be restricted to the format 10.0.0.X.
The mask should always be /32.
The loopback address should always be required.
The loopback must be unique between multiple devices.
If you are starting this lab without doing the previous one, you can add all devices to NSO with this config:
Initial NSO Configuration
Task 1 Answer
Change the leaf-list device line to just a leaf. By default, this service can be applied to a list of devices. However, we are configuring one service per device.
Change the dummy leaf to be an “ip-address” leaf. Add a constraint and make this leaf required. Use the pattern keyword, making sure to preface literal dots with two slashes (\\).
Require that the ip-address leaf value is unique among all instances of this service.
Grab the XML config from NCS using a template and outputting the dry-run in XML format. Previously, we created a template per-device type. However, NCS native templates allow you to specify a config per-NED type. We can use this to build a single package template that handles both XE and XR.
We’ll use both of the config sections for the package template. NCS is able to know whether to apply the IOS or IOSXR config to each device.
We’ll now make the package.
Start NCS and reload the packages.
Task 2. Apply one service per device
Task 2 Answer
Notice how the YANG module affects the CLI. When we create a new service, we are prompted for the required IP address:
We are also constrainted to the format 10.0.0.X:
Additionally, we can only apply each service to one device, as we changed the device type from leaf-list to leaf. If device was a leaf-list, we would have an open bracket ([) as a possible completion:
When we commit the config, NSO only applys the IOS config to the IOS-XE routers, and the IOS-XR config to the IOS-XR routers.
Also, notice that the loopback IP address must be unique between services. We cannot assign the same IP address to different loopback services:
Task 2a. Auto-rollback Example
Currently R1 has 10.0.0.1/32 on a different interface:
Watch what happens when I commit:
On another device, such as R2, the configuration is changed, but then is automatically rolled back when NSO finds that the IP address overlaps with another existing interface.
This is called an atomic commit. NSO only allows the commit to complete on all devices if all devices are successful. If any one device has an issue, the commit is rolled back on all devices completely.
Task 3. Add BGP advertisement of the loopback to the template
Add configuration that advertises the loopback into BGP ASN 65000 to the template. Make sure that you account for the differences in IOS-XE vs. IOS-XR.
Task 3 Answer
Notice above that after the <config> stanza, we have the same router XMLNS (XML namespace) stanza. This means that we can simply take the config at this router stanza and paste it underneath our loopback config.
We’ll now reload this package in NCS and apply it to our routers.
# Stop ncs
cd ~/nso-instance
ncs --stop
# Navigate to the packages dir of the instance
cd ~/nso-instance/packages
# Create a skeleton template package
ncs-make-package --service-skeleton template loopback
# Edit the YANG data module
nano ~/nso-instance/packages/loopback/src/yang/loopback.yang
# Edit the template to include the BGP configuration.
# Stage this in NSO first to capture the XML formating
devices device r1
config
router bgp 65000
network 1.1.1.1 mask 255.255.255.255
!
!
!
devices device xr1
config
router bgp 65000
address-family ipv4 unicast
network 1.1.1.1/32
commit dry-run outformat xml