NSO – Part 3

Let’s continue playing around some more with NSO. In the last posts we’ve added our netsim-devices to NSO and managed to push out some simple config & tried rollbacks. Instead of specifying each single router everytime we want to manage them we can instead use device-groups for easier management.

Let’s start with creating two groups for our Core- & Edge-routers:

dmin@ncs# config 
Entering configuration mode terminal
admin@ncs(config)# devices device-group Core device-name [ r0 r1 ]


admin@ncs(config)# devices device-group Edge device-name [ r2 r
Possible completions:
  r0  r1  r3
admin@ncs(config)# devices device-group Edge device-name [ r2 r3 ]


admin@ncs(config)# show full-configuration devices device-group 
devices device-group Core
 device-name [ r0 r1 ]
!
devices device-group Edge
 device-name [ r2 r3 ]

admin@ncs(config)# do show devices device-group
NAME  MEMBER     INDETERMINATES  CRITICALS  MAJORS  MINORS  WARNINGS  
----------------------------------------------------------------------
Core  [ r0 r1 ]  0               0          0       0       0         
Edge  [ r2 r3 ]  0               0          0       0       0 

We can then use the group-name when we want to check if router are in sync f.ex.:

admin@ncs# devices device-group Core check-sync 
sync-result {
    device r0
    result in-sync
}
sync-result {
    device r1
    result in-sync
}

We can also have groups in a group:

devices device-group all
 device-group [ Core Edge ]
!

Let’s also take a look at creating a template that we can later call on to configure something generic on our device(s). By using “{$VARIABLENAME}” NSO gives us the ability to input our own variables when calling the specific template. Here’s an example of a simple VRF-template:

admin@ncs(config)# devices template NEW_VRF
admin@ncs(config-template-NEW_VRF)# config ios:vrf definition {$VRF}
admin@ncs(config-definition-{$VRF})# description {$CUSTOMER}
admin@ncs(config-definition-{$VRF})# rd 3301\:{$VRF}
admin@ncs(config-definition-{$VRF})# address-family ipv4 route-target import 3301\:{$VRF}
admin@ncs(config-import-3301:{$VRF})# exit
admin@ncs(config-definition-{$VRF})# address-family ipv4 route-target exoort 3301\:{$VRF}
admin@ncs(config-export-3301:{$VRF})# exit
admin@ncs(config-definition-{$VRF})# top
admin@ncs(config)# commit

admin@ncs(config)# show full-configuration devices template NEW_VRF 
devices template NEW_VRF
 config
  ios:vrf definition {$VRF}
   description {$CUSTOMER}
   rd          3301:{$VRF}
   address-family ipv4 route-target export 3301:{$VRF}
   !
   address-family ipv4 route-target import 3301:{$VRF}
   !
  !
 !

When we want to configure a new VRF we than only have to name our NEW_VRF-template and input the variables for CUSTOMER & VRF. NSO’s autocomplete/tab feature is excellent here and keeps track of available variables we can use.

admin@ncs(config)# devices device-group Edge apply-template template-name NEW_VRF variable { name CUSTOMER value 'GEKAS' } variable { name VRF value '22222' }
apply-template-result {
    device r2
    result ok
}
apply-template-result {
    device r3
    result ok
}
admin@ncs(config)# commit
Commit complete.
admin@ncs(config)# 

admin@ncs(config)# devices device-group all apply-template template-name NEW_VRF variable { name CUSTOMER value 'MGMT' } variable { name VRF value '999' } 
apply-template-result {
    device r0
    result ok
}
apply-template-result {
    device r1
    result ok
}
apply-template-result {
    device r2
    result ok
}
apply-template-result {
    device r3
    result ok
}

If we login and check our routers we can see that all routers now have the MGMT-vrf & Edge-routers (R2 & R3) also have a customer vrf GEKAS.

$ ncs-netsim cli-i r1

admin connected from 192.168.15.186 using ssh on labb-nso
r1> en
r1# show running-config vrf
vrf definition 999
 description MGMT
 rd          3301:999
 address-family ipv4
  route-target export 3301:999
  route-target import 3301:999
  exit-address-family
 !
!

$ ncs-netsim cli-i r2

admin connected from 192.168.15.186 using ssh on labb-nso
r2> en
r2# show running-config vrf
vrf definition 22222
 description GEKAS
 rd          3301:22222
 address-family ipv4
  route-target export 3301:22222
  route-target import 3301:22222
  exit-address-family
 !
!
vrf definition 999
 description MGMT
 rd          3301:999
 address-family ipv4
  route-target export 3301:999
  route-target import 3301:999
  exit-address-family
 !
!

Let’s see what happens when we do a manual change and R2 gets out of sync.

r2# conf
Enter configuration commands, one per line. End with CNTL/Z.
r2(config)# vrf definition 999
r2(config-vrf)# description CustomerA
r2(config-vrf)# exit

admin@ncs# devices device-group all check-sync 
sync-result {
    device r0
    result in-sync
}
sync-result {
    device r1
    result in-sync
}
sync-result {
    device r2
    result out-of-sync
    info got: 77727c766ca3b799f52c13a9cb76daa3 expected: 1d88fb85cf89d8f417701fac26e6df3d

}
sync-result {
    device r3
    result in-sync
}
admin@ncs# *** ALARM out-of-sync: got: 77727c766ca3b799f52c13a9cb76daa3 expected: 1d88fb85cf89d8f417701fac26e6df3d

That hash-value isn’t helping us very much, but we can easily check what the actual difference is with compare-config:

admin@ncs# devices device r2 compare-config 
diff 
 devices {
     device r2 {
         config {
             ios:vrf {
                 definition 999 {
-                    description MGMT;
+                    description CustomerA;
                 }
             }
         }
     }
 }


admin@ncs# devices device r2 sync-to       
result true

admin@ncs# devices device-group all check-sync
sync-result {
    device r0
    result in-sync
}
sync-result {
    device r1
    result in-sync
}
sync-result {
    device r2
    result in-sync
}
sync-result {
    device r3
    result in-sync
}

There’s also a pretty cool option to use policy-rules to f.ex warn the user before he/she tries to removes an important vrf. It was pretty tricky however how to figure out how it should be written so I had a lot of trial and error here, but ultimately this is what I ended up with:

admin@ncs(config)# policy rule MGMT foreach /devices/device expr config/ios:vrf/definition[name='999'] warning-message "Device {name} must have a Management-VRF"

A really good command to easier see what path we should check in our expr-string was by using the “| display xpath”:

admin@ncs(config)# show full-configuration devices device r2 config ios:vrf | display xpath
/devices/device[name='r2']/config/ios:vrf/definition[name='22222']/description GEKAS
/devices/device[name='r2']/config/ios:vrf/definition[name='22222']/rd 3301:22222
/devices/device[name='r2']/config/ios:vrf/definition[name='22222']/address-family/ipv4
/devices/device[name='r2']/config/ios:vrf/definition[name='22222']/address-family/ipv4/route-target/export[asn-ip='3301:22222']
/devices/device[name='r2']/config/ios:vrf/definition[name='22222']/address-family/ipv4/route-target/import[asn-ip='3301:22222']
/devices/device[name='r2']/config/ios:vrf/definition[name='999']/description MGMT
/devices/device[name='r2']/config/ios:vrf/definition[name='999']/rd 3301:999
/devices/device[name='r2']/config/ios:vrf/definition[name='999']/address-family/ipv4
/devices/device[name='r2']/config/ios:vrf/definition[name='999']/address-family/ipv4/route-target/export[asn-ip='3301:999']
/devices/device[name='r2']/config/ios:vrf/definition[name='999']/address-family/ipv4/route-target/import[asn-ip='3301:999']

When a user tries to remove the vrf 999 for management they should now get an error:

admin@ncs(config)# no devices device r2 config ios:vrf definition 999 
admin@ncs(config)# show configuration 
devices device r2
 config
  no ios:vrf definition 999
 !
!
admin@ncs(config)# commit
The following warnings were generated:
  Device r2 must have a Management-VRF
Proceed? [yes,no] no
Aborted: by user

I’ve only scratched the surface yet but i’m really starting to dig NSO. 🙂

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *