Site icon Karneliuk

Automation 2. Exploring Nokia SR OS configuration in a programmable way with pySROS

Hello my friend,

Thanks a lot for all your interactions over our last post, it was very good feeling. As it attracted your attention, we decided to explore this topic further. Today we’ll focus on two main aspects: how you can figure out from Nokia SR OS CLI, what is your path to use in pySROS and how you visualise a configuration tree following YANG module.


1
2
3
4
5
No part of this blogpost could be reproduced, stored in a
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.

I Have Heard, Facebook Automation Caught It, Isn’t It?

Facebook outage happened the last week caused a lot of discussions, how reliable automation is in general and if there are too much automatons these days already in the infrastructure systems. Really, if Facebook with their smartest network and automation engineers failed, should I stay far away from automation? We believe, everyone will find his or her answer. From our perspective, we know that Facebook will make their systems after failure more robust and working. By the way, in our training we discussing such use cases: how can we build the system which thoroughly validates the impact of the change on the network baseline. In fact, we not only discuss, we teach you how to do that.

At our trainings, zero-to-hero network automation and automation with Nornir (2nd step after zero-to-hero network automation), we give you detailed knowledge of all the technologies relevant:

Great job! Thanks Anton.

Tilo Chucholowius @ Deutsche Telekom

Technologies themselves are good, but it is not good enough for us. Therefore, we put all of them in the context of the 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 you are doing the lab afterwards to master your skills. Such a mixture creates a unique learning environment, which all students value so much. Join us and unleash your potential.

Both trainings are available in live class and online formats. And more trainings coming soon!

Start your automation study today.

Brief Description

In our network automation training we discuss YANG in-depth and teach you how to be read, use and build them. On of the critical aspects of working with YANG is the possibility to understand how to navigate down the data tree. Depending on the vendor, it may be easy or not; it all depends on whether the configuration in CLI follows YANG modules. From our experience, many vendors have in CLI a different structure of commands compared to YANG modules. Nokia has two CLIs: classical CLI and model-driven CLI, which was introduced in release 16.0.R1:

Read our blogpost about introduction to Nokia model-driven CLI.

Further on this blogpost you will learn how to find from CLI what is the path for the particular configurational or operational context, so that you can use it for further automation with pySROS and Python.

The another aspect, which we will touch, can be considered as continuation of the path discussion. Once you are getting to a particular configurational context in Nokia SR OS model driven CLI, you often need to know, what is configured there at the moment. Normally, you just use info or info detail command for that. The output of the command shows you either all non-default configuration or in the latter case the full configuration including default values.

The same operation you can do with pySROS using the get() operation, which we discovered in the previous blogpost. However, it might be slightly difficult to read and interpret that for network engineers, which are doing first steps in automation. To help them, Nokia added some functionality to pySROS, which simplifies the visual representation of the actual data following YANG modules. You can think about it as a possibility to run info with Python.

Let’s see how all that works.

Lab Setup

The lab setup for today’s session is exactly the same as in the previous one:

The Linux host can be anything, though we are using Debian 11. As an automation engine, we use Python 3.9, though not the latest version. From the router perspective, we use Nokia SR OS 21.7.R1 and it shall be the latest version for pySROS to work, actually.

There is one important characteristic of Nokia SROS 21.7.R1 actually, which makes this release (and later) a mandatory one. Previously, even in Nokia SR OS 20.10.R1, the YANG modules were not embedded in the operating system. As such, it was not possible to retrieve the content of YANG modules via corresponding NETCONF calls (i.e., get-schema). At the same time, pySROS relies on this call to build local cache of YANG modules. In Nokia SR OS 21.7.R1, YANG modules finally became part of operating system and, therefore, you need this version for pySROS to work.

Scenario Description

As mentioned beforehand, there are two main questions to answer today:

Once we cover these topics, you will have a complete view on how you can use pySROS to collect and interpret all the data from your Nokia SR OS based devices.

If you want experts to build and operate automation for your network, we are happy to do that for you. Leave a request and we will get in touch with you.

Python Script Development

Step #1. Get Path From Nokia SR OS CLI

Login to your Nokia SR OS device and make sure it runs the SW version at least 21.7.R1:


1
2
3
4
5
[/]
A:admin@SR1# show version
TiMOS-B-21.7.R1 both/x86_64 Nokia 7750 SR Copyright (c) 2000-2021 Nokia.
All rights reserved. All use subject to applicable license agreements.
Built on Thu Jul 29 14:54:01 PDT 2021 by builder in /builds/c/217B/R1/panos/main/sros

The go in configuration context you plan to configure. For example, go to the configuration of line cards:


1
2
3
4
5
6
7
8
9
[/]
A:admin@SR1# configure global
INFO: CLI #2054: Entering global configuration mode

[gl:/configure]
A:admin@SR1# card 1

[gl:/configure card 1]
A:admin@SR1#

The next step is to get the path. If you already worked with Nokia SR OS based devices before, you know the command pwc, which stands for present working context. Try to call it:


1
2
3
4
5
[gl:/configure card 1]
A:admin@SR1# pwc
Present Working Context:
  configure
  card 1

You see the path, how to get in the current context from the CLI perspective, which is often used in CLI-based automations. However, this command has on optical argument, which allows you to get the path in a YANG-compatible format, which can be used in NETCONF, RESTCONF and GNMI. This argument is named json-instance-path and here is how you can use it:


1
2
3
4
[gl:/configure card 1]
A:admin@SR1# pwc json-instance-path
Present Working Context:
/nokia-conf:configure/card[slot-number="1"]

This path is exactly what we used in the previous blogpost. You can navigate to any other configuration context and get path using the described approach, which you can use in your Python application with pySROS.

In our Zero-To-Hero Network Automation Training you can learn Python in-depth to build both text-based and model-driven automation tools for Nokia, Cisco, Arista and Cumulus.

Whilst you are still in CLI of your Nokia SR OS based device, execute info command:


1
2
3
4
5
6
7
8
9
[gl:/configure card 1]
A:admin@SR1# info detail
    admin-state enable
    card-type iom-1
    level he
    mda 1 {
        admin-state enable
        mda-type me6-100gb-qsfp28
    }

You can see the output containing all the keys we have configured. Now it is time to Python!

Step #2. Develop a Python Script with pySROS

In the previous blogpost we’ve covered the step-by-step approach how to build the Python script with pySROS. Therefore, it is expected you read that already. We’ll take the get_config script and modify that accordingly our needs:


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
39
40
41
42
43
44
45
#!/usr/bin/env python

# Modules
import datetime
import os
from dotenv import load_dotenv
from pysros.management import connect
from pysros.pprint import printTree


# Body
if __name__ == "__main__":
    ## Get connectivity details
    load_dotenv()
    host={
            "ip_address": os.getenv("NOKIA_IP"),
            "username": os.getenv("NOKIA_USER"),
            "password": os.getenv("NOKIA_PASS")
         }

    ## Get path
    path = '/nokia-conf:configure/card[slot-number="1"]'

    ## Timestamp: started
    t1 = datetime.datetime.now()

    ## Interecting with the device
    connect_obj = connect(host=host["ip_address"], username=host["username"],
                          password=host["password"])

    results = connect_obj.running.get(path)
    connect_obj.disconnect()

    ## Timestamp: completed
    t2 = datetime.datetime.now()

    ## Printing results
    tl = os.get_terminal_size()
    print(f"{'=' * tl.columns}\nCompleted in {t2 -t1}\n{'=' * tl.columns}\n")

    ## Printing collected data
    print(path)
    printTree(results)

    print(f"\n{'=' * tl.columns}\n")

We’ve covered the vast majority of this script step-by-step already. As such, we will focus only on new elements, which are new:

  1. Variable with path. As you see, we have created a new one, which contains the string value, which you copy straight from model driven-cli as a result of pwc json-istance-path command. This variable is used as an argument to connect_obj.running.get() function.
  2. New function printTree() from pysros.pprint is imported and used to print the collected results, which, as you learned in the previous blogpost, is a custom Python classes. It prints the results in a hierarchical tree view, which simplifies understanding of the data hierarchy within configuration context.

If you haven’t read previous blogpost, we strongly recommend you to do that to get better understanding of the script above.

Step #3. Execute Your Python Script with pySROS Automation

Let’s run our created script to see the results:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ python pysros_get_tree.py
==========================================================================================================
Completed in 0:00:04.647615
==========================================================================================================

/nokia-conf:configure/card[slot-number="1"]
+-- admin-state: enable
+-- card-type: iom-1
+-- level: he
+-- mda:
|   `-- 1:
|       +-- admin-state: enable
|       +-- mda-type: me6-100gb-qsfp28
|       `-- mda-slot: 1
`-- slot-number: 1

==========================================================================================================

As a result of the script execution, you can see exactly the same information, as you have seen just before in the CLI, when executed info command in the configuration context. Moreover, this information is represented in an easy consumable hierarchical format following the Nokia native YANG modules. Such visualization gives you clear understanding, what is configured and which key is a child to another one.

In our Network Automation Training you will learn all the details of YANG modelling and their application.

Let’s choose another context, for example, OpenConfig interfaces. The path would be:


1
/openconfig-interfaces:interfaces

Let’s modify the value path in the script and execute it again:


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
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
$ python pysros_get_tree.py
==========================================================================================================
Completed in 0:00:04.715393
==========================================================================================================

/openconfig-interfaces:interfaces
`-- interface:
    +-- system:
    |   +-- config:
    |   |   +-- name: system
    |   |   +-- type: softwareLoopback
    |   |   `-- enabled: True
    |   +-- state:
    |   |   +-- name: system
    |   |   `-- type: softwareLoopback
    |   +-- subinterfaces:
    |   |   `-- subinterface:
    |   |       `-- 0:
    |   |           +-- config:
    |   |           |   +-- index: 0
    |   |           |   `-- enabled: True
    |   |           +-- state:
    |   |           |   +-- index: 0
    |   |           |   +-- enabled: True
    |   |           |   +-- name: system
    |   |           |   +-- ifindex: 1
    |   |           |   +-- admin-status: UP
    |   |           |   +-- oper-status: UP
    |   |           |   +-- last-change: 1633642927900000000
    |   |           |   `-- counters:
    |   |           |       +-- in-octets: 0
    |   |           |       +-- in-unicast-pkts: 0
    |   |           |       +-- in-broadcast-pkts: 0
    |   |           |       +-- in-multicast-pkts: 0
    |   |           |       +-- in-fcs-errors: 7939631134649771264
    |   |           |       +-- out-octets: 0
    |   |           |       +-- out-unicast-pkts: 0
    |   |           |       +-- out-broadcast-pkts: 0
    |   |           |       +-- out-multicast-pkts: 0
    |   |           |       +-- out-discards: 0
    |   |           |       `-- last-clear: 13264824941614597512
    |   |           +-- ipv4:
    |   |           |   +-- addresses:
    |   |           |   |   `-- address:
    |   |           |   |       `-- 10.0.255.11:
    |   |           |   |           +-- config:
    |   |           |   |           |   +-- ip: 10.0.255.11
    |   |           |   |           |   `-- prefix-length: 32
    |   |           |   |           +-- state:
    |   |           |   |           |   +-- ip: 10.0.255.11
    |   |           |   |           |   +-- prefix-length: 32
    |   |           |   |           |   `-- origin: STATIC
    |   |           |   |           `-- ip: 10.0.255.11
    |   |           |   `-- state:
    |   |           |       `-- primary-address: 10.0.255.11
    |   |           +-- ipv6:
    |   |           |   `-- state:
    |   |           |       `-- dup-addr-detect-transmits: 1
    |   |           `-- index: 0
    |   `-- name: system
!
! OUTPUT IS TRUNCATED FOR BREVITY
!
        +-- 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
        `-- name: 1/1/c2/1

==========================================================================================================

OpenConfig YANG modules contain the configuration (config) and operational information (state) in same modules; therefore, you see more information compared what is configured on the Nokia SR OS based network function.

The latter also means, you can apply this printTree() function for any collected data in YANG format. For example, nokia-state.

Examples in GitHub

You can find this and other examples in our GitHub repository.

Lessons Learned

You still need to learn the structure of the YANG modules, as at the time of writing there are no good options, how you see the path towards operational YANG modules. That could change though in future, as, for example, another Nokia network operating system SR Linux has possibility to print the content of all the information in the model driven approach directly in CLI.

Conclusion

Now you are armed with pySROS from the perspective of data analysis. Besides printTree(), the modules pysros.pprint has some other formats: for example, it allows you to print custom tables, which creates a basis for the creation of custom configuration or validation commands. in the next blog post in this series we’ll show you how to configure the Nokia SR OS based network function with pySROS. 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

Exit mobile version