# Unpatchable?

Quite often cable management is something that starts well when a new IDF is deployed and then gets messier over time.

Cable p0rn channel on reddit shows plenty of example of how cabling should look like.

I usually don’t do cabling and I’m not good at it either so I’ll not post my home lab setup ;-)

## Unpatchable?

The real problem with poor cable management arises when a new box must be connected and all switch ports are already patched.

A down port is down right? Who’ll be the lucky one to lose wired connection to leave some room to the newcomer?

Natural Born Killers

## Hello snmp

SNMP is really helpful in this case with ifLastChange that is defined as:

The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value.

Doesn’t sound really helpful but we can fix this.

When the system boots an uptime counter starts. sysUpTime

## Enter Python

With some Python and EasySNMP we can read sysUpTime, ifOperStatus and ifLastChange and with a few datetime operations get the actual date the port went down.

Be sure to install EasySNMP and enable SNMP on the switch before running the script.

Sample output:

gp@westworld:/CODE/GITHUB/various# ./unpatchable.py
IP ADDRESS:     10.0.0.99
COMMUNITY:      readonlycomm

HOST    10.0.0.99

UPTIME  196 days, 8:25:41

1       STATUS down     LAST CHANGE SINCE DAYS  196
2       STATUS down     LAST CHANGE SINCE DAYS  3
3       STATUS up       LAST CHANGE SINCE DAYS  65
4       STATUS down     LAST CHANGE SINCE DAYS  22
5       STATUS down     LAST CHANGE SINCE DAYS  136
6       STATUS down     LAST CHANGE SINCE DAYS  22
7       STATUS down     LAST CHANGE SINCE DAYS  36
8       STATUS down     LAST CHANGE SINCE DAYS  11
9       STATUS down     LAST CHANGE SINCE DAYS  17
10      STATUS up       LAST CHANGE SINCE DAYS  196
11      STATUS down     LAST CHANGE SINCE DAYS  21
12      STATUS down     LAST CHANGE SINCE DAYS  22
13      STATUS up       LAST CHANGE SINCE DAYS  60
14      STATUS up       LAST CHANGE SINCE DAYS  168
15      STATUS down     LAST CHANGE SINCE DAYS  1
16      STATUS up       LAST CHANGE SINCE DAYS  161
17      STATUS down     LAST CHANGE SINCE DAYS  196
18      STATUS down     LAST CHANGE SINCE DAYS  3
19      STATUS down     LAST CHANGE SINCE DAYS  117
20      STATUS down     LAST CHANGE SINCE DAYS  196
21      STATUS down     LAST CHANGE SINCE DAYS  1
22      STATUS down     LAST CHANGE SINCE DAYS  196
23      STATUS down     LAST CHANGE SINCE DAYS  196
24      STATUS up       LAST CHANGE SINCE DAYS  16
25      STATUS up       LAST CHANGE SINCE DAYS  22
26      STATUS up       LAST CHANGE SINCE DAYS  5


Ports in down state for the longer period are good candidate for unpatching.

Sounds better than just guessing down ports and waiting for a manager to call complaining, right? ;-)

## Wrap up

There’s plenty of room for improvement but that’s an MVP that solves my problem and saves more time that it took to write it. Pareto FTW!

I put the script in my github account. Feel free to improve it as you like but respect the CC share alike license.

comments powered by Disqus