This article explains the basics of interacting with SR OS devices through pySROS. The pySROS libraries provide a model-driven management interface for Python developers to integrate with supported Nokia routers. pySROS programs can be executed on the router itself using a local Python interpreter, as well as remotely using NETCONF. In both cases the programs produce the same results.
This article covers:
This article is not a detailed overview on how to use Python, and it does not provide details on the way to communicate with SR OS devices or write Python programs. The article gets you started with one way of automating SR OS in Python.
This article assumes that your system is not behind a proxy when attempting to reach the router.
| Element | Version |
|---|---|
| CentOS Workstation/Server | CentOS Linux release 7.9.2009 (Core) |
| SR OS device running in Model-Driven mode | 22.7.R2 |
| Python (on the CentOS machine) | 3.9.6 |
| Containerlab | 0.32.1 |
When using Python with SR OS and pySROS, only Python3 should be used. For this tutorial, a development machine running Centos 7 with Python version 3.9.6 is used. This development machine runs the scripts against the routers through NETCONF, using pySROS built-in functionality. The same scripts can then be run on the router as needed.
Using a common IDE is recommended for developing pySROS applications. If desired, a pySROS application can be executed on the router instead of through NETCONF. The script under development must only require a connection to the local router because connecting to other devices is not possible for pySROS when run on the router itself.
If your development environment is different, adapt the following steps as necessary.
Pip may be installed as part of the Python3 installation (depending on the operating system distribution). As the first step, open a command terminal window and install the virtualenv package. Use it to create a virtual environment to simplify Python package version control, then activate the environment:
yum install python-virtualenv
virtualenv env --python=python3.9
source env/bin/activateThe prompt will change to include (env) at the beginning. If you need to leave the virtual environment at any point, type:
deactivateRemain in the virtual environment to continue.
Some packages must be installed before you can proceed to using pySROS from your local computer:
Ensure that pip is the latest version:
pip install --upgrade pipFor the use cases listed in this article, only the following library is required:
pysros
Use the following one-liner to install all required dependencies with their recommended versions:
pip install pysrosFrom the virtual environment that is now created, a pySROS script can be executed toward one or more routers. Under the hood, the router's NETCONF interface is used when accessing the router remotely. Therefore, as far as the router is concerned, anything that is possible through NETCONF is possible locally. This implies that there is some delay built into any interactions with the router because there is a network between the script and the router. By executing scripts off the box, it is possible to gather information from multiple routers and present them to an operator via a single interface, rather than requiring interaction with each individual device.
Through the on-board pyexec, triple-play, alias, cron, or EHS features, Python code can be executed on the router. The main limitation compared to off-box execution is that only the local router can be addressed and interacted with. The speed of execution is increased as compensation for this limitation.
Scripts executed on the router are limited in execution time and memory usage to ensure that the general functioning of the router is safe from any errors in the Python code.
Aliases in MD-CLI are able to call pySROS scripts so that an operator need not be aware of which commands came with the router and which commands were created on top.
Aliases enable operators of the Nokia SR OS MD-CLI to streamline processes and workflows, abstracting away from repeated CLI command execution in favor of a single alias that does all the work in the background:
/configure python python-script "watch" { admin-state enable }
/configure python python-script "watch" { urls ["tftp://172.31.255.29/scripts/Watch.py", "cf3:/Watch.py"] }
/configure python python-script "watch" { version python3 }
/configure system management-interface cli md-cli { environment command-alias alias "watch" admin-state enable }
/configure system management-interface cli md-cli { environment command-alias alias "watch" python-script "watch" }
/configure system management-interface cli md-cli { environment command-alias alias "watch" mount-point "/" }In MD-CLI cron can trigger the execution of pySROS scripts, meaning that they will run at configured intervals. Something to watch out for with scripts running in cron tasks is that each time the script runs, a file containing the output is created and stored in the results directory. These files must be managed to prevent too many accumulating.
The following example shows a configuration is shown that runs a Python script named bgp_evpn_script configured to run every 60 seconds.
/configure python python-script "bgp_evpn_script" { admin-state enable }
/configure python python-script "bgp_evpn_script" { urls ["tftp://172.31.255.29/scripts/bgp_evpn_script.py", "cf3:/bgp_evpn_script.py"] }
/configure python python-script "bgp_evpn_script" { version python3 }
/configure system cron { schedule "bgp_evpn_script" owner "admin" admin-state enable }
/configure system cron { schedule "bgp_evpn_script" owner "admin" interval 60 }
/configure system cron { schedule "bgp_evpn_script" owner "admin" type periodic }
/configure system cron { schedule "bgp_evpn_script" owner "admin" script-policy name "bgp_evpn_script" }
/configure system cron { schedule "bgp_evpn_script" owner "admin" script-policy owner "admin" }
/configure system script-control { script-policy "bgp_evpn_script" owner "admin" admin-state enable }
/configure system script-control { script-policy "bgp_evpn_script" owner "admin" results "cf3:/results_bgp_evpn_script/" }
/configure system script-control { script-policy "bgp_evpn_script" owner "admin" python-script name "bgp_evpn_script" }Python scripts can be triggered by events. These event-handler scripts have existed for some time for regular CLI scripts. With pySROS and Python, an entire program can be run in response to an event in the OS. Whenever the configured event occurs, the script is triggered. As with the cron scripts, output is stored in the results directory. These files must be managed to prevent too many accumulatng.
The following example shows a Python script ehs_python_script configured to run whenever a LinkDown event occurs.
/configure python python-script "ehs_python_script" { admin-state enable }
/configure python python-script "ehs_python_script" { urls ["tftp://172.31.255.29/scripts/ehs_python_script.py", "cf3:/ehs_python_script.py"] }
/configure python python-script "ehs_python_script" { version python3 }
/configure system script-control { script-policy "ehs_python_script" owner "admin" admin-state enable }
/configure system script-control { script-policy "ehs_python_script" owner "admin" results "cf3:/results_ehs_python_script/" }
/configure system script-control { script-policy "ehs_python_script" owner "admin" python-script name "ehs_python_script" }
/configure log { event-handling handler "ehs_srexperts_demo" }
/configure log { event-handling handler "ehs_srexperts_demo" admin-state enable }
/configure log { event-handling handler "ehs_srexperts_demo" entry 10 }
/configure log { event-handling handler "ehs_srexperts_demo" entry 10 script-policy }
/configure log { event-handling handler "ehs_srexperts_demo" entry 10 script-policy name "ehs_python_script" }
/configure log { event-handling handler "ehs_srexperts_demo" entry 10 script-policy owner "admin" }
/configure log { event-trigger snmp event linkDown }
/configure log { event-trigger snmp event linkDown admin-state enable }
/configure log { event-trigger snmp event linkDown entr 10 }
/configure log event-trigger { snmp event linkDown entry 10 admin-state enable }
/configure log event-trigger snmp event linkDown entry 10 debounce time 1 second value 2
/configure log log-events snmp event linkDown specific-throttle true
/configure log log-events snmp event linkDown specific-throttle-limit 2
/configure log log-events snmp event linkDown specific-throttle-interval 30The use cases listed here show what is possible using pySROS. In general, they illustrate situations where the code is run using the on-board interpreter available in SR OS. The reason for this is that the programs intend to address only a single router. The programs are faster when run on the router. When many routers must be addressed or when flexibility is more important than speed, running the same programs from a workstation to connect through NETCONF is preferred.
If you would like to discuss your use cases please see your local Nokia representative.
One important note before working with the listed scripts is that when you first connect to a device remotely from pySROS, the YANG schema for that node is compiled. For the first connection, the connection time is longer and the schema is cached. Whenever a new node is addressed or the same node begins advertising a different set of YANG modules, this action will be repeated. After the schema is cached, when connecting to the same node advertising the same modules, the cache is used.
In this article, we covered how to install Python3 and create a virtual Python environment. We also covered installing additional Python libraries into this virtual environment.
Options for utilizing pySROS both for on-box and off-box use cases were described and some practical use cases were listed for further reading.