Общая информация
Broadcast-шторм — лавинообразный поток широковещательных кадров (BUM-трафика: broadcast / unknown unicast / multicast), генерируемый абонентским оборудованием и «съедающий» ресурсы сети. Burst — кратковременный импульс такого трафика (всплеск при загрузке устройств, массовом DHCP/ARP).
Среда PON — разделяемая: восходящий трафик всех ONT одного pon-port делит одну полосу. Поэтому flood от одного абонента заметен всем: деградация услуг на PON-порту, рост загрузки uplink, нагрузка на CPU OLT.
Шторм из-под абонента и петля на L2 — связанные, но разные сценарии. Для блокировки ONT по дублирующемуся MAC на OLT встроен отдельный механизм — см. Защита от петель на L2 в PON. Данная статья — про штормы, которые этот механизм не ловит (шторм без дублей MAC).
Типичные причины «из-под абонента»
- Петля в абонентской LAN: неуправляемый коммутатор или «разводка» ТВ-кабеля, воткнутые в один свитч оба конца одной витой пары, объединение двух роутеров/квартир в один мост.
- Неисправное сетевое устройство: сетевая карта или Wi-Fi-ретранслятор с некорректной прошивкой могут генерировать большое количество повторных широковещательных кадров.
- Заражённое устройство: массовые ARP-запросы (IPv4) и Neighbor Discovery (IPv6-аналог ARP), flood на DHCP-сервер.
- Flood прикладного уровня: discovery-протоколы «умного дома», старые IPTV-приставки.
- Burst при старте: одновременная загрузка нескольких устройств после отключения питания — кратковременный, не требует лечения, если не повторяется.
Последствия шторма зависят от схемы построения сети. В схеме VLAN на абонента (S-VLAN/QinQ) broadcast flood между абонентами не транслируется, но потребляет восходящую полосу pon-port и ухудшает услуги соседним ONT. В схеме с общей VLAN (единая VLAN на услугу/группу абонентов) flood дополнительно достигает всех абонентов общей VLAN.
Признаки шторма
| Где смотрим | Что видно |
|---|---|
| Uplink OLT | Жалобы абонентов одного PON; аномальный рост Rx Broadcast на uplink-интерфейсах (front-port) |
| Логи OLT | Сообщения DNA - Rate limit: started storm of broadcast traffic on pon-port N (если на pon-port настроен rate-limit с log) |
| Аварии OLT | Аварии ont-broadcast-storm / ont-multicast-storm (при включённом storm-control в профиле shaping) |
| Статусы ONT | BLOCKED у абонента-источника (если в назначенном ему профиле shaping задан параметр logging shutdown) |
Диагностика: поиск источника
1. Смотрим uplink OLT — убеждаемся, что flood идёт со стороны абонентов:
LTP-16N# show interface front-port 1 counters verbose front-port 1 statistics Rx Bytes 1036092010553 Rx Packets 942068752 Rx Unicast Packets 406883966 Rx Multicast Packets 507776425 Rx Broadcast Packets 27408363 ...
Резкий рост Rx Broadcast Packets при нормальном unicast — признак шторма из сети абонентов.
2. Смотрим аварии — OLT сам именует источник (если storm-control в профилях shaping включён, см. далее):
LTP-16N# show alarms active type ont-broadcast-storm LTP-16N# show alarms history type ont-broadcast-storm
Дублирование в систему мониторинга — SNMP-трапы ont-broadcast-storm (см. раздел «Настройка аварий и трапов»).
3. Проверяем статусы ONT на подозреваемом PON-порту:
LTP-16N# show interface ont 12 connected
ONT в состоянии BLOCKED — вероятный «штормующий» абонент с включённой автоматической блокировкой.
4. Смотрим счётчики GEM-порта ONT — строка Broadcast:
LTP-16N# show interface ont 3/3 counters olt-side gem-port ----------------------------------- [ONT 3/3] GEM port statistics ----------------------------------- GEM port id Rx Packet Rx Bytes Tx Packet Tx Bytes ----------- ------------ ----------- ------------ ------------ 204 0 0 0 0 Broadcast 0 0 530071 723511865 Multicast 0 0 60 3840
Здесь Rx — трафик от ONT на OLT (upstream). Аномально большие Rx Packet / Rx Bytes в строке Broadcast — признак штормящего терминала. Обходим ONT подозреваемого PON-дерева и сравниваем значения.
Если шторм активен, но профиль со storm-control на абонентах не настроен и автоматических аварий нет — временно включите на подозреваемом pon-port ограничение broadcast с логированием:
LTP-16N# configure terminal LTP-16N(configure)# interface pon-port 1 LTP-16N(config)(if-pon-1)# rate-limit broadcast 51200 65536 log LTP-16N(config)(if-pon-1)# do commit LTP-16N(config)(if-pon-1)# do save
где 51200 — лимит kбит/с на входе pon-port, 65536 — размер буфера в байтах (значения подбираются под ёмкость PON, см. [LTP-N, LTX, MA5K] Rate-limit на front-port, pon-port). При превышении в логе появится started storm of broadcast traffic on pon-port 1 — по PON-порту срабатываний и сужают поиск. После локализации источника настройку снимают: no rate-limit broadcast.
Для захвата содержимого flood используйте RSPAN — см. [LTP-N, LTX, MA5160] Зеркалирование трафика в VLAN (RSPAN).
Защита и подавление
1. Storm-control в профиле shaping (по каждой ONT)
Storm-control ограничивает скорость upstream-рассылки broadcast/multicast на стороне самой ONT. Настройка — в профиле shaping, профиль назначается на ONT.
Создание профиля:
LTP-16N# configure terminal LTP-16N(configure)# profile shaping storm-protect LTP-16N(config)(profile-shaping-storm-protect)# upstream broadcast storm-control enable LTP-16N(config)(profile-shaping-storm-protect)# upstream broadcast storm-control logging shutdown LTP-16N(config)(profile-shaping-storm-protect)# exit
Параметры (аналогично для multicast):
| Команда | Назначение | По умолчанию |
|---|---|---|
upstream <TYPE> storm-control enable | Включить контроль шторма (broadcast/multicast) | выключено |
upstream <TYPE> storm-control rate-limit <1-10000> | Порог, пакетов в секунду | 1000 |
upstream <TYPE> storm-control logging | Писать в лог при превышении порога | включено |
upstream <TYPE> storm-control logging shutdown | Плюс отключать (блокировать) ONT при превышении | выключено |
Выбор порога rate-limit. Порог сравнивается со скоростью upstream broadcast (или multicast) одной ONT в пакетах в секунду. Легитимные фоны и всплески абонентской сети — IGMP join/leave IPTV-приставок, discovery «умного дома», ARP/DHCP при одновременном старте устройств — укладываются в десятки–сотни pps; шторм — десятки тысяч pps, различие на порядки. Рекомендации (инженерные, не норматив):
- broadcast — 1000 pps (значение по умолчанию): покрывает все перечисленные легитимные сценарии с запасом и остаётся на порядок ниже штормового уровня. Ниже 500 pps опускать не рекомендую — начинаются ложные блокировки на нормальных всплесках.
- multicast при IPTV с несколькими приставками — 2000–3000 pps, либо multicast-канал настраивают только на
loggingбезshutdown. - точное значение проверяют по счётчикам: замеряют базовый уровень
show interface ont <ID> counters olt-side gem-portу типового абонента и ставят порог с 5–10-кратным запасом.
Назначение профиля на ONT:
LTP-16N# configure terminal LTP-16N(configure)# interface ont 12/12 LTP-16N(config)(if-ont-12/12)# profile shaping storm-protect LTP-16N(config)(if-ont-12/12)# exit LTP-16N# commit LTP-16N# save
При превышении порога ONT переходит в состояние BLOCKED и генерируется авария ont-broadcast-storm. Время блокировки задаётся глобально:
LTP-16N(configure)# pon olt ont-block-time <30-86400> Maximum unactivated timeout (sec)
По умолчанию 120 секунд для LTP-N / LTX. Для MA5160 команда выполняется из view слота:
MA5160(config)(slot-1-16)# pon olt ont-block-time <30-86400> Maximum unactivated timeout (sec)
Досрочный вывод из блокировки: reconfigure interface ont <PON>/<ONT>. После истечения таймера ONT активируется повторно; при продолжении шторма — блокируется снова.
Настройка аварий и трапов (из режима конфигурации — в alarm):
LTP-16N(configure)# alarm LTP-16N(config)(alarm)# ont-broadcast-storm severity major
Трапы SNMP о начале (... in) и окончании (... out) шторма по умолчанию включены; категория аварии по умолчанию — info. Если события шторма мониторингу не нужны, их отключают (ont-broadcast-storm in false), аналогично настраиваются ont-multicast-storm и время жизни аварии (ttl).
Параметр shutdown у storm-control автоматически выключает ONT при превышении порога — абонент остаётся без услуг до истечения ont-block-time, а при сохраняющейся проблеме блокировки будут повторяться циклически. Порог должен быть выше легитимных всплесков трафика, которые считаются в тот же счётчик: IGMP join/leave от IPTV-приставок (особенно при переключении каналов и старте нескольких приставок), discovery «умного дома» (mDNS, SSDP, UPnP — принтеры, колонки, датчики), ARP/DHCP при одновременном включении многих устройств после сбоя питания. Используйте порог не ниже 1000 pps (см. «Выбор порога rate-limit») — заниженный порог превращает защиту в серию ложных блокировок: абонент «теряет интернет» на время ont-block-time без реальной причины.
2. Rate-limit на pon-port — страховка уровня порта
Ingress rate-limit на pon-port отсекает flood на входе PON-порта на стороне OLT и защищает саму OLT и uplink. Настройка:
LTP-16N# configure terminal LTP-16N(configure)# interface pon-port 1 LTP-16N(config)(if-pon-1)# rate-limit broadcast 51200 65536 log LTP-16N(config)(if-pon-1)# do commit LTP-16N(config)(if-pon-1)# do save
При превышении в логе OLT появляются сообщения:
24 Nov 11:50:05 NOTICE DNA - Rate limit: started storm of broadcast traffic on pon-port 16. 24 Nov 11:50:20 NOTICE DNA - Rate limit: ended storm of broadcast traffic on pon-port 16. Total drop 6513228 bytes.
Пороги по front-port/pon-port/port-channel для LTP-N, LTX и MA5160 различаются; полный порядок настройки — в [LTP-N, LTX, MA5K] Rate-limit на front-port, pon-port.
3. Принудительное отключение ONT
Если источник установлен, а разбирательство с абонентом откладывается:
LTP-16N# configure terminal LTP-16N(configure)# interface ont 12/12 LTP-16N(config)(if-ont-12/12)# shutdown
Включение обратно — no shutdown.
Профилактика
- Назначайте базовый профиль shaping со storm-control на все ONT при активации (через template / EMS), а не постфактум по жалобам.
- Трапы
ont-broadcast-storm/ont-multicast-stormвключены по умолчанию — проверьте, что они не отключены в разделеalarmи доходят до системы мониторинга. - Используйте
rate-limit broadcast/multicastна pon-port как второй уровень защиты. - Отдельно от штормов «из-под абонента» защищайте multicast-сервисы: включите IGMP querier на OLT (Функционал IGMP Querier на OLT) — без него IGMP-обмен и unknown multicast обрабатываются как broadcast и сами становятся источником flood; ограничьте доступные для ONT multicast-группы (Ограничение доступных для ONT multicast групп) — это не даёт приставке или заражённому устройству «разкачать» multicast-поток на весь PON.
Особенности и ограничения
- Storm-control в профиле shaping по умолчанию выключен; порог по умолчанию — 1000 pps, логирование по умолчанию включено.
- Storm-control ограничивает upstream-трафик на самой ONT; rate-limit на pon-port работает на стороне OLT и подавляет flood уже на входе порта.
Связанные статьи
- Защита от петель на L2 в PON
- [LTP-N, LTX, MA5K] Rate-limit на front-port, pon-port
- Возможные состояния ONT на OLT
- [LTP-N, LTX, MA5160] Зеркалирование трафика в VLAN (RSPAN)
- Функционал IGMP Querier на OLT
- Ограничение доступных для ONT multicast групп
- [LTP-X, MA4000] Настройка storm-control для ONT (прежнее поколение OLT)