Comments 70
Профилактика бессильна против мультикаста. Его тогда надо просто рубить.
ИМХО только первый пункт даст результаты, остальное мёртвому припарки.
P.S. я когда-то описывал подобную проблему — ТЫЦ, можете почитать для ознакомления.
P.S. я когда-то описывал подобную проблему — ТЫЦ, можете почитать для ознакомления.
У нас, чтобы сделать первый пункт, нужно сделать для начала 3 :)…
по практике подобных реорганизаций, можно говорить, что умные свичи достаточно поставить только в ядро сети. Какой-нибудь длинк на 16 портов уже спасёт сеть: на каждый порт можно повесить отдельный сегмент сети, который будет относительно небольшим. А внутри этого сегмента пусть будет бродкаст.
Ну и кроме followme printing бывают други источники бродкаста. Их тоже можно различными способами душить. Таким образом, в своё время я наблюдал как в сети на 300 машин было достаточно «тихо».
Ну и кроме followme printing бывают други источники бродкаста. Их тоже можно различными способами душить. Таким образом, в своё время я наблюдал как в сети на 300 машин было достаточно «тихо».
Почитал. Можно у вас получить пару комментариев?
1. А на цисках был классический STP вместо рапид? RSTP вообще-то в случае измения топологии себя иначе ведет, там это называется синхронизацией, на таймеры вообще не завязано, отрабатывает от миллисек до максимум 1-2 сек для всего домена.
2. Не знаю как 2950, а 2960 как и упомянутые 3560 порт по шторму кладут только если это настроить. По дефолту просто срезают пакеты выше планки, ну и в лог и если настроено — трап. Почему порт клался, а не просто резались пакеты выше лимита?
1. А на цисках был классический STP вместо рапид? RSTP вообще-то в случае измения топологии себя иначе ведет, там это называется синхронизацией, на таймеры вообще не завязано, отрабатывает от миллисек до максимум 1-2 сек для всего домена.
2. Не знаю как 2950, а 2960 как и упомянутые 3560 порт по шторму кладут только если это настроить. По дефолту просто срезают пакеты выше планки, ну и в лог и если настроено — трап. Почему порт клался, а не просто резались пакеты выше лимита?
1. На доступе RSTP, в ядре MSTP. Какой именно коммутатор на тот момент был ROOT для данного vlan я точно не помню, вполне возможно, что как раз коммутатор с MSTP. Но TC там были точно, ибо я их лично снимал снифером с этой сетки, ну и со всеми вытекающими.
Кстати — ТЫЦ, см. раздел «New BPDU Format». Механизм другой, просто сокращено кол-во ситуаций, при которых выставляется флаг TC, но Topology Change никто не отменял.
2. В том же вилане находился и management интерфейс 2950, соответственно он пытался переварить весь этот шторм, проц там слабый и он моментально загружался, пропуская и\или не обрабатывая приходящие пакеты BPDU в том числе. Он не по шторму ложил порт, а по LoopGuard, так как не получал BPDU длительное время (статья начиналась строчкой из лога 2950).
3. По комменту ниже — клался аплинк до распределения. И он(аплинк) там был один.
Кстати — ТЫЦ, см. раздел «New BPDU Format». Механизм другой, просто сокращено кол-во ситуаций, при которых выставляется флаг TC, но Topology Change никто не отменял.
2. В том же вилане находился и management интерфейс 2950, соответственно он пытался переварить весь этот шторм, проц там слабый и он моментально загружался, пропуская и\или не обрабатывая приходящие пакеты BPDU в том числе. Он не по шторму ложил порт, а по LoopGuard, так как не получал BPDU длительное время (статья начиналась строчкой из лога 2950).
Loop Guard – переводит порт в Inconsistent state, если порт перестал получать BPDU, изолируя таким образом проблемный участок сети от участия в построении STP. Применяется к конкретному порту командой spanning-tree loopguard enable. Используется глобально командой spanning-tree loopguard default. Невозможно использовать одновременно с RootGuard.В данном случае была использована глобальная команда.
3. По комменту ниже — клался аплинк до распределения. И он(аплинк) там был один.
Вы только не подумайте, что я придираюсь :) Просто интересно разобраться до конца. Итак. Сторм-контрол реально не клал порт, как я понимаю. Он зарезал по некой уставке броадкасты/мультикасты. Таким образом и бпду перестали ходить, попав под это дело, правильно мыслю? Перестали ходить бпду, луп гуард положил порт. Упал порт, пошли уже друие процессы. А какова была уставка сторм-контрола, не вспомните? Тоже интересно.
Да не было там storm-control — это точно!
Перечитайте мой ответ внимательно.
BPDU-то может и приходили, проблема в другом — проц 2950 из-за огромного кол-ва броадкастов просто не успевал их все обрабатывать, а у процесса STP тем не менее таймер-то тикал, и он приходил к выводу что BPDU вообще не приходят — вот вам и сработка по LoopGuard.
Хотя это лишь моё предположение, но других объяснений я тогда не видел, и сейчас не вижу.
P.S. Этот процесс сопровождался высокой загрузкой проца, что также было зафиксировано.
Перечитайте мой ответ внимательно.
BPDU-то может и приходили, проблема в другом — проц 2950 из-за огромного кол-ва броадкастов просто не успевал их все обрабатывать, а у процесса STP тем не менее таймер-то тикал, и он приходил к выводу что BPDU вообще не приходят — вот вам и сработка по LoopGuard.
Хотя это лишь моё предположение, но других объяснений я тогда не видел, и сейчас не вижу.
P.S. Этот процесс сопровождался высокой загрузкой проца, что также было зафиксировано.
Спасибо.
На сторм-контрол навели вот эти ваши слова
«Дело в том, что когда они огребают такое количество широковещательного трафика, они воспринимают это как broadcast-storm». Справедливости ради надо отметить, что раз сторм-контрола не было, как вы убедительно сказали, значит и «воспринимают» тут ни при чем. Опять же не для придирок, а для ясности картины. Т.к. случай, имхо, интересный.
«Дело в том, что когда они огребают такое количество широковещательного трафика, они воспринимают это как broadcast-storm». Справедливости ради надо отметить, что раз сторм-контрола не было, как вы убедительно сказали, значит и «воспринимают» тут ни при чем. Опять же не для придирок, а для ясности картины. Т.к. случай, имхо, интересный.
Ну да.
Согласен. ))))
Согласен. ))))
К слову и для полноты картины
img.nag.ru/projects/setup/0bd/7861e1222e50bbfdeb074aa6fce8e9c6.pdf
В RSTP изменения топологии вызывают только неграничные порты, переходящие в состояние пересылки. Это означает, что в отличие от 802.1D потеря связи более не рассматривается как изменение топологии (то есть порт, переходящий в блокирующее состояние более не создает TC).
img.nag.ru/projects/setup/0bd/7861e1222e50bbfdeb074aa6fce8e9c6.pdf
В RSTP изменения топологии вызывают только неграничные порты, переходящие в состояние пересылки. Это означает, что в отличие от 802.1D потеря связи более не рассматривается как изменение топологии (то есть порт, переходящий в блокирующее состояние более не создает TC).
И потом. Блочились аксессные порты или алпинки, не совсем понял. Ну и «Loop guard blocking port» — loop гуард это вообще-то защитная фишка именно для stp, что бы блочить порт, если бпду-шки перестали получать. Сторм-контролу вообще по барабану причина шторма. Петля там или просто хост трафик генерит. И опять же — луп гуард надо настраивать вручную.
Если же клался клиентский порт — то почему он не фаст? Обычный ап/даун фаста не дает события изменения топологии.
Если же клался клиентский порт — то почему он не фаст? Обычный ап/даун фаста не дает события изменения топологии.
Когда я вижу какие-то не ожидаемые проблемы в сети с получением адреса, всегда первым делом запускаю сниффер.
Была похожая ситуация. Обнаружили случайно, когда игрались со сниффером. Нашли уйму UDP траффика. Оказалось, эфир засоряла одна из Цисок (основной маршрутизатор) из-за того, что там был прописан лишний маршрут. Забыли поправить после перекроссировки.
Выводы верны:
wi fi в одной сети, домен разделить в разные сети по зданиям/этажам.
Сам недавно столкнулся с подобной проблемой.
wi fi в одной сети, домен разделить в разные сети по зданиям/этажам.
Сам недавно столкнулся с подобной проблемой.
Без умных свитчей, конечно, туго. Я в таких случаях в первую очередь лезу на свитч, чтоб посмотреть чего и сколько он через себя прогоняет. Ваша проблема проявилась бы моментально. Но да, я избалован цисками вплоть до уровня доступа :)
Пойду wireshark посмотрю…
storm-control broadcast level или
storm-control broadcast level pps
storm-control multicast level или
storm-control multicast level pps
При срабатывании сообщения вида %STORM_CONTROL-3-FILTERED: A Multicast storm detected on Gi0/6. A packet filter action has been applied on the interface.
Если нет денег на свичи, способные это или что-то похожее — держать на каком-нибудь сервачке (можно в виртуалке) tcpdump, ловящий эти самые броадкасты, ротейтить перодически логи и парсить простейшим скриптом, при аномалиях — письмо админу. Если сегментов несколько — ввести этот тазик в каждый посредством транка. Можно еще arpwatch какой-нибудь параллельно заюзать для статистики по мак-ам/ип или на базе уже описанного выше парсера получить тот же функционал.
storm-control broadcast level pps
storm-control multicast level или
storm-control multicast level pps
При срабатывании сообщения вида %STORM_CONTROL-3-FILTERED: A Multicast storm detected on Gi0/6. A packet filter action has been applied on the interface.
Если нет денег на свичи, способные это или что-то похожее — держать на каком-нибудь сервачке (можно в виртуалке) tcpdump, ловящий эти самые броадкасты, ротейтить перодически логи и парсить простейшим скриптом, при аномалиях — письмо админу. Если сегментов несколько — ввести этот тазик в каждый посредством транка. Можно еще arpwatch какой-нибудь параллельно заюзать для статистики по мак-ам/ип или на базе уже описанного выше парсера получить тот же функционал.
:) Денег нет — держим wireshark и binaryplant arp monitor. Первый помог в этот раз, второй выручал в предыдущий (некое активное сетевое устройство притворялось эпизодически шлюзом).
unix way рулит
tcpdump + perl или Net::Pcap — максимальная гибкость под любые задачи
tcpdump + perl или Net::Pcap — максимальная гибкость под любые задачи
Странно, сетка в полтыщи хостов — уже кое-что. По крайней мере в ядро можно поставить что-то более умное. Да оно у вас и стоит, раз умеет дхцп. Вы уверены, что оно не умеет сторм контрол? У мнея древние ат8326, которые чистые л2, не умеют даже рстп, а сторм-контрол есть однако.
Стоит, но доступа к ней нет. Сетевик который ей рулит отделался общей фразой — «ищите проблему у себя внутри сети».
Ааа, так у вас вон еще какая градация. Ну завалите ему её и скажите — ищи теперь у себя :) Тем более что при его подходе к работе завалить наверное будет не квадратурой круга. Он ее из какого сегмента админит? Есть выделенный для этих целей? :)
Пусть это останется на его совести. Зато я свой скил прокачал.
Я только не понял, почему широковещание, учитывая что у вас плоский сегмент = широковещательный домен имело какое-то ограничение. Почему на нижней группе свичей проблема была, а выше — не было. На то оно и широковещание, что бы распространяться во всем л2 сегменте. Или на рисунке все же не один л2 сегмент?
Хороший вопрос. Скорее всего причина в том, что чем дальше тем тупее коммутаторы + количество трафика где то на грани их производительности
Ну нее. Широковещание или кладет все или нет (если его не резать как-либо). И потом, кроме невыдачи ип по дхцп проблемы были? Если бы броадкаст-флуд убил сетку, то там ничего нормально не работало бы. Просто напрочь. Если глючил дхцп, причем местами, а остальное — нет, боюсь, вы или не поняли реального механизма проблемы или поняли не до конца. Как раз где-то в сети может таки есть сторм-контрол настроенный, который как раз и срезал широковещание по планочке, от чего страдали протоколы, которым броадкаст нужен для работы хотя бы на каком-то этапе. Дхцп из них. Очень даже похоже.
Да и не верю я, что этот широковещательный дискаверинг сервиса мог так зафлудить сеть. Видел я подобные вещи и вижу регулярно, они не генерят такого зверского потока. А вот то, что у вас где-нибудь как раз на указанной вами границе сети сработал сторм-контрол где-то так на 500 — 2000 пакетов в секунду и не пропускал более — очень похоже. Отсюда и наблюдаемые эффекты + все же работоспособность сети в целом.
Так рубить трафик могла только магистральная циска (мой доступ к ней я уже описал). Есть еще один нюанс — она не DHCP, она пробрасывает трафик DHCP извне. Рисунок доступности — условный — но факт, остается фактом — страдали пользователи дальних (нижних) коммутаторов. Если уточнять схему-рисунок, то магистральный коммутатор находится над верхним на схеме коммутатором.
Уверены? У вас полностью неуправлямые свичи доступа? Просто совершенно не сходятся «концы» у истории. Широковещательный домен = единый домен отказа, чем оно и плохо. По совокупности «показаний» не вытанцовывается классическая картина флудосмерти сети.
Сниффер был подключен к верхнему (следующему за магистральным) коммутатору, картинку по % левых бродкастов брал с него. Завтра (на работе) проверю возможности зоопарка наших коммутаторов, может какой нибудь, чего нибудь и может.
Дальше от ядра, возможно, стоят самые древние свитчи, при флуде не справляющиеся с нагрузкой и начинающие терять пакеты.
Гринфин? :)
Каждый раз читая описания таких сетей у меня волосы шевелятся на всех возможных местах. Как эти сети работают в организациях для меня загадка, 500 машин и нет денег на бюджетные L2. Нет элементарного мониторинга состояния сети, проблему решают люди не имеющие прав доступа к головному коммутатору. Как, скажите мне как за 5 лет это первая проблема такого рода? Чем будете ловить ARP флуд или другие аномалии, для которых снифер на конечной машине ни как не поможет?
Да часто люди говорят — у нас обычные свичи, ниче не умеют. Ну прямо мыльницы. Уточнишь — умеют и 802.1q и stp и еще из минимального набора. При этом управляющий влан не настроен, конфиг дефолтовый. Раз один человек рассказал, как он попробовал включить stp и сеть пропала на полминуты (что логично :), если вспомнить о значении таймеров). Он застремался и все вернул в зад :)
Если так, то тут вопрос банальной некомпетентности сетевого администратора. Но я лично видел брудкаст домен на 1.5К хостов построенный на «мыльницах» — это чудовище еле ворочалось, загибалось от любого чиха в сети, на счетчики nonunicast пакетов было страшно смотреть, представил тут такую же структуру (следуя из описания). 802.1q + SNMP мониторинг уже решит 80% сетевых проблем, по крайней мере, вовремя предупредит о них. По поводу человека с STP, и правильно сделал, в чистом виде (не mstp или VRR) штука достаточно неповоротливая да и со стабильностью не очень, а включать не понимая всех возможных граблей только сделать хуже.
Как бэ это был год, когда классический stp для свича было уже круто и ничего другого еще просто не было. А на счет правильно — от чего же. Только от того, что топология без петель? Ну так его и учили за это юзеры, кривыми руками эти петли устраивавшие. На счет же стабильности — любые вариации на тему stp имеют свои риски, не даром это надо уметь готовить и недаром вендоры городят свои защитные механизмы в духе root guard, loop guard да и тот же storm-control как фича «последней надежды» так же крайне рекомендуется. Однако без stp риски еще больше и опять же недаром это часто включено по умолчанию.
Были бы у меня свичи хотя бы одного бренда (не говоря об одной серии), я бы с Вами согласился, а так, что толку от vlan и stp, если первые глючат, от вторых сеть тупит (проверено в реалиях)… Большая часть (верхний уровень) моих коммутаторов — L2, тем не менее это не спасло.
Как у вас глючат vlan? Тег не добавляется, не убирается, не обрабатыватся? Даже на дешевых смартах годами работают без единого сбоя, на совсем дешевых поделках бывают проблемы с гибридным режимом, и то не часто, но без него почти всегда можно обойтись. Виланы — не панацея, от проблем в сети не спасают, но позволяют ее локализовать очень не плохо ну и нарезка брудкастдомена позволяет незначительным штормам умирать по ttl раньше, чем достигнут критичного масштаба.
Как правильно заметил casperrr STP нужно уметь готовить, сколько устройств было в кольце, какие таймеры выставлены и прочее?
Если так, то скорее всего и snmp статистику ваши свичи отдавать умеют, делаем мониторинг который собирает эту статистику со всех свичей со всех портов и выводит на графики, получаете во первых средство быстрой диагностики проблем, во вторых видите узкие каналы.
Следующий шаг — добавить в сеть фаирвол (вполне подойдет софтверный) и перед аггрегацией виланов проганять трафик через него, вырезая из траффика все не нужное, закрыв вирусные порты и т.д.
Мультивендорство не отмазка для администратора, у меня в сети 9 вендоров, а уж разных моделей железяк так вообще вагон (сложилось исторически, выкупали уже существующие сети и интегрировали в себя) и это почти не мешает, единственное на стыке таких железок нельзя использовать фирменные технологии, все же остальные вполне нормально работают, тот же IEEE 802.1Q открыт и везде работает одинаково.
Громкое название статьи, открывая надеялся увидеть что-то типа автоматически строящегося vlan-per-user с опцией 82, хитрый анализатор траффика с автоматическим управлением железом или что-то типа того, но никак не описание «как мы выключали взбесившийся демон»
Как правильно заметил casperrr STP нужно уметь готовить, сколько устройств было в кольце, какие таймеры выставлены и прочее?
Если так, то скорее всего и snmp статистику ваши свичи отдавать умеют, делаем мониторинг который собирает эту статистику со всех свичей со всех портов и выводит на графики, получаете во первых средство быстрой диагностики проблем, во вторых видите узкие каналы.
Следующий шаг — добавить в сеть фаирвол (вполне подойдет софтверный) и перед аггрегацией виланов проганять трафик через него, вырезая из траффика все не нужное, закрыв вирусные порты и т.д.
Мультивендорство не отмазка для администратора, у меня в сети 9 вендоров, а уж разных моделей железяк так вообще вагон (сложилось исторически, выкупали уже существующие сети и интегрировали в себя) и это почти не мешает, единственное на стыке таких железок нельзя использовать фирменные технологии, все же остальные вполне нормально работают, тот же IEEE 802.1Q открыт и везде работает одинаково.
Громкое название статьи, открывая надеялся увидеть что-то типа автоматически строящегося vlan-per-user с опцией 82, хитрый анализатор траффика с автоматическим управлением железом или что-то типа того, но никак не описание «как мы выключали взбесившийся демон»
Однажды надо было пропустить через один коммутатор (AT950GS) трафик обратным ходом — сделал vlan по портам (иначе кольцо) — в итоге ничего не вышло, сеть стала падать, хотя не так сильно как при прямом кольце), нашел 5-портовый комутатор переключил этот трафик на него и все заработало… После этого читал, что они (AT) выпустили новую прошивку, где исправили багу с vlan-ами. После этого для себя я сделал вывод, что для vlan нужно что-то получше web-smart-switch-а.
Что значит обратным ходом, если не секрет?
Предполагаю это когда трафик прогоняется через какой-то сервер в обоих направлениях и там 2 сетевые и воткнуто 2 патчкорда с одного свича. Как пример интернет воткнут в свич, затем заходит на сервер (по вилану), сервер уже выступает в качестве маршрутизатора и раздает интернет во всю сеть через другую сетевую в этот же свич. Встречал такое у небольших провайдеров.
Возможно. Тут тогда вопрос в том, реально ли это были две разных сетевухи, или она одна с поддержкой 802.1q. Если одна и она работает транком, то можно себе представить эту проблему в случае SVL, а не IVL. Мак на влан-ах у сервера будет один (ну или на влан-е и нативный), а для SVL это не есть хорошо, как раз эффекты неприятные начнутся.
да нет. все проще: канал уходит из объекта «А» на объект «Б» и возвращается обратно на «А» (но должен был попасть в другу сеть), там была оптика и выход с медиаконвертера в 1G, а коммутатор дрогой сети 100М, надо было как-то преобразовать интрефейс из 1G в 100М.
Все равно не совсем понял этот изврат, если коротко, то на одном свиче получились закольцованные порты, но в разных влан-ах? Опять же, если свич svl — так делать нельзя, мак-и будут между портами скакать. Только на индепендент реализациях так можно делать. И это даже не баг, это если угодно фича.
Да. Так и было.
При шаред влан нельзя одному маку светиться в разных влан-ах. При этой реализации таблица общая. Тут не в баге прошивки дело, а просто в знании.
Кстать, указанная вами модель телесина умеет сторм-контрол как по броадкасту так и по мультикасту. И даже по дестинейшн локап фэйл ака анкновн юникаст.
www.alliedtelesis.com/manuals/S109V110WEBa/PdfManual/S109V110WEBa.pdf
Так что свич хоть и веб-базед, а вполне себе много чего умеет.
www.alliedtelesis.com/manuals/S109V110WEBa/PdfManual/S109V110WEBa.pdf
Так что свич хоть и веб-базед, а вполне себе много чего умеет.
А можете деть линк на багтреккер с описанием этого бага? Очень интересно глянуть что вызывало проблему, я разное видел в сетях и флудящие арпами медиаконвертора и кольца на неактивных портах и коллизии хешей, но вот с проблемой работы виланов пока столкнуться не посчастливилось.
Конечно, не тратьте деньги. А потом расскажите нам как вы ловили петли, искали человека подменявшего физический адрес, ну и под конец про то как вы решили пустить мультикаст и «ой, сеть упала». Да и человека который за всем следить будет тоже не берите, пользователи то теперь в курсе. Да, а самое главное паровоз из ваших свичей всегда наращивайте, не гоже когда каждый l2 свич смотрит напрямую в маршрутизатор.
Деньгами, я не распоряжаюсь, поэтому Ваш сарказм не уместен… Наша позиция о том что все активное сетевое оборудование необходимо заменить руководству озвучена уже как года 3.
Сарказм на эти темы уместен всегда ибо оборудование уже не стоит космических денег. Это раз. 2 — у вас явно не хватает знаний по теме, значит, если другого человека нет, надо читать или идти на курсы, в сетевую академию cisco например.
Вместо ваших вышеупомянутых AT950GS (кстати, allied telesis никогда не делали нормальных свичей) у которых 24 гигабитных порта, можно уставиться catalyst 2950G, которые нынче стоят копейки.
Лечить broadcast флуд скриптом который ходит по компам это здорово, но как только характер флуда изменится вы все начнете сначала.
Вместо ваших вышеупомянутых AT950GS (кстати, allied telesis никогда не делали нормальных свичей) у которых 24 гигабитных порта, можно уставиться catalyst 2950G, которые нынче стоят копейки.
Лечить broadcast флуд скриптом который ходит по компам это здорово, но как только характер флуда изменится вы все начнете сначала.
Пустое. Вы часом не наш крутой сетевик :) он тоже про циски любит поговорить, из кустов, про курсы, однако проблему решали мы — необразованые, на Телсинках и прочей ериси типа Длинков и Трисомах?
Боже упаси попасть в контору где явно не видят проблем дальше своего носа. А про циски я могу сколько угодно говорить — у меня они стоят везде и я знаю что они стоят не дороже тех же самых d-link'ов. А про телсинки и трисомы я вообще не слышал и за 5+ лет практики не видел. Кстати о курсах, сам я их не заканчивал, статус CCNA получал после прочтения книг. Пустое — это когда люди решают такого рода задачи по несколько дней и сваливают все на то что у них оборудование плохое, денег нет, да и сами необразованные.
Как то громко статья названа. Это вы не победили, а устранили временную проблему.
Флуд — был? Был. Побежден? Побежден. Причина выявлена? Выявлена! Выводы сделаны? Сделаны. Нормальное название.
Осталось победить флуд под статьей :)
Осталось победить флуд под статьей :)
Обычно флуд, всякие штормы и ddos побеждают на сетевом оборудовании, а не на клиентском.
Сделали выводы это хорошо.
Cisco даже рекомендует что в одном широковещательном домене не должно быть более 256 хостов, у вас 500. Более умные L2 коммутаторы проблему не решат.
Посмотрите в сторону таких железок, Juniper SRX100.
Сделали выводы это хорошо.
Cisco даже рекомендует что в одном широковещательном домене не должно быть более 256 хостов, у вас 500. Более умные L2 коммутаторы проблему не решат.
Посмотрите в сторону таких железок, Juniper SRX100.
А на клиентском источник флуда оставлять принято? Нужно и то и то.
Более умные L2 коммутаторы как раз проблему очень даже могут решить. В случае старттопика это был скорее всего флуд с широковещанием как по L2 так и по L3. Банальный PACL мог бы помочь. Для корпоративных сетей централизация сервисов с одной стороны и душение межпользовательского общения в рамках сегмента с другой — нормальное дело и для этого как раз нужны умные свичи. А в условиях изоляции клиентского порта тем или иным способом всяким флудам негде разгуляться или на крайняк сильно ограничивается область действия и соответсвенно последствия.
Более умные L2 коммутаторы как раз проблему очень даже могут решить. В случае старттопика это был скорее всего флуд с широковещанием как по L2 так и по L3. Банальный PACL мог бы помочь. Для корпоративных сетей централизация сервисов с одной стороны и душение межпользовательского общения в рамках сегмента с другой — нормальное дело и для этого как раз нужны умные свичи. А в условиях изоляции клиентского порта тем или иным способом всяким флудам негде разгуляться или на крайняк сильно ограничивается область действия и соответсвенно последствия.
Sign up to leave a comment.
Побеждаем широковещательный флуд в корпоративной локальной вычислительной сети