Какими способами можно защититься от броадкаст-шторма на уровне L2 в корпоративной сети?

Защита от броадкаст-шторма на уровне L2 в корпоративной сети — важная задача, особенно когда речь идет о динамическом генерации трафика, таком как ARP-запросы. Вот несколько способов, которые могут помочь защитить управляемый L3 коммутатор и минимизировать последствия броадкаст-шторма:

1. **Броадкаст-лимиты**: Многие управляемые коммутаторы позволяют установить лимиты на уровень броадкаст-трафика. Это может помочь предотвратить чрезмерную нагрузку на сеть. Вы можете настроить ограничение на количество броадкаст-фреймов, которые могут проходить через порт в определенный период времени.

2. **ARP-спуфинг защита**: Используйте функции безопасности, такие как Port Security или Dynamic ARP Inspection (DAI), для предотвращения ARP-спуфинга. DAI проверяет ARP-запросы и отклоняет их, если они не соответствуют разрешенным записям.

3. **VLAN**: Разделите сеть на несколько VLAN. Это не только помогает уменьшить объем броадкаст-трафика, но и повышает уровень безопасности, поскольку устройства в разных VLAN не могут "слышать" друг друга.

4. **Применение Spanning Tree Protocol (STP)**: Хотя STP в первую очередь служит для предотвращения петель в сети, его настройки могут помочь снизить влияние ненужного броадкаст-трафика.

5. **Качество обслуживания (QoS)**: Настройте QoS для приоритизации важного трафика. Это может помочь уменьшить влияние броадкастов на критически важные приложения.

6. **Мониторинг и алерты**: Установите системы мониторинга трафика, такие как SNMP или NetFlow, которые могут помочь вам выявлять аномалии в трафике, включая резкие всплески ARP-запросов. Это позволит вам быстро реагировать на потенциальные проблемы.

7. **Управление активностью устройств**: Если возможно, ограничьте устройство, которое генерирует чрезмерное количество ARP-запросов. Это может быть реализовано на уровне конфигурации самого устройства или через сетевую безопасность.

8. **Создание статических ARP-записей**: Если известны IP-адреса и соответствующие MAC-адреса устройств, вы можете создать статические ARP-записи на коммутаторе, что может снизить количество генерируемых ARP-запросов.

9. **Изолирование проблемных устройств**: Если в сети появляется устройство, которое создает проблему, рассмотрите возможность его физического или логического изолирования до выяснения причин проблемы.

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

Вообще, начинать с корня - PortSecurity на портах, чтобы не подключали таких устройств. А если легитимное устройство начинает буйствовать то разбираться почему оно это делает. 
 
 Потому что защититься от хорошего наплыва L2 шторма (в моем случае был Gratitude ARP от 300+камер) не получится. У коммутаторов есть встроенные средства типа "Ограничения Broadcast или даже конкретно ARP на порту", но проблема в том, что вы не сможете разграничить полезный трафик и вредный на уровне коммутатора. А из профилактики - уменьшение размера Broadcast домена настолько, насколько это возможно. Ну и Port Security, еще раз.

К сожалению в нашем случае это может быть легитимное устройство - ПЛК или виртуальный контроллер на ВМ,  которое было подключено программистом-разработчиком в процессе настройки\тестирования. 
 
 Пока на текущий момент как вариант быстрого решения -  отделить эту подсеть отдельным роутером и в случае проблемы упадет этот роутер а не центральный...