аукцион / FPR / donate / услуги / RSS / распечатать / вход 
Мой мир
Вконтакте
Одноклассники

[16 марта 2019 | 19 марта 2019 | 21 марта 2019]

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

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

Тэги: ИТ, Cisco

Отредактировано:2020-09-07 06:31:46




6 комментариев
Имя: Алексей 🖉
А автоматизировать это дело имеет смысл? Чтобы раз в пол-часа, скажем, прозванивать все порты и в случае проблем бить в набат? Или у Циски есть встроенные средства диагностики?

Опять же анализ протоколов активности юзеров на "железном" уровне может дать пищу для размышлений.
Комментарий оставлен: 2019-03-19 00:00:00


Имя: Orcinus Orca 🖉
Алексей, можно автоматизировать с помощью IP SLA, собственно таким образом делается переключение между несколькими провайдерами. Можно варьировать как с доступностью услуг со стороны провайдера, так и анализировать качество канала по джиттеру.

Опять же онлайн мониторить не имеет смысла для небольших компаний. А вот автоматизация поиска проблемы с подключением — это тема. Тут главное понять что ты хочешь от железки.
Комментарий оставлен: 2019-03-19 00:00:00


Имя: Алексей 🖉
Если задача стоит именно мониторить качество физического коннекта, то самое проблемное место — это переговорные комнаты и временные и гостевые рабочие места. Там, где штекеры перетыкают часто и в спешке. Можно, конечно, дождаться, когда юзеры прибегут жаловаться, но иногда тамошний юзер — это начальник. И он может прибежать сразу ругаться :) Шучу.

Да просто, регулярно прозванивать всю сетку на предмет, кто живой, и писать логи "обычного рабочего дня", "аврального рабочего дня", "праздников"... Потом скормить это дело нейросети и выявлять признаки несанкционированного доступа :) Безопасники такое любят.

Отличный учебный проект для студента-практиканта, если они у вас есть. Я бы, кстати, и про онлайн-мониторинг подумал. Почему нет?

Может, конечно, глупость написал. Я сам не админ, а пользователь с опытом разработки систем с использованием сетей. Но у нас своя специфика.
Комментарий оставлен: 2019-03-19 00:00:00


Имя: Orcinus Orca 🖉
Алексей, такое тоже можно сделать. При чём на том же Пайтоне подключаться через эмулятор Телнета, читать информацию об интерфейсах и потом читать данные об подключении.

Но подобное реально требуется в тех местах куда очень дорого отправлять админа ногами и проще просить найти аникейщика, либо попросить бухгалтера потыкать.
Комментарий оставлен: 2019-03-20 00:00:00


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

Но тебе конечни виднее, нужно ли заморачиваться вообще.
Комментарий оставлен: 2019-03-20 00:00:00


Имя: Orcinus Orca 🖉
Алексей, для мониторинга применяются разные схемы и системы. Конкретно то, что я описывал позволит администратору получить информацию для анализа. А так, взлом или разрушение узла — это уже другой уровень обеспечения целостности системы.

В реальной жизни, в нормальных условиях, сервер подключен не к одному, а к нескольким коммутаторам доступа, а эти коммутаторы подключены к коммутаторам распределения. Опять же иногда сервер подключен напрямую к коммутаторам ядра сети. У нас серверы обычно подключены 40гбит/с линками сразу в коммутаторы ядра сети, для этого выделяется по 2 и более порта в режиме агрегации.
Комментарий оставлен: 2019-03-20 00:00:00



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

Сообщайте мне о замеченных ошибках на: web@orcinus.ru. Все пожелания и советы будут учтены при дальнейшем проектировании сайта. Я готов сотрудничать со всеми желающими. В некоторых случаях, мнение автора может не совпадать с мнением автора! Phone: +7-902-924-70-49.

Top.Mail.Ru
Top.Mail.Ru LiveInternet Rambler's Top100 Яндекс.Метрика