есть сеть построенная на разномастных коммутаторах д-линк (DGS-3224TGR\DGS-3024\DGS-3550\DES-3526\DES-3010G\DGS-1252\DES 3028P\DES 3010G)
в результате перебоя электричества какая-то железка сошла с ума (на данный момент не выяснено) и уложила всю сеть


проявлялось все так : беспорядошно пропадали и появлялись устройства в сети (по пингам) как и сами свитчи так и устройства подключенные к ним.

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

вопрос: а можно ли как-то в мониторинге хабов выяснить с какого порта\ИП все это просисходит. желательно через веб или телнет.

Конечно можно!
Мониторинг через протокол SNMP. В качестве сервера (того, кто опрашивает, собирает, обрабатывает и показывает данные) как вариант можно использовать cacti ("кактус"). Поиск по форуму даст всю необходимую инфу.

Если это все уже есть и работает, то надо искать источник большого (огромного?) числа броадкастовых пакетов. Еще загрузка процессора свича, где это "нечто" происходит, как правило отличается от среднестатистической.

Ну а если ничего этого нет (я про мониторинг), то все равно можно отыскать, где собака порылась. Просто сравните трафик с "нормального" направления в плане соотношения броадкаст-мультикаст-юникаст пакетов и с "ненормального". Далее идя по "ненормальной" ветке вы найдете нужный клиентский порт.

У вас упраление свичами в отдельном вилане?
У вас шторм-контроль на длинках настроен?

_________________
не важно, из какого места растут золотые руки

нет. совместно с основной сетью. но гостевые сети и вайфай в отдельных вланах.




нет. я про такой и не слышал. где почитать ?

Все функции описаны в доках. Доки лежат тут: ftp://ftp.dlink.ru/pub/Switch/
там ищете свою модель, благо у вас их много. В папке Description как раз лежат доки. Выбираете самую последнюю версию и читаете. Часть доков даже переведена на русский. По-моему, для 3526-х. Так что начните с них - будет более понятно, о чем там речь.

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

А что до отдельного вилана для управления свичами - это по-любому должно быть. Грубо говоря, с этого начинается построение нормальной сети (имею в виду управляемую, масштабируемую сеть)

_________________
не важно, из какого места растут золотые руки

Было такое - завис 3026. Лег сегмент из 4 домов. Причем колбаса по сети шла такая, что некоторые пользователи попадали в управляющий VLAN.



Спасибо за вариант решения проблемы.

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

проблема была в одном DES-3526 . вылечился волшебным ребутом.

Добрый день. Возникла следующая ситуация:
1. Имеется ветка из коммутаторов Dlink Des-3526. Включены в кольцо. В качестве аггрегации используется cisco3750.
2. На коммутаторах настроено igmp, настроен IGMP Multicast vlan кусок конфига igmp:

# SNOOP
enable igmp_snooping
create igmp_snooping multicast_vlan iptv 4040
config igmp_snooping multicast_vlan iptv member_port 1-12,14-22 source_port 13,23-26 state enable replace_source_ip 10.48.1.169
config igmp_snooping iptv host_timeout 260 router_timeout 260 leave_timer 2 state enable
config igmp_snooping querier iptv query_interval 125 max_response_time 10 robustness_variable 2
config igmp_snooping querier iptv last_member_query_interval 1 state enable
config limited_multicast_addr ports 1-26 access deny state disable

3. Возникла следующая проблема:
На клиентском порту - 8 порт, начались проблемы с кабелем(либо возможно портом):
Диагностика выдает постоянно противоречивую информацию:
#cable_diag ports 8
Command: cable_diag ports 8
Perform Cable Diagnostics ...
Port Type Link Status Test Result Cable Length (M)
---- ------ ------------- ----------------------------- ----------------
8 FE Link Down Pair1 Short at 34 M -
Pair2 Open at 33 M

#cable_diag ports 8
Command: cable_diag ports 8
Perform Cable Diagnostics ...
Port Type Link Status Test Result Cable Length (M)
---- ------ ------------- ----------------------------- ----------------
8 FE Link Down Pair1 Short at 34 M -

из-за этого полезла петля на порту.

Порт сек включен и разрешен на 5 мак адресов.

Настройки loopdetect - a:
# LOOP_DETECT

enable loopdetect
config loopdetect recover_timer 60
config loopdetect interval 10
config loopdetect mode port-based
config loopdetect ports 1-12,14-22 state enabled
config loopdetect ports 13,23-26 state disabled

Лупдетект почему то не отрабатывал.
Как следствие получили:
1. Загрузку коммутатора под 100%.(Коммутатор ушел в защищенный режим SafeGuard ENGINE).
2. Коммутаторы по ветке ушли в 100% загрузку ЦПУ.
3. У всех коммутаторов по другим веткам, на которых настроен IGMP multicast Vlan, загрузка ушла в 90-100% и они вывалились в защищенный режим.
4. Причина оказалась именно в IGMP, так как при удалении на аггрегации влана 4040, через который идет мультикаст, все прекратилось. Нашли порт на аггрегации, а дальше по ветке.

Собственно вопрос - силами 3526 возможно как-нибудь ограничить передаваемый траффик мультикаст, при отказе порта, либо коротком замыкании (повторюсь - Лупдетект почему-то не отрабатывал и не ложил порт, сумели найти только по порт секам.).кабеля на порту, может есть какие-нибудь фильтры igmp, или еще что-то, что могло бы помочь?

P.S - на поиск аварии в ручную ушло окола 40 мин - стек из 4 цисок - 44 порта. Каждый проверять - долго. Да и по ночам не охото этим заниматься.

1. config igmp_snooping querier iptv state disable
2. Задействовать Traffic Control на клиентских портах в режиме Drop, шага 10pps хватит.

_________________
С уважением,
Бигаров Руслан.

Добрый вечер. У меня еще вопрос:
1. Есть ветка из 3526 прошивка b52 - 21 коммутатор замкнута в кольцо, поднят МСТП.
2. По ветке прокинут мультикаст влан. По вечерам, в часы наибольшей нагрузки начинают отваливаться крайние в кольце коммутаторы, уходят в защищенный режим при этом на аплинках у них сыпятся дропы, периодически по ветке перестраивается стп. Также иногда уходят в себя и остальные коммутаторы по ветке.
3. Траффик на 2 аплинках ветки порядка 300 Мбит в пике.
4. При отключении мультикаста все стабилизируется.

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

1. Обновить прошивку до последней версии.
2. Если Вы описываете проблему MSTP + IPTV, тогда приводите пример конфигурации обоих функций.

_________________
С уважением,
Бигаров Руслан.

Проблема не только в ветках где включено МСТП.
Также есть ветки работающие с 1 стороны, на них также первый коммутатор в ветке уходит в exhausted режим. И на транках начинает сыпаться дроп.

Настройки igmp:

enable igmp_snooping
create igmp_snooping multicast_vlan iptv 4040
config igmp_snooping multicast_vlan iptv member_port 1-12,14-22 source_port 13,23-26 state enable replace_source_ip 10.x.x.x
config igmp_snooping iptv host_timeout 260 router_timeout 260 leave_timer 2 state enable
config igmp_snooping querier iptv query_interval 125 max_response_time 10 robustness_variable 2
config igmp_snooping querier iptv last_member_query_interval 1 state enable
config limited_multicast_addr ports 1-26 access deny state disable

Последняя версия прошивки какая? И где ее можно взять?

Если есть PIM маршрутизатор, то он querier, т.е. на остальных коммутаторах querier включать не нужно, как это делаете Вы:
config igmp_snooping querier iptv last_member_query_interval 1 state enable
иначе, будут проблемы с переизбранием querier-а. Querier в сети должен быть один и находится максимально ближе к streamer-у.

P.S.: Вы какие версии прошивок используете?

_________________
С уважением,
Бигаров Руслан.

1. PIM маршрутизатором является Cisco7606, к ней подключен стример.
2. Прошивку используем в основном 5.01-В52.

1. Значит querier он, как я писал ранее, на остальных коммутаторах эту подфункцию включать не нужно.
2. Лучше обновить до версии 6.00.В51, хотя если на всех DES-3526 отключить querier, то может и так всё заработает нормально.

_________________
С уважением,
Бигаров Руслан.