Комментарии 62
Страшно представить, о какой логической структуре сети может идти речь, если в любой момент нужно добавить 10 клиентских девайсов…
Поясню. Обычно порты на коммутаторе чётко привязаны к клиентским розеткам. И «переткнуть» какой-то кабель в другую розетку — нарушение схемы сети.
Появился новый сегмент — ставьте новый коммутатор. Иначе через полгодика стойка обрастёт паутиной.
Поясню. Обычно порты на коммутаторе чётко привязаны к клиентским розеткам. И «переткнуть» какой-то кабель в другую розетку — нарушение схемы сети.
Появился новый сегмент — ставьте новый коммутатор. Иначе через полгодика стойка обрастёт паутиной.
Увы, в условиях современного рынка большинство руководителей нацелены на максимальную экономию. Если стойка обросла паутиной — то это ваши проблемы, а сэкономленные несколько сотен баксов карман греют им. :)
И будет вот так:
Пробросить лишний кабель во время строительства или ремонта здания на порядок дешевле чем проводить дополнительный кабель в уже заселённом здании. Поэтому у нас разеток в 2-3 больше чем используется. С другой стороны, закупать в 2-3 раза больше коммутаторов дешевле никак не будет. Насчёт паутины: мы берём шкафы шириной 80 см (вместо 60), так как у них есть дополнительное место по сторонам, в котором удобно проводить кабеля. Ещё мы монтируем оборудование в шкафы следующим образом: несколько коммутационных панелей (скажем 4 по 24 порта), потом один коммутатор на 48 портов, потом опят несколько коммутационных нанелей и т.д. Такой монтаж отменяет нужду в длинных кабелях и тоже уменьшает паутину.
Плюс один к вопросу. В больших сетях наверняка есть СКС, а в СКС напрямую в свитч ничего не втыкается, все физические трэки должны быть разведены на патч панель, а другой конец патч-панели должен быть заведен на коммутатор, разве нет?
Жаль мои AlliedTelesis'ы не умеют отсылать логи:( А проблема то насущная.
Скорее всего, они умеют отсылать SNMP Trap-ы. Посмотрите, алгоритм будет немножко другой, но суть та же.
Если у коммутатора аптайм больше месяца, просто посмотрите счетчики пакетов.
А какой серии у вас олени?
Может вы просто не знаете?
Может вы просто не знаете?
хм, а что у вас за элаеды? у меня 8000-ники с рождения пишут в сислог на равне с цисками.
ну Вы сравнили… Cisco и AlliedTelesis'ы… не линксис даже… работал и с тем и стем :) линксис до сих пор без нареканий, алиед сдохли все что были :( даже компекс работали дольше :-(
Умеют, если управляемые. Команда logging
В ITIL есть такое понятие, как CMDB, а процесс называется Configuration Management, соответственно есть такая штука, как Change Request.
Спасибо. Статья полезная.
И хотя реализация совсем не сложная и понятная, но тут самое ценное — сама идеи, как проверить что можно рубить, а что нет.
И хотя реализация совсем не сложная и понятная, но тут самое ценное — сама идеи, как проверить что можно рубить, а что нет.
Добавте в должносные инструкции, что при «переезде» на друную резетку/комутатор нужно «обновить» настройки в серверной. Еще хорошим вариантом бывает использование блокировки порта, если комутатор такое поддерживает, или переброс порта в другой влан. Если комутатор не поддерживает влан — плохо.
Приходим, вынимаем несветящийся шнурок — ждем. Никто не звонит в течение 2-3 дней. Профит :)
Ну а на самом деле — проблема то есть, и спасибо за одно из решений! :)
Ну а на самом деле — проблема то есть, и спасибо за одно из решений! :)
Предотвратить ситуацию с наличием ненужных линков на коммутаторе гораздо проще — вести учет. Компьютера не стало — линк долой, порт дизаблить, в журнале записать.
2000 розеток, практически перманентный ремонт в здании с переездом работников из комнаты в комнату — админы усердно пишут-пишут-пишут. Нафиг такое счастье? )
А счастье парсить логи нафиг? У нас в поле полторы тысячи коммутаторов, два десятка тысяч абонентов. Я всегда знаю, на каком порту какого коммутатора сидит каждый абонент, его MAC и IP. Какие порты свободны, какие заняты аплинками и куда эти аплинки смотрят.
А если абонент отключился и уехал в отпуск на пару дней? Вернётся — будет ведь в сапорт звонить.
Возникла идея крепить к дверце вебкамеру и анализировать зеленые\желтые огоньки.
И написать софт для анализа видеострима с этой камеры для статистики
А протом продать это «решение» какой-нибудь госкорпорации за бешенные деньги с 50% отката в качестве а-ля «Анализ технического состояния ключевого узла инфраструктуры действующей локальной сети электронно-вычислительных машин и дальнейшей системы её мониторинга в реальном времени»
Перспективненько…
:)
Перспективненько…
:)
А чем не поставить камеру с минимальным ISO и максимальной выдержкой?
Решение конечно рабочее) Но об учете портов все же стоит подумать, чтобы не изобретать такие вот грабли =)
У нас за коммутаторами, да и не только за ними следит prtg, общение происходит по snmp
Судя по комментариям, у многих и дома кабель от провайдера сначала приходит в шкаф (обязательно 80см) в патчпанель, затем в маршрутизатор, в коммутатор, в розетку и только потом в компьютер.
В реальности в небольших организациях в регионах СКС выглядит так: на полу стоит сервер, рядом лежит маршрутизатор и коммутатор. Розетки ставились в разное время разными людьми по мере расширения организации, плана нет, до вас в фирме работало пять админов, каждый подключал рабочие места к коммутатору по своей, одному ему известной схеме. :)
В реальности в небольших организациях в регионах СКС выглядит так: на полу стоит сервер, рядом лежит маршрутизатор и коммутатор. Розетки ставились в разное время разными людьми по мере расширения организации, плана нет, до вас в фирме работало пять админов, каждый подключал рабочие места к коммутатору по своей, одному ему известной схеме. :)
Не в данном случае.
>все пользовательские коммутаторы были фирмы Cisco модели 3560
Не тот уровень.
>все пользовательские коммутаторы были фирмы Cisco модели 3560
Не тот уровень.
Дома тоже порядок нужен! У меня не патчпанель дома, а розетки двухпортовые, каждый порт подписан.
С сетями построенными «абы как, лишь бы работало» тоже опыт был, товарищу помогал навести порядок.
Взяли две рации, кабельный тестер, вынули ВСЕ патчкорды из патчпанелей/свитчей и пошли проверять все розетки, попутно записывая.
В итоге были найдены мертвые линки (по мере возможности поправили перезаделав в патчпанели/розетке), живые линки и все записаны в журнал коммутации.
Вобщем было бы желание.
С сетями построенными «абы как, лишь бы работало» тоже опыт был, товарищу помогал навести порядок.
Взяли две рации, кабельный тестер, вынули ВСЕ патчкорды из патчпанелей/свитчей и пошли проверять все розетки, попутно записывая.
В итоге были найдены мертвые линки (по мере возможности поправили перезаделав в патчпанели/розетке), живые линки и все записаны в журнал коммутации.
Вобщем было бы желание.
Вообще, даже если делать сеть на коленке, без затрат на СКС, всё равно можно хотя бы розетки пронумеровать и на концы проводов в шкафу соответствующие резиновые колечки с цифрами надеть. Потом просто пройтись по физическим розеткам и посмотреть, куда ничего не воткнуто.
Я думал, решение будет такое — поставить веб-камеру и фотографировать лампочки на коммутаторах. Далее, если лампочка ни разу за месяц не загорелась, то порт незанят. Основная проблема, что лампочки за паутиной могут быть и не видны. Но в темном помещении, каковым является серверная комната, можно отработать и по отраженному свету. Тогда веб-камеру нужно брать такую, чтобы светочувствительность ISO была побольше.
Как видно, скрипт выдал все порты, чей статус (активный / неактивный) менялся в течении последнего месяца. Но что делать, если какой либо из перечисленных выше портов был непрерывно активен всё это время и его статус не менялся? Подключаемся к нужному коммутатору, и выполняем следующую команду:
Ну уже бы дальше пошли бы. Выборку по down делали бы, и сравнивали поднимался ли порт, тогда бы и не надо было на кошку лезть, и делать sh int des | i down.
Довольно хорошая привычка шатдаунить порт когда из него выехал клиент.
есть еще один визуальный способ оценки свободных портов, это MRTG снимает информацию по пакетикам, а в час икс вы просто смотрите сводку граффиков за месяц по портам. Там где граффик пустой — свободный порт.
есть еще один визуальный способ оценки свободных портов, это MRTG снимает информацию по пакетикам, а в час икс вы просто смотрите сводку граффиков за месяц по портам. Там где граффик пустой — свободный порт.
не стал читать после фразы «В то время, все пользовательские коммутаторы были фирмы Cisco...»:) не знаю почему :) люблю Cisco наверное ))))) Р.S.: не сарказм
Голь на выдумки хитра!
У нас около 3000 пользовательских портов.
Стоят Cisco 3560 и 3550.
Имеем два способа решения вашей проблемы:
1) В CiscoWorks LMS есть такой функционал как UserTracking — полезнейшая вещь при сопровождении такой большой кампусной сети.
Ведёт учёт по MAC-IP всех подключаемых девайсов, с указанием коммутатора, порта и времени, когда этот девайс на этом порту последний раз появлялся.
Хотя мы этот функционал используем обычно при переездах пользователей — переехал юзер с места на место и попал в чужой vlan. А какой у него раньше был — он сам-то не знает. Вот тут UT и выручает — MAC этого пользователя будет в базе UT дважды на его старом рабочем месте и на новом. Сразу видно — когда, куда и откуда он переехал. Ну ооочень удобно!
2) Ну а вообще мы это делаем так:
Те порты, на которых нули — давно не используются. На сколько давно?
Это я 3 секунды назад его поклирил командой
Т.е. с момента последней зачистки каунтеров порт имеющий 0 во всех каунтерах явно ни разу не использовался.
Соответственно что бы нормально этим пользоваться нужно иметь привычку каждый раз когда заходишь на железку по завершению всех своих работ клирить каунтеры. Если заходишь туда не чаше раза в месяц, то схема вполне рабочая.
Повторюсь мы пользуемся преимущественно именно ей. Только в сложных случаях лезем в UT.
У нас около 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.
Ну не совсем голь — у нас тоже есть лицензия на CiscoWorks, но у меня о нём мнение не очень. На бумаге он выглядит круто, а на самом деле — тратит больше времени чем экономит, поэтому мы полагаемся на другие инструменты. Настроить syslog — минуты, настроить коммутаторы на отправку сообщений на него — примерно минуту на каждый коммутатор (у нас их около 30), написать скриптик на баше в одну строчку для анализа логов — тоже несколько минут, включая проверки. И того, меньше чем за час всё работает. А установка и настройка CiscoWorks берёт на много дольше, просто не сопоставимо — за один час результатов вообще никаких не будет.
Насчёт UserTracking — у нас многие пользователи часто разъезжают по разным зданиям и филиалам (встречи, тренинги и т.д.), так что ихний MAC можно увидеть просто где угодно. Кроме того, приезжают гости из других стран со своими MAC-ами.
А насчёт Вашего подхода (sh int counters и т.д.): если коммутатор перезагрузится то счётчики обнуляются. Кроме того, требуется что-то помнить и иметь какие-то привычки, а так как все люди, то могут быть ошибки и тогда этот подход выдаст неверный результат. А для анализа логов + sh int | i down помнить вообще ничего не надо (кроме как один раз настроить отправку сообщений в syslog), и результат всегда будет правильный.
Насчёт UserTracking — у нас многие пользователи часто разъезжают по разным зданиям и филиалам (встречи, тренинги и т.д.), так что ихний MAC можно увидеть просто где угодно. Кроме того, приезжают гости из других стран со своими MAC-ами.
А насчёт Вашего подхода (sh int counters и т.д.): если коммутатор перезагрузится то счётчики обнуляются. Кроме того, требуется что-то помнить и иметь какие-то привычки, а так как все люди, то могут быть ошибки и тогда этот подход выдаст неверный результат. А для анализа логов + sh int | i down помнить вообще ничего не надо (кроме как один раз настроить отправку сообщений в syslog), и результат всегда будет правильный.
1) CiscoWorks конфигурится раз и на всегда.
У нас суммарно около 1000 устройств, и CiscoWorks более чем актуален. Во многом он всё же значительно облегчает жизнь, плюс аналогов функционала UT я вообще нигде больше не видел.
CiscoWorks 2.6 у нас несколько лет работал, после первичной настройки, вот только недавно решили переходить на 4-ку.
2) А у вас часто перезагружаются коммутаторы?
У нас не чаще раза в год и то как правило по причинам обновления ПО.
3) На счёт «что-то помнить» я с вами согласен, но повторюсь — это работает. В реальной сети, на живом железе и с живыми админами =). Так что это не теоретические умозаключения, а практический опыт.
Как правило стоит задача — какие порты свободны? Задачу обычно по телефону ставит админ\СКС-ник который стоит возле стойки и хочет получить ответ. Вывод команды
сходу позволяет назвать порты, которыми можно воспользоваться.
А дальше идёт детализация:
— сколько порт не используется можно посмотреть по выводу
У нас суммарно около 1000 устройств, и CiscoWorks более чем актуален. Во многом он всё же значительно облегчает жизнь, плюс аналогов функционала UT я вообще нигде больше не видел.
CiscoWorks 2.6 у нас несколько лет работал, после первичной настройки, вот только недавно решили переходить на 4-ку.
2) А у вас часто перезагружаются коммутаторы?
У нас не чаще раза в год и то как правило по причинам обновления ПО.
3) На счёт «что-то помнить» я с вами согласен, но повторюсь — это работает. В реальной сети, на живом железе и с живыми админами =). Так что это не теоретические умозаключения, а практический опыт.
Как правило стоит задача — какие порты свободны? Задачу обычно по телефону ставит админ\СКС-ник который стоит возле стойки и хочет получить ответ. Вывод команды
sh int countersсходу позволяет назвать порты, которыми можно воспользоваться.
А дальше идёт детализация:
— сколько порт не используется можно посмотреть по выводу
Вы правы — если подход работает — значит это то что надо в данном случае. Наверное зависит от контингента, а то у нас кое-какие нелады с дисциплиной, поэтому и нужны 100% foolproof решения. А насчёт перезагрузок коммутаторов, то у нас это тоже происходит редко, но бывают и нештатные ситуации, например когда UPS выходит из строя или происходит какая нибудь периодическая проверка электрических систем. И даже если перезапускать коммутаторы всего один раз в год, то после перезапуска уйдёт месяц на сбор новой статистики, а значит решение sh int counters будет работать только 11 месяцев в году.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как узнать какие порты на коммутаторах уже не используются