Всем привет! Ранее я нашёл вот эту тему — там совсем непонятно было, что происходит, но мы решили попробовать отключить MD5-аутентификацию, предварительно убедившись, что все меры защиты от «прямых атакующих» работают и включены. Мы выключили OSPF MD5-аутентификацию. Это никак не решило проблему, поэтому подозреваем, что аутентификация изначально не была настоящей причиной. На той же странице сказано, что проблема — в потере пакетов. Мы же не видим потери связи (adjacency) ни на одном из маршрутизаторов.
Конкретный сетевой сегмент состоит из двух коммутаторов (каждый: 48×10G + 4×40G), связанных между собой парой и настроенных на vPC (LACP) до маршрутизаторов там, где это возможно, либо 10G активный + 2×1G LACP в режиме ожидания, если доступен всего один 10G порт. Также мы не наблюдаем потерь при отправке эхо-запросов/ответов (я только что отправил почти 10 миллионов таких запросов с интервалом 1 мс и получил 0% потерь — в этот период один из маршрутизаторов случайно выпал из OSPF). Мы фиксируем от 20 до 25 выбросов в день на каждый пострадавший маршрутизатор.
Подробные симптомы: Другие маршрутизаторы на том же L2 сегменте теряют маршруты, исходящие от этого MT, иногда на длительные периоды (например, полчаса и больше). Маршруты, исходящие из других источников и объявленные MT, не затрагиваются (то есть MT сохраняет свои маршруты к остальной сети).
Маршрутизаторы на этом сегменте (адреса интерфейсов и приоритеты выбора DR):
172.31.255.1 — FRR 8.2.2 — приоритет 200 — выпадал в 08:15:33
172.31.255.2 — FRR 8.2.2 — приоритет 200 (текущий DR) — выпадал в 08:15:42
172.31.255.3 — RouterOS 6.48.4 (будет обновлен в ближайшие 48 часов) — приоритет 1
172.31.255.5 — RouterOS 6.49.6 (текущий BDR, обновлён сегодня утром) — приоритет 1
В логах перед удалением маршрутов я замечаю много записей «Skipping flooding: from DR or BDR». Это логично — мы хотим раздавать обновления по сети только если маршрутизатор является DR или BDR. Но, подозреваю, что это также означает, что маршрутизатор недостаточно часто обновляет свои маршруты у DR и BDR. Не уверен, учитывается ли это, но я предположу, что если MT не информирует DR и BDR время от времени о том, что его маршруты ещё актуальны, то они будут периодически удаляться.
Что меня раздражает — после обновления сегодня утром перезагруженный маршрутизатор работает стабильно, а за этот же час (чуть больше 4) мы получили 4 сбоя на том узле, который не перезагружали (логи приведены выше для первого из них). По моему мнению, причина может быть одна из двух:
- Перезагрузка временно решает скрытую проблему, которая потом возвращается;
- Если маршрутизатор является DR или BDR, он раздаёт LSAs, благодаря чему у соседей обновляются маршруты.
Я недостаточно знаком с OSPF, чтобы подтвердить или опровергнуть любую из этих гипотез.
Последствия проблемы:
iBGP обычно должен подключаться к loopback-адресам — при сбое OSPF loopback’и тоже падают, iBGP не работает, сеть в целом отказывается работать. Нам пришлось перенастроить iBGP на интерфейсные адреса, что превращает сбои на канальном уровне в сбои маршрутизации, но таких сбоев намного меньше, чем сейчас с OSPF (несколько в год против почти часовых перебоев OSPF).
Неоптимальная внутренняя маршрутизация (например, маршруты BGP с /21 пойдут через route-reflector, а более точные /28 из OSPF — через другой маршрутизатор). Это добавляет лишь небольшую задержку, но не катастрофу, поскольку next-hop направит правильно (хотя он и не MT).
Не работает маршрутизация напрямую подключенных маршрутов, исходящих с Mikrotik (похожая проблема с loopback’ами). К счастью, эти сети в основном для EGP-маршрутизации, так что обычно проблема не блокирующая, поскольку доступ к ним нужен только самому маршрутизатору.
Первый пункт — критичный для всей сети. Да, можно обходиться маршрутизацией по интерфейсным адресам, но это сильно нивелирует смысл избыточности в сети.
Готов создать pcap всего трафика на стороне FRR (это с гораздо меньшим влиянием на производительность), но могу предоставить Mikrotik сырые логи OSPF напрямую в поддержку Mikrotik (не могу публиковать их открыто, но готов обсудить и проверить).
Конкретный сетевой сегмент состоит из двух коммутаторов (каждый: 48×10G + 4×40G), связанных между собой парой и настроенных на vPC (LACP) до маршрутизаторов там, где это возможно, либо 10G активный + 2×1G LACP в режиме ожидания, если доступен всего один 10G порт. Также мы не наблюдаем потерь при отправке эхо-запросов/ответов (я только что отправил почти 10 миллионов таких запросов с интервалом 1 мс и получил 0% потерь — в этот период один из маршрутизаторов случайно выпал из OSPF). Мы фиксируем от 20 до 25 выбросов в день на каждый пострадавший маршрутизатор.
Подробные симптомы: Другие маршрутизаторы на том же L2 сегменте теряют маршруты, исходящие от этого MT, иногда на длительные периоды (например, полчаса и больше). Маршруты, исходящие из других источников и объявленные MT, не затрагиваются (то есть MT сохраняет свои маршруты к остальной сети).
Маршрутизаторы на этом сегменте (адреса интерфейсов и приоритеты выбора DR):
172.31.255.1 — FRR 8.2.2 — приоритет 200 — выпадал в 08:15:33
172.31.255.2 — FRR 8.2.2 — приоритет 200 (текущий DR) — выпадал в 08:15:42
172.31.255.3 — RouterOS 6.48.4 (будет обновлен в ближайшие 48 часов) — приоритет 1
172.31.255.5 — RouterOS 6.49.6 (текущий BDR, обновлён сегодня утром) — приоритет 1
В логах перед удалением маршрутов я замечаю много записей «Skipping flooding: from DR or BDR». Это логично — мы хотим раздавать обновления по сети только если маршрутизатор является DR или BDR. Но, подозреваю, что это также означает, что маршрутизатор недостаточно часто обновляет свои маршруты у DR и BDR. Не уверен, учитывается ли это, но я предположу, что если MT не информирует DR и BDR время от времени о том, что его маршруты ещё актуальны, то они будут периодически удаляться.
Что меня раздражает — после обновления сегодня утром перезагруженный маршрутизатор работает стабильно, а за этот же час (чуть больше 4) мы получили 4 сбоя на том узле, который не перезагружали (логи приведены выше для первого из них). По моему мнению, причина может быть одна из двух:
- Перезагрузка временно решает скрытую проблему, которая потом возвращается;
- Если маршрутизатор является DR или BDR, он раздаёт LSAs, благодаря чему у соседей обновляются маршруты.
Я недостаточно знаком с OSPF, чтобы подтвердить или опровергнуть любую из этих гипотез.
Последствия проблемы:
iBGP обычно должен подключаться к loopback-адресам — при сбое OSPF loopback’и тоже падают, iBGP не работает, сеть в целом отказывается работать. Нам пришлось перенастроить iBGP на интерфейсные адреса, что превращает сбои на канальном уровне в сбои маршрутизации, но таких сбоев намного меньше, чем сейчас с OSPF (несколько в год против почти часовых перебоев OSPF).
Неоптимальная внутренняя маршрутизация (например, маршруты BGP с /21 пойдут через route-reflector, а более точные /28 из OSPF — через другой маршрутизатор). Это добавляет лишь небольшую задержку, но не катастрофу, поскольку next-hop направит правильно (хотя он и не MT).
Не работает маршрутизация напрямую подключенных маршрутов, исходящих с Mikrotik (похожая проблема с loopback’ами). К счастью, эти сети в основном для EGP-маршрутизации, так что обычно проблема не блокирующая, поскольку доступ к ним нужен только самому маршрутизатору.
Первый пункт — критичный для всей сети. Да, можно обходиться маршрутизацией по интерфейсным адресам, но это сильно нивелирует смысл избыточности в сети.
Готов создать pcap всего трафика на стороне FRR (это с гораздо меньшим влиянием на производительность), но могу предоставить Mikrotik сырые логи OSPF напрямую в поддержку Mikrotik (не могу публиковать их открыто, но готов обсудить и проверить).
