У меня проблема: OSPF вдруг стал периодически сбоить на одном оптоволоконном канале. Связь работала без нареканий больше двух лет, а тут вдруг начали появляться рассинхронизации таймера Hello. Я трижды проверял настройки и логи — ничего не менялось. Чтобы исправить ситуацию, я добавил шифрование на канал, установил таймер Hello на 10 секунд, перезагрузил и обновил все маршрутизаторы до версии 6.34.1. Казалось, это немного помогло. Но сегодня утром я получил ошибку «Database description packet has different master status flag OSPF issue», OSPF отвалился, и маршрутизация остановилась. При этом пинги по цепочке не терялись. Нашёл вот этот пост, но он кажется устаревшим и сваливает вину на канал. http://forum.mikrotik.com/t/database-description-packet-has-different-master-status-flag/30658/1 Кто-нибудь сталкивался с таким и может подсказать?
Я начал замечать это после обновления до 6.35.2 на беспроводной линии, где у нас уже были проблемы со стабильностью соединения. Собирался начать развёртывание обновлений после пары перезагрузок watchdog за последние несколько дней, но не хочу в итоге получить сломанный OSPF на куче удалённых площадок.
Ubiquity AirFiber A5X… и, что интересно, именно на этих каналах мы видели ошибки базы данных. Раньше мы использовали широковещательные типы сетей и динамическое обнаружение интерфейсов и соседей без проблем на оборудовании Ubiquiti и других лицензионных устройствах связи. Ошибки базы данных регистрируются только на этих.
У меня такая же проблема. Пробовал версии 6.34.2 и 6.35.2, используя и NBMA, и Broadcast типы сетей, но проблема всё равно остается. В этом конкретном случае проблема возникает между двумя роутерами, соединёнными через L2VPN по сети провайдера транспорта. Сейчас попробую ещё добавить аутентификацию на канал, чтобы посмотреть, поможет ли это.
Попробую также добавить аутентификацию к ссылке, чтобы проверить, поможет ли это. Вообще не помогает. Мне кажется, один из ваших mikrotik — это CCR или AHAx2?
Один из роутеров — RB951, другой — CRS, модель сейчас не вспомню. Правила файрвола вообще не используются, настройка OSPF в порядке, это маленькая сеть с менее чем 8 роутерами, все работают нормально. Только эта связка не работает. На обоих устройствах установлена последняя версия с исправлениями ошибок. Оба роутера подключены к другим роутерам, проблем с соседством нет, MTU проверяли — передаёт пакеты по 1500 байт, так что и с этим всё в порядке. В любом случае склоняюсь к неисправности канала, но пока проблему найти не удалось. При тесте канал простаивает, та же проблема независимо от того, мультикаст или юникаст используются для hello.
Проверьте MTU с обеих сторон канала — все параметры должны совпадать точно, иначе не получится установить соседство. Можно попробовать включить отладочный лог для OSPF, чтобы понять, почему он так "злюсь".
Это сохраняло бы соседство на ex-start, но в этом случае оно переходит в состояние full и начинает случайным образом "клевать" спустя некоторое время. Может через минуту, может через три, но в итоге оно всё равно "клевать" начинает. В любом случае конфигурация OSPF правильная, проблем нет, со способностями MTU транспорта тоже всё в порядке. Я ещё не пробовал использовать другие устройства, чтобы проверить, связана ли проблема с линком (для меня это единственное логичное объяснение, кроме странного бага). Автор темы столкнулся с той же проблемой, но в другой ситуации при том же раскладе.
Если соединение нестабильно после установления, я видел похожее поведение на UBNT P2P-связях (AirMax, не AirFiber), и, по всей видимости, это было связано с потерей пакетов из-за резких всплесков нагрузки или изменений модуляции и т.д. (и это происходило при использовании Cisco-to-Cisco OSPF, а не Mikrotik). Пробовали ли вы выставлять DSCP в EF на OSPF-пакетах, чтобы оборудование UBNT понимало, что эти пакеты имеют высокий приоритет?
Показать конфигурацию OSPF на роутерах? Нет, сбои в соединении вызывают другие сообщения — «OSPFv2 сосед x.x.x.x: изменение состояния с (Init|Full) на Down» следует читать как «истек таймер отключения» (нет входящих пакетов OSPF в течение 40 секунд). «Пакет с другим флагом статуса мастера» — проблема с выбором мастер/слейв.
У меня сегодня была точно такая же проблема с сетью клиента на багфиксе 6.34.6, и я решил её, вернув приоритет интерфейса OSPF к значению по умолчанию — 1. Раньше на нескольких маршрутизаторах стояли разные целочисленные значения, чтобы принудительно назначить DR Master. Ты случайно не менял приоритет интерфейса на каком-то из маршрутизаторов?
Прежде всего, спасибо всем за ваши мнения, отвечу на некоторые вопросы, но, похоже, проблема решилась (adjacency держится последние три дня). Как я и предполагал, дело было в транзитной сети, провайдер точно не рассказал, что именно сделал, но позвонил и сказал, что обнаружил неисправность и исправил её (наши роутеры не трогали). Пока всё работает отлично. Приоритет я не менял, учту это.
Пробовал Broadcast, NBMA и PTP — результат тот же.
В этом конкретном случае беспроводная связь не задействована, транзитный провайдер подключается к нам через FO, а их CPE дают нам медный интерфейс. У OP были аналогичные проблемы с беспроводным звеном.
Я написал здесь, потому что испытывал те же проблемы.
Конфигурация роутера в порядке, проблем нет, это достаточно базовая настройка в данном случае. Adjacency случайно формируется и разрывается. Я тоже считаю, что система должна показывать другое сообщение, как и вы. Несколько дней назад проверял логи и заметил, что время от времени появляются повторные передачи LSA (примерно 3–5, не всегда по одному в час). Поэтому я и виню ссылку.
Я сталкивался с таким же поведением много лет, и общий знаменатель всегда был в Mikrotik. Раньше я думал, что это проблема Ubiquiti, но наблюдал это на оборудовании следующих брендов:
Я также экспериментировал с разным MTU, разными приоритетами для NBMA-соседей, пробовал точка-точка, широковещание, NBMA и так далее. Очень долго копался на форумах, но так и не нашёл однозначного объяснения, что именно вызывает это. Странно, что одни люди сталкиваются с этой проблемой, а другие — нет.