Как сдать MTCRE от MikroTik: разбор OSPF, рекурсивных маршрутов и типичных провалов

MTCRE — это MikroTik Certified Routing Engineer, вторая ступень после базового MTCNA. Программа формально про VLAN, статические маршруты и OSPF. По факту экзамен проверяет одну способность: понимаете ли вы, как маршрут попадает в таблицу маршрутизации — и почему иногда не попадает.

У меня этот трек был профильной специализацией стипендии APNIC Foundation BCAP 2026. Сдал. Но полезнее самого факта две темы, на которых я реально застрял: проектирование OSPF-зон и рекурсивная маршрутизация со значениями scope. В документации им отведено по паре абзацев, а на экзамене и в работе провайдера они решают больше, чем весь остальной билет.

Кому это нужно, а кому нет

Сертификат имеет смысл в двух ситуациях. Первая: вы работаете или хотите работать в провайдере и вам нужен формальный аргумент на собеседовании, потому что десятилетним стажем в маршрутизации похвастаться нечем. Вторая: вы в интеграторе, и сертификат идёт в партнёрский профиль компании — иногда это требование контракта с вендором, а не личная прихоть.

Если вы админите офис с одним маршрутизатором, парой подсетей и NAT, MTCRE вам ничего не даст. Там нет ни OSPF, ни BGP, ни рекурсивных nexthop'ов — уровень MTCNA закрывает задачу с запасом. И да, сертификаты MikroTik имеют срок действия, так что «сдал один раз и навсегда» не работает: актуальные условия продления смотрите на сайте вендора, они меняются.

Как устроен экзамен по темам

Три уровня сертификации MikroTik отличаются не глубиной, а зоной ответственности. Полезно понимать, где вы находитесь:

Внутри MTCRE куски неравнозначные. VLAN и статика — это техника, там достаточно аккуратности: правильная инкапсуляция, корректный MTU, отсутствие петли в мосту. OSPF — единственная тема, где нужно думать архитектурно, и именно она обычно съедает время на подготовку.

OSPF: где ломается голова

Синтаксис OSPF в RouterOS не сложный. Сложность в том, что соседство поднимается с полпинка, а маршруты в таблице появляются не те, которые вы ожидали. Причины почти всегда в дизайне зон и в том, как протокол переливает LSA между ними.

Правила, которые стоит выучить до автоматизма:

1. Backbone-зона 0 обязательна и должна быть связной. Всё остальное цепляется к ней.
2. Зоны соединяются через ABR — пограничный маршрутизатор, у которого один интерфейс в area 0, другой в своей зоне.
3. Две не-backbone зоны нельзя соединить линком напрямую и ждать, что трафик пойдёт по короткому пути. Он не пойдёт: транзит между зонами идёт только через area 0.
4. Если area 0 физически разорвана, спасает virtual link — но это костыль, а не решение, и на экзамене такие сценарии любят.
5. Типы зон (stub, totally stubby, NSSA) уменьшают объём LSA и размер таблицы, но каждый со своей ценой: stub отрезает внешние маршруты, NSSA нужен, когда внутрь зоны надо влить внешние префиксы.
6. Суммирование адресов делается на ABR, а внешних маршрутов — на ASBR. Без него таблица на边缘-роутере раздувается до неприличия.

Отдельно стоит потренировать выбор DR/BDR и стоимость интерфейсов. В маленьких лабах это неважно, в реальной сети с десятком роутеров на сегменте — определяет, кто кому пересчитывает SPF.

Рекурсивная маршрутизация и scope

Вот сюда я бы посоветовал закопаться, даже если OSPF у вас уже идёт легко. Классическая задача: маршрут указывает не на интерфейс, а на IP-адрес, который сам доступен через другой маршрут. RouterOS должен сначала разрешить nexthop — и здесь включается внутренняя механика.

У каждого маршрута в RouterOS есть два параметра: scope — условная «надёжность» маршрута, и target-scope — максимальный scope, которым разрешено разрешать его nexthop. Маршрут не может использовать в качестве шлюза маршрут с большим scope, чем его собственный target-scope. Звучит абстрактно, пока не столкнёшься: маршрут просто висит inactive, хотя все адреса пингуются.

Цифры зависят от версии RouterOS и от того, как настроен протокол, — проверяйте в документации под свою версию. Но логика неизменна: если nexthop ищется через маршрут с более высоким scope, чем target-scope вашего маршрута, разрешения не произойдёт. Лечится поднятием target-scope, а не танцами с firewall.

На экзамене такие задания выглядят безобидно: «почему маршрут не активен». Ответ почти всегда не в конфиге маршрута, а во взаимосвязи двух его параметров с окружением.

Как готовиться: план, который работает

Смотреть видео и кивать — бесполезно, экзамен практический по своей сути. Что реально помогает:

• Поднимите лабу на виртуалках (CHR подойдёт) — минимум четыре роутера, тогда появится место для area 0, двух обычных зон и ABR между ними.
• Соберите OSPF, убедитесь, что всё работает, а потом ломайте: уберите линк в backbone, поменяйте тип зоны, добавьте virtual link. Смотреть, как соседство залипает в ExStart из-за несовпадения MTU, полезнее десяти роликов.
• Сделайте связку static → BGP → OSPF с рекурсивным nexthop и добейтесь, чтобы маршрут стал активным без подсказок. Это и есть тот самый scope.
• Разберитесь с выводом /ip route print detail: активный маршрут, неактивный, отброшенный — и почему. На экзамене вопросы формулируются вокруг именно этих статусов.

Типичные ошибки при подготовке

Учить команды вместо механизма. RouterOS меняет синтаксис между версиями, а принцип выбора маршрута остаётся тем же — заучивание путей в WinBox разваливается на первом же нестандартном задании.

Игнорировать VLAN и MTU как «скучную базу». Половина проблем с OSPF-соседством в реальной сети растёт именно из стыка L2 и MTU, а не из протокола маршрутизации.

Готовиться только по дампам конфигов. Пока вы не соберёте топологию руками и не увидите, как маршрут пропадает и появляется, схема не уложится.

Сдавать MTCRE сразу после MTCNA без работы с OSPF на реальном оборудовании. Технически можно, но между «видел в лабе» и «понимаю, почему так» лежит пропасть, и экзамен её проверяет.

И главное: скилл, который даёт MTCRE, — это умение читать таблицу маршрутизации как текст. Не «какая команда включает OSPF», а «почему маршрут ведёт себя именно так». В работе провайдера это и есть основная задача, а сертификат — просто побочный продукт её решения.