RouterOS 7.15: обновляем клиентские MikroTik и смотрим на новый BGP

RouterOS 7.x появился в 2021 году и с тех пор идёт волнами обновлений. 7.15 - очередной минорный релиз, но в нём достаточно конкретных изменений по BGP и фильтрации маршрутов, чтобы мы взялись за плановые обновления клиентских маршрутизаторов и параллельно пересмотрели конфигурации, которые ставились ещё под ветку 6.x.

Что изменилось в BGP

Ветка 7.x переписала BGP с нуля относительно старого 6.x - другой синтаксис конфига, другие объекты в Winbox, другая логика работы с peer-группами. Если в 6.x BGP был достаточно монолитным, то в 7.x есть отдельные концепции: connection, session, template. Это давало больше гибкости, но поначалу вносило путаницу - особенно для тех, кто переезжал с работающей 6.x-конфигурации.

В 7.15 улучшения сосредоточены в нескольких местах.

Фильтрация через routing-filter. Синтаксис цепочек правил доработан - теперь можно более точечно матчить маршруты по комбинациям атрибутов. На практике это важно в схемах с несколькими upstream-провайдерами, где нужно разделить трафик между каналами не просто по весу, а по конкретным prefix-листам или community.

Стабильность BGP-сессий под нагрузкой. В предыдущих 7.x-релизах были жалобы на flapping сессий при большой routing table - в первую очередь у тех, кто получает полную таблицу от провайдера. В changelog 7.15 есть фиксы в этом направлении. Мы не получаем full view у клиентов, так что эту часть проверяли опосредованно, но по форуму MikroTik - тема закрытая для большинства.

VRF и BGP. Улучшена изоляция VRF-инстансов при работе с несколькими BGP-сессиями. Для сегментированных офисных сетей, где в одном железе сидят несколько виртуальных роутеров, это дополнительная стабильность.

Как выглядит наша типичная схема с двумя провайдерами

Большинство клиентов, у кого мы занимаемся managed-сопровождением инфраструктуры, используют схему с двумя интернет-каналами. Не BGP в полном смысле слова - скорее eBGP с одним или двумя upstream-провайдерами, где MikroTik получает частичную таблицу или только default route через BGP, и маршрутизирует трафик между каналами.

Логика отказоустойчивости строится так:

• Основной провайдер - получает весь трафик при нормальной работе, BGP-сессия держит дефолтный маршрут.
• Резервный провайдер - BGP-сессия активна, но в таблице lower preference. При падении основного дефолт через резервный поднимается автоматически - без вмешательства, без скриптов.
• Метрики и мониторинг - через Netwatch или ICMP probe отслеживаем доступность конечных точек, а не просто живость BGP-сессии. Сессия может быть alive, а трафик через неё ходить в никуда.

Переключение в такой схеме занимает секунды - BGP hold timer по умолчанию 240 секунд, но мы давно выставляем 30/10 для клиентских конфигураций. При реальном падении канала это заметно.

Что пришлось трогать при обновлении

Обновление с 7.14 на 7.15 прошло без сюрпризов - маршрутизаторы уходили в ребут, возвращались с теми же конфигурациями. Но мы совместили волну обновлений с ревизией самих конфигов.

Нашли несколько типичных вещей, которые накопились за время работы на 7.x:

Устаревшие routing-filter цепочки. Часть правил была написана в период, когда синтаксис 7.x ещё менялся между минорными версиями. К 7.15 некоторые конструкции работают, но выглядят как legacy - переписали в актуальном виде, заодно стало читаемее.

Таймеры BGP. На паре маршрутизаторов обнаружили дефолтные значения 240/80 - явно конфиги создавались давно. Привели к единому стандарту.

Логирование. В 7.x появился /log/ с topic-фильтрацией, но не везде он был настроен так, чтобы BGP-события писались отдельно. Теперь при flapping сессии это видно сразу, а не приходится реконструировать из общего потока.

RouterOS 7.x как платформа в 2024 году

Ветка 7.x долго считалась сырой - первые релизы действительно были нестабильными, и часть сообщества сидела на 6.49 LTS до последнего. К середине 2024 года 7.x выглядит существенно зрелее. Большинство известных нам проблем первых версий закрыты, новый синтаксис конфигурации устаканился, документация догнала реализацию.

Мы рекомендуем 7.x для новых установок уже несколько месяцев. С 7.15 рекомендация стала уверенней - конкретно для схем с BGP и несколькими провайдерами нет причин оставаться на 6.49.

Отдельный момент - CHR (Cloud Hosted Router). В 7.x CHR работает стабильно, и для ряда клиентов это удобный способ поднять маршрутизатор в облаке или в виртуальной среде с теми же инструментами, что и на физическом железе. Это не замена аппаратному решению на периметре, но как дополнительный элемент схемы - вполне.

Следующий плановый обход - уточнить поведение routing-filter в 7.15 на граничных кейсах с community и посмотреть на новую документацию по VRF. Ничего экстренного, просто текущая работа.