[ad_1]
This weblog is authored by Rodolphe Trujillo,
Cisco Buyer Supply Engineering Technical Chief
One of many difficult matters of community automation is to check the routers to see if their present operational state match the anticipated operational state. Or, within the case you’re altering configuration, evaluate pre-operational states with post-operational states.
The standard manner for community engineers to do that is to make use of the CLI. We discover the information returned on the display… retrieve the related states, counters… and put them in an Excel doc. As there are lots of of these states and counters, verifications grow to be tough if the operation has a number of checks. Furthermore you probably have all these checks multiplied by numerous gadgets, it’s unimaginable to cowl with out automation.
You could have a number of methods to automate checks in your community. You need to use customized scripts, open supply options like Netmiko or Ansible. Alternatively, you need to use pyATS, which is an excellent testing framework from Cisco.
The purpose of this put up is to indicate a approach to automate checks with NSO and create an Excel doc for audit.
This isn’t THE approach to do it, simply A manner, however I’ve utilized it on hundreds of gadgets and run thousands and thousands of checks with an identical methodology because the one offered right here.
Together with NSO I will even use the pyATS parser. Traditionally, I used to be utilizing TextFSM do-it-yourself templates for doing the parsing a part of my workflow. Nonetheless, I are inclined to progressively migrate to the very wealthy parsers record of pyATS.
Be aware: The code offered solely works with CLI NEDs and Cisco gadgets.
On the Python set up working alongside your NSO let’s set up some libraries I’ve ready for this demonstration :
pip set up pyats-parser
This library, as described within the documentation, deliver the facility of the massive PyATS parsers assortment to each piece of python you possibly can write, the draw back is, due to dependencies, you’ll have to set up all of the PyATS libraries and never solely the parsing half.
pip set up nso-live-status
In truth, you possibly can straight set up this library as a result of it is dependent upon pyats-parser to run. So, pyats-parser might be put in mechanically. NSO-live-status is a wrapper to the dwell standing of NSO, and I needed to have a handy operate:
run_live_status(root_nso_object, system, str_cli_command)
Not solely will this operate execute the dwell standing, but when the command is acknowledged by pyATS it will likely be parsed and the article returned will comprise a structured output.
pip set up nso-restconf
This might be helpful for manipulating NSO by way of the Restconf API. Lastly, the favored openpyxl for producing excel paperwork:
pip set up openpyxl
For this instance we’ll merely verify the model of IOS-XR to see if it match a goal model.
I’ve ready a NSO Package deal which can be utilized as a “checks beginning pack” at: https://github.com/rtrjl/check_device, so all it’s important to do is:
git clone git@github.com:rtrjl/check_device.git
in your NSO packages listing, and
cd check_device cd src make clear make
within the NSO CLI session:
# packages reload
As soon as the package deal reload is finished, we are able to strive the motion within the NSO CLI session:
# check_device check_version system Paris-75 target_version 7.5.1 check_status NOK check_message [check_version] Present model 7.3.2 does not match the goal model 7.5.1 on the system Paris-75
You now have an motion to verify the model and you may name it with the CLI which is good, however NSO deliver a really highly effective built-in function with an auto-generated RESTConf API on prime of all of your actions and companies.
Utilizing this RESTConf API we are able to launch the checks on a set of gadgets:
import json
from nso_restconf.restconf import RestConf
from concurrent.futures import ThreadPoolExecutor, as_completed
nso_api = RestConf(handle="http://127.0.0.1", port=8080,
username="admin", password="admin")
# for the instance credentials are within the code :-)
devices_list = ["Kiev-47",
"Madrid-40",
"Napoli-50",
"Paris-66",
"Riga-46",
"Stuttgard-64"]
#the numbers haven't any significations they're simply the final bytes of the IP of the routers on the lab I take advantage of.
def nso_check_version(system, target_version):
information = json.dumps({'enter': {'system': f"{system}", "target_version":
f"{target_version}"}})
outcome = nso_api.motion(information, "check_device/check_version")
return outcome.json()
The script ought to print one thing like that:
{'check_device:output': {'system': 'Kiev-47', 'current_version': '7.3.2', 'operating_system': 'IOSXR', 'check_status': 'NOK', 'check_message': "[check_version] Present model 7.3.2 does not match the goal model 7.5.1 on the system Kiev-47"}}
{'check_device:output': {'system': 'Madrid-40', 'current_version': '7.3.2', 'operating_system': 'IOSXR', 'check_status': 'NOK', 'check_message': "[check_version] Present model 7.3.2 does not match the goal model 7.5.1 on the system Madrid-40"}}
{'check_device:output': {'system': 'Napoli-50', 'current_version': '7.3.2', 'operating_system': 'IOSXR', 'check_status': 'NOK', 'check_message': "[check_version] Present model 7.3.2 does not match the goal model 7.5.1 on the system Napoli-50"}}
{'check_device:output': {'system': 'Paris-66', 'current_version': '7.3.2', 'operating_system': 'IOSXR', 'check_status': 'NOK', 'check_message': "[check_version] Present model 7.3.2 does not match the goal model 7.5.1 on the system Paris-66"}}
{'check_device:output': {'system': 'Riga-46', 'current_version': '7.3.2', 'operating_system': 'IOSXR', 'check_status': 'NOK', 'check_message': "[check_version] Present model 7.3.2 does not match the goal model 7.5.1 on the system Riga-46"}}
{'check_device:output': {'system': 'Stuttgard-64', 'current_version': '7.3.2', 'operating_system': 'IOSXR', 'check_status': 'NOK', 'check_message': "[check_version] Present model 7.3.2 does not match the goal model 7.5.1 on the system Stuttgard-64"}}
The script is working nicely. Nonetheless, with this strategy it might take loads of time as a result of it is going to hook up with gadgets one after the opposite. It is going to be effective on a small community however on a much bigger one…?
Let’s use threads to speed up the method:
from concurrent.futures import ThreadPoolExecutor, as_completed
processes = []
with ThreadPoolExecutor(max_workers=10) as executor:
for system in devices_list:
processes.append(executor.submit(nso_check_version, system, "7.5.1"))
for process in as_completed(processes):
print(f"{process.outcome()}")
The identical output because the sequential one might be printed however on this model we leverage one other fascinating function of NSO:
gadgets could be reached in parallel to run present instructions, with limits , it is going to depend upon the quantity of RAM on the server on which NSO is put in, however we are able to run 10 employees with out issues.
Now now we have retrieved the checks we are able to put the leads to outdated excel doc:
checks_list = []
for process in as_completed(processes):
outcome = process.outcome()["check_device:output"]
checks_list.append([result["device"], outcome["operating_system"], outcome["current_version"], outcome["check_status"], outcome["check_message"]])
from openpyxl import Workbook
wb = Workbook()
ws = wb.lively
headers = ["Device", "OS", "OS version", "Check status", "Check message"]
ws.append(headers)
for information in checks_list:
ws.append(information)
wb.save("devices-version-audit.xlsx")
On this demo now we have checked out completely different matters equivalent to:
- utilizing pyATS parsers with NSO
- doing NSO dwell standing (present instructions) in parallel leveraging the auto-generated RESTCONF API
- writing a verify utilizing actions in NSO
Discover the pyATS parsers web page and picture all of the checks you are able to do. 🙂
Share:
[ad_2]
