OSPF bird, маршрут прилетает от того узла его его нет. Куда копать?

Столкнулся на тестовом стенде с проблемой когда маршрут прилетает от того хоста, где этого маршрута по факту нет.
Вот схема сети:

Все соединения OSPF между серверами PtP.
Конфигурация bird на всех хостах идентична(конечно router id разные у всех) вот пример с OSPF1:

router id 192.168.201.1;  filter input {     if net = 0.0.0.0/0 then reject;     else accept; }  filter output {     if net ~ [ 10.99.99.0/24{32,32} ] then accept;     else reject; }  protocol kernel {     ipv4 {         import all;         export all;     };     scan time 10;     learn; }  protocol device {     scan time 10; }  protocol ospf {     ipv4 {         export filter output;         import filter input;     };     area 102 {         interface "eth1" {             cost 100;             hello 2;             dead 6;             type ptp;         };         interface "eth2" {            cost 100;            hello 2;            dead 6;            type ptp;         };     }; }

При такой конфигурации проблема в том что при обрыве связи между OSPF1 и OSPF3 маршрут 10.99.99.59/32 прилетает от хоста OSPF2, какую настройку крутить чтобы исключить прилёт маршрутов от клиентских устройств.
Даже если я на OSPF2 не буду ничего отдавать (export none;) маршрут 10.99.99.59/32 на OSPF1 я всё равно увижу.
Что было сделано:
1. Были соединены OSPF1 и OSPF4, маршрутизация перестраивается корректно и маршрут я вижу от OSPF4, но завязываться на это соединение не очень хочется, т.к. при его обрыве есть риск получить маршрут от какого-нибудь устройства из клиентской сети.
2. Можно на всех клиентских хостах включить опцию "stub router" тогда маршрута с OSPF2 не будет, но OSPF2 будет принимать все маршруты от серверных хостов с максимальной метрикой и в такой конфиге отсутствует возможность рулить маршрутизацией с помощью cost.

Дополнительно:

Судя по ваше схеме, все работает так как должно - при обрыве связи OSPF1-OSPF3, маршрут до целевой сети пойдет по пути OSPF1-OSPF2-OSPF4-OSPF3 - протокол именно так и работает.

• Да, я понимаю что маршрутизация построится именно так.
  Мне нужно чтобы так не строилось, может как-то распилить на зоны? Но тогда получится слишком много зон(каждый клиент своя зона)
  Или есть какие-то другие не очевидные опции которые позволят на серверной части отбрасывать такие маршруты? Пока у меня вариант отбрасывать если OSPF.metric1 больше определённого значения
• Можно на OSPF2 отдавать только connected-сети, но тогда какой смысл делать OSPF, если не будет резервирования маршрутов?
• По идее резервирование будет осуществляться за счёт OSPF1 и OSPF4.
  Странное то что если даже маршрута 10.99.99.52/32 нет в таблице маршрутизации на OSPF2, то он всё равно прилетает на OSPF1.
  Может я неправильно изначально приступил к построению OSPF?
• Так, если нет прямой связи между OSPF1 и OSPF4, вы так и будете получать маршрут на OSPF1 от OSPF2. Не нужно с этим бороться, это нормальное поведение протокола OSPF.
  Для вашей топологии прекрасно подходит.
• Вы задачу понормальному опишите. Чего хотите добиться-то на тестовом стенде??
• Kuddesnik, обычно в OSPF можно cost выставлять линкам, чтобы выбирались предпочительные. Самым ненужным выставить очень высокие значения, чтобы туда что-то пошло только если уж совсем всё развалится...
• asmelnik, добиться хочу чтобы на OSPF1 я видел маршрут 10.99.99.59/32 только от хоста OSPF3 или OSPF4 (при наличии связи с OSPF4), и не получать маршрут от хоста OSPF2.
• Kuddesnik, В таком случае, сделайте постоянный линк между OSPF1 и OSPF4 - это решит все ваши проблемы. Пока линка нет, путь до OSPF4 все равно будет лежать через OSPF2
• Kuddesnik,
  С точки зрения архитектуры OSPF это вот вообще неправильно, он link-state, а вы от него path-vector по факту хотите. для этого BGP есть :)

  Получается по факту вам надо НЕЗАВИСИМЫЕ OSPF1 и OSPF4, чтоб они друг о друге вообще не знали.

  На OSPF3 и OSPF2 делаете по 2 шт OSPF-а, это допустимо как в BIRD, так и практически в любой железячной реализации.
  OSPF3.1 -- только интерфейс на OSPF1, и фильтром -- что ему знать можно
  OSPF3.4 -- только интерфейс на OSPF4, и фильтром -- что ему знать можно
  На OSPF2 -- аналогично.

  Либо горку stub area делать.

  Для OSPF-а важно, чтоб его "внутренняя" топология на всех узлах была однинаковая, а вы как раз хотите ее "перекосить", что крайне не желательно.

• Да, похоже это единственный выход, либо городить костыли, либо пересматривать архитектуру.
  Всем спасибо за ответы!