Я воспроизвёл проблему на следующей конфигурации:
R1 и R2 настроены как ASBR-маршрутизаторы — они перераспределяют статические маршруты в OSPF как Type-1 внешние маршруты.
R1 имеет статический маршрут blackhole для 172.16.0.0/16
R2 имеет плавающий статический резервный маршрут для 172.16.0.0/16 с distance, равным 200.
OSPF использует область 0 для сети 192.168.1.0/24.
R3 выступает в роли клиента, показывая, что другие узлы увидят анонсируемое с R1 и R2.
Вот конфигурации маршрутизаторов:
R1
[admin@R1] > export compact
# jun/28/2016 17:59:17 by RouterOS 6.36rc13
# software id =
/ interface bridge
add name=loop
/ interface ethernet
set [ find default-name=ether4 ] comment=mgmt
/ routing ospf instance
set [ find default=yes ] redistribute-static=as-type-1 router-id=10.10.10.1
/ ip address
add address=10.1.1.1/24 comment=mgmt interface=ether4 network=10.1.1.0
add address=10.10.10.1 interface=loop network=10.10.10.1
add address=192.168.1.1/24 interface=ether1 network=192.168.1.0
/ ip route
add distance=1 dst-address=172.16.0.0/16 type=blackhole comment="test route primary"
/ routing ospf network
add area=backbone network=10.10.10.0/24
add area=backbone network=192.168.1.0/24
/ system identity
set name=R1
R2
[admin@R2] > export compact
# jun/28/2016 17:29:51 by RouterOS 6.36rc13
# software id =
/ interface bridge
add name=loop
/ interface ethernet
set [ find default-name=ether4 ] comment=mgmt
/ routing ospf instance
set [ find default=yes ] redistribute-static=as-type-1 router-id=10.10.10.2
/ ip address
add address=10.1.1.2/24 comment=mgmt interface=ether4 network=10.1.1.0
add address=10.10.10.2 interface=loop network=10.10.10.2
add address=192.168.1.2/24 interface=ether1 network=192.168.1.0
/ ip route
add distance=200 dst-address=172.16.0.0/16 type=blackhole comment="test route backup"
/ routing ospf network
add area=backbone network=10.10.10.0/24
add area=backbone network=192.168.1.0/24
/ system identity
set name=R2
R3:
[admin@R3] > /export compact
# jun/28/2016 17:30:17 by RouterOS 6.36rc13
# software id =
/ interface bridge
add name=loop
/ interface ethernet
set [ find default-name=ether4 ] comment=mgmt
/ routing ospf instance
set [ find default=yes ] router-id=10.10.10.3
/ ip address
add address=10.1.1.3/24 comment=mgmt interface=ether4 network=10.1.1.0
add address=192.168.1.3/24 interface=ether1 network=192.168.1.0
add address=10.10.10.3 interface=loop network=10.10.10.3
/ routing ospf network
add area=backbone network=10.10.10.0/24
add area=backbone network=192.168.1.0/24
/ system identity
set name=R3
Пока всё нормально, R3 показывает:
[admin@R3] /ip route> print where dst-address=172.16.0.0/16
Flags: X - отключено, A - активно, D - динамическое, C - напрямую подключено, S - статическое, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - недоступно, P - запрещено
DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADo 172.16.0.0/16 192.168.1.1 110
Если я отключаю маршрут на 172.16.0.0/16 на R1, тогда R2 берёт управление корректно:
[admin@R3] /ip route> print where dst-address=172.16.0.0/16
DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADo 172.16.0.0/16 192.168.1.2 110
Когда я снова включаю статический маршрут на R1, R2 отказывается убрать своё объявление, основанное на статическом маршруте с distance 200, и на R3 теперь установлен маршрут с балансировкой ECMP:
[admin@R3] /ip route> print where dst-address=172.16.0.0/16
DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADo 172.16.0.0/16 192.168.1.2 110
192.168.1.1
Очевидно, что ECMP можно исправить, изменив базовую метрику у R2, но суть не в этом – суть в том, что у R2 путь с меньшим distance для доступа к 172.16.0.0/16 – это OSPF-путь с distance 110. Однако OSPF НЕПРАВИЛЬНО игнорирует это обновление, потому что он уже сам объявляет этот маршрут через собственный статический маршрут.
[admin@R2] /ip route> print where dst-address=172.16.0.0/16
DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A SB 172.16.0.0/16 200
(обратите внимание, что OSPF-маршрут отсутствует – его даже нет в списке, даже как отключённого)
Если я отключаю статический маршрут и включаю его заново на R2, тогда всё возвращается в норму:
[admin@R2] /ip route> print where dst-address=172.16.0.0/16
DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADo 172.16.0.0/16 192.168.1.1 110
1 ASB 172.16.0.0/16 200
Такое ошибочное поведение наблюдается и когда маршрутизаторы вводят default-information в OSPF, исходя из другого протокола (static, BGP и т.д.).
Если я создаю ту же топологию на Cisco, поведение ожидаемое:
Когда R1 подтверждает доступность к 172.16.0.0/16, R2 отзывается и убирает свой внешний Type-1 маршрут из OSPF и устанавливает новый внешний Type-1 маршрут через R1 из OSPF в таблицу маршрутизации.
Я не говорю, что ROS должен делать всё как Cisco – это разные платформы, но когда в ROS есть ошибки в поведении, полезно показать, что другие платформы так не работают.
Я отправлю ещё один баг-репорт в Mikrotik с ссылкой на этот пост для подробностей.
