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

Диагностика неисправных коммутаторов D-link может кто что придумал?

Добрый день.

В сети очень много коммутаторов D-link 3526.

По видимому они уже отслужили свое.

В последнее время они начинают умирать со следующими симптомами:

На абонентских портах у клиентов вылезают большие потери пакетов от 10 до 90%. Часто отмирают "секции". Поэтому проблему не всегда определишь. Часто одного из абонентов кто пожаловался перетыкают в другой порт/секцию и он доволен.

Остальные же клиенты с коммутатора вместо того, чтобы звонить и жаловаться на скорость часто фиксируют факто того, что интернет тупит и молча меняют провайдера.

 

Ну и "скачут порты".

При этом магистральные оптические порты не дают потерь ни по оптике, ни по меди.

Собственно коммутаторы мы меняем потихоньку.

 

Но хотелось бы мониторить такие случаи самостоятельно, а не ждать обращения клиентов.

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

Пинговать абонентов за коммутатором - так пинг закрыт у 90% абонентов.

На ARP - клиенты обычно отвечают - все таки потери не 100%. Да и потери бывают только на больших пакетах.

 

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

А вот как на сети их искать - пока неясно.

 

P.S. по SNMP сниму все что угодно, zabbix отрисует.

 

Уверен что проблема встречается у многих. Кто как ее решает?

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


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

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

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

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


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

Да, часто причиной плохой работы портов являются высохшие конденсаторы.

Причем в офисе коммутатор может отогреться заработать нормально.

Надо просто заменить опухшие конденсаторы. И не только 470мкФx25в в DC-DC преобразователях, но и 100мкФx25В рассыпанные по плате.

На этих мелких конденсаторах опухлость заметна не очень хорошо, так что их можно менять чисто из профилактики.

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


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

Господа, вопрос не о том как чинить, а как удаленно диагностировать проблему

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


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

Присоединяюсь к ТС

Заметил ещё одну тонкость

Переводишь абона на 10 Мбит/с у него всё начинает работать без потерь. (ну у нас у некоторых тарифы по 1-2 Мбит/с, люди этого и не замечают иногда)

Не знаю как у вас. а мы приучаем абонента звонить нам по всем вопросам (конечно иногда приходится отвечать "почему в ворде подчёркивает красным"), но вроде никто от того что у него вдруг стали потери/тупит скорость не сбегает.

Привозишь свитч в офис, он отлежится и всё работает нормально.

Возили в СЦ длинка несколько таких. Вернули назад "проблема не обнаружена"

Ставлю пока на замену из запаса.

Готовлюсь к постепенному выводу 3526 из обращения.

 

Сейчас если вижу что есть на коммутаторе хотя бы 2 юзера с 10Мбит/с ставим такой коммутатор на замену. ну и в тех.подде уже народ натаскан :

1) делаем чтобы были доступны пинги до юзера ( кстати раньше у одного прова прям обязательное требование было, разрешённые icmp на оборудование клиента, очень ок идея я пытался такое сделать, но монтажники слишком "тяжёлый" народ на подъём)

2) переводим на 10Мбит/с порт

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


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

А последняя миля у Вас случайно не как на фотках из ужастиков? :) Не хочу никоим образом обидеть, но мало ли.. монтажеики по большей части ленивые.. там скрутка а то и две, бочку поставили, распарили витуху, коннектор недожали. Если есть закономерности какие либо - надо думать аналитически :)

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


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

DejaVu я для себя вывел только одну закономерность ( смотрели и распарки и нагрузку и ошибки на портах и ток в сети и наличие бесперебойника и был ли уже в ремонте ) - всё мимо и возникает неожиданно.

Оборудование которое уже работает 7-8 лет 24/7 , пора бы и на пенсию отправить ;)

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


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

Оборудование которое уже работает 7-8 лет 24/7 , пора бы и на пенсию отправить

А зачем, если оно может еще столько же отработать? :)

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


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

Буквально вчера заменили DGS-3627G, сняли, решили почистить, разобрали, нашли 4 вспухших кондера, почесали репу. Как оно без малейшего глюка работало более 4-х лет?

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


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

на 10 мбит все и правда работает.

Последняя миля не идеал, как у всех, но дело не в ней.

С заменой свича все начинает работать.

проблема именно в коммутаторах. Они и правда отжили свое. Меняем их.

Речь о том как диагностировать проблему.

Разрешать ICMP на оборудовании клиента это утопия, да и не объяснишь никому как это сделать

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


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

Как оно без малейшего глюка работало более 4-х лет?

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

 

проблема именно в коммутаторах. Они и правда отжили свое. Меняем их.

Смените конденсаторы на одном. Уверен - будет чудесное исцеление... Цена сей операции - баксов 10 от силы. Только low-esr поставить с небольшим (но не менее 30-50%) запасом относительно рабочего напряжения (ну там на 3.3 и ниже В - ставить на 6.3В рабочее напряжение, на 12В - 16В; на 5В - 10В) вместо установки обычных с огромным запасом по напряжению. А лучше - полимерные...

 

Речь о том как диагностировать проблему.

Вам уже подсказали. Ошибки CRC на портах.

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


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

Ну и "скачут порты".

Я бы попробовал так:

1) собирать журналы коммутаторов в центральный syslog,

2) ежедневно составлять по нему список коммутаторов с количествами up/down-скачков на портах, деленными на количество активных портов,

3) коммутаторы с наибольшими значениями = первые кандидаты на замену, особенно если эти значения на порядок больше средних.

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


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

Вам уже подсказали. Ошибки CRC на портах.

нет там ошибок! Писал об этом уже

 

Я бы попробовал так:

1) собирать журналы коммутаторов в центральный syslog,

2) ежедневно составлять по нему список коммутаторов с количествами up/down-скачков на портах, деленными на количество активных портов,

3) коммутаторы с наибольшими значениями = первые кандидаты на замену, особенно если эти значения на порядок больше средних.

 

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

Грубо говоря есть скачущие порты во вполне исправном варианте, а есть места где поры не скачут - но коммутатор по факту неисправен. Хотя обычно все же на неисправном коммутаторе их бывает больше.

Длинк кстати так внятно и не ответил почему скачут порты, написал только что это не является проблемой. И правда, несмотря на скачущий порт - трафик с него исправно льется без перерывов.

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


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

Вам уже подсказали. Ошибки CRC на портах.

нет там ошибок! Писал об этом уже

А среднее количество tcp retransmissions от клиентов на битых портах примерно такое же, как на исправных?

Если оно на единицу трафика заметно больше, это можно использовать для выборочных проверок сниффером.

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


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

Оборудование которое уже работает 7-8 лет 24/7 , пора бы и на пенсию отправить

А зачем, если оно может еще столько же отработать? :)

 

Можно конечно и чинить.

Но в Москве, да и кое где в регионах 3526 уже морально устарели((

Все хотят Гигабит в квартиру + 100 каналов в HD. эволюция однако.

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


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

А среднее количество tcp retransmissions от клиентов на битых портах примерно такое же, как на исправных?

Это уже в трафик надо лезть, чего не хотелось бы.

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


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

С заменой свича все начинает работать.

проблема именно в коммутаторах. Они и правда отжили свое. Меняем их.

А сколько их? Если 3-4 сотни, может в принудительном порядке везде перепаять конденсаторы?

 

Разрешать ICMP на оборудовании клиента это утопия, да и не объяснишь никому как это сделать

А если не при помощи ICMP проверять абонента, а по наличию ACK/RST ответов? Эдакий "скрытый пинг". Вряд ли винда закрыта совсем уж наглухо своим брандмауэром.

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


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

Спасибо, попробуем. Но, честно говоря, ожидал что кто то уже нашел некие параметры, которые можно снять с коммутатора, вроде того же счетчика ошибок. Коммутаторов сотни 4-5.

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


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

У меня в сети были 3526 которые генерили на портах клиента кучу маков.(замечу, проблема бы не в кабеле) В итоге на свиче было под 800 маков. Благо мониторинг сообщил , а у клиентов были жуткие тормоза и потери. Как вариант еще в мониторинг добавить таблицу fdb count , на доступе у меня не более 35

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

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


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

Тоже волнует проблема, большая часть зоопарка 3526.

а если на порту вот так

show utilization ports

Command: show utilization ports

Port TX/sec RX/sec Util Port TX/sec RX/sec Util

------ ---------- ---------- ---- ------ ---------- ---------- ----

1 0 0 0 22 0 0 0

2 2 1 1 23 0 0 0

3 0 0 0 24 0 0 0

4 0 0 0 25 1288 1963 1

5 1 0 1 26 1594 1276 1

6 0 0 0

7 0 0 0

8 1 2 1

9 0 0 0

10 1 0 1

11 13 9 1

12 0 0 0

13 0 0 0

14 0 0 0

15 1 0 1

16 0 0 0

17 0 0 0

18 0 0 0

19 1 0 1

20 0 0 0

21 1 0 1

 

Второй порт жалуется, почему в итиле пакеты хотя нагрузки нет.

 

У вендора на форуме не спрашивали?

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


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

Мы их тупо меняем на 3200 при малейших жалобах со свитча... Способа диагностики кроме crc не нашли, а crc далеко не всегда со стороны свитча вылазят

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


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

И правда, несмотря на скачущий порт - трафик с него исправно льется без перерывов.

Это есть раз в 5 минут снимать счетчики? А если раз в минуту? В 30 сек?

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


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

Есть 2 варианта быстрого решения проблемы. Один дешевый, второй дорогой.

1. Нанимаем "электроника" с прямыми руками и паяльником на пару месяцев. Запускаем плановую "перепайку" всех свичей подряд. Ибо, кто не сдох все равно сдохнет. Емкости - это у 3526/3550 ФИЧА! Расходы - 1 подменный 3526 + з/п электроника.

2. Меняем все свичи 3526 на 3200-26/28/52 rev.C1. Расходы - новые свичи. Можно продать старые 3526 как б/у, но тогда их все равно придется перепаять, ибо покупатели набьют лицо...

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


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

Это есть раз в 5 минут снимать счетчики? А если раз в минуту? В 30 сек?

Да какие счетчики.

tcpdump + логи свича все видно.

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


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

Join the conversation

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

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

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

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

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

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

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