http://mikrotik.moscow Новое в теме OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Sat, 23 May 2026 19:35:07 +0300 OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Привет, я этого не понимаю. Причина, почему для меня это бессмысленно, в том, что единственная проблема, с которой мы сталкиваемся с OSPFv2 на RouterOS, — это то, что в некоторых случаях у нас он переходит в состояние «full» слишком рано, до того как получает все LSA. Иногда он получает очень мало LSA, и таблица маршрутизации почти пустая, многие пути недоступны. В таких случаях ровно через полчаса таблица маршрутизации становится полной, и все отсутствующие маршруты появляются, и больше ничего не пропадает. Если бы было правдой, что MikroTik не отправляет LSA каждые полчаса, я не понимаю, почему именно полчаса — это для нас «волшебный» интервал, после которого внезапно у маршрутизатора есть все маршруты и дальше всё работает нормально.
15.09.2022 12:00:00, mducharme.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427416 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427416 Thu, 15 Sep 2022 12:00:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Соседство никогда полностью не сбрасывается… обновляется только LSA, что поддерживает маршруты. Все ли тайминги OSPF одинаковы между устройствами? Например, у нас была проблема с нестабильностью OSPF на FortiOS v7.0.6 при использовании таймеров по умолчанию (неявных), и нам пришлось их явно настраивать. Есть ли промежуточные коммутаторы (или логика коммутаторов внутри OSPF-устройств), которые могут ограничивать мультикаст-пакеты, например, с помощью rate limiting, IGMP snooping и т. п.? Явных таймеров нет, все опирается на таймеры по умолчанию (указанные в стандарте). Ранее я исследовал этот вопрос, и единственные таймеры, с которыми реально можно влиять, — это hello-таймеры, и их рассогласование приводит к сбоям установления соседства, как и с MTU.  

Для ясности, на обеих инстансах FRR таймеры настроены так:  
Hello 10 с, Dead 40 с, Wait 40 с, Retransmit 5 с.  
И на обоих MikroTik:  
retransmit-interval=5 с, transmit-delay=1 с, hello-interval=10 с, dead-interval=40 с.  

Согласно документации, transmit-delay и wait — это разные вещи и не влияют на протокол.  

Wait заставляет FRR ждать это время перед перерасчетом (https://docs.frrouting.org/en/latest/ospfd.html), а MikroTik говорит всего лишь: «link state transmit delay — это приблизительное время передачи пакета обновления состояния ссылки на интерфейсе», что толком ничего не объясняет.  

Стандарт предписывает, что LSA действует 3600 секунд и должен пересылаться каждые 1800 секунд, а retransmit-interval нужен для получения подтверждений (ACK) при передаче.  

Другими словами, MikroTik должен отправлять (и получать ACK) для LSA каждые полчаса. Но он этого не делает.  

Надеюсь, RoS7 исправит это, поскольку текущая настройка BGP дошла до настоящего ужаса, и мы очень хотели бы ее привести в порядок.  

Что касается ограничения скорости вещания и мультикаста, то с прошлого вечера установлено ограничение на уровне 1% от пропускной способности интерфейса, чтобы смягчить проблемы с внешним пирами (не под нашим прямым контролем), который мешал и вызывал неполадки.  

1% кажется немного, но все задействованные порты — 10G, то есть разрешено до 100 Мбит/с вещания и еще 100 Мбит/с мультикаста на каждый порт. Большинство из них — агрегированные через LACP в vPC на паре CISCO Nexus, то есть потенциально до 20G. Хотя, насколько я понимаю, вещательный трафик хэшируется на один из линков в соответствии с политикой LACP egress hash.  

Кажется, я уже выкладывал логи MikroTik, которые показывают, что LSA обновление не отправляется.  

Соседство при этом поддерживается корректно всё время.
15.09.2022 07:41:00, jkroon.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427415 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427415 Thu, 15 Sep 2022 07:41:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
В любом случае могу только подтвердить, что RouterOS 6.48.6 в смешанной среде с устройствами разных производителей работает нормально. В нашей основной сети устройства Mikrotik CCR общаются с Cisco, Aruba, Fortigate и другими, и соседство держится уже много дней, так что стоит обратить внимание на другие моменты. Все ли тайминги OSPF одинаковы между устройствами? Например, у нас была проблема с нестабильностью OSPF на FortiOS v7.0.6 при использовании стандартных (неявных) таймеров OSPF, пришлось настраивать их вручную. Есть ли промежуточные коммутаторы (или внутренняя логика коммутаторов в OSPF-устройствах), которые могут ограничивать мультимедийные пакеты — например, rate limiting, IGMP snooping и прочее? Алекс
15.09.2022 06:41:00, AlexDF.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427414 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427414 Thu, 15 Sep 2022 06:41:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Это правда. И сейчас мы закупаем два новых маршрутизатора на RouterOS7 (существующие планируем перенести в новый POP). Просто пока не хватало смелости массово переходить на RouterOS v7. В течение ближайших двух-четырёх недель начнем закупки и постепенно мигрируем сервисы и пиринги по одному на эти два новых CCR-маршрутизатора. Рассматривали вариант использовать что-то другое, но решили пока остаться на Mikrotik.

Что касается стабильности с новой конфигурацией:

> /routing ospf export  
# sep/15/2022 07:14:23 by RouterOS 6.49.6  
# software id = 22X0-517R  
#  
# model = CCR1016-12S-1S+  
/routing ospf instance  
set [ find default=yes ] distribute-default=if-installed-as-type-1 router-id=loop_ip
/routing ospf interface  
add interface=bonding-cisco.2-routing network-type=broadcast priority=0  
/routing ospf network  
add area=backbone network=172.31.0.0/16  
add area=backbone network=loop_ip/32  

Мы не увидели никакого улучшения:  
2022-09-15 00:20:16: ospf  
2022-09-15 01:51:01: bgp  
2022-09-15 02:01:01: ospf  
2022-09-15 03:37:01: bgp  
2022-09-15 04:31:01: ospf  
2022-09-15 05:31:01: bgp  
2022-09-15 06:01:01: ospf  
2022-09-15 06:17:01: bgp  
2022-09-15 06:18:02: ospf  

Код, используемый для отслеживания этого:

#! /bin/bash

loop_ips=(... ... ...)

for ip in "${loop_ips[@]}"
do  
cproto=$(ip ro sh $ip/32 | sed -nre 's/^.* proto ([^ ]+)( .*)?$/\1/p')
lproto=$(tail -n1 .$ip.proto | sed -re 's/.* //')  
[[ "${cproto}" != "${lproto}" ]] && date "+%F %T: ${cproto}" >> .$ip.proto
done  

Пока что loopback-интерфейсы не уходят в недоступное состояние, и хотя текущее решение НЕ МОЖЕТ масштабироваться (что, конечно, проблема), по крайней мере, мы работаем.
15.09.2022 05:20:00, jkroon.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427413 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427413 Thu, 15 Sep 2022 05:20:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Итак, могу подтвердить ваше понимание. Судя по всему, большинство маршрутизаторов других брендов тоже работают примерно так. Мы копнули глубже с пассивным интерфейсом, но так и не смогли воспроизвести тот же результат, что был раньше. Предполагаем, что NMBA мог быть задействован, чтобы корректно проксировать через беспроводной мост, который плохо обращался с мультикаст-трафиком. Сейчас мы решили вместо этого перераспределять connected и static маршруты через iBGP (хотя предпочли бы этого избежать). При этом перераспределение connected и static теперь отключено со стороны OSPF.

Для connected маршрутов мы можем использовать стратегию с пассивным интерфейсом, но для static это не работает (а они нам нужны, потому что некоторые пиры отказываются работать по eBGP и настаивают на статической маршрутизации). Спасибо за последний совет — это полезно.

Это не наш первый опыт с крайне нестабильным OSPFv2 на Mikrotik — даже при p2p "ethernet" линке (т.е. OSPFv2 в /30 сети только для маршрутизации) мы писали скрипты, которые детектировали ошибочное состояние OSPF и автоматически исправляли ситуацию. К сожалению, эти проверки здесь не работают.

Там была совершенно другая сеть, и одна из компаний, с которыми мы сотрудничаем, придумала устраивать "перезагрузку раз в неделю" в 2 часа ночи для всех routerboard в сети, чтобы смягчить ту же проблему. Но когда маршрутизаторы заняты ключевыми ролями, такой вариант исключён. Даже обновления прошивок тщательно проверяются, чтобы понять, действительно ли они нужны, ведь запланировать даже 5 минут простоя на перезагрузку проблематично, независимо от времени суток. Причём заполнение таблиц BGP занимает намного больше времени.

В идеале Mikrotik просто интегрировал бы frr в RouterOS и дело с концом.
14.09.2022 22:11:00, jkroon.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427412 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427412 Wed, 14 Sep 2022 22:11:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Я просто хотел сказать, что полностью согласен с @AlexDF. По моему опыту, OSPFv2 на MikroTik работает очень надёжно, если всё рекламировать через OSPF->Networks и при этом отключить перераспределение. И если раньше у вас интерфейс был настроен как пассивный, но соседство всё равно устанавливалось, значит, что-то было действительно не так — такого быть не должно. Советую добавить интерфейс «all» и установить ему passive, тогда по умолчанию все интерфейсы будут пассивными, кроме тех, которые явно прописаны как активные.
12.09.2022 23:46:00, mducharme.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427411 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427411 Mon, 12 Sep 2022 23:46:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Хорошо, я повторно проверю и подтвержу. Спасибо.
12.09.2022 19:12:00, jkroon.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427410 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427410 Mon, 12 Sep 2022 19:12:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Извините, но я вполне уверен, что пассивный интерфейс не может устанавливать соседство и не может получать маршруты от других OSPF-маршрутизаторов. Согласно документации Mikrotik: «passive (yes | no; По умолчанию: no) — если включено, не отправляет и не принимает OSPF-трафик на этом интерфейсе». Чтобы убедиться, я воспроизвел в лаборатории два устройства RouterOS, соединенных через Ethernet-интерфейс; каждое из них имеет loopback-интерфейс с одним IP-адресом, который совпадает с router ID; оба имеют соседство по OSPF через Ethernet. Когда у обоих маршрутизаторов Ethernet-интерфейс «активен» для OSPF, IP-адреса loopback успешно обмениваются, но если на одном из двух маршрутизаторов Ethernet-интерфейс пометить как пассивный, оба теряют соседство и оба теряют маршрут до loopback IP другого. Подтверждается, что пассивный режим означает игнорирование входящего OSPF-трафика, что подтверждается и в документации других производителей. Алекс
06.09.2022 14:25:00, AlexDF.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427409 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427409 Tue, 06 Sep 2022 14:25:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Насколько я знаю, ты ошибаешься. Режим Passive просто значит, что устройство не будет активно посылать Hello-сообщения, но оно точно войдёт в сеть, если другие будут их отправлять. Мы используем это в нашей сети в других местах. В любом случае, можешь сделать тест с использованием IP-адреса loopback как OSPF-сети? Очевидно, что на сегменте loopback соседей нет. Loopback-интерфейс безопасен, ведь никто не может туда транслировать пакеты. Да, конечно, мы можем это протестировать, хотя я уверен, что это не изменит ситуацию. Всё равно придётся делать redistribute connected, чтобы повторно анонсировать все остальные /29, но если loopback в итоге останется активным — тогда да, можно применить это и к другим сегментам, учитывая безопасность. Даже не нужно явно делать loopback passive — по умолчанию он такой, потому что у него нет интерфейсов, связанных с мостом. Ты уверен, что в сети нет пересечений IP на loopback или одинаковых router-id? Если ты спрашиваешь, уверен ли я, что нет дублирующихся router-id в сети — то да, я в этом уверен. То же самое и с повторяющимися IP-сетями, так что все маршруты заканчиваются в отдельном L2-домене, будь то loopback-домен или Ethernet-сегмент (чаще всего VLAN).
04.09.2022 15:29:00, jkroon.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427408 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427408 Sun, 04 Sep 2022 15:29:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Привет, Jkroon! Я почти уверен, что пассивный интерфейс не сможет подключиться к активным OSPF-соседям в одном сегменте LAN и не обрабатывает полученные Hello, так что безопасно использовать такой способ вместо redistribute connected. В любом случае, можешь провести тест, включая IP-адреса loopback как сеть OSPF? Очевидно, что на сегменте loopback соседей нет. Ты точно уверен, что в сети нет пересечений IP loopback или router ID? Алекс
02.09.2022 16:21:00, AlexDF.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427407 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427407 Fri, 02 Sep 2022 16:21:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Наоборот. MK поддерживает маршруты к другим хостам. Другие хосты теряют маршруты к MK из-за того, что их не «обновляют» в течение часа, как описано в предыдущем посте. Мы специально не хотим включать другие сети и делать интерфейс пассивным, так как они ЧАЩЕ всего подключены к клиентам. При этом даже пассивный интерфейс МОЖЕТ присоединиться к OSPF, если другой хост на сегменте начнёт рекламировать OSPF, что мы уже видели у некоторых наших клиентов, так что это слишком рискованно.

redistribute-connected делает то, что нам нужно — распределяет напрямую подключённые маршруты и позволяет нам двигаться дальше. Сейчас мы серьёзно рассматриваем вариант статической маршрутизации loopback-интерфейсов и использования iBGP для redistribute-connected.

Это будет сложнее, так как придётся внедрять достаточно много дополнительной фильтрации BGP, которая сейчас не нужна. Я заново настрою syslog на другой хост... мы переместили физический сервер, куда шли логи, но, думаю, это оправдано.
02.09.2022 15:58:00, jkroon.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427406 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427406 Fri, 02 Sep 2022 15:58:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Привет, jkroon, маска сети /16 — это не проблема, она участвует только в выборе интерфейсов для OSPF. Мне не очень нравится использовать redistribute connected, я предпочитаю указывать сетевые IP и объявлять интерфейсы пассивными. В предыдущем сообщении ты писал о потере маршрутов с mk к другим, а теперь — с других к mk. Можешь прояснить ситуацию? А что насчёт логов отладки OSPF в момент потери маршрутов?
23.08.2022 16:34:00, AlexDF.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427405 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427405 Tue, 23 Aug 2022 16:34:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
/routing ospf instance  
set [ find default=yes ] distribute-default=if-installed-as-type-1 redistribute-connected=as-type-1 redistribute-static=as-type-1 router-id=a.b.c.d
/routing ospf interface  
add interface=bonding-cisco.2-routing network-type=broadcast priority=0  
/routing ospf network  
add area=backbone network=172.31.0.0/16  

bonding-cisco.2 имеет адрес 172.31.255.d/24 и является тегированным VLAN с id=2. Cisco названа в честь коммутатора, у которого нет интерфейса на VLAN=2. Оба MK настроены абсолютно одинаково, отличие только в a.b.c.d.  

Конфигурация frr (x2):  
interface bond0.2  
ip ospf cost 10  
ip ospf priority 200  
exit  

router ospf  
ospf router-id a.b.c.d  
redistribute kernel metric-type 1 route-map iewc-permit-kernel  
redistribute connected metric-type 1 route-map iewc-filter-dynamic  
network 172.31.255.0/24 area 0  
area 0 authentication message-digest  
exit  

Не публикую маршрутные карты, но между двумя инстансами frr маршруты остаются целыми. Также маршруты MK => FRR целы, проблема только в маршрутах обратно к MK, которые теряются. Хмм, может ли дело быть в том, что сеть задана как /16, а не /24? Не вижу, КАК это может повлиять, ведь это должно использоваться только локально, чтобы определить, какие интерфейсы к каким областям относятся.
23.08.2022 13:38:00, jkroon.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427404 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427404 Tue, 23 Aug 2022 13:38:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Мы внедрили множество MK в смешанных средах с оборудованием разных производителей (Aruba, Cisco, Fortigate, PaloAlto) и не заметили никаких перебоев с петлевыми маршрутами в ospf (RouterOS версии 6.48.6). Можешь предоставить выдержку из конфигурации по ospf? Алекс.
08.08.2022 05:46:00, AlexDF.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427403 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427403 Mon, 08 Aug 2022 05:46:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Думаю, OSPF в Mikrotik полон багов. Когда делаешь довольно простые вещи, всё работает. Но, по моему мнению, он не до конца реализован. У меня открыто обращение в поддержку, потому что я заметил, что ABR протекает все маршруты из backbone в stub/nssa области при перезагрузке или рестарте экземпляра. По сути, роутеры в stub/nssa областях начинают вести себя как роутеры backbone/area0, и на них становятся известны все сети, чего быть не должно.
04.08.2022 04:08:00, freshtechs.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427402 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427402 Thu, 04 Aug 2022 04:08:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Небольшое обновление для всех, кто тоже столкнулся с этим — просто перезапустить инстанс недостаточно, нужно перезагружать весь роутер. Поэтому единственный разумный выход — полностью исключить Mikrotik из нашей сетевой настройки, кроме самых простых случаев использования.
03.08.2022 21:03:00, jkroon.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427401 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427401 Wed, 03 Aug 2022 21:03:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Вы сравниваете RouterOS v6 с другими платформами, а не с RouterOS v7, в которой весь стек маршрутизации, включая все протоколы, переписан с нуля. Большинство этих проблем в v7 уже устранены, хотя, конечно, есть и новые ошибки, над которыми работают, ведь стек новый.
15.09.2022 02:58:00, mducharme.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427400 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427400 Thu, 15 Sep 2022 02:58:00 +0300 RouterOS OSPF "пропадания" (маршруты, созданные на MT, исчезают из остальной сети) RouterOS в форуме RouterOS.
Всем привет! Ранее я нашёл вот эту тему http://forum.mikrotik.com/t/ospf-invalid-sequence-number-md5-authentication-failed/71030/1 — там совсем непонятно было, что происходит, но мы решили попробовать отключить 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 (не могу публиковать их открыто, но готов обсудить и проверить).
03.06.2022 10:29:00, jkroon.]]> http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427399 http://mikrotik.moscow/forum/forum57/88490-ospf-_propadaniya_-_marshruty_-sozdannye-na-mt_-ischezayut-iz-ostalnoy-seti/message427399 Fri, 03 Jun 2022 10:29:00 +0300 RouterOS