+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

NAT уничтожает OSPF

NAT уничтожает OSPF, RouterOS

myke1124

Guest

16.01.2017 21:08:00

/interface bridge add name=loopback
/interface bridge settings set use-ip-firewall=yes
/ip address
add address=123.123.123.208/32 interface=loopback
add address=10.100.100.117/29 interface=ether1-gateway
add address=10.212.1.1/29 interface=ether2-south_tower
add address=10.212.8.1/24 interface=ether3-north_AP
/ip route add gateway=10.100.100.113

Базовая настройка OSPF.

/routing ospf interface
add network-type=broadcast passive=yes
add authentication=md5 authentication-key=myOSPFkey interface=ether1-gateway network-type=broadcast priority=0
add authentication=md5 authentication-key=myOSPFkey interface=ether2-south_tower network-type=broadcast priority=0

OSPF у меня заработал. Потом я добавил в конфигурацию правило NAT.

/ip firewall address-list
add list=my_network address=10.0.0.0/8
add list=my_network address=123.123.123.0/24

/ip firewall nat
add action=src-nat chain=srcnat dst-address-list=!my_network src-address=10.0.0.0/8 to-addresses=123.123.123.208

После добавления правила NAT соседа OSPF потерял. Я пробовал добавить к правилу nat protocol=!ospf dst-address-type=unicast out-interface=ether1-gateway. Также добавил 224.0.0.0/23 и 255.255.255.255 в список my_network. Перепробовал несколько версий RouterOS и разные модели RouterBoard. Вывод — правило NAT перехватывает трафик OSPF.

myke1124

Guest

30.01.2020 00:02:00

Спустя годы эта ошибка всё ещё присутствует.

/routing ospf area set [ find default=yes ] disabled=yes
add area-id=0.0.0.101 name=101
/routing ospf instance set [ find default=yes ] name=101 redistribute-connected=as-type-2 router-id=10.101.4.5
/routing ospf interface add network-type=broadcast passive=yes
add authentication=none interface=ether3 network-type=broadcast
/routing ospf network add area=101 network=10.0.0.0/8

OSPF работает с этой конфигурацией.

Эта настройка ломает OSPF:

/ip firewall nat add action=masquerade chain=srcnat out-interface=sfp+1 src-address=169.254.1.1

169.254.1.1 нигде в сети не активен. Интерфейс sfp+1 неактивен на устройстве, не имеет адреса или связанного маршрута. Это правило не совпадает ни с одним трафиком. Правила NAT показывают 0 байт и 0 пакетов.

Отключение этого правила NAT исправляет работу OSPF.

Я также пробовал добавить рекомендованное правило "add chain=srcnat protocol=ospf action=accept" в единственном экземпляре — оно тоже ломает OSPF.

Вывод логов:

17:14:53 system,info nat rule changed by admin
17:15:26 route,ospf,info OSPFv2 neighbor 10.108.255.254: state change from 2-Way to Init
17:15:27 route,ospf,info OSPFv2 neighbor 10.132.2.1: state change from 2-Way to Init
17:15:27 route,ospf,info OSPFv2 neighbor 10.116.1.1: state change from 2-Way to Init
17:15:27 route,ospf,info OSPFv2 neighbor 10.101.4.3: state change from 2-Way to Init
17:15:29 route,ospf,info OSPFv2 neighbor 10.108.40.1: state change from 2-Way to Init
17:15:30 route,ospf,info OSPFv2 neighbor 10.101.255.255: state change from 2-Way to Init
17:15:30 route,ospf,info OSPFv2 neighbor 10.100.0.15: state change from 2-Way to Init
17:15:30 route,ospf,info OSPFv2 neighbor 10.101.4.39: state change from 2-Way to Init
17:15:33 route,ospf,info OSPFv2 neighbor 10.140.32.1: state change from 2-Way to Init
17:15:33 route,ospf,info OSPFv2 neighbor 10.102.8.1: state change from 2-Way to Init
17:15:34 route,ospf,info OSPFv2 neighbor 10.140.60.1: state change from 2-Way to Init
17:15:34 route,ospf,info OSPFv2 neighbor 10.101.4.25: state change from 2-Way to Init

MCN

Guest

09.03.2020 21:58:00

Что я сделал — добавил в правило NAT: protocol=!ospf.
Например, правило src nat может выглядеть так:
add action=src-nat chain=srcnat comment="my new nat rule" protocol=!ospf src-address=192.168.88.0/24 to-address=192.168.1.11

Это меня надолго поставило в тупик. Если есть какой-то более удобный способ сделать это — пожалуйста, дайте знать, у меня очень мало опыта с mikrotik.

sri2007 Guest	#4 0 30.03.2020 04:26:00 Этот вариант тоже работает, есть ещё один: использовать такой: /ip firewall raw add chain=prerouting protocol=ospf action=notrack

Mantic

Guest

20.03.2021 10:53:00

Подтверждаю. То же самое случилось у меня. Включение любого NAT-правила меняло исходящий IP, который использовал OSPF, даже если NAT-правило никак не было связано с этим IP. Отключение IP, удаление его из сетей OSPF и прочее — ничего не помогало. Единственный способ вернуть всё в рабочее состояние — добавить raw-правило для отключения трекинга протокола OSPF.

P.S. Это на CCR1009-7G-1C-1S+ с прошивкой 6.48.1.

Mihawk95

Guest

06.04.2022 13:46:00

Редактирование 2022 года. Ошибка всё ещё присутствует в версиях 6.49.5 и 7.1.5 тоже. У нас в настройках действие raw prerouting в файрволе не работает, но если добавить правило в цепочку output, OSPF начинает функционировать… Очень раздражает, потому что в нашей версии 6.47.1 этой ошибки не было, а после обновления ПО она появилась…

UplinkLLC

Guest

15.05.2022 04:34:00

Если кому-то это поможет… Мы используем OSPF и NAT на роутере с Router OS версии 7.2.3. Из-за этого возникали проблемы: NAT менял исходящий IP-адрес OSPF на IP, который мы использовали для NAT трафика клиентов. Мы попробовали некоторые советы из этого поста, с разным успехом. Иногда после перезагрузки роутера все состояния соседей OSPF зависали на init. Для нас решением стало отключение отслеживания соединений для OSPF с помощью кода Router OS ниже.

/ip firewall raw
add action=notrack chain=prerouting protocol=ospf
add action=notrack chain=output protocol=ospf

Когда эти правила RAW были добавлены, всё работает стабильно.

CCIS Guest	#8 0 23.05.2022 02:54:00 +1 Это тоже сработало у нас, спасибо!

samPC Guest	#9 0 23.09.2022 02:34:00 +1 тоже работает здесь, наконец-то, после многих часов борьбы я это нашёл.

Joni

Guest

#10

08.10.2023 11:29:00

(2017 звонит, постинг ключевых слов для поиска, ссылка на обсуждение в http://forum.mikrotik.com/t/v7-1-1-ospfneighbor-received-wrong-ls-ack/155679/24) Между любыми RouterOS v7.11.2. default-v2 { version: 2 router-id: x.x.x.13 } backbone { 0.0.0.0 } interface { p2p x.x.x.13%l2tp-x} neighbor { router-id: x.x.x.254 state: Full } получен неверный LS Ack для маршрутизатора x.x.x.13, x.x.x.13 0x80000382 ожидался 0x80000383 (так называемое +1, 2 → 3). Маскарад / NAT, похоже, вызывает это (внутренние интерфейсы), вероятно, не должен, почти точно дефолтная логическая ошибка, так как IP-адреса верны.

novasys Guest	#11 0 03.06.2024 23:04:00 Это единственное решение, которое у меня сработало. Раздражающая ошибка, подозреваю, что в версии 6.49.2 её не было, так как до обновления на 6.49.15 никаких проблем не возникало. Спасибо, @CCIS!

kelsoncamargo Guest	#12 0 20.05.2025 19:05:00 +1, сработало! Я уже несколько дней мучаюсь с этой проблемой!

wiseroute Guest	#13 0 21.05.2025 08:49:00 Пожалуйста... не хочу показаться грубым, но зачем сетевикам усложнять себе жизнь, делая NAT на таких важных базовых протоколах связи? Учите основы, стройте фундамент — проектируйте и управляйте. OSPF использует мультикаст, если он доступен, иначе работает по юникасту. А внутренние маршруты должны быть связаны любыми способами или через VPN-туннели.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры