Hello my friend,
In the previous blogpost we have compared the usage of NAPALM and OpenConfig YANG modules with NETCONF transport for Cisco IOS XR and Arista EOS. Those two operation systems are so called core operating systems for NAPALM and are included in its standard distribution. Besides them, other three (there are five core network operating systems in NAPALM) are Cisco IOS, Cisco Nexus, and Juniper Junos. You though can use NAPALM with other operating systems, if there are community drivers available. In today’s blogpost we cover installation and usage of NAPALM Community Driver for Nokia SR OS and its comparison against OpenConfig/YANG with NETCONF.
2
3
4
5
retrieval system, or transmitted in any form or by any
means, electronic, mechanical or photocopying, recording,
or otherwise, for commercial purposes without the
prior permission of the author.
How Is It Important to Know Python?
Recently we were engaged with one of our customers to help with OpenStack deployment. The first step for us was to build the lab, which could replicate the desired setup. The installation of OpenStack manually (there are means to automate that as well) was the most complicated activity we have done for quite a long period of time. Even writing the full-blown network automation solution with frontend and backend, databases and cache is not that complicated. Probably, it is not correct to compare two tasks, which are different in nature, but still. And a lot of troubleshooting we did in that regard was about some modules not working, or not properly working. So, Python ?..
OpenStack (its services and components) are written in Python and, therefore, possibility to read Python’s code and to understand what it is supposed to do together with possibility to understand errors and exceptions helped us a lot in this journey. Python is everywhere, and good network engineers with good Python knowledge are in a great demand on the market. Start learning Network Automation and Python today with us!
We offer the following training programs:
- Zero-to-Hero Network Automation Training
- Automation with Nornir (2nd step after advanced network automation)
- Automation Orchestration wth AWX
During these trainings you will learn the following topics:
- Success and failure strategies to build the automation tools.
- Principles of software developments and tools for that.
- Data encoding (free-text, XML, JSON, YAML, Protobuf)
- Model-driven network automation with YANG, NETCONF, RESTCONF, GNMI.
- Full configuration templating with Jinja2 based on the source of truth (NetBox).
- Best programming languages (Python, Bash) for developing automation, configuration management tools (Ansible) and automation frameworks (Nornir).
- Network automation infrastructure (Linux, Linux networking, KVM, Docker).
- Orchestration of automation workflows with AWX and its integration with NetBox, GitHub, as well as custom execution environments for better scalability.
I would recommend the Network Automation Training to anyone who has been working in the industry for a period of time and prepare to become the next generation of network engineers.
Eric Leung @ Bloomberg
Moreover, we put all mentions technologies in the context of real use cases, which our team has solved and are solving in various projects in the service providers, enterprise and data centre networks and systems across the Europe and USA. That gives you opportunity to ask questions to understand the solutions in-depts and have discussions about your own projects. And on top of that, each technology is provided with online demos and labs to master your skills thoroughly. Such a mixture creates a unique learning environment, which all students value so much. Join us and unleash your potential.
Brief Description
As promised in the previous blog, we continue comparison of data collection in NAPLAM and OpenConfig/YANG with NETCONF for Nokia SR OS.
As stated below, NAPALM has five core network operation systems, which were chosen by authors. There might be multiple reasons for such a choice:
- Those network operating systems NAPALM authors had in their networks at the moment of development and they aimed to automate them.
- Those network operating systems are the most popular worldwide across many markets. For example, Cisco IOS XR and Juniper JunOS alone represent more than 50% of service provider market (together with Nokia SR OS – almost 100% in US and close to 70% in Europe); Cisco NX-OS, Arista EOS and Juniper JUNOS are more than 60% of data centre market (especially, if we put hyper scalers aside).
At that same time, the need for multi vendor automation exists in all markets for all the network operating systems existing. This need creates something called NAPALM Automation Community Drivers. So, what is that?
NAPALM Automation Community Drivers is a collection of the NAPALM drivers, which were created mainly by network vendors (or some community enthusiasts) in a response to the community demand. For some vendors, it was a good opportunity to position their products as automation-grade. For others, it was a need to comply with customers’ RFP (Request For Proposals) process and an opportunity to win some business. There, for sure, may be other reasons, which drove the creation of a specific NAPALM drivers. What matters is that NAPALM drivers for network operating systems others that original 5 are now available.
NAPALM Automaton Community Driver for Nokia SR OS
Nokia SR OS, which is not part of those 5 core network operating systems, are widely used in Service Provider networks worldwide, with being the most popular in some segments (e.g., IP/MPLS Edge Routers). Clearly there is a need to automate it. And Nokia folks has delivered the NAPALM Automation Community Driver for Nokia SR OS.
From NAPALM perspective, there are no limitations in terms of particular protocol usage between the host with Python/NAPLAM and the network device in question. As long as the driver accepts in a standard format necessary variables and instructions as an input (NAPALM functions, e.g. get_interfaces()) and provides back the proper response (meaning, containing all the relevant keys and variables in a desired format), it can be qualified as NAPALM.
As there is no specific transport requirements, Nokia chose NETCONF to collect the data in a structured format with follow up processing to map it to NAPALM dictionaries. The NETCONF calls use Nokia-native YANG modules to query the relevant data; therefore, in theory that could have existed before OpenConfig. However, Nokia published finally YANG modules only in 2019 and encouraged people to start using NETCONF for Nokia SR OS automation in the same year, whereas support of OpenConfig was added in 2018. Looking in the commit history of NAPALM Automation Community Driver for Nokia SR OS, the module was published in October 2019, almost at the same time when Nokia YANG modules appeared in the GitHub as well.
OpenConfig Support in Nokia SR OS
Nokia introduced support of OpenConfig in summer 2018, we wrote about it soon after release. Since that it was including it in their YANG modules published per new OS release. Not all the OpenConfig YANG modules are implemented in Nokia, but only the most widely used and asked by customers. At the same time, we haven’t seen any vendor, which has implemented all the OpenConfig YANG modules.
Ultimately, it means that support of OpenConfig YANG modules over NETCONF and NAPALM, which in case of Nokia SR OS relies on NETCONF/YANG with Nokia-native YANG modules, became available for a wide audience approximately at the same time. Yet the possibility to use OpenConfig with NETCONF existed since 2018.
Lab Setup
We use the same lab setup as we described in the previous blogpost:
In today’s blogpost we focus only on Cisco IOS XR. For Arista EOS and Cisco IOS XR, read the previous blogpost.
Software components used in this lab has following versions:
- Debian 11.1
- Python 3.9
- napalm 3.3.1
- ncclient 0.6.12
- Noka SR OS 21.10.R1
Scenario Description
The main focus for today is to:
- Install the NAPALM Automation Community Driver for Nokia SR OS.
- Re-apply (and modify if needed) a Python automation tool created in the previous blogpost to Nokia SR OS.
Enrol to our Network Automation Trainings to learn how to automate Cisco, Nokia, Arista and Cumulus networks altogether.
Part #1. Solution with NAPALM
Step #1.1. NAPALM Automation Community Driver for Nokia SR OS Installation
In fact, the installation is not that much installation, as there won’t be even a word install anywhere (there will be but not for the driver).
First of all, it is exited you are in the project directory we created in the previous blogpost. Just clone it from our GitHub.
2
3
4
5
6
7
8
9
10
total 1900
-rw-r--r-- 1 root root 1290 Jan 23 15:45 01_collect_napalm.py
-rw-r--r-- 1 root root 1398 Jan 16 19:57 01_collect_openconfig.py
-rw-r--r-- 1 root root 1483 Jan 16 12:08 LICENSE
-rw-r--r-- 1 root root 1520 Jan 16 12:06 README.md
drwxr-xr-x 3 root root 4096 Jan 16 10:39 bin
drwxr-xr-x 2 root root 4096 Jan 23 15:37 inventory
-rw-r--r-- 1 root root 98 Jan 23 15:48 requirements.txt
drwxr-xr-x 6 root root 4096 Jan 16 09:24 venv
Now we need to download the driver in question:
Once that is done, copy from the downloaded repo the directory napalm-sros in the parent and delete the rest:
2
3
$ rm -rf napalm-sros
$ mv temp_sros napalm-sros
These manipulations result in us having directory napalm-sros contain only python files needed by napalm at a level of hierarchy it needs:
- If you use community driver, NAPALM would look for a directory named napalm-xxx, where xxx is name of the operating system.
- If the directory found, the driver is used. If not, then the error is returned (in Pythonic terms, the corresponding exception is raised).
The last final step is to add the dependency needed for the package. On top what was already installed in the previous blogpost, there is one more needed:
This is the very same library we used for our pyGNMI for a comparison function.
Step #1.2. Prepare Nokia SR OS to Interact with NAPALM
The next step is enable NETCONF on Nokia SR OS to allow the communication:
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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
system {
management-interface {
netconf {
admin-state enable
auto-config-save true
}
yang-modules {
nokia-submodules true
nokia-combined-modules false
}
}
security {
aaa {
local-profiles {
profile "administrative" {
netconf {
base-op-authorization {
action true
cancel-commit true
close-session true
commit true
copy-config true
create-subscription true
delete-config true
discard-changes true
edit-config true
get true
get-config true
get-data true
get-schema true
kill-session true
lock true
validate true
}
}
}
}
}
user-params {
local-user {
user "admin" {
access {
netconf true
}
console {
member ["administrative"]
}
}
}
}
}
}
}
It is expected that the network device is running in the model-driven mode. Refer to a separate article to learn how to do that.
At a high-level, the following configuration is done:
- NETCONF is enabled.
- The needed (Nokia-native) YANG modules are enabled.
- Security profile authorises the usage of NETCONF requests.
- A chosen user is permitted to access NETCONF.
Step #1.3. Develop a Python Script with NAPALM
This step is where we normally spend the most amount of time – development of the automation. However, we already did it the last time. And this is multivendor automation (and NAPALM) shines, as no single Python script modification is needed.
Step #1.4. Execution of Python Script with NAPALM
It means that we can safely run our Python’s script to get the results:
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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
!
! OUTPUT IS TRUNCATED FOR BREVITY
!
Interfaces operational data:
{
"1/1/c1": {
"mac_address": "00:00:00:00:00:00",
"is_up": true,
"speed": "",
"last_flapped": -1.0,
"is_enabled": true,
"mtu": "",
"description": "QSFP28 Connector"
},
"1/1/c1/1": {
"mac_address": "0e:ae:18:b8:05:6b",
"is_up": true,
"speed": 10000,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c1/2": {
"mac_address": "00:00:01:01:00:02",
"is_up": false,
"speed": 10000,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c1/3": {
"mac_address": "00:00:01:01:00:03",
"is_up": false,
"speed": 10000,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c1/4": {
"mac_address": "00:00:01:01:00:04",
"is_up": false,
"speed": 10000,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c2": {
"mac_address": "00:00:00:00:00:00",
"is_up": true,
"speed": "",
"last_flapped": -1.0,
"is_enabled": true,
"mtu": "",
"description": "QSFP28 Connector"
},
"1/1/c2/1": {
"mac_address": "3a:98:de:fe:0e:86",
"is_up": true,
"speed": 10000,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c2/2": {
"mac_address": "00:00:01:01:00:0c",
"is_up": false,
"speed": 10000,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c2/3": {
"mac_address": "00:00:01:01:00:0d",
"is_up": false,
"speed": 10000,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c2/4": {
"mac_address": "00:00:01:01:00:0e",
"is_up": false,
"speed": 10000,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c3": {
"mac_address": "00:00:00:00:00:00",
"is_up": false,
"speed": "",
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c4": {
"mac_address": "00:00:00:00:00:00",
"is_up": false,
"speed": "",
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c5": {
"mac_address": "00:00:00:00:00:00",
"is_up": false,
"speed": "",
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"1/1/c6": {
"mac_address": "00:00:00:00:00:00",
"is_up": false,
"speed": "",
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"A/1": {
"mac_address": "ae:3e:e2:1d:ab:0b",
"is_up": true,
"speed": 100,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"A/3": {
"mac_address": "00:00:00:00:00:00",
"is_up": false,
"speed": 0,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"A/4": {
"mac_address": "00:00:00:00:00:00",
"is_up": false,
"speed": 0,
"last_flapped": -1.0,
"is_enabled": false,
"mtu": "",
"description": ""
},
"system": {
"mac_address": "ca:0b:ff:00:00:00",
"speed": -1,
"is_up": true,
"last_flapped": 1639784771.6,
"mtu": 1500
},
"oc_1/1/c1/1_0": {
"mac_address": "",
"speed": -1,
"is_up": true,
"last_flapped": 1639784771.6,
"mtu": 1500
},
"oc_1/1/c2/1_0": {
"mac_address": "",
"speed": -1,
"is_up": true,
"last_flapped": 1639784771.6,
"mtu": 1500
},
"management": {
"mac_address": "",
"speed": -1,
"is_up": true,
"last_flapped": 1639784548.5,
"mtu": 1500
}
}
ARP table:
[
{
"interface": "oc_1/1/c1/1_0",
"mac": "c2:6c:3e:c6:ea:9d",
"ip": "10.0.0.3",
"age": 14369.0
},
{
"interface": "oc_1/1/c2/1_0",
"mac": "a6:f7:49:a9:37:b4",
"ip": "10.0.0.1",
"age": 4771.0
},
{
"interface": "management",
"mac": "da:7a:6d:bf:7f:ca",
"ip": "192.168.101.1",
"age": 1112.0
}
]
Config:
{
"running": "<configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">\n <card>\n <slot-number>1</slot-number>\n <admin-state>enable</admin-state>\n <card-type>iom-1</card-type>\n <level>he</level>\n <mda>\n <mda-slot>1</mda-slot>\n <admin-state>enable</admin-state>\n <mda-type>me6-100gb-qsfp28</mda-type>\n </mda>\n </card>\n <log>\n <filter>\n <filter-name>1001</filter-name>\n <named-entry>\n <entry-name>10</entry-name>\n <description>Collect only events of major severity or higher</description>\n <action>forward</action>\n <match>\n <severity>\n <gte>major</gte>\n </severity>\n </match>\n </named-entry>\n </filter>\n <log-id>\n <name>100</name>\n <description>Default Serious Errors Log</description>\n <filter>1001</filter>\n <source>\n <main>true</main>\n </source>\n <destination>\n <memory>\n <max-entries>500</max-entries>\n </memory>\n </destination>\n </log-id>\n <log-id>\n <name>99</name>\n <description>Default System Log</description>\n <source>\n <main>true</main>\n </source>\n <destination>\n <memory>\n <max-entries>500</max-entries>\n </memory>\n </destination>\n </log-id>\n </log>\n <port>\n <port-id>1/1/c1</port-id>\n <admin-state>enable</admin-state>\n <connector>\n <breakout>c4-10g</breakout>\n </connector>\n </port>\n <port>\n <port-id>1/1/c2</port-id>\n <admin-state>enable</admin-state>\n <connector>\n <breakout>c4-10g</breakout>\n </connector>\n </port>\n <router>\n <router-name>Base</router-name>\n <static-routes>\n <route>\n <ip-prefix>0.0.0.0/0</ip-prefix>\n <route-type>unicast</route-type>\n <next-hop>\n <ip-address>10.0.0.1</ip-address>\n <admin-state>enable</admin-state>\n </next-hop>\n </route>\n </static-routes>\n </router>\n <system>\n <name>pod-013-sr1</name>\n <grpc>\n <admin-state>enable</admin-state>\n <allow-unsecure-... OUTPUT IS TRUNCATED"
}
====================================================================================
Completed in 0:00:02.811593 for pod-013-sr1
====================================================================================
!
! OUTPUT IS TRUNCATED FOR BREVITY
!
The output is collected as expected. If we compare it to the one we collected before:
- The ARP table and network interfaces data is collected and stored in the vendor independent format, which is very useful. I matches the data from Cisco IOS XR and Arista EOS collected perviously.
- The configuration data is provided in XML format, which is a NETCONF serialisation format. By default both startup and running config fields are populated with the same configuration, provided you configured automatic save after commit in Nokia SR OS network device. The configuration is provided in Nokia vendor-specific format.
So, the observation is the same as we had for NAPALM for Cisco IOS XR and Arista EOS. What about OpenConfig?
Part #2. Solution with OpenConfig/YANG over NETCONF
Step #2.1. NETCONF Client Installation
All the predatory work on the Python host is done: ncclient was installed in the previous blogpost, so we don’t need to bother about that.
Step #2.2. Prepare Nokia SR OS to Interact with NETCONF
This part is also completed. However, in Nokia SR OS we enable the YANG modules explicitly. We haven’t yet enabled OpenConfig YANG modules, so this is what you would need to do now:
2
3
4
5
6
7
8
9
system {
management-interface {
yang-modules {
openconfig-modules true
}
}
}
}
It was possible to complete this step in 1.2 together with enabling other modules, but we decided to separate them to emphasise the OpenConfig part.
Step #2.3. Develop a Python Script with NETCONF and OpenConfig YANG modules
And again, in the same way as for 1.3, the multivendor automation brings us valuable benefits: we don’t need to modify our code at all. In this case, as long as OpenConfig YANG modules are implemented in the network operating system we are interacting with, we don’t need to do modify our script.
Step #2.4. Execution of Python Script with OpenConfig/YANG over NETCONF
Let’s run our new Python script for multivendor network automation focusing on Nokia SR OS:
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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
!
! OUTPUT IS TRUNCATED FOR BREVITY
!
Interfaces operational and config data including ARP:
{
"rpc-reply": {
"@message-id": "urn:uuid:08548f60-b135-41e7-95dd-109d273f0648",
"@xmlns:nc": "urn:ietf:params:xml:ns:netconf:base:1.0",
"@xmlns": "urn:ietf:params:xml:ns:netconf:base:1.0",
"data": {
"interfaces": {
"@xmlns": "http://openconfig.net/yang/interfaces",
"interface": [
{
"name": "system",
"config": {
"name": "system",
"type": "softwareLoopback",
"enabled": "true"
},
"state": {
"name": "system",
"type": "softwareLoopback"
},
"hold-time": null,
"subinterfaces": {
"subinterface": {
"index": "0",
"config": {
"index": "0",
"enabled": "true"
},
"state": {
"index": "0",
"enabled": "true",
"name": "system",
"ifindex": "1",
"admin-status": "UP",
"oper-status": "UP",
"last-change": "1639784771600000000",
"counters": {
"in-octets": "0",
"in-unicast-pkts": "0",
"in-broadcast-pkts": "0",
"in-multicast-pkts": "0",
"in-fcs-errors": "4294967296",
"out-octets": "0",
"out-unicast-pkts": "0",
"out-broadcast-pkts": "0",
"out-multicast-pkts": "0",
"out-discards": "0",
"last-clear": "9190408127"
}
},
"ipv4": {
"@xmlns": "http://openconfig.net/yang/interfaces/ip",
"addresses": {
"address": {
"ip": "10.0.255.11",
"config": {
"ip": "10.0.255.11",
"prefix-length": "32"
},
"state": {
"ip": "10.0.255.11",
"prefix-length": "32",
"origin": "STATIC"
}
}
},
"state": {
"primary-address": "10.0.255.11"
}
},
"ipv6": {
"@xmlns": "http://openconfig.net/yang/interfaces/ip",
"state": {
"dup-addr-detect-transmits": "1"
}
}
}
}
},
{
"name": "1/1/c2/1",
"config": {
"name": "1/1/c2/1",
"type": "ethernetCsmacd",
"mtu": "1514",
"description": "sr1_1/1/c2/1_xr1_g0/0/0/0",
"enabled": "true"
},
"state": {
"name": "1/1/c2/1",
"type": "ethernetCsmacd",
"mtu": "1514",
"description": "sr1_1/1/c2/1_xr1_g0/0/0/0",
"enabled": "true",
"ifindex": "1610899585",
"admin-status": "UP",
"oper-status": "UP",
"last-change": "224090000000",
"hardware-port": "port 1/1/c2/1",
"counters": {
"in-octets": "34691544",
"in-unicast-pkts": "111490",
"in-broadcast-pkts": "0",
"in-multicast-pkts": "106120",
"in-discards": "0",
"in-errors": "0",
"in-unknown-protos": "0",
"in-fcs-errors": "0",
"out-octets": "8693228",
"out-unicast-pkts": "111490",
"out-broadcast-pkts": "4",
"out-multicast-pkts": "0",
"out-discards": "0",
"out-errors": "0"
}
},
"hold-time": {
"state": {
"up": "0",
"down": "0"
}
},
"subinterfaces": {
"subinterface": {
"index": "0",
"config": {
"index": "0",
"enabled": "true"
},
"state": {
"index": "0",
"enabled": "true",
"name": "oc_1/1/c2/1_0",
"ifindex": "3",
"admin-status": "UP",
"oper-status": "UP",
"last-change": "1639784771600000000",
"counters": {
"in-octets": "9786",
"in-unicast-pkts": "233",
"in-broadcast-pkts": "0",
"in-multicast-pkts": "0",
"in-fcs-errors": "4294967296",
"out-octets": "8678124",
"out-unicast-pkts": "111258",
"out-broadcast-pkts": "0",
"out-multicast-pkts": "0",
"out-discards": "0",
"last-clear": "9190408127"
}
},
"ipv4": {
"@xmlns": "http://openconfig.net/yang/interfaces/ip",
"addresses": {
"address": {
"ip": "10.0.0.0",
"config": {
"ip": "10.0.0.0",
"prefix-length": "31"
},
"state": {
"ip": "10.0.0.0",
"prefix-length": "31",
"origin": "STATIC"
}
}
},
"state": {
"primary-address": "10.0.0.0"
}
},
"ipv6": {
"@xmlns": "http://openconfig.net/yang/interfaces/ip",
"state": {
"dup-addr-detect-transmits": "1"
}
},
"vlan": {
"@xmlns": "http://openconfig.net/yang/vlan"
}
}
},
"ethernet": {
"@xmlns": "http://openconfig.net/yang/interfaces/ethernet",
"state": {
"mac-address": "3a:98:de:fe:0e:86",
"auto-negotiate": "false",
"hw-mac-address": "3a:98:de:fe:0e:86",
"negotiated-duplex-mode": "FULL",
"negotiated-port-speed": "SPEED_10GB",
"counters": {
"in-mac-pause-frames": "0",
"in-oversize-frames": "0",
"in-jabber-frames": "0",
"in-fragment-frames": "0",
"in-crc-errors": "0",
"out-mac-pause-frames": "0"
}
}
}
}
]
}
}
}
}
====================================================================================
Completed in 0:00:01.119180 for pod-013-sr1
====================================================================================
!
! OUTPUT IS TRUNCATED FOR BREVITY
!
The output is collected in the same format, using the same OpenConfig YANG module for interfaces we have used before in Cisco IOS XR and Arista EOS:
- This time you have not only vendor-agnostic counters but also configuration for Nokia SR OS in the same format as other vendors.
- However, if we carefully compare the output for Cisco IOS XR/Arista EOS from example before and this one from Nokia SR OS, we will find that one important piece of information is missing: there is no ARP information provided for Nokia SR OS.
This is where the dark side of OpenConfig starts being visible: in the ideal world, where all vendors support OpenConfig YANG modules in a full capacity, the multivendor automation would be a very easy thing. However, there are no such vendors. What we see in the example above means that Nokia didn’t implement part of the OpenConfig YANG module for interfaces, which Cisco IOS XR and Arista EOS have implemented. The might be different reasons for that, but the outcome is this:
OpenConfig is as useful as good it is implemented by a vendor in a network operating system.
That also means that you need to test your solution thoroughly against each operating system to make sure that the relevant is available for you.
GitHub Repository
You can find these and other scripts in our GitHub repository.
Lessons Learned
Apparently, we didn’t expect ourselves that there will be no code modification. This was a very pleasant and unexpected surprise. At the same time, it shows the real importance of a multivendor automation: low maintenance costs and possibility to adopt the new devices and/or vendors at a high pace, what is needed for modern networks.
Enrol to our Network Automation Training to build your automation foundation.
Conclusion
This blogpost concluded the discussion started in the previous one, which covers the comparison of NAPALM and OpenConfing/YANG over NETCONF for the purpose of the multivendor data collection (operational data and configuration). Today’s information was very valuable, as it allowed to cover some highlight the complications with OpenConfig, which were not visible in there previous blogpost. There is no such a thing as a free lunch. There will be always trade-offs, so be aware. Take care and good bye.
Support us
P.S.
If you have further questions or you need help with your networks, we are happy to assist you, just send us a message. Also don’t forget to share the article on your social media, if you like it.
BR,
Anton Karneliuk
