FRR/OSPF не выбирает оптимальный маршрут

viktor_g

@solo_s
Что если BFD отключить?
Что в логах FRR, WireGuard? Какие события?

Solo_S

Отключение BFD на клиническую картину не влияет.
В логах FRR в момент переключения на "второй" канал тишина, даже при том, что влючен Extended level логирования. Т.е. когда, например, перезавпускаю OSPF или меняю состояние интерфейсов, что провоцирует согласование маршрутов, в логе вижу всю цепочку Init -> ExStart -> Exchange -> Full (ExchangeDone), а вот через час - полная тишина.
И я не могу найти, где настраиваются логи Wireguard, у меня пакет 0.1.5. В syslog не пишет. О состоянии могу судить только по статусу пиров.

werter

@solo_s
У BFD таймер (время на отработку) выставлен меньше ,чем у ospf ?
https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/concept/ospf-bfd-overview.html

Вот тут в Advanced Options - https://docs.netgate.com/pfsense/en/latest/packages/frr/bfd/peers.html .Может эти настройки и покрутить?

Зы. В крайнем случае на IPSec VTI перейти (временно) вместо WG.

Solo_S

@werter Спасибо! У BFD тайминги на порядок меньше. Дополнительный монитоинг канала показывает, что сами туннели в момент переключения не лагают. Тут именно как-то криво обрабатывается LS. Нейборы живы, в router database все лики видны, а в результирующей ospf database часть пропадает (ингода востанавливается черз какое-то время, но не всегда). Происходит это как только age доходит до 0, т.е. ровно спустя час после успешного согласования маршрутов. Иногда перезапуск frr помогает на сутки двое, а затем опять каждый час начинается расколбас.
Кажется, что причина кроется в сегменте, где стык pfsense и wyos, хотя frr и конфиги идентичные (пока предположение, потому, как после тестового отключения канала на ночь маршруты не лагали, но это гипотиза).
IPSec не мой вариант, увы. Либо WG (в целом он прекрасен), либо OpenVPN (со всеми его плюсами и, к сожалению, минусами).

werter

@solo_s
ОГРОМНАЯ просьба, выложить мануал с картинками по настройке этого дела.
Тема впн + дин. маршрутизация крайне актуальна и пригодится многим.
Заранее благодарен )

Solo_S

@werter Пока рановато с картинками. Т.е. оно как бы работает, но не так как предполагалось. Склонен предполагать, что это баг в текущей версии FRR, но допускаю, что мои кривые руки.
На текущий момент реализована full mesh сеть между пятью локациями с резервированием по провайдерам и почти все какждый-с-каждым. OSPF поднимается и адекватно реагирует на разрывы соединений (посредством BFD). Но вот периодически по истечении LS age в расчете Дейкстры возникает лажа (по моему субъективному видению): выбираются маршруты с суммарным большим весом, чем существующие и живые (bfd и ospf пакеты бодро бегают между соседями) рядом, а иногда в результате таких хаотичных перестроений маршрут до какой-нибудь локации вообще не строится (при этом целевой роутер есть в database, соседи в Full-стейте, BFD - Up), т.е. как бы ничто не предвещает. И ладно, если кто-то куда-то идет в обход, неприятно, но не смертельно, а вот когда что-то отваливается, это хуже.
Первое случается почти ежедневно, второе раз в неделю-две. Пока лечение такое: гавкнул мониторинг - сходил на любой из узлов и клацнул большую карсную (кажется, что разработчики что-то знают об этой багуле и недоговаривают, иначе с чего бы такой жир) кнопку "Force Service Restart". Пять секунд и вся сеть идеальна (в точности соответствует конфигам).

Мануал прост:

поднять туннели, не забыть открыть внутри bfd ospf (у меня вообще any - any, фильтрую отдельно, не на гейтах)
мастер-пароль, прфикс-лист с сетью за шлюзом, роуд-мапу с этим префиксом и set metric 10
прописать зону (у меня единственная 0.0.0.0)
прописать интерфейсы (я делаю unicast для однозначности), прописать в них косты, MD5-пароли и интервалы, заэнейблить bfd (локальный - пассивный)
явно прописать соседей (т.к. unicast, ну т.е. network non-broadcast)
прописать BFD-пиры

Всё.
Если интерсны мои интервалы, то опытным путём вышел на:

ip ospf dead-interval 12
ip ospf hello-interval 3

и BFD profile

detect-multiplier 3
receive-interval 300
transmit-interval 300
echo-interval 50
no shutdown
echo-mode

еще явно прописал у роутера
timers throttle spf 200 1000 10000
и у соседей
poll-interval 10

З.Ы. Чуть не забыл, на VPN-интерфейсах пропишите корректные MTU/MSS (для WG это 1420/1380), поверьте, это важно

werter

Добрый.
@solo_s
Это вас провидение "наказывает" (шутка юмора) за то ,что не хотите мануалом с картинками делиться )
Это ж не сложно. Лучше один раз увидеть, поверьте.
И как вы роуты, выдаваемые по ospf фильтруете - acl или route map?

werter

@solo_s said in FRR/OSPF не выбирает оптимальный маршрут:

Первое случается почти ежедневно, второе раз в неделю-две. Пока лечение такое: гавкнул мониторинг - сходил на любой из узлов и клацнул большую карсную (кажется, что разработчики что-то знают об этой багуле и недоговаривают, иначе с чего бы такой жир) кнопку "Force Service Restart". Пять секунд и вся сеть идеальна (в точности соответствует конфигам).

В кач-ве костыля в cron скрипт, к-ый будет передергивать службу по пингу удаленного узла?

Solo_S

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

Solo_S

В целом проблема сохранилась и оформилась в такую картину.
Сеть не "моргает", в т.ч. BFD не регистрирует потерь, соседи в сстоянии Full. Нагрузка на CPU не превышает 5%, памяти достаточно. При этом сразу после запуска/перезапуска FRR все выглядит предсказуемо, OSPF DB соответствует конфигурации.
Но... ровно через час (буквально до секунды) и без единой записи в логи происходит следующее:

из Net Link States пропадает линк на соседа
из OSPF network routing table выпиливается маршрут в транзитную сеть
из OSPF external routing table пропадает маршрут в целевую сеть

При этом OSPF Neighbors без изменений, сосед в Full, в BFD интерфейс Up.
Из замеченного: в Thread statistics for ospfd появляется ospf_maxage_lsa_remover.
Лечится (ну если можно так назвать) через FRR/Global Settings - Force Service Restart (ну тут в логах все красиво), после чего все работает... ровно час.
Конфиг:

frr defaults traditional
...
log syslog
service integrated-vtysh-config
!
interface tun_wg0
...
 ip ospf network non-broadcast
...
 ip ospf dead-interval 12
 ip ospf hello-interval 3
 ip ospf bfd
router ospf
 ospf router-id Х.Х.Х.Х
 log-adjacency-changes detail
 redistribute kernel route-map ХХХ
 timers throttle spf 200 1000 10000
 passive-interface vmx1
 area 0.0.0.0 shortcut default
 neighbor 10.Х.Х.2 poll-interval 10
!
...
bfd
 profile profile1
  detect-multiplier 3
  receive-interval 300
  transmit-interval 300
  echo-interval 50
  no shutdown
  echo-mode
 !
 peer 10.Х.Х.2 local-address 10.Х.Х.1 interface tun_wg0
  profile profile1

Немного помогает добавление альтернативных маршрутов, тогда при отвале одного включается другие, правда иногда ассиметрично, при том, что косты расставлены корректно и для каждого конечного маршрута однозначно. Т.е. ручной рассчет дейкстры не совпадает с выбранным маршрутизатором. Да собственно и в OSPF external routing table виден результирующий кост, который больше, чем живые альтернативы.

Уже обновлял PFSense и FRR, играл с FW и MTU/MSS, медитировал на BFD и OSPF пакеты на интерфейсах...

Идеи закончились. Угнетает тишина в логах при потере маршрутов. Готов возвращаться на статику (BGP не предлагать).

Буду благодарен за любые конструктивные идеи.