How to find out which ports on the switches are no longer used

A little more than a year ago I ran into a problem familiar to every admin, probably: almost all the free ports ended in one of the communication cabinets. Visually, it was obvious that almost every port had a cable connected, only one or two ports remained free, and about ten new devices were required to be connected.

It was clearly clear to me that not all ports were actually used: some of them were most likely connected temporarily and then forgot to disconnect, network printers could be moved and connected to another switch, some of the ports were connected for users who changed their cabinets, etc.

Disabling inactive ports was unacceptable, since the fact that a port is not active at the moment does not mean that it was not used 10 minutes ago, and the user simply turned off his computer, and, say, left for a meeting.

At that time, all user switches were Cisco models 3560, which had 100Mbps ports for users and SFP jacks for a fast channel to concentrating switches, so spend at least $ 2500 on an additional switch when I’m sure that this is not really necessary. just did not raise a hand.
')

Task

Find out which ports on the switches were not used during the last month.

Decision

All switches were configured to send their messages to a central syslog server. In my example, we used Syslog-NG on Arch Linux, but, of course, you can use any other syslog solution and / or Linux distribution. Logrotate was used to rotate logs and logs older than one month were erased. Also about switches: I suppose that on any managed switch you can configure sending messages to a remote syslog server - except Cisco, I have experience only with Nortel and HP - as I recall, they also support this feature.

Principle of operation

Cisco switches by default generate messages during activation and deactivation of ports, and since all switches were configured to send messages to a central syslog server, all that was left was to analyze the files that store messages from the switches. Let me remind you that the server was configured logrotate, so that messages were not stored for more than one month. I think that we can safely assume that the port, which is not used during the month, most likely is no longer needed, and it can be used for other needs.

Settings Examples

Configuring a Cisco switch to send messages to a remote syslog server is very simple; you should go to the configure terminal and enter just one command:

logging 10.20.100.12

(10.20.100.12 - address of the syslog server)

Here are the lines from syslog-ng.conf responsible for receiving messages over the network:

source remote_udp {
udp();
};

destination d_switches { file("/var/log/remote/switches.log"); };

filter f_switches { netmask("10.20.120.0/255.255.255.0") or netmask("10.30.120.0/255.255.255.0"); };

log { source(remote_udp); filter(f_switches); destination(d_switches); };

As you can see from the example, only messages from certain subnets are placed in /var/log/remote/switches.log. This is done to ensure that messages from different equipment are not mixed into a mess in a single log file. I prefer that the messages from equipment with different functionalities are placed in different files: user switches separately, concentrating switches separately, routers separately, data storage systems separately, etc. In this example, 10.20.120.0/24 and 10.30.120.0/24 are the network segments in which the service IP addresses of the user switches are located.

Every time the equipment is connected to the switch port, a similar message pops up:

Apr 27 16:38:44 switch1 330827: Apr 27 15:39:27.317: %LINK-3-UPDOWN: Interface FastEthernet0/4, changed state to up

Here is an example of a message in case of equipment shutdown:

Apr 27 16:38:53 switch1 330830: Apr 27 15:39:37.635: %LINK-3-UPDOWN: Interface FastEthernet0/4, changed state to down

Here is the algorithm for analyzing log files:

1. Select only messages originating from a specific switch.
2. Select only messages that include the string “LINK-3-UPDOWN”
3. Cut the unnecessary parts of the lines (time, name of the switch, etc.), leaving only the name of the port and its number
4. Select only messages that include the “FastEthernet” line (in my case, all user ports were 100Mbps, only connections to concentrating switches were gigabit)
5. Cut everything except the port number
6. Sort
7. Keep only unique strings.

Implementation on bash:

#!/bin/bash

cat /var/log/remote/switches.log* | grep $1 | grep LINK-3-UPDOWN | cut -d ':' -f 8 | cut -d ' ' -f 3 | grep FastEthernet | cut -d '/' -f 2 | cut -d ',' -f 1 | sort -n | uniq

Usage example

# ./usedports.sh switch1
1
3
4
5
6
8
9
10
11
12
13
14
15
17
23
24
25
29
38
39
41
43

As you can see, the script issued all ports, whose status (active / inactive) has changed during the last month. But what to do if any of the above ports has been continuously active all this time and its status has not changed? Connect to the correct switch, and execute the following command:

show interface description | include down

This command lists all inactive ports. If the port is inactive, and its status has not changed during the last month, it means that it can look for another use.

Addition

This solution works fine with individual switches that have all user ports of 100Mbps. But soon we began to add new switches models 2975 and 2960, produced by the same Cisco. They all have Gigabit ports, as well as they are equipped with stack modules that allow you to combine several switches into one managed unit, and this led to a change in the name of the ports, since not only the port number, but the number of the switch in the stack was taken into account.

Here is a modified implementation.

#!/bin/bash

cat /var/log/remote/switches.log* | grep $1 | grep LINK-3-UPDOWN | cut -d ':' -f 8 | cut -d ' ' -f 3 | grep GigabitEthernet | cut -d 't' -f 4 | cut -d ',' -f 1 | sort -t '/' -k 1,1n -k 3,3n | uniq

Conclusion

The described solution has been successfully working in our organization for more than a year, without any modifications. Its advantages are low price (in our case, absolutely free, since the syslog server already existed), easy setup (in our case, no configuration was required, since all the switches were already configured to send messages to the remote syslog server) and very simple use. This decision has saved us the purchase of additional switches, which actually did not need and helps in planning our network, because now we can find out the number of free ports on any switch at any time, which allows us to prepare in time for the needs of a growing organization.

I hope this article will be useful to someone.

Good luck!