BGP на MikroTik — настройка для ISP и multihoming
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) — не анонсировать за пределы ASno-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 6 | RouterOS 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 на линке к ISPlocal.role=customer— определяет роль в BGP-сессии (RFC 9234). Для клиента ISP —customerhold-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
Ожидаемый вывод:
codeFlags: 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. Другие состояния указывают на проблемы:
| Состояние | Проблема |
|---|---|
idle | BGP не пытается установить сессию (disabled или ошибка конфигурации) |
connect | TCP-соединение не устанавливается (firewall, нет маршрута, wrong IP) |
active | TCP-соединение установлено, но BGP-согласование не проходит (wrong AS, MD5 mismatch) |
opensent | OPEN-сообщение отправлено, ждём ответ |
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 не принимают более специфичные маршруты)
Решение:
- Проверьте регистрацию prefix в IRR (RIPE, ARIN) через
whois - Убедитесь что ROA (Route Origin Authorization) создан в RPKI
- Свяжитесь с 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 и проверяйте время переключения и доступность сервисов.
┌──── 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=""