mikrotik-wiki.ru
Главная
Загрузка...

BGP на MikroTik — настройка для ISP и multihoming

RouterOS 7.xRouting13 мин330 мар. 2026 г.
TelegramVK

BGP (Border Gateway Protocol) — единственный протокол междоменной маршрутизации в интернете. Для сетевого инженера владение BGP — это переход от администрирования отдельных маршрутизаторов к управлению автономной системой, которая взаимодействует с глобальной таблицей маршрутизации. MikroTik RouterOS 7 существенно переработал синтаксис BGP, приблизив его к логике промышленных маршрутизаторов. В этом руководстве — полная настройка eBGP для dual-homed клиента с собственным PI-блоком, фильтрация маршрутов, communities и диагностика.

Описание

Зачем нужен BGP

BGP используется в следующих сценариях:

СценарийОписание
MultihomingПодключение к двум и более ISP с автоматическим failover
PI-адресаАнонс собственного PI (Provider Independent) адресного блока
PeeringОбмен трафиком на IX (Internet Exchange) точках
ISP-инфраструктураСвязь между AS, управление маршрутами клиентов
AnycastАнонс одного префикса из нескольких точек для балансировки

Когда BGP не нужен:

  • Один провайдер, один канал — достаточно default route
  • Два провайдера без PI-блока — используйте PBR и failover на уровне маршрутов
  • Внутренняя сеть предприятия — OSPF или статические маршруты

Ключевые концепции

AS (Autonomous System) — сеть (или группа сетей) под единым административным управлением, идентифицируемая уникальным номером ASN. Для BGP необходим собственный ASN (или private ASN для iBGP).

eBGP vs iBGP:

  • eBGP (external BGP) — сессии между разными AS. Стандартный TTL=1, пиры обычно напрямую подключены.
  • iBGP (internal BGP) — сессии внутри одной AS. TTL=255, требуется full-mesh или route reflector.

Prefix — сетевой блок, анонсируемый через BGP (например, 203.0.113.0/24).

BGP Attributes:

  • AS-PATH — список AS, через которые прошёл маршрут. Основной критерий выбора маршрута.
  • LOCAL-PREF — приоритет маршрута внутри AS (чем выше, тем предпочтительнее). По умолчанию 100.
  • MED (Multi-Exit Discriminator) — подсказка для соседней AS, какой линк предпочесть. Чем ниже, тем лучше.
  • NEXT-HOP — IP-адрес следующего маршрутизатора.
  • COMMUNITY — метка для группировки и фильтрации маршрутов.

BGP Communities — 32-битные метки формата ASN:value, используемые для управления маршрутами. Стандартные well-known communities:

  • no-export (65535:65281) — не анонсировать за пределы AS
  • no-advertise (65535:65282) — не анонсировать никаким пирам
  • no-peer (65535:65284) — не анонсировать на bilateral peer sessions

ISP часто используют собственные communities для управления local-pref, prepend и blackhole. Документация community обычно размещена на сайте ISP или в PeeringDB.

Синтаксис BGP в RouterOS 7

RouterOS 7 полностью переработал конфигурацию BGP. Основные изменения:

RouterOS 6RouterOS 7
/routing bgp instance/routing/bgp/template
/routing bgp peer/routing/bgp/connection
/routing bgp network/routing/bgp/connection (output.network) или filter
/routing filter/routing/filter/rule (новый синтаксис)
/routing bgp advertisements/routing/bgp/advertisements/print

Ключевые сущности в RouterOS 7:

  • Template — шаблон с общими параметрами BGP (AS, router-id, address-family). Аналог instance в v6.
  • Connection — описание BGP-сессии с конкретным пиром. Привязывается к template.
  • Filter Rule — правила фильтрации маршрутов (input/output). Полностью новый язык.

Схема сети: dual-homed с PI-блоком

code
                    ┌──── ISP A (AS 64500) ────┐
                    │    Peer IP: 192.0.2.1     │
                    │                           │
[Наша сеть]         │                           │     [Интернет]
AS 65000            │                           │
PI: 203.0.113.0/24  │                           │
                    │                           │
                    │    Peer IP: 192.0.2.5     │
                    └──── ISP B (AS 64501) ────┘

MikroTik Router:
  ether1 → ISP A (192.0.2.2/30)
  ether2 → ISP B (192.0.2.6/30)
  ether3–5 → LAN (203.0.113.0/24)

Задача:

  • Анонсировать PI-блок 203.0.113.0/24 обоим ISP
  • ISP A — основной канал, ISP B — резервный
  • При падении ISP A трафик автоматически переключается на ISP B
  • Принимать от ISP только default route (0.0.0.0/0)
  • Фильтровать входящие и исходящие анонсы

Настройка

Шаг 1: Базовая IP-конфигурация

[admin@MikroTik] >
# WAN к ISP A
/ip/address add address=192.0.2.2/30 interface=ether1 comment="WAN ISP A"

# WAN к ISP B
/ip/address add address=192.0.2.6/30 interface=ether2 comment="WAN ISP B"

# LAN — PI-блок
/ip/address add address=203.0.113.1/24 interface=bridge-LAN comment="PI block"

Шаг 2: Создание BGP Template

Template определяет общие параметры BGP-процесса:

[admin@MikroTik] >
/routing/bgp/template add \
  name=default \
  as=65000 \
  router-id=203.0.113.1 \
  address-families=ip \
  routing-table=main \
  comment="Our AS 65000"

Параметры:

  • as=65000 — номер нашей автономной системы
  • router-id — уникальный идентификатор (обычно loopback или WAN IP)
  • address-families=ip — только IPv4 unicast. Для IPv6 добавьте ipv6

Шаг 3: Создание фильтров маршрутов

Фильтры — критически важная часть BGP-конфигурации. Без правильных фильтров можно случайно анонсировать чужие маршруты или принять полную таблицу BGP (900k+ префиксов), что положит маршрутизатор.

Фильтр на вход (принимаем только default route):

[admin@MikroTik] >
/routing/filter/rule add \
  chain=bgp-in \
  rule="if (dst == 0.0.0.0/0) { accept }" \
  comment="Accept default route only"

/routing/filter/rule add \
  chain=bgp-in \
  rule="reject" \
  comment="Reject everything else"

Фильтр на выход (анонсируем только наш PI-блок):

[admin@MikroTik] >
/routing/filter/rule add \
  chain=bgp-out \
  rule="if (dst == 203.0.113.0/24) { accept }" \
  comment="Announce our PI block"

/routing/filter/rule add \
  chain=bgp-out \
  rule="reject" \
  comment="Reject everything else"

Фильтр на выход для ISP B (резервный — делаем AS-PATH prepend):

[admin@MikroTik] >
/routing/filter/rule add \
  chain=bgp-out-ispb \
  rule="if (dst == 203.0.113.0/24) { set bgp-path-prepend 3; accept }" \
  comment="Announce PI with 3x prepend via ISP B"

/routing/filter/rule add \
  chain=bgp-out-ispb \
  rule="reject" \
  comment="Reject everything else"

AS-PATH prepend добавляет наш ASN в AS-PATH три раза, делая маршрут через ISP B «длиннее» и менее предпочтительным для внешнего мира. Это стандартный метод управления входящим трафиком.

Шаг 4: Фильтр для управления LOCAL-PREF (исходящий трафик)

Для управления тем, через какого ISP уходит наш трафик, используем LOCAL-PREF:

[admin@MikroTik] >
# Default route от ISP A — высокий приоритет
/routing/filter/rule add \
  chain=bgp-in-ispa \
  rule="if (dst == 0.0.0.0/0) { set bgp-local-pref 200; accept }" \
  comment="ISP A default - high priority"

/routing/filter/rule add \
  chain=bgp-in-ispa \
  rule="reject"

# Default route от ISP B — низкий приоритет
/routing/filter/rule add \
  chain=bgp-in-ispb \
  rule="if (dst == 0.0.0.0/0) { set bgp-local-pref 100; accept }" \
  comment="ISP B default - low priority"

/routing/filter/rule add \
  chain=bgp-in-ispb \
  rule="reject"

При работе обоих ISP трафик пойдёт через ISP A (local-pref 200 > 100). При падении ISP A — автоматически переключится на ISP B.

Шаг 5: Настройка BGP Connection к ISP A

[admin@MikroTik] >
/routing/bgp/connection add \
  name=isp-a \
  template=default \
  remote.address=192.0.2.1 \
  remote.as=64500 \
  local.address=192.0.2.2 \
  local.role=customer \
  multihop=no \
  hold-time=90s \
  keepalive-time=30s \
  address-families=ip \
  input.filter=bgp-in-ispa \
  output.filter=bgp-out \
  output.network=203.0.113.0/24 \
  comment="eBGP to ISP A (primary)"

Параметры:

  • remote.address / remote.as — IP и ASN пира (предоставляет ISP)
  • local.address — наш IP на линке к ISP
  • local.role=customer — определяет роль в BGP-сессии (RFC 9234). Для клиента ISP — customer
  • hold-time=90s — если за 90 секунд не получен keepalive, сессия считается упавшей
  • input.filter / output.filter — цепочки фильтров для входящих/исходящих маршрутов
  • output.network — сети, которые мы анонсируем (в дополнение к фильтру)

Шаг 6: Настройка BGP Connection к ISP B

[admin@MikroTik] >
/routing/bgp/connection add \
  name=isp-b \
  template=default \
  remote.address=192.0.2.5 \
  remote.as=64501 \
  local.address=192.0.2.6 \
  local.role=customer \
  multihop=no \
  hold-time=90s \
  keepalive-time=30s \
  address-families=ip \
  input.filter=bgp-in-ispb \
  output.filter=bgp-out-ispb \
  output.network=203.0.113.0/24 \
  comment="eBGP to ISP B (backup)"

Обратите внимание: output.filter=bgp-out-ispb — фильтр с AS-PATH prepend для резервного канала.

Шаг 7: Добавление статического маршрута для PI-блока

Чтобы BGP анонсировал prefix, он должен присутствовать в таблице маршрутизации. Добавляем blackhole-маршрут:

[admin@MikroTik] >
/ip/route add dst-address=203.0.113.0/24 type=blackhole comment="Anchor route for BGP announcement"

Blackhole-маршрут гарантирует, что prefix всегда присутствует в routing table, независимо от состояния интерфейсов. Реальный трафик к конкретным хостам пойдёт по более специфичным connected-маршрутам (203.0.113.0/24 на bridge-LAN).

Шаг 8: Настройка безопасности BGP-сессий

MD5-аутентификация (если ISP поддерживает):

[admin@MikroTik] >
/routing/bgp/connection set isp-a tcp-md5-key="SecretKeyISPA2024"
/routing/bgp/connection set isp-b tcp-md5-key="SecretKeyISPB2024"

MD5-ключ должен совпадать с настройкой на стороне ISP. Он защищает от TCP RST/injection-атак на BGP-сессию.

TTL Security (GTSM — Generalized TTL Security Mechanism):

[admin@MikroTik] >
/routing/bgp/connection set isp-a multihop=no

Для eBGP с directly connected пирами TTL=1 по умолчанию. Это значит, что атакующий из удалённой сети не сможет установить поддельную BGP-сессию (его пакеты придут с TTL < 1 после прохождения нескольких хопов).

Max-Prefix — защита от утечки полной таблицы:

[admin@MikroTik] >
/routing/bgp/connection set isp-a input.limit-process-routes-ipv4=10
/routing/bgp/connection set isp-b input.limit-process-routes-ipv4=10

Если ISP случайно пришлёт больше 10 префиксов (а мы ожидаем только default route), сессия будет сброшена. Это защищает от переполнения памяти маршрутизатора.

Краткое введение в iBGP

Если в вашей AS несколько маршрутизаторов, между ними нужен iBGP для распространения маршрутов, полученных от eBGP-пиров. Основные отличия iBGP от eBGP:

  • remote.as совпадает с local AS (оба — 65000)
  • TTL=255 (multihop по умолчанию)
  • Требуется full-mesh между всеми iBGP-роутерами, или route reflector
  • LOCAL-PREF передаётся в iBGP (не передаётся в eBGP)
  • AS-PATH не модифицируется в iBGP

Пример iBGP-соединения:

[admin@MikroTik] >
/routing/bgp/connection add \
  name=ibgp-router2 \
  template=default \
  remote.address=10.255.255.2 \
  remote.as=65000 \
  local.address=10.255.255.1 \
  local.role=ibgp \
  address-families=ip \
  comment="iBGP to Router 2"

Для сетей с более чем двумя маршрутизаторами рекомендуется использовать route reflector (один или два маршрутизатора в роли RR) вместо full-mesh iBGP.

BGP Communities — продвинутое управление маршрутами

Communities позволяют «тегировать» маршруты и применять к ним политики на стороне ISP.

Пример: пометить анонс community для blackhole (DDoS-protection):

[admin@MikroTik] >
/routing/filter/rule add \
  chain=bgp-out-blackhole \
  rule="if (dst == 203.0.113.100/32) { set bgp-communities 64500:666; accept }" \
  comment="Blackhole single IP at ISP A"

Многие ISP поддерживают community ASN:666 для blackhole. Отправив анонс /32 с этим community, ISP будет отбрасывать трафик к этому IP на своей стороне, защищая остальную сеть от DDoS.

Пример: управление local-pref на стороне ISP:

[admin@MikroTik] >
# Попросить ISP A установить local-pref 50 (backup) для нашего анонса
/routing/filter/rule add \
  chain=bgp-out-low-pref \
  rule="if (dst == 203.0.113.0/24) { set bgp-communities 64500:50; accept }"

Конкретные значения communities зависят от ISP — уточняйте в документации провайдера или на PeeringDB.

Проверка

Проверка BGP-сессий

[admin@MikroTik] >
/routing/bgp/session/print

Ожидаемый вывод:

code
Flags: E - established
 #   NAME      REMOTE-ADDRESS  REMOTE-AS  STATE        UPTIME
 0 E isp-a     192.0.2.1       64500      established  1d12h
 1 E isp-b     192.0.2.5       64501      established  1d12h

Оба соединения должны быть в состоянии established. Другие состояния указывают на проблемы:

СостояниеПроблема
idleBGP не пытается установить сессию (disabled или ошибка конфигурации)
connectTCP-соединение не устанавливается (firewall, нет маршрута, wrong IP)
activeTCP-соединение установлено, но BGP-согласование не проходит (wrong AS, MD5 mismatch)
opensentOPEN-сообщение отправлено, ждём ответ
openconfirmСогласование параметров

Проверка анонсируемых маршрутов

[admin@MikroTik] >
/routing/bgp/advertisements/print

Убедитесь, что виден наш PI-блок 203.0.113.0/24 в анонсах для обоих пиров. Для ISP B в AS-PATH должен быть prepend.

Проверка полученных маршрутов

[admin@MikroTik] >
/routing/route/print where bgp

Или более детально:

[admin@MikroTik] >
/routing/route/print detail where dst-address=0.0.0.0/0

Должны быть два default route: один от ISP A (local-pref 200, active) и один от ISP B (local-pref 100, backup).

Проверка таблицы маршрутизации

[admin@MikroTik] >
/ip/route/print where routing-table=main

Активный default route должен указывать на ISP A (192.0.2.1). Маршрут от ISP B должен быть в таблице, но не active.

Тест failover

Для проверки переключения можно временно отключить интерфейс к ISP A:

[admin@MikroTik] >
/interface/disable ether1

Через несколько секунд (hold-time / 3) BGP-сессия с ISP A упадёт, и default route переключится на ISP B. Проверьте:

[admin@MikroTik] >
/routing/bgp/session/print
/ip/route/print where dst-address=0.0.0.0/0

Не забудьте включить обратно:

[admin@MikroTik] >
/interface/enable ether1

Мониторинг BGP в production

Для постоянного мониторинга:

[admin@MikroTik] >
# Логирование BGP-событий
/system/logging/add topics=bgp action=memory

# Просмотр логов BGP
/log/print where topics~"bgp"

Рекомендуется настроить SNMP-мониторинг или syslog на внешний сервер для алертов при падении BGP-сессий.

Типичные ошибки

1. Сессия зависает в состоянии «active»

Симптом: BGP session показывает state=active, не переходит в established.

Причина: чаще всего — несовпадение ASN, MD5-ключа или address-family. Также возможно: firewall блокирует TCP port 179.

Диагностика:

[admin@MikroTik] >
/system/logging/add topics=bgp,!packet action=memory
/log/print where topics~"bgp"

В логах будет конкретная причина: «bad AS», «MD5 digest mismatch», «unsupported capability».

Решение: сверьте все параметры с данными, предоставленными ISP:

  • Наш ASN и ASN пира
  • IP-адреса обеих сторон
  • MD5-ключ (если используется)
  • Address family (ipv4, ipv6)
[admin@MikroTik] >
/routing/bgp/connection/print detail where name=isp-a

2. Маршрут анонсируется, но не виден у ISP

Симптом: advertisements/print показывает наш prefix, но ISP не видит его в своей таблице.

Причины:

  • ISP фильтрует наш анонс (prefix не зарегистрирован в IRR/RPKI)
  • AS-PATH содержит неожиданный ASN
  • Prefix length > /24 (многие ISP не принимают более специфичные маршруты)

Решение:

  1. Проверьте регистрацию prefix в IRR (RIPE, ARIN) через whois
  2. Убедитесь что ROA (Route Origin Authorization) создан в RPKI
  3. Свяжитесь с ISP для проверки их prefix-filter
[admin@MikroTik] >
# Проверить что именно мы анонсируем
/routing/bgp/advertisements/print detail

3. Полная таблица BGP положила маршрутизатор

Симптом: маршрутизатор стал недоступен после установки BGP-сессии. Высокое потребление RAM.

Причина: ISP прислал полную таблицу BGP (~930000 префиксов на 2025 год). MikroTik (кроме CCR/CHR с достаточным объёмом RAM) не справляется.

Решение: никогда не принимайте полную таблицу без необходимости и достаточных ресурсов. Используйте input filter для приёма только default route:

[admin@MikroTik] >
/routing/filter/rule add \
  chain=bgp-in \
  rule="if (dst == 0.0.0.0/0) { accept }"

/routing/filter/rule add \
  chain=bgp-in \
  rule="reject"

Если полная таблица необходима, используйте CHR или CCR2004/CCR2216 с минимум 4 ГБ RAM.

Также установите max-prefix limit:

[admin@MikroTik] >
/routing/bgp/connection set isp-a input.limit-process-routes-ipv4=5

4. Трафик не возвращается по тому же ISP (asymmetric routing)

Симптом: исходящий трафик идёт через ISP A, но ответы приходят через ISP B.

Причина: это нормальное поведение BGP — каждая AS независимо выбирает маршрут. Ваш prepend может не влиять на все AS в интернете.

Решение:

  • Увеличьте prepend на резервном канале (3–5 раз)
  • Используйте BGP communities ISP для более точного управления
  • Примите ассиметричность как факт — большинство firewall с connection tracking работают корректно с asymmetric routing (если настроен connection-state=established,related в правилах)

5. BGP-сессия падает каждые несколько минут

Симптом: сессия устанавливается, но через 1–3 минуты падает и переустанавливается.

Причина: обычно — hold-time слишком мал при высокой загрузке CPU. Если маршрутизатор не успевает отправить keepalive за hold-time/3, пир считает сессию мёртвой.

Решение: увеличить hold-time:

[admin@MikroTik] >
/routing/bgp/connection set isp-a hold-time=3m keepalive-time=1m

Также проверьте CPU-нагрузку:

[admin@MikroTik] >
/system/resource/print

Если CPU > 90%, разгрузите маршрутизатор: уменьшите количество принимаемых маршрутов, отключите ненужные фильтры, рассмотрите более мощное оборудование.

6. Ошибки в синтаксисе filter/rule

Симптом: фильтр не применяется или выдаёт ошибку при создании.

Причина: синтаксис /routing/filter/rule в RouterOS 7 существенно отличается от RouterOS 6 и требует внимательности к кавычкам и структуре.

Решение: основные правила синтаксиса:

[admin@MikroTik] >
# Правильно — условие в if, действие в фигурных скобках
rule="if (dst == 0.0.0.0/0) { accept }"

# Правильно — множественные условия
rule="if (dst in 10.0.0.0/8 && bgp-as-path .64500.) { reject }"

# Правильно — установка атрибута
rule="if (dst == 203.0.113.0/24) { set bgp-path-prepend 3; accept }"

# Неправильно — забыты скобки или кавычки
rule=if dst == 0.0.0.0/0 accept

Проверьте фильтры после создания:

[admin@MikroTik] >
/routing/filter/rule/print where chain=bgp-in

7. Не работает MD5-аутентификация

Симптом: сессия не устанавливается после добавления tcp-md5-key. В логах «TCP connection reset».

Причина: MD5-ключ не совпадает с настройкой на стороне ISP. Даже один лишний пробел или разница в регистре приведёт к отказу.

Решение:

  • Сверьте ключ символ за символом с ISP
  • Проверьте нет ли пробелов в начале/конце ключа
  • Временно уберите MD5 с обеих сторон для диагностики:
[admin@MikroTik] >
/routing/bgp/connection set isp-a tcp-md5-key=""

Рекомендации для production

  • Всегда фильтруйте входящие и исходящие маршруты. Открытый BGP без фильтров — угроза для интернета.
  • Регистрируйте маршруты в IRR (RIPE DB, RADb) и создайте ROA-записи в RPKI. Многие ISP и IX уже enforce RPKI validation.
  • Мониторьте BGP-сессии через SNMP/syslog. Алерт при падении сессии должен приходить немедленно.
  • Используйте looking glass сервисов (lg.he.net, bgp.tools, stat.ripe.net) для проверки видимости ваших анонсов из разных точек мира.
  • Документируйте все BGP-сессии, communities и фильтры. BGP-конфигурация — не то место, где можно полагаться на память.
  • Тестируйте failover регулярно — отключайте один из ISP и проверяйте время переключения и доступность сервисов.
[admin@MikroTik] >
┌──── ISP A (AS 64500) ────┐
                    │    Peer IP: 192.0.2.1     │
                    │                           │
[Наша сеть]         │                           │     [Интернет]
AS 65000            │                           │
PI: 203.0.113.0/24  │                           │
                    │                           │
                    │    Peer IP: 192.0.2.5     │
                    └──── ISP B (AS 64501) ────┘

MikroTik Router:
  ether1 → ISP A (192.0.2.2/30)
  ether2 → ISP B (192.0.2.6/30)
  ether3–5 → LAN (203.0.113.0/24)
# WAN к ISP A
/ip/address add address=192.0.2.2/30 interface=ether1 comment="WAN ISP A"

# WAN к ISP B
/ip/address add address=192.0.2.6/30 interface=ether2 comment="WAN ISP B"

# LAN — PI-блок
/ip/address add address=203.0.113.1/24 interface=bridge-LAN comment="PI block"
/routing/bgp/template add \
  name=default \
  as=65000 \
  router-id=203.0.113.1 \
  address-families=ip \
  routing-table=main \
  comment="Our AS 65000"
/routing/filter/rule add \
  chain=bgp-in \
  rule="if (dst == 0.0.0.0/0) { accept }" \
  comment="Accept default route only"

/routing/filter/rule add \
  chain=bgp-in \
  rule="reject" \
  comment="Reject everything else"
/routing/filter/rule add \
  chain=bgp-out \
  rule="if (dst == 203.0.113.0/24) { accept }" \
  comment="Announce our PI block"

/routing/filter/rule add \
  chain=bgp-out \
  rule="reject" \
  comment="Reject everything else"
/routing/filter/rule add \
  chain=bgp-out-ispb \
  rule="if (dst == 203.0.113.0/24) { set bgp-path-prepend 3; accept }" \
  comment="Announce PI with 3x prepend via ISP B"

/routing/filter/rule add \
  chain=bgp-out-ispb \
  rule="reject" \
  comment="Reject everything else"
# Default route от ISP A — высокий приоритет
/routing/filter/rule add \
  chain=bgp-in-ispa \
  rule="if (dst == 0.0.0.0/0) { set bgp-local-pref 200; accept }" \
  comment="ISP A default - high priority"

/routing/filter/rule add \
  chain=bgp-in-ispa \
  rule="reject"

# Default route от ISP B — низкий приоритет
/routing/filter/rule add \
  chain=bgp-in-ispb \
  rule="if (dst == 0.0.0.0/0) { set bgp-local-pref 100; accept }" \
  comment="ISP B default - low priority"

/routing/filter/rule add \
  chain=bgp-in-ispb \
  rule="reject"
/routing/bgp/connection add \
  name=isp-a \
  template=default \
  remote.address=192.0.2.1 \
  remote.as=64500 \
  local.address=192.0.2.2 \
  local.role=customer \
  multihop=no \
  hold-time=90s \
  keepalive-time=30s \
  address-families=ip \
  input.filter=bgp-in-ispa \
  output.filter=bgp-out \
  output.network=203.0.113.0/24 \
  comment="eBGP to ISP A (primary)"
/routing/bgp/connection add \
  name=isp-b \
  template=default \
  remote.address=192.0.2.5 \
  remote.as=64501 \
  local.address=192.0.2.6 \
  local.role=customer \
  multihop=no \
  hold-time=90s \
  keepalive-time=30s \
  address-families=ip \
  input.filter=bgp-in-ispb \
  output.filter=bgp-out-ispb \
  output.network=203.0.113.0/24 \
  comment="eBGP to ISP B (backup)"
/ip/route add dst-address=203.0.113.0/24 type=blackhole comment="Anchor route for BGP announcement"
/routing/bgp/connection set isp-a tcp-md5-key="SecretKeyISPA2024"
/routing/bgp/connection set isp-b tcp-md5-key="SecretKeyISPB2024"
/routing/bgp/connection set isp-a multihop=no
/routing/bgp/connection set isp-a input.limit-process-routes-ipv4=10
/routing/bgp/connection set isp-b input.limit-process-routes-ipv4=10
/routing/bgp/connection add \
  name=ibgp-router2 \
  template=default \
  remote.address=10.255.255.2 \
  remote.as=65000 \
  local.address=10.255.255.1 \
  local.role=ibgp \
  address-families=ip \
  comment="iBGP to Router 2"
/routing/filter/rule add \
  chain=bgp-out-blackhole \
  rule="if (dst == 203.0.113.100/32) { set bgp-communities 64500:666; accept }" \
  comment="Blackhole single IP at ISP A"
# Попросить ISP A установить local-pref 50 (backup) для нашего анонса
/routing/filter/rule add \
  chain=bgp-out-low-pref \
  rule="if (dst == 203.0.113.0/24) { set bgp-communities 64500:50; accept }"
/routing/bgp/session/print
Flags: E - established
 #   NAME      REMOTE-ADDRESS  REMOTE-AS  STATE        UPTIME
 0 E isp-a     192.0.2.1       64500      established  1d12h
 1 E isp-b     192.0.2.5       64501      established  1d12h
/routing/bgp/advertisements/print
/routing/route/print where bgp
/routing/route/print detail where dst-address=0.0.0.0/0
/ip/route/print where routing-table=main
/interface/disable ether1
/routing/bgp/session/print
/ip/route/print where dst-address=0.0.0.0/0
/interface/enable ether1
# Логирование BGP-событий
/system/logging/add topics=bgp action=memory

# Просмотр логов BGP
/log/print where topics~"bgp"
/system/logging/add topics=bgp,!packet action=memory
/log/print where topics~"bgp"
/routing/bgp/connection/print detail where name=isp-a
# Проверить что именно мы анонсируем
/routing/bgp/advertisements/print detail
/routing/filter/rule add \
  chain=bgp-in \
  rule="if (dst == 0.0.0.0/0) { accept }"

/routing/filter/rule add \
  chain=bgp-in \
  rule="reject"
/routing/bgp/connection set isp-a input.limit-process-routes-ipv4=5
/routing/bgp/connection set isp-a hold-time=3m keepalive-time=1m
/system/resource/print
# Правильно — условие в if, действие в фигурных скобках
rule="if (dst == 0.0.0.0/0) { accept }"

# Правильно — множественные условия
rule="if (dst in 10.0.0.0/8 && bgp-as-path .64500.) { reject }"

# Правильно — установка атрибута
rule="if (dst == 203.0.113.0/24) { set bgp-path-prepend 3; accept }"

# Неправильно — забыты скобки или кавычки
rule=if dst == 0.0.0.0/0 accept
/routing/filter/rule/print where chain=bgp-in
/routing/bgp/connection set isp-a tcp-md5-key=""
Routing / BGP на MikroTik — настройка для ISP и multihoming