Как узнать какие порты на коммутаторах Cisco уже не используются
Чуть больше года назад столкнулся с проблемой, знакомой, наверное, каждому админу: в одном из коммуникационных шкафов закончились почти все свободные порты. Визуально было видно, что почти к каждому порту подключён кабель, свободных осталось только один-два порта, а требовалось подключить около десяти новых девайсов.
Мне было чётко ясно, что на самом деле используются не все порты: какие-то, скорее всего, подключали временно, а затем забыли отключить, сетевые принтеры могли переместить и подключить к другому коммутатору, часть портов были подключены для пользователей, за время сменивших свои кабинеты, и т.д.
Отключение неактивных портов было неприемлемо, так как то, что какой-то порт в данный момент не активен, не говорит о том, что он не использовался 10 минут назад, а пользователь просто отключил свой компьютер, и, скажем, уехал на встречу.
В то время, все пользовательские коммутаторы были фирмы Cisco модели 3560, имевшие 100Mbps-порты для пользователей и гнёзда SFP для быстрого канала к концентрирующим коммутаторам, так что тратить как минимум $2500 на дополнительный коммутатор, когда уверен, что на самом деле это совсем необязательно, просто рука не поднималась.
Задача
Узнать, какие порты на коммутаторах не использовались в течении последнего месяца.
Решение
Все коммутаторы были настроены отсылать свои сообщения на центральный syslog сервер. В моём примере использовался Syslog-NG на Arch Linux, но, естественно, можно использовать любое другое syslog-решение и/или дистрибутив Линукса. Для ротации логов использовался logrotate и логи старее одного месяца стирались. Также насчёт коммутаторов: я полагаю, что на любом управляемом коммутаторе можно настроить отправку сообщений на удалённый syslog-сервер – кроме Cisco, у меня опыт только с Nortel и HP – насколько я помню, они тоже поддерживают эту функцию.
Принцип работы
Коммутаторы Cisco по умолчанию генерируют сообщения во время активации и деактивации портов, а так как все коммутаторы были настроены отсылать сообщения на центральный syslog сервер, то все, что оставалось, это проанализировать файлы, хранящие сообщения от коммутаторов. Напомню, что на сервере был настроен logrotate, так что сообщения не хранились больше одного месяца. Думаю, что можно смело предположить что порт, не используемый в течение месяца, скорее всего больше не нужен, и его можно использовать под другие нужды.
Примеры настроек
Настроить коммутатор Cisco для отправки сообщений на удалённый syslog-сервер очень просто, следует перейти в режим конфигурирования (configure terminal) и внести всего одну команду:
где 10.20.100.12 – адрес syslog сервераВот строки из syslog-ng.conf отвечающие за приём сообщений по сети:
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); };
Как видно из примера, только сообщения из определённых подсетей помещаются в /var/log/remote/switches.log. Сделано это для того, чтоб сообщения от разного оборудования не перемешивались в кашу в одном лог файле. Я предпочитаю, чтоб сообщения от разного по функционалу оборудования помещаются в разные файлы: пользовательские коммутаторы отдельно, концентрирующие коммутаторы отдельно, роутеры отдельно, системы хранения данных отдельно и т.д. В данном примере 10.20.120.0/24 и 10.30.120.0/24 это сегменты сети, в которых расположены служебные IP адреса пользовательских коммутаторов.
Каждый раз, когда к порту коммутатора подключается оборудование, всплывает подобного рода сообщение:
Apr 27 16:38:44 switch1 330827: Apr 27 15:39:27.317: %LINK-3-UPDOWN: Interface FastEthernet0/4, changed state to up
А вот пример сообщения в случае отключения оборудования:
Apr 27 16:38:53 switch1 330830: Apr 27 15:39:37.635: %LINK-3-UPDOWN: Interface FastEthernet0/4, changed state to down
Вот алгоритм анализа лог файлов:
1. Выбрать только сообщения, исходящие от определённого коммутатора
2. Выбрать только сообщения, включающие строку LINK-3-UPDOWN
3. Отрезать не нужные части строк (время, название коммутатора и т.д.), оставив только название порта и его номер.
4. Выбрать только сообщения, включающие строку FastEthernet (в моём случае все пользовательские порты были 100Mbps, гигабитными были только подключения к концентрирующим коммутаторам).
5. Отрезать всё, кроме номера порта.
6. Отсортировать.
7. Оставить только уникальные строки.
Реализация на 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
Пример использования
Как видно, скрипт выдал все порты, чей статус (активный / неактивный) менялся в течении последнего месяца.
Но что делать, если какой либо из перечисленных выше портов был непрерывно активен всё это время и его статус не менялся?
Подключаемся к нужному коммутатору, и выполняем следующую команду:
Эта команда выводит список всех неактивных портов. Если порт неактивен, и его статус не менялся в течении последнего месяца, значит ему можно искать другое применение.
Дополнение
Данное решение отлично работает с отдельными коммутаторами, у которых все пользовательские порты 100Mbps. Но вскоре мы начали добавлять новые коммутаторы моделей 2975 и 2960, производимые всё той же Cisco. Все порты у них гигабитные, а так же они оснащены стековыми модулями, позволяющими объединять несколько коммутаторов в одну управляемую единицу, а это приводило к изменению наименования портов, так как учитывался не только номер порта, но и номер коммутатора в стеке.
Вот модифицированная реализация:
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
Заключение
Описанное решение успешно работает в нашей организации уже больше года, без каких-либо модификаций. Его плюсы это низкая цена (в нашем случае совсем бесплатно, так как syslog сервер уже был), лёгкая настройка (в нашем случае настройка не потребовалась, так как все коммутаторы уже были настроены на отсылку сообщений на удалённый syslog сервер) и очень простое использование. Это решение сэкономило нам покупку дополнительных коммутаторов, в которых на самом деле не было надобности и помогает в планировании нашей сети, ведь теперь мы в любой момент можем узнать количество свободных портов на любом коммутаторе, что позволяет вовремя подготавливаться к нуждам растущей организации.