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:

./unpatchable.py -H 172.16.100.7 -c READONLY

HOST     172.16.100.7

DEVICE UPTIME    175 days, 12:40:14.44000

+-----------+--------+------------------+
| INTERFACE | STATUS | LAST CHANGE DAYS |
+-----------+--------+------------------+
|   Fa0/1   |   up   |        0         |
|   Fa0/2   |   up   |        0         |
|   Fa0/3   |   up   |        8         |
|   Fa0/4   |   up   |        0         |
|   Fa0/5   |   up   |        0         |
|   Fa0/6   |   up   |        0         |
|   Fa0/7   |   up   |        0         |
|   Fa0/8   |   up   |        0         |
|   Fa0/9   |   up   |        0         |
|   Fa0/10  |  down  |       175        |
|   Fa0/11  |   up   |        23        |
|   Fa0/12  |   up   |       175        |
|   Fa0/13  |   up   |       175        |
|   Fa0/14  |   up   |       175        |
|   Fa0/15  |   up   |        0         |
|   Fa0/16  |   up   |       175        |
|   Fa0/17  |   up   |       175        |
|   Fa0/18  |   up   |        26        |
|   Fa0/19  |   up   |        4         |
|   Fa0/20  |   up   |        5         |
|   Fa0/21  |   up   |       175        |
|   Fa0/22  |   up   |        48        |
|   Fa0/23  |   up   |       175        |
|   Fa0/24  |   up   |       175        |
|   Gi0/1   |   up   |       175        |
|   Gi0/2   |   up   |       175        |
+-----------+--------+------------------+

Or print only down ports with option -d y:

./unpatchable.py -H 172.16.100.7 -c READONLY -d y

HOST     172.16.100.7

DEVICE UPTIME    175 days, 12:43:26.270000

+-----------+--------+------------------+
| INTERFACE | STATUS | LAST CHANGE DAYS |
+-----------+--------+------------------+
|   Fa0/10  |  down  |       175        |
+-----------+--------+------------------+

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 .

UPDATE 2019-01-04

Updated code on GitHub to Python3 and prettytable for better output. Moved script to its own repository . Added option to print only down ports, useful for modular switches with many ports.