This is a collection of scripts and other files to ease handling/updating a more or less large amount of Cisco devices, and some CLI compatibles. If has two main features:
- Obtain and parse generic data about the device,
- Obtain and save configuration data for backup (and restore!) purposes.
Please read the NEWS for incompatible changes between updates and suggested remedies.
The application as a whole is split in two:
- A Perl script for automatic inventory data collection,
- Database tables and maintenance application for AS/400 V4R5 and successors.
This document is part of the Cisco device management solution, to be found on GitHub. Its content is subject to the CC BY-SA 4.0 license, also known as Attribution-ShareAlike 4.0 International. The project itself is subject to the GNU Public License version 2.
The application is used in two production environments — at least that's what I know for sure — and thus is continuously tested against
- Cisco ASA running software version 9.x
- Cisco IOS and IOS XE devices
- Routers:
- classic IOS ranging from 2500s running 11.2 and 12.0, 2600s running IOS 12.3, 870, 1700 running 12.4, 880, c880, 2900 running 15.x
- 1100 and ISR4K running IOS XE 17.x
- Switches:
- classic IOS ranging from version 12.1 (Cat 2950) to 15.2 (Cat 2960, 3560, 3750)
- IOS XE 16 and 17 on Cat 3850 and Cat 9300
- WiFi:
- AP1142N running IOS 15.x
- Routers:
- Nexus 5k/7.3
If you can't find your device in this list, that doesn't mean it won't work. It just means I have no regular access to said device (anmymore) to actually test. Chances are very high that also your device will work, if configured properly.
There is some basic support for Ubiquity switches, but this has not been tested for a long time and should be considered "likely broken".
Some of the more elaborated HP switches should also work, but same applies here: No way for me to test.
The Perl script automatically extracts and parses text output obtained by issuing commands to the device, according to the master data provided by the user. After parsing, the data is inserted into database tables. Acquired data includes the configuration, which is the NVRAM stored configuration on IOS based devices, and the currently active (running) configuration on ASAs. Configuration data is copied to a database table as well as saved into CVS or git repository to keep track of changes.
Consult README-devices-requirements to learn about the data acquisition process and recommended changes on the devices in question.
On the AS/400 platform, some green screen applications are provided to not only provide master data, but also work with the automatically acquired device data, notably:
- Structurated view of parsed data, including Vlan-configuration, and
show inventory, - Text viewers for obtained configuration and raw output of
show version, - Search application for serial numbers of devices and their individual components,
- Maintenance application for a list of recommended OS version for a given combination of model, RAM, and flash size,
- Compare application for finding and eliminating of orphaned and missing records in the recommended OS version data,
- Maintenance application for a general list of recommended Cisco Anyconnect images,
- Printed report listing devices with mismatches in OS- or Anyconnect versions: devices needing upgrades,
- Printed report listing devices by uptime, mainly for boasting about.
In addition, while using the applications, secondary information is calculated and used to modify the presented data:
- highlight if a different (newer) OS release is detected,
- highlight if acquired data is older than three days - a hard coded value -, indicating an error to reach the device,
- highlight if an ASA indicates being member of a failover cluster, to not forget to handle both devices on upgrade,
- highlight if a given OS release has an end-of-support date set.
Extensive online help (in German language) is provided in the AS/400 part.
The involved steps basically comprise of:
- assemble the AS/400 part of the application,
- manually fill the hosts master file with data about how to connect to your devices,
- configure devices with separate login credentials having the least required authorization (optional),
- set up ODBC on Linux so the perl script can connect to the database,
- set up CVS or git on the Linux machine for keeping track of configuration changes,
- setup the perl script to be run,
- run the perl script to acquire data,
- manually fill subsequent tables with desired software versions,
- run the upgrade report for learning which devices have mismatched software versions.
In any case, read the already mentioned READMEs. They point out important details regarding the setup process.
A huge thank you goes to Mathias Peter IT-Systemhaus, my current employer who allowed me to spend part of my work time on this project.
We agreed on this "light" version of the application to be released as OpenSource, and a non-public, more complete version for our internal use, featuring:
- customer numbers,
- further device flags,
- audit trails for individual tasks when doing a "maintenance run",
- and more.
Contact me if you're interested. This version will be available for a fee.
Note: Currently, the internal version is still in development stage and not yet ready for external deployment.
2024-08-04 poc@pocnet.net