[Negator]

Добрый день.

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

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

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

 

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

 

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

[xcme]

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

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

[gibbon]

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

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

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

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

[Negator]

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

[PuZaN]

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

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

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

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

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

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

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

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

 

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

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

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

[DejaVu]

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

[PuZaN]

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

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

[NiTr0]

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

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

[pppoetest]

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

[Negator]

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

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

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

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

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

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

[NiTr0]

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

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

 

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

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

 

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

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

[Ilya Evseev]

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

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

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

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

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

[Negator]

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

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

 

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

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

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

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

 

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

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

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

[Ilya Evseev]

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

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

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

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

[PuZaN]

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

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

 

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

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

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

[Negator]

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

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

[xcme]

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

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

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

 

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

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

[Negator]

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

[roysbike]

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

Edited October 16, 2014 by 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

 

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

 

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

[Wingman]

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

[Negator]

Мы пока тоже меняем

[xcme]

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

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

[Alexandr Ovcharenko]

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

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

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

[Negator]

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

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

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