Jump to content
Калькуляторы

Кабельный тестер - истоник глюков протов коммутаторов D-Link?

D-Link молчит, но проблема серьезная. Вроде бы без особых оснований начинают глючить абонентские порты. Не поднимаются на 100 мегабит линки, линки постоянно поднимаются и падают, потери до 50% и прочие симптомы плохого кабеля, разъемов, скруток и тд. Но вот перепрокладка кабеля не помогает, помогает переключить кабель в другой порт этого же свитча, иногда переключание порта на 10_half, и потом снова Auto, но всегда помогает перезагрузка коммутатора. Насколько стало понятно, при запуске встроенного в свитч кабельного тестера иногда получается такие данные, что от них сносит крышу порту настолько, что даже когда порт начинает работать в нормальном режиме его уже не отпускает. Обсуждение и видео на форуме длинка тут. Точно затронуты DES-3526 DES-3528 и по сообщениям нашего саппорта DES-3200, но сам с глюками 3200 пока не сталкивался. А мы то все коммутаторы меняем и линии переобжимаем ... Подвердите или опровергните, пожалуйста, мои наблюдения.

Edited by Tracert

Share this post


Link to post
Share on other sites

Было нечто похожее на каком-то свитче, когда от тестера в порт прилетало 9в от тестера, он то ли пытался снова сделать autonegotation, то ли просто придуривался. Помогло включение принудительного 100mb FD и люлей монтажнику

Share this post


Link to post
Share on other sites

Было нечто похожее на каком-то свитче, когда от тестера в порт прилетало 9в от тестера, он то ли пытался снова сделать autonegotation, то ли просто придуривался. Помогло включение принудительного 100mb FD и люлей монтажнику

Тестер имеется ввиду встроенный в сам свитч

cable_diag ports

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

Edited by Tracert

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Точно затронуты DES-3526

В них разве был cable_diag? Разве что в самых крайних ревизиях, да и то они EOL уже несколько лет как.

 

Из всего зоопарка длинков что у нас был (~300 единиц, 3526/3028/3200) того что вы описали нет. Может стоит в сервис?

Share this post


Link to post
Share on other sites

DVM-Avgoor, у DES-3526 совершенно точно диагностика кабеля есть, есть даже у DES-3026)

у DES-3526 были проблемы с конденсаторами на материнке, когда они переставали работать, то начинали идти потери крупных пакетов

Я так подозреваю, что у ТС проблемы с мониторинговым софтом, который иногда вступает в конфликт со свитчем, например программа зацикливается и свитчу становится плохо от количества запросов на порт, т.к. иногда диагностика кабеля пишет вместо длины кабеля просто "-", программа может криво интерпретировать этот параметр и отправлять запросы на свитч до получения валидных параметров (длины кабеля в цифрах)

v31LhHuFM2U.jpg

Обратите внимание 17, 23, 24 порт статус порта "Link UP", а длина кабеля "-"

ЗЫ: кажется нашел глючного абонента))

Edited by EShirokiy

Share this post


Link to post
Share on other sites

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

 

Данные эти отрабатываются скриптом, примерно так :

switch($ps->{$pair2_state_oid})
       {
           case '0' {$pair2_state="OK";}
           case '1' {$pair2_state="Open";}
           case '2' {$pair2_state="Short";}
           case '3' {$pair2_state="Open-short";}
           case '4' {$pair2_state="Crosstalk";}
           case '5' {$pair2_state="Unknown";}
           case '6' {$pair2_state="Count";}
           case '7' {$pair2_state="No cable";}
           case '8' {$pair2_state="Other";}
       }

       if ($pair2_len eq '-1') { $pair2_len='NULL'; }

 

Но дело не в отработке и не в залипании, в комментах от 2011 года человек писал, что повторяемость ситуации у него 100% при использовании кабеля 110 метрах длинной с тремя скрутками, после тестирования такого кабеля свитчем - порт начинает глючить. Те если параметры кабеля отличаются от эталонного то данные полученные с него переводят порт в нестабильное состояние. Неужели ни у кого не возникает случайных проблем с абонентскими портами? Свитчи не меняете, порты не перетыкаете? Вполне возможно проблема то эта и проявляется.

Share this post


Link to post
Share on other sites

Из всего зоопарка длинков что у нас был (~300 единиц, 3526/3028/3200) того что вы описали нет. Может стоит в сервис?

Видишь суслика? (с)

 

Периодически наблюдаем залипание портов на разных коммутаторах (сейчас точно не скажу на каких), лечащиеся только с ребутом коммутатора. Не скажу чтобы прям так много, чтоб наводить какую-то панику, но все же проблема есть. Попутно еще des-1228/me со своим port_security подливал масло в огонь (порты так же сходили с ума до ребута железки), но в последних прошивках это дело вылизали.

Share this post


Link to post
Share on other sites

Да вот не понятно, чем глубже в лес тем больше хочется сменить длинк на что-то другое, но вот на что - большой вопрос. А паники то, конечно, нет но обидно если пользователь не позвонит, а тупо с матюгами переключиться к конкурентам, еще и друзьям расскажет. :(

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Попутно еще des-1228/me со своим port_security подливал масло в огонь (порты так же сходили с ума до ребута железки), но в последних прошивках это дело вылизали.

 

На 3028 был или есть такой прикол, что иногда порт секьюрити начинал не пускать даже один правильный мак выводя в лог мессаж с этим одним маком постоянно. Причем появлялось на конкретных абонентах и редко. На последней fw - хз, перешил пока не было.

Share this post


Link to post
Share on other sites

Подтверждаю - известная проблема. Саппорт длинка забил :)

 

Перепишите логику скриптов, если часто делают диагностику. Ну и саппорту скажите не злоупотреблять :)

Share this post


Link to post
Share on other sites

Подтверждаю - известная проблема. Саппорт длинка забил :)

 

Перепишите логику скриптов, если часто делают диагностику. Ну и саппорту скажите не злоупотреблять :)

это именно у 35 серии?

Share this post


Link to post
Share on other sites

Подтверждаю - известная проблема. Саппорт длинка забил :)

 

Перепишите логику скриптов, если часто делают диагностику. Ну и саппорту скажите не злоупотреблять :)

это именно у 35 серии?

 

3526,3528.3200-XX(rev a/b). В 3200-хх ревизии С не сталкивались, но тогда логика массовой кабель-диагностики была переработана.

Share this post


Link to post
Share on other sites

Длинна часто не определается когда с другой стороны отключенное устройство находится, к примеру отключенный от сети комп

Есть три состояния:

Link Up/Connected - длина определяется

(Link Up/Not_connected - не может быть по определению)

Link Down/Connected - длина НЕ определяется, свичик пишет "OK"

Link Down/Not_connected - Длина определяется

 

На скрине налицо некорректная работа cable diag на трех портах, выше замечание про 17, 23, 24 верное.

 

Правильно понимаю, что проблему провоцирует исключительно cable diagnostic, причем в массовом/частом применении?

Если "ДА", давайте разбираться, а то я тут тоже хотел наладить сбор данных в промышленных масштабах. :)

Кто как именно стреляет? Дело в том, что по SNMP сначала надо сделать инициализацию порта, затем желательно выждать таймаут 1-2 сек, после чего забирать результат. Set-request для каждого порта можно делать последовательно, а можно отправить один пакет сразу для всех портов (если есть чем, на PHP такой возможности нет, на Python+netsnmp или просто netsnmp есть). Стрелять гигабитные порты нельзя - они падают независимо от типа оптика/медь. Таймаут нужен, чтобы свичик успел отдуплиться и вернул правильные цифры, а не какую то ерунду (может вернуть "other"). 3028, кажется, успевает мгновенно, но вот 3200-28 лучше дать 1-2 секунды на "подумать", а 3200-28/С1 отвечает дольше дольше всех (как быстро он именно проводит диагностику не проверял). После этого результат забирается walk'ом.

У всех ли так? Ни разу не видел, чтобы порт на 3028/3200-28/3200-28_С1 залип от диагностики, но я пока не делаю ее массово.

 

Буду признателен за любую информацию.

Share this post


Link to post
Share on other sites

 

На скрине налицо некорректная работа cable diag на трех портах, выше замечание про 17, 23, 24 верное.

 

Правильно понимаю, что проблему провоцирует исключительно cable diagnostic, причем в массовом/частом применении?

Если "ДА", давайте разбираться, а то я тут тоже хотел наладить сбор данных в промышленных масштабах. :)

Кто как именно стреляет? Дело в том, что по SNMP сначала надо сделать инициализацию порта, затем желательно выждать таймаут 1-2 сек, после чего забирать результат.

 

Ну смотрите к линуховому snmptrapd есть отличный способ прикруить perl библиотеку для работы. просто в конфиге указываете -

perl do "/etc/sysconfig/utils/snmp_trapd.pl"

это тот скрипт в котором делается обработчик трапов со стороны свитчей, по падению линка - логично сразу проверить длинну трассы, и просто внести ее в БД, или если она уменьшилась на 20-30 метров , тем более если несколько таких трапов сразу пришло - режут кабель. Поэтому в скрипте сразу описываем трапы от падений линка и их включений. Очень удобно ибо сетевая часть вся будет написана на C и очень стабильна, на перле по крайней мере у меня не получается создавать нормальные сетевые демоны работающие месяцами. А логику споконой описываем своими функциями.

 

#linkDown
NetSNMP::TrapReceiver::register("linkDown", \&link_change) || warn "failed to register our perl trap handler\n";

#linkDown
NetSNMP::TrapReceiver::register("linkUp", \&link_change) || warn "failed to register our perl trap handler\n";

 

Когда приходят трапы о изменении статуса линка - вызывается функция link_change , которая кроме всего еще и тестирует длины кабелей.

 

Сама функция определения длины на перле у меня получилась такая, просьба сильно не ржать, тк я вовсе не программер, а ген.дир, функция учитывает что может быть порт не готов и переопрашивает его 3 раза через 1 секунду. Сейчас она отключена, ибо свитчи глючат - первой функцией - return 1 идет.

 

sub ls_handler
{
   return 1;
   my ($sw_ip,$port,$state)= @_;
   print "STATE::::::::::::::: $sw_ip,$port,$state\n!";

   my $session = Net::SNMP->session( -hostname  => $sw_ip, -community => 'private', -version => 'snmpv2c', -timeout=>'3', -retries=>'2',) or die "session error: ".$!;
   my $cabel_tester_support_oid="1.3.6.1.4.1.171.12.58.1.1.1.2.".$port;
   my $cabel_tester_start_oid="1.3.6.1.4.1.171.12.58.1.1.1.12.".$port;

   my $link_state_oid  ="1.3.6.1.4.1.171.12.58.1.1.1.3.".$port;
   my $pair1_len_oid   ="1.3.6.1.4.1.171.12.58.1.1.1.8.".$port;
   my $pair2_len_oid   ="1.3.6.1.4.1.171.12.58.1.1.1.9.".$port;
   my $pair1_state_oid ="1.3.6.1.4.1.171.12.58.1.1.1.4.".$port;
   my $pair2_state_oid ="1.3.6.1.4.1.171.12.58.1.1.1.5.".$port;

   my $cabel_tester_supported = $session->get_request( -varbindlist =>[$cabel_tester_support_oid]) or die "request error: ".$session->error;

   #если поддерживается ли кабельный тестер
   if ($cabel_tester_supported->{$cabel_tester_support_oid}==0)
   {
       #запускаем тест
       my $result = $session->set_request( -varbindlist  => [ $cabel_tester_start_oid,  INTEGER, "1"]) or die "request error: ".$session->error;
       my $finished=0;

       for (my $i=1; $i<=3; $i++)
       {
           my $result = $session->get_request( -varbindlist =>[$cabel_tester_start_oid]) or die "request error: ".$session->error;
           #если тест окончен
           if ($result->{$cabel_tester_start_oid}==3)
           {
               $finished=1;
               last;
           }
           sleep 1;
       }

       #Если тест окончился неудачей.
       if ($finished ==0)
       {
           print LOG "\n".strftime('%D %T',localtime)." ERROR!!! $sw_ip ============> Cable tester result is not ready after 3 attempts.\n";
           LOG->flush;
           return 1;
       }


       #Получаем данные кабельного тестера
       my $ps=$session->get_request( -varbindlist =>[$link_state_oid,$pair1_state_oid,$pair2_state_oid,$pair1_len_oid,$pair2_len_oid])       or die "request error: ".$session->error;
       my $link_state;
       my $pair1_state;
       my $pair2_state;
       my $pair1_len= $ps->{$pair1_len_oid};
       my $pair2_len= $ps->{$pair2_len_oid};

       switch($ps->{$link_state_oid})
       {       #enum('Up', 'Down')
                       case '0' {$link_state="Down";}
                       case '1' {$link_state="Up";}
                       case '2' {$link_state="Other";}
       }

       switch($ps->{$pair1_state_oid})
       {       #('Open', 'Short', 'No cable', 'OK', 'ShutDown')
           case '0' {$pair1_state="OK";}
           case '1' {$pair1_state="Open";}
           case '2' {$pair1_state="Short";}
           case '3' {$pair1_state="Open-short";}
           case '4' {$pair1_state="Crosstalk";}
           case '5' {$pair1_state="Unknown";}
           case '6' {$pair1_state="Count";}
           case '7' {$pair1_state="No cable";}
           case '8' {$pair1_state="Other";}
       }

       switch($ps->{$pair2_state_oid})
       {
           case '0' {$pair2_state="OK";}
           case '1' {$pair2_state="Open";}
           case '2' {$pair2_state="Short";}
           case '3' {$pair2_state="Open-short";}
           case '4' {$pair2_state="Crosstalk";}
           case '5' {$pair2_state="Unknown";}
           case '6' {$pair2_state="Count";}
           case '7' {$pair2_state="No cable";}
           case '8' {$pair2_state="Other";}
       }

       if ($pair1_len eq '-1') { $pair1_len='NULL'; }
       if ($pair2_len eq '-1') { $pair2_len='NULL'; }

       #print "\n\n===>> $link_state P1: $pair1_state - $pair1_len P2: $pair2_state - $pair2_len <<===\n\n";
       my $sth = $dbh->prepare("SELECT switch_id FROM switches WHERE switch_ip='$sw_ip'") or die $dbh->db_errstr;
       $sth->execute or die $dbh->db_errstr;
       if ($sth->rows==1) #IP адрес коммутатора в базе
       {
           my @row = $sth->fetchrow_array;
           my $sw_id=$row[0];
           $dbh->do(qq{ INSERT INTO sw_ports (date,sw_id,sw_port,port_action,link,A_len,A_state,B_len,B_state) VALUES (now(),'$sw_id','$port','$state','$link_state',$pair1_len,'$pair1_state',$pair1_len,'$pair2_state')})  or die $Mysql::db_errstr;
           return 1;
       }
       else
       {
           print LOG "\n".strftime('%D %T',localtime)." ERROR!!! $sw_ip ============> switch IP is not in DB.\n";
           LOG->flush;
           return 1;
       }
   }
}

Share this post


Link to post
Share on other sites

Set-request для каждого порта можно делать последовательно, а можно отправить один пакет сразу для всех портов (если есть чем, на PHP такой возможности нет, на Python+netsnmp или просто netsnmp есть). Стрелять гигабитные порты нельзя - они падают независимо от типа оптика/медь. Таймаут нужен, чтобы свичик успел отдуплиться и вернул правильные цифры, а не какую то ерунду (может вернуть "other"). 3028, кажется, успевает мгновенно, но вот 3200-28 лучше дать 1-2 секунды на "подумать", а 3200-28/С1 отвечает дольше дольше всех (как быстро он именно проводит диагностику не проверял). После этого результат забирается walk'ом.

Угу, у мну стоит напрочь перепиленный swtoolz, щяс глянул в переменные, таймаут для таких целей стоял 0,1сек, поставил 2 сек, проверил, "муть" в ответах с1 пропала. Выражалась оная в постоянно разных ответах на портах без кабеля.

Share this post


Link to post
Share on other sites

-timeout=>'3'

Это в каких единицах? Миллисекунды?

my $result = $session->set_request( -varbindlist => [ $cabel_tester_start_oid, INTEGER, "1"]) or die "request error: ".$session->error;

Что если таймаут а 2 секунды поставить после этой строчки?

 

Еще можно снифером посмотреть как это реально выглядит. Может скриптик долбит (3 в цикле * (retries+1) = 9 раз в итоге) еще не готовый свич, отчего у последнего и сносит башню?

 

p.s. Если положить свичик на столе, подключить к нему что-нибудь и стрельнуть этот порт 100 раз нон-стоп в цикле, проблема воспроизведется?

Share this post


Link to post
Share on other sites

Всеже проблема чаше всего связана с кондерами на плате. Еще один признак поддохших емкостей - на порту начинают иногда возникать левые маки отличающиеся от реально висящего на порту в 1-2х битах (причем почемуто младших обычно).

Share this post


Link to post
Share on other sites

 

p.s. Если положить свичик на столе, подключить к нему что-нибудь и стрельнуть этот порт 100 раз нон-стоп в цикле, проблема воспроизведется?

Сделал так на 3028 и 3200-28 - никаких аномалий вообще.

Проблема только в 35-й серии?

 

#!/usr/local/bin/python
#coding=UTF8

import netsnmp,time
from config import snmp_WComm

host='10.99.192.19'
port='7'
start=time.time()
for i in range(100):
   var=netsnmp.Varbind('.1.3.6.1.4.1.171.12.58.1.1.1.12',port,'1','INTEGER')
   res = netsnmp.snmpset(var,Version = 2, DestHost = host, Community = snmp_WComm, Timeout = 250000, Retries = 2)
   print res

   oids_CableDiag = [
       '.1.3.6.1.4.1.171.12.58.1.1.1.3',
       '.1.3.6.1.4.1.171.12.58.1.1.1.4',
       '.1.3.6.1.4.1.171.12.58.1.1.1.5',
       '.1.3.6.1.4.1.171.12.58.1.1.1.8',
       '.1.3.6.1.4.1.171.12.58.1.1.1.9',
   ]
   var=netsnmp.VarList(*[netsnmp.Varbind(VarBindItem) for VarBindItem in oids_CableDiag])
   res = netsnmp.snmpwalk(var,Version = 2, DestHost = host, Community = snmp_WComm, Timeout = 250000, Retries = 2)
   print res

print "\nElapsed Time: %.4f" %(time.time() - start)

 

Кстати по результатам видно, что 3028 справляется намного лучше, а 3200 бывает не успевает (тут не таймаута).

 

p.s. В примере используется одновременный walk пяти веток - запрос приходит одним пакетом, что экономит время.

Share this post


Link to post
Share on other sites

Апну тему, может появились у кого-нибудь новые соображения. Хочу ввести автоматическую диагностику, DES-3526 в парке нет. Провожу испытания в маленьких масштабах, опрашиваю 3 свичика: DES-3028, DES-3200-28, DES-3200-28/C1. Сам я подключен через один из них. Раз в две минуты собираю CRC, режим дуплекса, административно заданную скорость порта, состояния пар и длины пар. Перед сбором данных идет инициализация диагностики с паузой в 1 сек. В бесконечном режиме висит пинг, опрос продолжается где-то пару часов. Со свичей снимаются графики загрузки CPU. Вообще никаких проблем не замечаю! То есть проблема с диагностикой касается все же только 3526?

 

p.s. Бот нашел ошибку, т.е. алгоритмы работают: :)

attractor: Пара №1 порта 10 на устройстве 172.17.111.10 [DES-3028] имеет повреждения!

attractor: Пара №2 порта 10 на устройстве 172.17.111.10 [DES-3028] имеет повреждения!

Edited by xcme

Share this post


Link to post
Share on other sites

Зачем тестировать порты автоматически? Позвонил абонент - тестируй из биллинга в живом времени.. Или во время проведения ремонта.. НО не постоянно или по графику...

Share this post


Link to post
Share on other sites

Зачем тестировать порты автоматически? Позвонил абонент - тестируй из биллинга в живом времени.. Или во время проведения ремонта.. НО не постоянно или по графику...

Затем и тестировать, чтобы не позвонил. :)

Share this post


Link to post
Share on other sites

Хм, я тут на днях занимался проблемой.

Прикрутил собирать длины и статусы пар в заббикс 4 раза в сутки.

Все собирается уже пару недель на ~500 свичах. Жалоб на залипание не наблюдаем(хотя возможно рано говорить).

Но вот результаты...

Когда провод включен в комп/роутер - свичи показывают что попало.

Длину показывают иногда корректную, иногда показывают -1 м (просто cable ОК)

Иногда (по словам сотрудников на некоторых моделях сетевок при выключенном компе) -показывает обе пары short. Включаешь комп - все ок.

Также сама длина кабеля может изменяться по показаниям и значительно. У абонента все работает.

В итоге никакой логики я прикрутить к этому не смог.

 

Если кто смог придумать логику - прошу ей поделиться с общественностью, даже готов соком проставиться.

 

Что то более -менее корректное показывает ТОЛЬКО при вытащенном из оборудования клиента кабеле.

Итого мы сейчас мониторим длины только вытащенных линков. Но вот зачем оно нам и смысл во всем этом я пока не придумал.

А хотелось конечно другого - сравнили длину с эталонной - не совпадает - проблема.

short на одной из пар - проблема.

Но показывают свичи все сплошь подряд. Проблем валится куча, по факту все в порядке.

Тестировал на 3526.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.