Perhaps you have 100 network devices and you want to retrieve some data ONLY from those where the management access is provided to save the time. The question is : Is the management access disponible for all the devices AND how to notice the devices ensured the retrievement operation from those where the management access does not provided which cause the fail of the operation.
Yes of course you can use some testing frameworks such as pytest combined with other network frameworks such as Netmiko to test the access process. But what if you are not familliar with one of them especially pytest ? You can use PyATS/AEtest but some networkers found it not simple comparing to PyATS/Genie since it needs understanding of python unit testing.
And for the case of CI/CD pipelines perhaps you want to test the access and there is a FAIL for one device and the retrievement process STOP because the test step FAIL!! What about the others 99 ?!!…We can reach them and retrieve the targed data !
Here I introduce to you my use case Efficient Network Devices Data Retrieving - Application case of Validate/Monitor access to network devices with the integration of Genie/pyATS, WebEx Messenger and Syslog server use case. It represent an application and a use case of my project Check_Access published in my previous blog. As a reminder, the idea behind Check_Access is to leverages Genie/pyATS framework, WebEx Messenger and python logging module to check access into network devices by displaying, sending the result to WebEx Messenger Space and triggering logs to Syslog server for information and maintenance purposes.
Retrieve_Data_Application_Case aims to :
- Check if there is an access to the network devices and generating notification for each of them to Syslog server and as report incorporated in text file to WebEx Messenger Space.
- Retrieve data only form devices on witch there is access and generate notifications to Syslog server for both case : Retrieving Success or Not
Remarks :
- We focus here only on the result for the Syslog server notifications and the package installation and requirements, the others details like configuration files modification, topology and the WebEx Messenger result could be found at Check_Access repository related to Validate/Monitor access to network devices with the integration of Genie/pyATS, WebEx Messenger and Syslog server use case as it is a part of this project (https://github.com/cherifimehdi/Check_Access)
- For testing purposes, the topology used here is the same as that used in the Check_Access project
The same project is published in Cisco Code Exchange. Here the link: https://developer.cisco.com/codeexchange/github/repo/cherifimehdi/Retrieve_Data_Application_Case
Retrieve_Data_Application_Case in action
Here the topology used in this case
The command show ip interface brief is used here for testing the data retrieving process
In case of access
Here we run retrieve_data_application_case.py script from the Admin host:
(Retrieve_Data_Application_Case) [mehdi@Retrieve_Data_Application_Case]$python retrieve_data_application_case.py
+--------------------+
| Access Check |
+--------+-----------+
| Device | Status |
+--------+-----------+
| R1 | Access Ok |
| R2 | Access Ok |
| R3 | Access Ok |
+--------+-----------+
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Result for R1
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
{'interface': {'FastEthernet0/0': {'interface_is_ok': 'YES',
'ip_address': '192.168.1.251',
'method': 'NVRAM',
'protocol': 'up',
'status': 'up'},
'FastEthernet0/1': {'interface_is_ok': 'YES',
'ip_address': 'unassigned',
'method': 'NVRAM',
'protocol': 'down',
'status': 'administratively down'}}}
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Result for R2
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
{'interface': {'FastEthernet0/0': {'interface_is_ok': 'YES',
'ip_address': '192.168.1.252',
'method': 'NVRAM',
'protocol': 'up',
'status': 'up'},
'FastEthernet0/1': {'interface_is_ok': 'YES',
'ip_address': 'unassigned',
'method': 'NVRAM',
'protocol': 'down',
'status': 'administratively down'}}}
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Result for R3
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
{'interface': {'FastEthernet0/0': {'interface_is_ok': 'YES',
'ip_address': '192.168.1.253',
'method': 'NVRAM',
'protocol': 'up',
'status': 'up'},
'FastEthernet0/1': {'interface_is_ok': 'YES',
'ip_address': 'unassigned',
'method': 'NVRAM',
'protocol': 'down',
'status': 'administratively down'}}}
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Here the result sent to the Syslog Server:
In case of access problem
Now we will deactivate the management interface of the router R2
Now we run the retrieve_data_application_case.py script from the Admin host:
(Retrieve_Data_Application_Case [mehdi@Retrieve_Data_Application_Case]$ python retrieve_data_application_case.py
+--------------------+
| Access Check |
+--------+-----------+
| Device | Status |
+--------+-----------+
| R1 | Access Ok |
| R2 | No Access |
| R3 | Access Ok |
+--------+-----------+
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Result for R1
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
{'interface': {'FastEthernet0/0': {'interface_is_ok': 'YES',
'ip_address': '192.168.1.251',
'method': 'NVRAM',
'protocol': 'up',
'status': 'up'},
'FastEthernet0/1': {'interface_is_ok': 'YES',
'ip_address': 'unassigned',
'method': 'NVRAM',
'protocol': 'down',
'status': 'administratively down'}}}
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
NO Retrieving Data Process for R2 : Refer to Result.txt for more infos
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Result for R3
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
{'interface': {'FastEthernet0/0': {'interface_is_ok': 'YES',
'ip_address': '192.168.1.253',
'method': 'NVRAM',
'protocol': 'up',
'status': 'up'},
'FastEthernet0/1': {'interface_is_ok': 'YES',
'ip_address': 'unassigned',
'method': 'NVRAM',
'protocol': 'down',
'status': 'administratively down'}}}
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
As expected, the Syslog server received the logs:
From the results from the console and the Syslog server, we observe that there is no data retrieved from the router R2 and this process was escaped because there was no access to it which conducted to save the time.
I hope you find this blog and project useful and you will try it ! Comments and Suggestions are Welcome. Thank you for reading and don't forget to rate it if you found it useful and helpful!!!.