Tracert Posted September 1, 2014 (edited) · Report post D-Link молчит, но проблема серьезная. Вроде бы без особых оснований начинают глючить абонентские порты. Не поднимаются на 100 мегабит линки, линки постоянно поднимаются и падают, потери до 50% и прочие симптомы плохого кабеля, разъемов, скруток и тд. Но вот перепрокладка кабеля не помогает, помогает переключить кабель в другой порт этого же свитча, иногда переключание порта на 10_half, и потом снова Auto, но всегда помогает перезагрузка коммутатора. Насколько стало понятно, при запуске встроенного в свитч кабельного тестера иногда получается такие данные, что от них сносит крышу порту настолько, что даже когда порт начинает работать в нормальном режиме его уже не отпускает. Обсуждение и видео на форуме длинка тут. Точно затронуты DES-3526 DES-3528 и по сообщениям нашего саппорта DES-3200, но сам с глюками 3200 пока не сталкивался. А мы то все коммутаторы меняем и линии переобжимаем ... Подвердите или опровергните, пожалуйста, мои наблюдения. Edited September 1, 2014 by Tracert Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ChargeSet Posted September 1, 2014 · Report post Было нечто похожее на каком-то свитче, когда от тестера в порт прилетало 9в от тестера, он то ли пытался снова сделать autonegotation, то ли просто придуривался. Помогло включение принудительного 100mb FD и люлей монтажнику Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Tracert Posted September 1, 2014 (edited) · Report post Было нечто похожее на каком-то свитче, когда от тестера в порт прилетало 9в от тестера, он то ли пытался снова сделать autonegotation, то ли просто придуривался. Помогло включение принудительного 100mb FD и люлей монтажнику Тестер имеется ввиду встроенный в сам свитч cable_diag ports Мы, как и многие другие операторы довольно часто этим пользуемся, от отладки проблем с пользователем, до отлавливания ворующих кабеля граждан. Каждый раз когда линк включается или опускается, меряем длину кабеля и анализируем. Edited September 1, 2014 by Tracert Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ChargeSet Posted September 1, 2014 · Report post упс, это я невнимательно прочитал, извините. Фишку такую знаю, сами пользуемся, просто она на железках МТ, у него вывод теста кабеля иногда как минимум странный :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
DVM-Avgoor Posted September 1, 2014 · Report post Точно затронуты DES-3526 В них разве был cable_diag? Разве что в самых крайних ревизиях, да и то они EOL уже несколько лет как. Из всего зоопарка длинков что у нас был (~300 единиц, 3526/3028/3200) того что вы описали нет. Может стоит в сервис? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
EShirokiy Posted September 1, 2014 (edited) · Report post DVM-Avgoor, у DES-3526 совершенно точно диагностика кабеля есть, есть даже у DES-3026) у DES-3526 были проблемы с конденсаторами на материнке, когда они переставали работать, то начинали идти потери крупных пакетов Я так подозреваю, что у ТС проблемы с мониторинговым софтом, который иногда вступает в конфликт со свитчем, например программа зацикливается и свитчу становится плохо от количества запросов на порт, т.к. иногда диагностика кабеля пишет вместо длины кабеля просто "-", программа может криво интерпретировать этот параметр и отправлять запросы на свитч до получения валидных параметров (длины кабеля в цифрах) Обратите внимание 17, 23, 24 порт статус порта "Link UP", а длина кабеля "-" ЗЫ: кажется нашел глючного абонента)) Edited September 1, 2014 by EShirokiy Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Tracert Posted September 2, 2014 · Report post Длинна часто не определается когда с другой стороны отключенное устройство находится, к примеру отключенный от сети комп, тогда пишет -, если питание есть, но комп отключен пишет обычно не могу определить, если роутер без питания с другой стороны пишет 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 метрах длинной с тремя скрутками, после тестирования такого кабеля свитчем - порт начинает глючить. Те если параметры кабеля отличаются от эталонного то данные полученные с него переводят порт в нестабильное состояние. Неужели ни у кого не возникает случайных проблем с абонентскими портами? Свитчи не меняете, порты не перетыкаете? Вполне возможно проблема то эта и проявляется. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
darkagent Posted September 2, 2014 · Report post Из всего зоопарка длинков что у нас был (~300 единиц, 3526/3028/3200) того что вы описали нет. Может стоит в сервис? Видишь суслика? (с) Периодически наблюдаем залипание портов на разных коммутаторах (сейчас точно не скажу на каких), лечащиеся только с ребутом коммутатора. Не скажу чтобы прям так много, чтоб наводить какую-то панику, но все же проблема есть. Попутно еще des-1228/me со своим port_security подливал масло в огонь (порты так же сходили с ума до ребута железки), но в последних прошивках это дело вылизали. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Tracert Posted September 5, 2014 · Report post Да вот не понятно, чем глубже в лес тем больше хочется сменить длинк на что-то другое, но вот на что - большой вопрос. А паники то, конечно, нет но обидно если пользователь не позвонит, а тупо с матюгами переключиться к конкурентам, еще и друзьям расскажет. :( Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
darkagent Posted September 5, 2014 · Report post Шило на мыло. Выбор железа хоть и огромный, но бестолковый - у кого-то одни тараканы, у кого-то другие. У длинка покрайней мере с поставками все более менее стабильно, и ценовая политика достаточно гибкая. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vurd Posted September 5, 2014 · Report post Попутно еще des-1228/me со своим port_security подливал масло в огонь (порты так же сходили с ума до ребута железки), но в последних прошивках это дело вылизали. На 3028 был или есть такой прикол, что иногда порт секьюрити начинал не пускать даже один правильный мак выводя в лог мессаж с этим одним маком постоянно. Причем появлялось на конкретных абонентах и редко. На последней fw - хз, перешил пока не было. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
h1vs2 Posted September 5, 2014 · Report post Подтверждаю - известная проблема. Саппорт длинка забил :) Перепишите логику скриптов, если часто делают диагностику. Ну и саппорту скажите не злоупотреблять :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Butch3r Posted September 5, 2014 · Report post Подтверждаю - известная проблема. Саппорт длинка забил :) Перепишите логику скриптов, если часто делают диагностику. Ну и саппорту скажите не злоупотреблять :) это именно у 35 серии? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
h1vs2 Posted September 7, 2014 · Report post Подтверждаю - известная проблема. Саппорт длинка забил :) Перепишите логику скриптов, если часто делают диагностику. Ну и саппорту скажите не злоупотреблять :) это именно у 35 серии? 3526,3528.3200-XX(rev a/b). В 3200-хх ревизии С не сталкивались, но тогда логика массовой кабель-диагностики была переработана. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
xcme Posted September 10, 2014 · Report post Длинна часто не определается когда с другой стороны отключенное устройство находится, к примеру отключенный от сети комп Есть три состояния: 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 залип от диагностики, но я пока не делаю ее массово. Буду признателен за любую информацию. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Tracert Posted September 11, 2014 · Report post На скрине налицо некорректная работа 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; } } } Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
pppoetest Posted September 11, 2014 · Report post Set-request для каждого порта можно делать последовательно, а можно отправить один пакет сразу для всех портов (если есть чем, на PHP такой возможности нет, на Python+netsnmp или просто netsnmp есть). Стрелять гигабитные порты нельзя - они падают независимо от типа оптика/медь. Таймаут нужен, чтобы свичик успел отдуплиться и вернул правильные цифры, а не какую то ерунду (может вернуть "other"). 3028, кажется, успевает мгновенно, но вот 3200-28 лучше дать 1-2 секунды на "подумать", а 3200-28/С1 отвечает дольше дольше всех (как быстро он именно проводит диагностику не проверял). После этого результат забирается walk'ом. Угу, у мну стоит напрочь перепиленный swtoolz, щяс глянул в переменные, таймаут для таких целей стоял 0,1сек, поставил 2 сек, проверил, "муть" в ответах с1 пропала. Выражалась оная в постоянно разных ответах на портах без кабеля. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
xcme Posted September 12, 2014 · Report post -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 раз нон-стоп в цикле, проблема воспроизведется? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted September 12, 2014 · Report post Всеже проблема чаше всего связана с кондерами на плате. Еще один признак поддохших емкостей - на порту начинают иногда возникать левые маки отличающиеся от реально висящего на порту в 1-2х битах (причем почемуто младших обычно). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
xcme Posted September 13, 2014 · Report post 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 пяти веток - запрос приходит одним пакетом, что экономит время. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
xcme Posted December 24, 2014 (edited) · Report post Апну тему, может появились у кого-нибудь новые соображения. Хочу ввести автоматическую диагностику, 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 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
satboy Posted December 24, 2014 · Report post Зачем тестировать порты автоматически? Позвонил абонент - тестируй из биллинга в живом времени.. Или во время проведения ремонта.. НО не постоянно или по графику... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
xcme Posted December 24, 2014 · Report post Зачем тестировать порты автоматически? Позвонил абонент - тестируй из биллинга в живом времени.. Или во время проведения ремонта.. НО не постоянно или по графику... Затем и тестировать, чтобы не позвонил. :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
xcme Posted February 17, 2015 · Report post В общем, я подтверждаю проблему. :( Похоже, подвержены все модели, просто где-то чаще, где то реже. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Negator Posted February 17, 2015 · Report post Хм, я тут на днях занимался проблемой. Прикрутил собирать длины и статусы пар в заббикс 4 раза в сутки. Все собирается уже пару недель на ~500 свичах. Жалоб на залипание не наблюдаем(хотя возможно рано говорить). Но вот результаты... Когда провод включен в комп/роутер - свичи показывают что попало. Длину показывают иногда корректную, иногда показывают -1 м (просто cable ОК) Иногда (по словам сотрудников на некоторых моделях сетевок при выключенном компе) -показывает обе пары short. Включаешь комп - все ок. Также сама длина кабеля может изменяться по показаниям и значительно. У абонента все работает. В итоге никакой логики я прикрутить к этому не смог. Если кто смог придумать логику - прошу ей поделиться с общественностью, даже готов соком проставиться. Что то более -менее корректное показывает ТОЛЬКО при вытащенном из оборудования клиента кабеле. Итого мы сейчас мониторим длины только вытащенных линков. Но вот зачем оно нам и смысл во всем этом я пока не придумал. А хотелось конечно другого - сравнили длину с эталонной - не совпадает - проблема. short на одной из пар - проблема. Но показывают свичи все сплошь подряд. Проблем валится куча, по факту все в порядке. Тестировал на 3526. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...