[Tracert]

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

Edited September 1, 2014 by Tracert

[ChargeSet]

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

[Tracert]

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

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

cable_diag ports

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

Edited September 1, 2014 by Tracert

[ChargeSet]

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

[DVM-Avgoor]

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

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

 

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

[EShirokiy]

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

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

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

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

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

Edited September 1, 2014 by EShirokiy

[Tracert]

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

[darkagent]

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

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

 

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

[Tracert]

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

[darkagent]

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

[vurd]

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

 

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

[h1vs2]

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

 

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

[Butch3r]

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

 

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

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

[h1vs2]

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

 

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

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

 

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

[xcme]

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

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

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

 

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

[Tracert]

 

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

[pppoetest]

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

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

[xcme]

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

[alex_001]

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

[xcme]

 

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

[xcme]

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

[satboy]

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

[xcme]

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

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

[xcme]

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

[Negator]

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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