Mikrotik.moscow [тема: Вопрос по QSPF для экспертов] http://mikrotik.moscow Новое в теме Вопрос по QSPF для экспертов форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Tue, 04 Aug 2026 15:05:16 -0400 Вопрос по QSPF для экспертов Вопрос по QSPF для экспертов RouterOS в форуме RouterOS.
BUMP, прошло 5 лет, и мы наконец-то подошли к ROSv7. Мне интересно, решалась ли эта проблема в каком-то из релизов ROSv6 или в текущей бете ROSv7. EDIT: Думаю, лучше обновить эту тему, чем оживлять другую. Согласно этому сообщению, проблема до сих пор не решена. Но есть обходной путь. На дворе 2020-й, а проблема всё ещё актуальна. Обход для тех, кто наткнётся на эту статью: Впрысните на роутер две более мелкие маршрутизации через предпочтительное соединение — более мелкие маршруты всегда будут иметь приоритет над большими. Например: используйте статические маршруты 10.2.3.0/25 + 10.2.3.128/25 вместо 10.2.3.0/24 на предпочтительном линке.
16.05.2021 00:24:00, JJT211.]]> http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382410 http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382410 Sun, 16 May 2021 00:24:00 -0400 RouterOS Вопрос по QSPF для экспертов Вопрос по QSPF для экспертов RouterOS в форуме RouterOS.
Ответы техподдержки создают довольно ясное впечатление, что Mikrotik не планирует решать эту проблему в ROSv6 из-за фундаментальных особенностей реализации OSPF. Иначе говоря, в версии 7 будет серьезный пересмотр кода в части маршрутизации, и чтобы исправить это поведение, нужно именно такое обновление, поэтому оно будет выполнено только в ROSv7. (печально)
18.07.2016 13:52:00, ZeroByte.]]> http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382409 http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382409 Mon, 18 Jul 2016 13:52:00 -0400 RouterOS Вопрос по QSPF для экспертов Вопрос по QSPF для экспертов RouterOS в форуме RouterOS.
Я не знал об этом, спасибо! И я присоединяюсь к списку тех, кто считает, что это нужно исправить в следующем стабильном обновлении ROSv6, а не ждать ROSv7, потому что кто знает, когда мы вообще сможем увидеть это в релиз-кандидате.
17.07.2016 18:15:00, StefanM.]]> http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382408 http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382408 Sun, 17 Jul 2016 18:15:00 -0400 RouterOS Вопрос по QSPF для экспертов Вопрос по QSPF для экспертов RouterOS в форуме RouterOS.
Абсолютно с тобой согласен! Спасибо за твою лабораторную работу и подробный отчёт.
13.07.2016 20:20:00, bajodel.]]> http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382407 http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382407 Wed, 13 Jul 2016 20:20:00 -0400 RouterOS Вопрос по QSPF для экспертов Вопрос по QSPF для экспертов RouterOS в форуме RouterOS.
Я также нашёл свой предыдущий отчёт об этой ошибке, и Mikrotik заявил, что это поведение будет исправлено в ROSv7. Но, честно говоря, это слишком серьёзная ошибка, чтобы оставлять её без исправления в ROSv6.
28.06.2016 18:23:00, ZeroByte.]]> http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382406 http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382406 Tue, 28 Jun 2016 18:23:00 -0400 RouterOS Вопрос по QSPF для экспертов Вопрос по QSPF для экспертов RouterOS в форуме RouterOS.
Я воспроизвёл проблему на следующей конфигурации:  
Пользователь добавил изображение  

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 с ссылкой на этот пост для подробностей.
28.06.2016 18:08:00, ZeroByte.]]> http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382405 http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382405 Tue, 28 Jun 2016 18:08:00 -0400 RouterOS Вопрос по QSPF для экспертов Вопрос по QSPF для экспертов RouterOS в форуме RouterOS.
Хорошо, пора проверить это в GNS3, чтобы убедиться, что я говорю именно о том же, что и с инъекцией маршрута по умолчанию… И сначала поддержка Mikrotik сказала мне то же самое: «это не баг, это сделано для предотвращения петель маршрутизации». Я им объяснил, что они немного неправильно поняли поведение, и показал, как это работает корректно на Cisco, на что они ответили просто: «окей, это баг, и его исправят в будущих версиях ROS» — видимо, этот тикет закрыли и забыли.
28.06.2016 17:08:00, ZeroByte.]]> http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382404 http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382404 Tue, 28 Jun 2016 17:08:00 -0400 RouterOS Вопрос по QSPF для экспертов Вопрос по QSPF для экспертов RouterOS в форуме RouterOS.
Всем привет. Может, кто-то сможет помочь. У меня такая проблема: у клиентов есть основное оптоволоконное соединение и резервное — беспроводное. Обе линии заканчиваются в разных наших точках. Для основного подключения я настроил маршрутизацию сети клиента с помощью статического маршрута с обычной метрикой. В резервной точке тоже использую статический маршрут, но с метрикой 200. Обе точки находятся в области OSPF магистрали. Всё работает, как и ожидалось. Статический маршрут в резервной точке неактивен, а маршрут идёт через OSPF. В случае сбоя основного канала резервный маршрут становится активным, и всё нормально. Проблема: после восстановления основного канала резервный маршрут остаётся активным, несмотря на то, что в OSPF есть маршрут с меньшей метрикой. Это сделано специально? Кто может помочь?
12.06.2016 05:58:00, complete2006.]]> http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382403 http://mikrotik.moscow/forum/forum57/84016-vopros-po-qspf-dlya-ekspertov/message382403 Sun, 12 Jun 2016 05:58:00 -0400 RouterOS