Script to identify unused switch ports > 30 days

I don't have the script for you, but do have a couple of thoughts on the topic of disabling ports.  My organization was concerned about unused ports being used by unauthorized devices plugged into patched network jacks.  We embarked on a project to unpatch unused ports, but never found a way to force technicians to unpatch them from the switches when the techs would remove gear from their wall jacks. 

Equally as bad was our plan to disable ports that were inactive for X days. 

1. It meant there were 30 days where unauthorized users could jack into the wall ports and attempt to access our network. 

2. Users regularly and temporarily move equipment from one room to another (or even to a different floor or building or city), and then move the device back to the original port, and need its switchport(s)  active anytime something was plugged in.

3. Technicians temporarily remove a device (perhaps for replacement or upgrades or troubleshooting), and then find no link when they bring it back to the original location due to its switch port being unpatched or administratively disabled.

We found no solution for this until we started using Cisco ISE to manage NAC.  It was a big project, with several expensive missteps, but eventually it proved to be the right solution for every one of 80,000+ switchports. 

Benefits:

* Every jack would remain patched.

* Unpatched ports, when repatched, never need any special VLAN or port-security--ISE takes care of that.

* Every authorized device ("authorized" means it was properly onboarded by our Techs & Information Security, including being added to Active Directory and automatically receiving security certificates that helped ISE use the proper port-VLAN security settings, as well as automatically downloading security patches, anti-virus, and more) would automatically get access to the appropriate VLANs/subnets through ISE.

* Every authorized user is given the appropriate security access through AD, and ISE applies a combination of the user security and the device security allowed access to provide the appropriate subnet & VLAN access.

* Unauthorized devices never get access to the internal/protected corporate network; their VLAN settings force them either to the bit bucket, or to a remediation VLAN (where they can request internal access by joining AD and accepting downloads of security certs and patches and the latest version of A/V, etc.)  Or, they automatically get dumped into a Guest VLAN that provides only Internet access through a filtered service.

Drawbacks:

* Cost of purchasing ISE & implementing NAC.  It's complex & time-consuming.

* Correctly identifying EVERY device attaching to the network (including wireless) and putting it into the proper AD groups

* Creating the proper machine AD groups and giving them the correct security access, and then testing & confirming EVERY device is included.

* Training, testing, and certifying that anyone who adds a device to the network (I mean a corporate-employed & certified installation Technician) makes sure every device goes through the onboarding process to get it patched, certified, added to A/D, etc.

* Staying on top of all new types of devices, and understanding what access they and their users require to get the job done, and then building or modifying AD groups and putting the new devices into them.

Until ISE NAC was successfully implemented across 100% of the organization's ports, we in the Network Team would run a Report from NPM / NCM / UDT that identified all the ports on a switch or switch stack, and sorted them by how long it's been since the port saw link.  We'd then use the list of inactive ports, sorted by decreasing inactivity time, to let Technicians know which ports could most-safely be unpatched (for security or for reuse) without expecting impact to someone who'd been accustomed to using that patch. 

I published how to build the Report in Thwack some years ago, if you're interested in using it, or modifying it, for your original purpose.

The Network Team originally assigned the list of inactive ports to Techs for unpatching.  Later, when Techs wouldn't do this (for varying reasons, including insufficient staff & time), the Network Team would submit it to I.S. Security for approval to disable the ports.  We never disabled ports on our own--we couldn't take the heat for Security when we had an I.T. Security Team who was responsible for the decision.

If you do find a way of accomplishing your original goal, please post your how-to-do-it here so others can benefit from your experience!

Swift Packets!

Rick Schroeder