Quick Script to check the uptime of ASR920's

All,

I just created a quick script to check the uptime of a ASR920 via SNMP if you have a fairly long list of devices. It's a simple bash script and snmpwalk version 2c. Figured I would share it with you. Happy Friday

Grab the code from GitHub: https://github.com/esundberg/CiscoRouterUptime
It's a quick and dirty script and my first repo on github. Let me know if there any issues with it.

Output Format in CSV
DeviceName, IP, Uptime in Days, OK/Warning

I set my warning to 800 Days, you can change this in the code

ASR920list.txt

Doh.. Sent this to the wrong list. :facepalm:

Check out c-nsp if you want to find out about Cisco Bug CSCvk35460 on ASR920. Counters stop working at 889 days of uptime.

Erik,

That’s a nice little script. Thanks!

So you want a warning if a router hasn’t been rebooted in a long time? Just out of curiosity, why? I’m kind of glad that my routers don’t reboot, pretty much ever. Usually I want to know if the uptime suddenly became less than the most recent uptime, indicting a possibly unplanned reboot.

-mel

It was a script I created in regards to this thread below... Interface counters and some other things stop working after a Cisco ASR920 is up 889 days.... Fun Fun

https://puck.nether.net/pipermail/cisco-nsp/2019-January/106558.html

It’s worth mentioning that’s it’s not limited to just the cosmetic issue of interface counters/snmp counters.

  • I’ve had multiple instances of 920 interfaces getting stuck in their previous operational state. Unplugging-replugging/shut/no-shut doesn’t change anything.
  • The 920 fails to process traffic towards very specific IPs. That one is a pain to debug. You can reach the IP directly from the device but flows through the device are just dropped (also saw the same behavior on 903 with RSP3)
  • ARP under a BDI show up and are re-learned after a clear but traffic towards those IP do not work through or sourced from the 920.
  • One 920 started to show the above described symptoms, was rebooted and failed to back up. ISIS went up, cannot ping any of the P2P.

That said, uptime should definitely be monitored through your central NMS-flavor system. :wink:

Good stuff! Thanks for sharing this will come in handy.

Quick note for those running <other systems> it would be a little more portable by changing the shebang line to #!/bin/sh as bash on a lot of systems does not exist in /bin

Erik,

Just in case you want to go into/learn the data model-driven management, here is a NETCONF/YANG script.

CiscoRouterUptimeNETCONF) dvulovic@DVULOVIC-D2DW2:~/python-venv/CiscoRouterUptimeNETCONF$ ./CiscoRouterUptimeNETCONF.py testinput

CiscoRouterUptimeNETCONF by Djordje Vulovic (dvulovic@cisco.com)

I realize you’re aiming for the NETCONF paradigm, but for anyone interested, a more consistent, device- and release-independent method is to just query the SNMP uptime variable:


$ **snmpget -v 1 -c demopublic 10.1.2.1 system.sysUpTime.0** 
system.sysUpTime.0 = Timeticks: (586731977) 67 days, 21:48:39.77

-mel beckman