Let’s continue playing around some more with NSO. In the previous 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 every time 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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.:
1
2
3
4
5
6
7
8
9
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:
1
2
3
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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 export 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.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
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.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
$ 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.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
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:
1
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”: |
1
2
3
4
5
6
7
8
9
10
11
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:
1
2
3
4
5
6
7
8
9
10
11
12
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. :)