В моей работе часто возникает необходимость быстро продиагностировать физические порты на коммутаторах. Способ который я предлагаю ускоряет процесс диагностики и делает его более наглядным по сравнению с прописыванием команд на коммутаторе. Тестирование производится на Linux, так же требуются:
minicom (putty тоже подойдет, утилита играет роль отображения информации в консоль);
сведенный к дефолтным настройкам коммутатор Dlink DGS-1210-28/ME;
в моем случая "модеризированный патч-корд" из 4 штук в одной шине (картинка в конце текста), но можно и обычный патч-корд.
Для удобства была написана программа gui на python 3. Она разбита на два модуля, один из которых реализует подключение по COM порту, второй - графический интерфейс.
Подробный алгоритм диагностики портов:
включаем коммутатор (ждем когда загрузится), подключаем его к компьютеру через конвертор USB to RS-232;
Чтобы узнать какие USB устройства у вас подключены можно воспользоваться командой:
ls /dev/ttyUSB*;
(номер(строка) идущая после "USB" указать при запуске скрипта main.py)запускаем программу командой:
python3 main.py 0- это часть имени USB to RS-232, который в программе представлен как:
0port = "/dev/ttyUSB"+str(sys.argv[1]);
у вас эта часть может отличаться.запускаем параллельно в другом терминале minicom командой:
minicom -D /dev/ttyUSB0 -b 9600;
после запуска нажать несколько раз Enter, чтобы пройти строки авторизации;коммутируем порты витой пары или SFP. Нажимаем кнопки графического интерфейса, что в свою очередь генерирует данные диагностики кабеля соответствующего порта.
Диагностику можно проводить как на одном так и на множестве коммутаторов:
Четыре совмещенных патч-корда склеил для удобства, в основном пользуюсь одним из них, переключая и проверяя сразу 4 порта (8 - если на одном коммутаторе).
SFP так же можно диагностировать, для этих портов прописанное отдельное условие для команды коммутатора show ports <номер порта(25-28)>.
Программу планирую дорабатывать:
универсальность для DGS 3120, 3100, 1210;
индикация о состоянии кабелей;
опция генерации циклического прохода по всем портам и записи результатов диагностики в файл.
Комментарии (12)
martin74ua
03.10.2022 16:01+1А в чем тест то заключается? Зачем миником в соседней консоли? Вообщем писать начали, дальше вступления не пошли....
IDDQDesnik
03.10.2022 16:52Как я понял, вся прога это панель с кнопками, которая плюет в сторону свитча команды:
test cable-diagnostics interface INTERFACE-ID
show cable-diagnostics
(у меня DGS-1510, синтаксис может отличаться)
Миником в соседней консоли сидит в параллель и ловит результаты.
Basil_12 Автор
04.10.2022 12:22да, все верно, мне просто нужно было очень много портов проверять за короткое время, эта простая программа упрощала этот процесс.
Basil_12 Автор
04.10.2022 12:28я понимаю, что программа большой ценности не представляет, я просто поделился способом диагностики свичей после ремонта/перепрошивки.
edo1h
05.10.2022 13:09ну вот этого всего очень не хватает в статье: почему вам нужно диагностировать (вы работаете в компании, которая чинит свитчи), что именно вы понимаете под диагностикой (запуск в консоли свитча конкретной команды).
далее было бы очень неплохо описать что это за команда, что она выводит и как интерпретировать полученное.
vasilisc
03.10.2022 17:44Такой мартышкин труд лучше автоматизировать. Например, поручить это делать Zabbix по SNMP. Триггера сразу предупредят что некоторый порт НЕ ОК. И не нужно коммутатор для проверки изымать с производства.
Basil_12 Автор
04.10.2022 12:24я занимался ремонтом коммутаторов, поэтому это было вынужденное снятие коммутаторов из сети.
pod
04.10.2022 00:55Такое замечательно делается из консоли скриптом на tcl(хоть свич на ком порту, хоть свич по сети). А дальше, если есть какой-то биллинг, можно дергать этот скрипт из него, если не хочется ходить в консоль...
gpcade
05.10.2022 13:41Как говорится - где ты был вчера, когда я тестировал moxa uport на Линухе ))))
CodARM
Я, обычно, стараюсь избавляться от сбоящих, по непонятной причине, не модульных устройств. А из этого вышло, что лучше всего не использовать dlink\tplink, а выбирать microti'ки, cis'ки и прочие устройства первого и второго эшелона.
Не представляю сколько денег и человеко часов компания тратит из-за того, что экономит на оборудовании и закупает D/TP-link'и.
mayorovp
Ну вот у меня дома последний tplink продержался 5 лет, а microtik — 1 год, ровно на неделю пережил гарантийный срок.
achekalin
Это Вы сильно сказанули!
Микроты как роутеры универсальны, как коммутаторы неплохи, но им еще расти и расти в этом смысле, а вот с ростом у микротов как компании слабовато. Просто размер комании и распыление играют роль.
Свичи у них хороши те, что сделаны по референс-дизайнам от производителей чипов. Недорого, неплохо, получше длинка в смысле управления - но не 1-й эшелон.
P.S. Микротики нежно люблю, но - у всего своя область применимости.