I'm always interested in re-purposing inactive switchports that used to go to users' devices; it prevents me from having to buy more switches. But knowing which ports can be safely unpatched (meaning they haven't been used in three months), means doing a custom report (which I've previously documented here: How to create a report displaying the Last Time Data was Transmitted or Received on a Switch Port ).
Shouldn't there be an easy way for UDT to display this for me?
UDT tells how many Ports Available and the Top 10 Nodes by Percent Ports Used.
But what does that actually mean?
What ports does it include? Does it include fiber modules that won't ever have more connections added? Does it include local 100 Mb Management Ports? If so, how do I filter the UDT info so it only shows copper interfaces between 1 and 48 on all my switch stacks (up to 8 switches deep) or on chassis switches (up to 10 slots filled, but only 8 of them are line cards)?
Part of what I'm asking is is "How reliable is UDT's information for my specific use case?"
When UDT shows there are 56 unused ports, but that count includes ports which are reserved for fiber uplinks, or are in specialty modules, or only goes back 24 hours (and the port was in use two days ago), that makes UDT seem unreliable to my peers.
I need to be able to defend UDT when others challenge its output. I need to say things like "UDT calls a port available if it hasn't seen link in X days/weeks/months, AND if it's a copper port usable for a new computer connection." But what is X, and how frequently is it calculated? What ports are included?
Hey I have read some of your earlier posts and believe you are trying to find a way to show ports that have not been in use for a long time. If I remember correctly in one of your posts you mentioned you have all of your ports managed (check marked). If so I think you could achieve this with something as simple as an alert.
Since you can't go beyond 999 might as well stop every 30 days (672 hours)
You don't even really need to run the alert, just go enable it and view the results and you have your answer on which interfaces have been in a down state for 672 hours.
If you have the trigger write out to a log every 30 days you could always review the log to see what has gone beyond.
Given that we're pretty burned out and wary of alert fatigue, and also given that I like your way of thinking here, I'd rather have a report showing the interfaces down for X hours than have to look at alerts. I have about 66,000 ports, and perhaps 10% - 25% might occasionally qualify for that alert. No one wants between 6,000 and 15,000 alerts.
Do you have a method of leveraging this same kind of data in a report, sorted by node, port, and amount of time the interface has been down?
I've tentatively determined, after reading the available documentation about UDT's abilities to identify and report used versus unused copper switchports, that the options available won't fill my specific needs.
I want to quickly display the ports on a switch that have seen no link in a month or three months, but only include copper access ports. The options available that I've found include fiber uplink ports and other ports that aren't appropriate for use to connect to end user devices. These additional ports, that are unusable for computer connections, skew the count and percentage of available ports off, rendering the data unreliable for my use case.
Using the available Widgets added to a web page DO give options for longer than the last 24-hours. But the resulting information includes ports that aren't copper, aren't usable for connecting more computers. I suspect some SWQL tweaking might be able to filter the output to just the ports that are useful for my purpose, but I haven't figured out that part so far.
I'm willing to be educated! If you have a method of using UDT to show which copper ports on a Cisco switch haven't seen link in three months, please inform me how you accomplished it.
Swift Packets, All!
From poking at this in the past it seemed to me that it to get the port count it just looks at the interface type and captures everything that was not virtual, so physical or unknowns if the device doesn't utilize the relevant SNMP OIDs.
As far as the available goes, I want to say it is calculated at the time of the polling job just based on up/down operational statuses. So if you happen to unplug a laptop some time in the next 30 min (assuming defaults) UDT will poll your switch, see the port as currently admin up, oper down, and call that available. I haven't tested it deeply enough to be sure how it handles admin downs, and I know for sure some of the port types that it counts are not actually available. I feel like it always has at least a 5-10 percent skew between the number of ports I would say are "real" versus it counting things like loopbacks or mgmt ports or backplane interfaces or whatever. Maybe not those specific types of interfaces, because I'm going from memory here, but in any case if I know I have what I am calling a 48 port switch it will probably come back with a number like 52 total ports because they are tracking things I wouldn't actually plug a user or other gear into.
Another thing that can skew the numbers is that if an interface is not marked as being monitored with UDT it basically doesn't exist for these calculations. So you could potentially clean out all those extra ports, or you could also accidentally remove ports that you should be counting.
I think if you keep all those kinds of factors in mind you can get a sense of how "true" the numbers are and you do have some ability to fix places where it is counting incorrectly, but that can be a lot of work in environments like yours with tens of thousands of ports to sort out.
I dug a bit more into this and found the default UDT "Top XX Nodes by Percent Ports Used" only uses the last 24 hours to determine whether a port is used or unused by whether it had a link or not in that time frame. Not so useful in my environment, where we can't unpatch an unused cable unless it hasn't seen link in three months or more.
I'm reading the drop-down widget that can be added to an NPM view is more customizable:
A little more playing with it will reveal if I can get what I want from the customizable widget.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.