Как узнать какие порты на коммутаторах уже не используются

Чуть больше года назад столкнулся с проблемой, знакомой, наверное, каждому админу: в одном из коммуникационных шкафов закончились почти все свободные порты. Визуально было видно, что почти к каждому порту подключён кабель, свободных осталось только один-два порта, а требовалось подключить около десяти новых девайсов.

Мне было чётко ясно, что на самом деле используются не все порты: какие-то, скорее всего, подключали временно, а затем забыли отключить, сетевые принтеры могли переместить и подключить к другому коммутатору, часть портов были подключены для пользователей, за время сменивших свои кабинеты, и т.д.

Отключение неактивных портов было неприемлемо, так как то, что какой-то порт в данный момент не активен, не говорит о том, что он не использовался 10 минут назад, а пользователь просто отключил свой компьютер, и, скажем, уехал на встречу.

В то время, все пользовательские коммутаторы были фирмы Cisco модели 3560, имевшие 100Mbps-порты для пользователей и гнёзда SFP для быстрого канала к концентрирующим коммутаторам, так что тратить как минимум $2500 на дополнительный коммутатор, когда уверен, что на самом деле это совсем необязательно, просто рука не поднималась.

Задача


Узнать, какие порты на коммутаторах не использовались в течении последнего месяца.

Решение


Все коммутаторы были настроены отсылать свои сообщения на центральный syslog сервер. В моём примере использовался Syslog-NG на Arch Linux, но, естественно, можно использовать любое другое syslog-решение и/или дистрибутив Линукса. Для ротации логов использовался logrotate и логи старее одного месяца стирались. Также насчёт коммутаторов: я полагаю, что на любом управляемом коммутаторе можно настроить отправку сообщений на удалённый syslog-сервер – кроме Cisco, у меня опыт только с Nortel и HP – насколько я помню, они тоже поддерживают эту функцию.

Принцип работы

Коммутаторы Cisco по умолчанию генерируют сообщения во время активации и деактивации портов, а так как все коммутаторы были настроены отсылать сообщения на центральный syslog сервер, то все, что оставалось, это проанализировать файлы, хранящие сообщения от коммутаторов. Напомню, что на сервере был настроен logrotate, так что сообщения не хранились больше одного месяца. Думаю, что можно смело предположить что порт, не используемый в течение месяца, скорее всего больше не нужен, и его можно использовать под другие нужды.

Примеры настроек

Настроить коммутатор Cisco для отправки сообщений на удалённый syslog-сервер очень просто, следует перейти в режим конфигурирования (configure terminal) и внести всего одну команду:

logging 10.20.100.12

(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:

#!/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


Пример использования

# ./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


Как видно, скрипт выдал все порты, чей статус (активный / неактивный) менялся в течении последнего месяца. Но что делать, если какой либо из перечисленных выше портов был непрерывно активен всё это время и его статус не менялся? Подключаемся к нужному коммутатору, и выполняем следующую команду:

show interface description | include down

Эта команда выводит список всех неактивных портов. Если порт неактивен, и его статус не менялся в течении последнего месяца, значит ему можно искать другое применение.

Дополнение

Данное решение отлично работает с отдельными коммутаторами, у которых все пользовательские порты 100Mbps. Но вскоре мы начали добавлять новые коммутаторы моделей 2975 и 2960, производимые всё той же Cisco. Все порты у них гигабитные, а так же они оснащены стековыми модулями, позволяющими объединять несколько коммутаторов в одну управляемую единицу, а это приводило к изменению наименования портов, так как учитывался не только номер порта, но и номер коммутатора в стеке.

Вот модифицированная реализация

#!/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


Заключение


Описанное решение успешно работает в нашей организации уже больше года, без каких-либо модификаций. Его плюсы это низкая цена (в нашем случае совсем бесплатно, так как syslog сервер уже был), лёгкая настройка (в нашем случае настройка не потребовалась, так как все коммутаторы уже были настроены на отсылку сообщений на удалённый syslog сервер) и очень простое использование. Это решение сэкономило нам покупку дополнительных коммутаторов, в которых на самом деле не было надобности и помогает в планировании нашей сети, ведь теперь мы в любой момент можем узнать количество свободных портов на любом коммутаторе, что позволяет вовремя подготавливаться к нуждам растущей организации.

Надеюсь, эта статья будет кому-нибудь полезна.

Желаю удачи!
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 62

    +1
    Страшно представить, о какой логической структуре сети может идти речь, если в любой момент нужно добавить 10 клиентских девайсов…

    Поясню. Обычно порты на коммутаторе чётко привязаны к клиентским розеткам. И «переткнуть» какой-то кабель в другую розетку — нарушение схемы сети.

    Появился новый сегмент — ставьте новый коммутатор. Иначе через полгодика стойка обрастёт паутиной.
      +1
      Увы, в условиях современного рынка большинство руководителей нацелены на максимальную экономию. Если стойка обросла паутиной — то это ваши проблемы, а сэкономленные несколько сотен баксов карман греют им. :)
        +5
        И будет вот так:

        image
          +1
          Пробросить лишний кабель во время строительства или ремонта здания на порядок дешевле чем проводить дополнительный кабель в уже заселённом здании. Поэтому у нас разеток в 2-3 больше чем используется. С другой стороны, закупать в 2-3 раза больше коммутаторов дешевле никак не будет. Насчёт паутины: мы берём шкафы шириной 80 см (вместо 60), так как у них есть дополнительное место по сторонам, в котором удобно проводить кабеля. Ещё мы монтируем оборудование в шкафы следующим образом: несколько коммутационных панелей (скажем 4 по 24 порта), потом один коммутатор на 48 портов, потом опят несколько коммутационных нанелей и т.д. Такой монтаж отменяет нужду в длинных кабелях и тоже уменьшает паутину.
            0
            Плюс один к вопросу. В больших сетях наверняка есть СКС, а в СКС напрямую в свитч ничего не втыкается, все физические трэки должны быть разведены на патч панель, а другой конец патч-панели должен быть заведен на коммутатор, разве нет?
              +1
              в теории так ))) в реальности — далеко не так ))))
          0
          Жаль мои AlliedTelesis'ы не умеют отсылать логи:( А проблема то насущная.
            +2
            Скорее всего, они умеют отсылать SNMP Trap-ы. Посмотрите, алгоритм будет немножко другой, но суть та же.
              0
              Если у коммутатора аптайм больше месяца, просто посмотрите счетчики пакетов.
                0
                А какой серии у вас олени?
                Может вы просто не знаете?
                  0
                  хм, а что у вас за элаеды? у меня 8000-ники с рождения пишут в сислог на равне с цисками.
                    0
                    Да видимо я ошибся. AlliedTelesis'ы у меня разные, а те к которым интересно прикрутить логи 8350.
                    –2
                    ну Вы сравнили… Cisco и AlliedTelesis'ы… не линксис даже… работал и с тем и стем :) линксис до сих пор без нареканий, алиед сдохли все что были :( даже компекс работали дольше :-(
                      0
                      К работе Telesis'ов нареканий в принципе нет. Жирный минус, по миому, у них только один, у каждой железки свой cli. Хотя я уже и с эти свыкся:)
                      +1
                      Умеют, если управляемые. Команда logging
                      +1
                      В ITIL есть такое понятие, как CMDB, а процесс называется Configuration Management, соответственно есть такая штука, как Change Request.
                        0
                        Спасибо. Статья полезная.
                        И хотя реализация совсем не сложная и понятная, но тут самое ценное — сама идеи, как проверить что можно рубить, а что нет.
                          +1
                          Добавте в должносные инструкции, что при «переезде» на друную резетку/комутатор нужно «обновить» настройки в серверной. Еще хорошим вариантом бывает использование блокировки порта, если комутатор такое поддерживает, или переброс порта в другой влан. Если комутатор не поддерживает влан — плохо.
                            0
                            У наших в сапорте не всё в порядке с дисциплиной — сделают что-то не по инструкции, а потом море отмазок (не знал, не понял, это временное решение, торопился и т.д.). А мне главное результат, что это решение и даёт.
                            +6
                            Приходим, вынимаем несветящийся шнурок — ждем. Никто не звонит в течение 2-3 дней. Профит :)
                            Ну а на самом деле — проблема то есть, и спасибо за одно из решений! :)
                              0
                              первая мысль была ))) а если их много? ))
                                0
                                так а куда спешить? :) Понемногу… по-одному…
                                  0
                                  Так и вижу как админ стоит такой с троллофейсом и гыгыканьем вынимает по одному патчику из свитча.
                                0
                                Особенно признательны вам будут те сотрудники, которые в это время будут в отпуске.
                                  0
                                  я не писал, что это универсальный метод… так один из сотни :)
                                +2
                                Предотвратить ситуацию с наличием ненужных линков на коммутаторе гораздо проще — вести учет. Компьютера не стало — линк долой, порт дизаблить, в журнале записать.
                                  +1
                                  2000 розеток, практически перманентный ремонт в здании с переездом работников из комнаты в комнату — админы усердно пишут-пишут-пишут. Нафиг такое счастье? )
                                    +2
                                    А счастье парсить логи нафиг? У нас в поле полторы тысячи коммутаторов, два десятка тысяч абонентов. Я всегда знаю, на каком порту какого коммутатора сидит каждый абонент, его MAC и IP. Какие порты свободны, какие заняты аплинками и куда эти аплинки смотрят.
                                      0
                                      А если абонент отключился и уехал в отпуск на пару дней? Вернётся — будет ведь в сапорт звонить.
                                        0
                                        Порт зарезервирован за абонентом, пока не поступило заявление на отключение или пока не прошло полгода с последнего платежа. Во втором случае абонент выдается предупреждение, что абонент не пользуется более полугода.
                                          –1
                                          а разве про провайдеров статья?
                                            +1
                                            А разве только провайдерам надо знать, что куда подключено?
                                  +4
                                  Возникла идея крепить к дверце вебкамеру и анализировать зеленые\желтые огоньки.
                                    +2
                                    И написать софт для анализа видеострима с этой камеры для статистики
                                      +2
                                      А протом продать это «решение» какой-нибудь госкорпорации за бешенные деньги с 50% отката в качестве а-ля «Анализ технического состояния ключевого узла инфраструктуры действующей локальной сети электронно-вычислительных машин и дальнейшей системы её мониторинга в реальном времени»
                                      Перспективненько…


                                      :)
                                        0
                                        Чёрд! скушлася тэг irony
                                          0
                                          Тут нет такого тега :-(
                                            0
                                            Есть
                                              0
                                              Спасибо, но [irony][/irony] не работают
                                                0
                                                <irony>
                                                    Работают же!
                                                </irony>
                                                0
                                                курсив, курсив сожрался! :)
                                        0
                                        А чем не поставить камеру с минимальным ISO и максимальной выдержкой?
                                        +2
                                        Решение конечно рабочее) Но об учете портов все же стоит подумать, чтобы не изобретать такие вот грабли =)
                                          0
                                          У нас за коммутаторами, да и не только за ними следит prtg, общение происходит по snmp
                                            +2
                                            Судя по комментариям, у многих и дома кабель от провайдера сначала приходит в шкаф (обязательно 80см) в патчпанель, затем в маршрутизатор, в коммутатор, в розетку и только потом в компьютер.

                                            В реальности в небольших организациях в регионах СКС выглядит так: на полу стоит сервер, рядом лежит маршрутизатор и коммутатор. Розетки ставились в разное время разными людьми по мере расширения организации, плана нет, до вас в фирме работало пять админов, каждый подключал рабочие места к коммутатору по своей, одному ему известной схеме. :)
                                              0
                                              Не в данном случае.
                                              >все пользовательские коммутаторы были фирмы Cisco модели 3560
                                              Не тот уровень.
                                                0
                                                Согласен, но я про комментаторов говорил. Сеть автора явно делалась не по принципу «главное чтоб работало».
                                                  0
                                                  У меня, например, кабель на розетку приходит. Патчкорд до роутера, патчкорды до компа и плеера, WiFi до ноутов.
                                                +1
                                                Дома тоже порядок нужен! У меня не патчпанель дома, а розетки двухпортовые, каждый порт подписан.

                                                С сетями построенными «абы как, лишь бы работало» тоже опыт был, товарищу помогал навести порядок.
                                                Взяли две рации, кабельный тестер, вынули ВСЕ патчкорды из патчпанелей/свитчей и пошли проверять все розетки, попутно записывая.

                                                В итоге были найдены мертвые линки (по мере возможности поправили перезаделав в патчпанели/розетке), живые линки и все записаны в журнал коммутации.

                                                Вобщем было бы желание.
                                                +1
                                                Вообще, даже если делать сеть на коленке, без затрат на СКС, всё равно можно хотя бы розетки пронумеровать и на концы проводов в шкафу соответствующие резиновые колечки с цифрами надеть. Потом просто пройтись по физическим розеткам и посмотреть, куда ничего не воткнуто.
                                                  0
                                                  Вы серьёзно? А если розеток несколько тысяч и не все находятся в легко доступных местах? Плюс иногда стены сносятся, а с ними и розетки.
                                                    0
                                                    Нет, что Вы, я шучу. В один свитч у вас не несколько тысяч розеток входит, а 48. Вам не все тысячи розеток надо искать, а всего лишь 48 в худшем случае. По поводу недоступных возразить нечего, Вы правы.
                                                  –2
                                                  Я думал, решение будет такое — поставить веб-камеру и фотографировать лампочки на коммутаторах. Далее, если лампочка ни разу за месяц не загорелась, то порт незанят. Основная проблема, что лампочки за паутиной могут быть и не видны. Но в темном помещении, каковым является серверная комната, можно отработать и по отраженному свету. Тогда веб-камеру нужно брать такую, чтобы светочувствительность ISO была побольше.
                                                    0
                                                    А что правда это сообщение никого не улыбнуло? :) Оно универсальное и вендор-независимое.
                                                    Вопрос по теме...show logging всегда показывает информацию о линках или это нужно дополнительно включать в настройках коммутатора?
                                                    0
                                                    Как видно, скрипт выдал все порты, чей статус (активный / неактивный) менялся в течении последнего месяца. Но что делать, если какой либо из перечисленных выше портов был непрерывно активен всё это время и его статус не менялся? Подключаемся к нужному коммутатору, и выполняем следующую команду:

                                                    Ну уже бы дальше пошли бы. Выборку по down делали бы, и сравнивали поднимался ли порт, тогда бы и не надо было на кошку лезть, и делать sh int des | i down.
                                                      0
                                                      Довольно хорошая привычка шатдаунить порт когда из него выехал клиент.

                                                      есть еще один визуальный способ оценки свободных портов, это MRTG снимает информацию по пакетикам, а в час икс вы просто смотрите сводку граффиков за месяц по портам. Там где граффик пустой — свободный порт.
                                                        0
                                                        не стал читать после фразы «В то время, все пользовательские коммутаторы были фирмы Cisco...»:) не знаю почему :) люблю Cisco наверное ))))) Р.S.: не сарказм
                                                          0
                                                          Голь на выдумки хитра!

                                                          У нас около 3000 пользовательских портов.
                                                          Стоят Cisco 3560 и 3550.
                                                          Имеем два способа решения вашей проблемы:

                                                          1) В CiscoWorks LMS есть такой функционал как UserTracking — полезнейшая вещь при сопровождении такой большой кампусной сети.
                                                          Ведёт учёт по MAC-IP всех подключаемых девайсов, с указанием коммутатора, порта и времени, когда этот девайс на этом порту последний раз появлялся.
                                                          Хотя мы этот функционал используем обычно при переездах пользователей — переехал юзер с места на место и попал в чужой vlan. А какой у него раньше был — он сам-то не знает. Вот тут UT и выручает — MAC этого пользователя будет в базе UT дважды на его старом рабочем месте и на новом. Сразу видно — когда, куда и откуда он переехал. Ну ооочень удобно!

                                                          2) Ну а вообще мы это делаем так:
                                                          sh int counters
                                                          Те порты, на которых нули — давно не используются. На сколько давно?
                                                          sh int fa 0/1 | in count
                                                             Last clearing of "show interface" counters 00:00:03

                                                          Это я 3 секунды назад его поклирил командой
                                                          clear counters fa 0/1

                                                          Т.е. с момента последней зачистки каунтеров порт имеющий 0 во всех каунтерах явно ни разу не использовался.

                                                          Соответственно что бы нормально этим пользоваться нужно иметь привычку каждый раз когда заходишь на железку по завершению всех своих работ клирить каунтеры. Если заходишь туда не чаше раза в месяц, то схема вполне рабочая.
                                                          Повторюсь мы пользуемся преимущественно именно ей. Только в сложных случаях лезем в UT.
                                                            0
                                                            Ну не совсем голь — у нас тоже есть лицензия на CiscoWorks, но у меня о нём мнение не очень. На бумаге он выглядит круто, а на самом деле — тратит больше времени чем экономит, поэтому мы полагаемся на другие инструменты. Настроить syslog — минуты, настроить коммутаторы на отправку сообщений на него — примерно минуту на каждый коммутатор (у нас их около 30), написать скриптик на баше в одну строчку для анализа логов — тоже несколько минут, включая проверки. И того, меньше чем за час всё работает. А установка и настройка CiscoWorks берёт на много дольше, просто не сопоставимо — за один час результатов вообще никаких не будет.
                                                            Насчёт UserTracking — у нас многие пользователи часто разъезжают по разным зданиям и филиалам (встречи, тренинги и т.д.), так что ихний MAC можно увидеть просто где угодно. Кроме того, приезжают гости из других стран со своими MAC-ами.
                                                            А насчёт Вашего подхода (sh int counters и т.д.): если коммутатор перезагрузится то счётчики обнуляются. Кроме того, требуется что-то помнить и иметь какие-то привычки, а так как все люди, то могут быть ошибки и тогда этот подход выдаст неверный результат. А для анализа логов + sh int | i down помнить вообще ничего не надо (кроме как один раз настроить отправку сообщений в syslog), и результат всегда будет правильный.
                                                              0
                                                              1) CiscoWorks конфигурится раз и на всегда.
                                                              У нас суммарно около 1000 устройств, и CiscoWorks более чем актуален. Во многом он всё же значительно облегчает жизнь, плюс аналогов функционала UT я вообще нигде больше не видел.
                                                              CiscoWorks 2.6 у нас несколько лет работал, после первичной настройки, вот только недавно решили переходить на 4-ку.

                                                              2) А у вас часто перезагружаются коммутаторы?
                                                              У нас не чаще раза в год и то как правило по причинам обновления ПО.

                                                              3) На счёт «что-то помнить» я с вами согласен, но повторюсь — это работает. В реальной сети, на живом железе и с живыми админами =). Так что это не теоретические умозаключения, а практический опыт.
                                                              Как правило стоит задача — какие порты свободны? Задачу обычно по телефону ставит админ\СКС-ник который стоит возле стойки и хочет получить ответ. Вывод команды
                                                              sh int counters
                                                              сходу позволяет назвать порты, которыми можно воспользоваться.
                                                              А дальше идёт детализация:
                                                              — сколько порт не используется можно посмотреть по выводу
                                                                0
                                                                Вы правы — если подход работает — значит это то что надо в данном случае. Наверное зависит от контингента, а то у нас кое-какие нелады с дисциплиной, поэтому и нужны 100% foolproof решения. А насчёт перезагрузок коммутаторов, то у нас это тоже происходит редко, но бывают и нештатные ситуации, например когда UPS выходит из строя или происходит какая нибудь периодическая проверка электрических систем. И даже если перезапускать коммутаторы всего один раз в год, то после перезапуска уйдёт месяц на сбор новой статистики, а значит решение sh int counters будет работать только 11 месяцев в году.

                                                          Only users with full accounts can post comments. Log in, please.