Cisco Catalyst тестирование длины кабеля, поиск обрыва
Сегодня обойдёмся без фотографий. И так, в жизни каждого администратора наступает момент когда необходимо найти обрыв кабеля или проверить работу аникейщика, которого пригласили в удалённый офис. Вот и сейчас пришлось выкручиваться в ситуации когда «стоишь на асфальте в лыжи обутый...» Приглашенный аникей говорит, что вставил в нужный порт нужный патчкорд, а ничего не работает и грешит на «глюки» железа или настроек. И так, немного предыстории. Так как на объекте используются коммутаторы Cisco Catalyst 2960 с пачкой VLAN, то могут возникнуть определённые проблемы у неопытного администратора. Но у меня на объектах все порты в конфигурационном файле подписаны, по удалёнке можно посмотреть кто должен пользоваться портом, включен ли он и на какой скорости подключился пользователь. А так, же самая нужная мне опция: дистанция от коммутатора до пользователя. Используя информацию о длине кабеля мы всегда можем понять, что произошло: обрыв, не вставлен кабель, кабель отошел в патчпанелях в коммутационной.
Процесс получения информации о длине кабеля делится на две части: произвести тест на порту и просмотреть результаты теста на порту.
Для теста запускаем команду: test cable-diagnos tdr int порт. Например, вот результат вывода для порта
c2960-d2#test cable-diagnos tdr int fa0/48 Link state may be affected during TDR test TDR test started on interface Fa0/48 A TDR test can take a few seconds to run on an interface Use 'show cable-diagnostics tdr' to read the TDR results.
И через несколько секунд можно посмотреть информацию с помощью команды: show cable-diagnos tdr int порт.
c2960-d2#show cable-diagnos tdr int fa0/48 TDR test last run on: April 27 11:05:32 Interface Speed Local pair Pair length Remote pair Pair status --------- ----- ---------- ------------------ ----------- -------------------- Fa0/48 100M Pair A 0 +/- 15 meters Pair A Normal Pair B 0 +/- 15 meters Pair B Normal Pair C N/A Pair C Not Supported Pair D N/A Pair D Not Supported
В результатах можно увидеть, что порт работает на скорости 100 мбит/с по двум парам. А дистанция от коммутатора до компьютера 15 метров. Что соответствует действительной дистанции.
А что будет если выдернуть патчкорд из патчпанели?
c2960-d2#test cable-diagnos tdr int fa0/47 Link state may be affected during TDR test TDR test started on interface Fa0/47 A TDR test can take a few seconds to run on an interface Use 'show cable-diagnostics tdr' to read the TDR results. c2960-d2# c2960-d2# c2960-d2# c2960-d2# c2960-d2#show cable-diagnos tdr int fa0/47 TDR test last run on: April 27 11:07:10 Interface Speed Local pair Pair length Remote pair Pair status --------- ----- ---------- ------------------ ----------- -------------------- Fa0/47 auto Pair A 1 +/- 1 meters N/A Open Pair B 1 +/- 1 meters N/A Open Pair C N/A N/A Not Supported Pair D N/A N/A Not Supported
Так как Pair status в режиме Open, то со второй стороны нет подключенного устройства. А длина кабеля определилась всего один метр. Так как в этой коммутационной используются патчкорды длиной один метр, то можно предположить, что он либо не вставлен в патчпанель, либо джек не защелкнулся в порт патчпанели.
Вот, с помощью небольшой, но очень полезной опции, можно идентифицировать проблему. Чисто теоретически, подобный функционал можно автоматизировать и написать программу, которая будет мониторить доступность сервисов в конторе и запрашивать у оборудования информацию о длине линка. Можно, конечно, автоматизировать до того что при физическом обрыве программа оповестит администратора по электронной почте. Но это уже тема совсем иного поста.
Но такой замер длины работает только на медных портах. Если попробовать замерить длину оптического кабеля на SFP то будет выдана ошибка.
c2960-d2#test cable-diagnos tdr int gi0/1 % Set 'media-type rj45' to run TDR test on interface Gi0/1
Успехов в освоении оборудования и запомните, чем лучше вы знаете своё железо, тем меньше вам придётся бегать ногами.
Отредактировано:2020-09-07 06:31:46
А автоматизировать это дело имеет смысл? Чтобы раз в пол-часа, скажем, прозванивать все порты и в случае проблем бить в набат? Или у Циски есть встроенные средства диагностики?
Опять же анализ протоколов активности юзеров на "железном" уровне может дать пищу для размышлений.