Перейти к содержимому
Калькуляторы

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

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

Изменено пользователем Tracert

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

cable_diag ports

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

Изменено пользователем Tracert

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

v31LhHuFM2U.jpg

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

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

Изменено пользователем EShirokiy

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Длинна часто не определается когда с другой стороны отключенное устройство находится, к примеру отключенный от сети комп, тогда пишет -, если питание есть, но комп отключен пишет обычно не могу определить, если роутер без питания с другой стороны пишет 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 метрах длинной с тремя скрутками, после тестирования такого кабеля свитчем - порт начинает глючить. Те если параметры кабеля отличаются от эталонного то данные полученные с него переводят порт в нестабильное состояние. Неужели ни у кого не возникает случайных проблем с абонентскими портами? Свитчи не меняете, порты не перетыкаете? Вполне возможно проблема то эта и проявляется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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 залип от диагностики, но я пока не делаю ее массово.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

На скрине налицо некорректная работа 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;
       }
   }
}

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

-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 раз нон-стоп в цикле, проблема воспроизведется?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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 пяти веток - запрос приходит одним пакетом, что экономит время.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Апну тему, может появились у кого-нибудь новые соображения. Хочу ввести автоматическую диагностику, 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] имеет повреждения!

Изменено пользователем xcme

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В общем, я подтверждаю проблему. :( Похоже, подвержены все модели, просто где-то чаще, где то реже.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.