L3 BGP — визуализированный

BGP (Border Gateway Protocol) — клей всего интернета. Это единственный протокол, который связывает десятки тысяч автономных систем (провайдеров, облаков, корпораций) в одну сеть. В отличие от OSPF, BGP заботится не о «самом быстром пути», а о политике: с кем дружим, через кого пускаем трафик, кого предпочитаем. И всё чаще BGP приходит внутрь дата-центров и Kubernetes — поэтому учим глубоко, с пакетами и реальными сценариями.

Заявка из реальной жизни

Понедельник, 09:47. В мониторинге красное: «BGP-сессия с провайдером Beeline (AS 3216) упала в 09:31, трафик ушёл через резервного провайдера, клиенты жалуются на задержки». Дежурный старший бросает тебе в чат: «глянь show bgp summary на границе, что там с пирингом, и почему префиксы с резерва идут кривым путём через Франкфурт».

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

Вспомни из прошлых модулей

Модуль 5: у каждого маршрута есть источник и administrative distance (AD) — «уровень доверия». Сегодня появятся два новых: eBGP (AD 20) и iBGP (AD 200).
Модуль 6: OSPF ищет кратчайший путь по метрике внутри одной сети. BGP решает другую задачу: выбирает путь между организациями по политике, а не по скорости.
Ступень 1, урок 4: BGP-сессия живёт поверх TCP 179, соседи прописываются руками, здоровое состояние — Established. Сегодня раскроем всё, что было «за кадром»: атрибуты, best-path, route reflector, политика, безопасность.

Что узнаешь

Что такое автономная система (AS), path-vector, транзит и пиринг, IX
eBGP против iBGP — в чём разница и зачем оба
4 типа сообщений BGP и как выглядит OPEN/UPDATE «на проводе»
Как поднимается сессия (TCP 179), состояния FSM и по какому состоянию — какой диагноз
Категории path-атрибутов и best-path selection «на зубок» + полный разбор на примере
Инструменты политики: Local-Pref, AS-Path prepend, MED, communities, prefix-list и route-map
Проблема iBGP full-mesh, next-hop-self и route reflector (с дизайном на два RR)
Таймеры, BFD и скорость сходимости — почему сессия «висела 3 минуты»
Реальный сценарий multihoming с двумя провайдерами — на Cisco, Juniper и Huawei
Агрегация, multipath, безопасность: hijacking, RPKI/ROV, фильтры, max-prefix
Плейбуки диагностики: сессия не поднимается / префикса нет / путь кривой
Мини-лабы: настоящий BGP интернета из браузера и свой BGP-стенд в Docker за 15 минут
Мост в DevOps: Calico и MetalLB с конфигами
Задачи с ответами, вопросы с собеседований, словарик

1. Автономные системы и path-vector

Автономная система (AS) — это сеть под единым управлением с единой политикой маршрутизации (провайдер, крупная компания, облако). У каждой — свой номер ASN (например, 15169 — Google, 13335 — Cloudflare). Номера бывают 16-битные (до 65535) и 32-битные; диапазоны 64512–65534 и 4200000000+ — приватные (для внутреннего использования, как RFC1918 для IP). BGP работает между AS.

BGP — path-vector: вместе с префиксом он несёт AS-PATH — список AS, через которые маршрут прошёл. Это и защита от петель (видишь свой ASN в пути — отбрасываешь), и информация для выбора пути (короче AS-PATH — обычно лучше).

Префикс путешествует между AS, накапливая AS-PATH

Каждая AS, передавая маршрут дальше, дописывает свой ASN в начало AS-PATH.

Аналогия

AS — государства, BGP — дипломатия

Внутри страны (AS) дороги строит сама страна и правила движения свои — это IGP (OSPF). А вот между странами всё решают договоры: с кем открыть границу, чей транзит пускать, кому дать скидку. BGP — язык этих договоров. Поэтому в BGP «лучший путь» — не самый быстрый, а самый выгодный по политике: деньги и договорённости важнее миллисекунд.

Номера AS: какие бывают и что можно занимать

Диапазон ASN	Что это	Пример
`1 – 64495`	публичные 16-битные — выдаёт региональный регистратор (RIPE, ARIN…)	15169 Google, 3216 Билайн, 13335 Cloudflare
`64512 – 65534`	приватные 16-битные — как RFC1918 для IP: внутри сети, в лабах, на стыках PE–CE	65010 в наших примерах
`65536 – 4199999999`	публичные 32-битные (asplain) — новых 16-битных давно не хватает	196608+ у новых операторов
`4200000000 – 4294967294`	приватные 32-битные — любимый диапазон дата-центров (по ASN на стойку)	4200000001 в фабриках Clos
`23456`	AS_TRANS — «заглушка» для совместимости старых роутеров с 32-битными ASN	увидел 23456 в пути — где-то старое железо

На собеседовании любят: «какой диапазон приватных ASN?» — 64512–65534 (и 4200000000+ для 32-битных). И вдогонку: «что будет, если приватный ASN утечёт в интернет?» — приличный оператор вычищает их командой remove-private-as на выходе.

Транзит, пиринг и IX — экономика, на которой стоит BGP

Связи между AS бывают двух главных типов, и от типа связи зависит вся политика анонсов — это фундамент, без которого конфиги BGP выглядят магией:

💰 Транзит (customer → provider)

Ты платишь провайдеру, он даёт тебе весь интернет
Провайдер анонсирует тебе всё (или default), а твои префиксы — всему миру
Трафик клиента для провайдера — доход, поэтому маршруты клиентов всегда в приоритете

🤝 Пиринг (peer ↔ peer)

Две AS обмениваются трафиком бесплатно (или почти)
Анонсируют друг другу только свои сети и сети своих клиентов — не весь интернет!
Часто происходит на IX (Internet Exchange, точка обмена: MSK-IX, DE-CIX, AMS-IX) — один порт, сотни соседей

Отсюда золотое правило политики любого оператора (правило Gao–Rexford, его же спрашивают на собеседованиях уровнем повыше): маршруты от клиентов отдаём всем (нам платят за их трафик), маршруты от пиров и аплинков — только клиентам (иначе бесплатно повезём чужой транзит). Реализуется это через LOCAL_PREF: клиент ~ 300, пир ~ 200, аплинк ~ 100. Запомни эту тройку — она объяснит тебе половину чужих конфигов.

Tier-1, Tier-2, Tier-3. Tier-1 — операторы, которые не платят за транзит никому (Lumen, Cogent, Telia…, их порядка 15 в мире): у них пиринг со всеми равными. Tier-2 — покупают транзит у Tier-1, но много пирятся (крупные национальные операторы). Tier-3 — почти всё покупают (региональные провайдеры). Твоя компания, скорее всего, клиент Tier-2/3.

Попробуй прямо сейчас

Настоящие AS и их связи видны публично — 3 минуты, только браузер:

Открой bgp.tools и вбей AS13335 (Cloudflare). Вкладка Connectivity — живые аплинки и пиры этой AS: вот они, транзит и пиринг из абзаца выше.
Там же вбей IP своего сайта — увидишь, какая AS его анонсирует и каким префиксом.
Открой lg.he.net (looking glass Hurricane Electric) → «BGP Route» для 8.8.8.8 — увидишь настоящий AS-PATH от магистрали до Google. Обрати внимание, какой он короткий: до крупных сетей обычно 1–3 хопа AS.

2. eBGP против iBGP

eBGP — между разными AS

Сессия между соседями в разных ASN
AD = 20 (высокое доверие)
TTL=1 (обычно напрямую связаны)
Меняет next-hop на себя, добавляет свой ASN в AS-PATH

iBGP — внутри одной AS

Сессия между роутерами в одной ASN
AD = 200 (ниже доверие, чем у IGP)
Не меняет AS-PATH и (по умолч.) next-hop
Правило split-horizon: маршрут из iBGP нельзя передать другому iBGP-соседу → нужен full-mesh или RR

Зачем iBGP вообще? Чтобы пронести внешние префиксы (полученные по eBGP на границе) через свою AS до других пограничных роутеров — не «загрязняя» этим IGP. IGP держит внутренние сети, iBGP — внешние.

3. Четыре сообщения BGP

Сообщение	Зачем
OPEN	установить сессию: согласовать версию, ASN, hold-time, capabilities
UPDATE	анонс/отзыв маршрутов: NLRI (префиксы) + path-атрибуты
KEEPALIVE	«я жив» (по умолчанию каждые 60 с); держит сессию
NOTIFICATION	ошибка → закрыть сессию (с кодом причины)

UPDATE «на проводе» (упрощённый разбор):

── BGP UPDATE (поверх TCP, порт 179) ── Withdrawn Routes: (нет) Path Attributes: ORIGIN: IGP AS_PATH: 65020 65010 # через кого пришёл NEXT_HOP: 203.0.113.1 LOCAL_PREF: 100 # только в iBGP COMMUNITY: 65020:300 NLRI: 203.0.113.0/24 # сам анонсируемый префикс

4. Сессия BGP: TCP 179 и состояния

В отличие от OSPF (свой транспорт поверх IP), BGP работает поверх TCP, порт 179 — надёжно и с потоковым контролем. Соседи (peers) задаются вручную: BGP не «находит» соседей автоматически. Сессия проходит конечный автомат:

FSM сессии BGP

Здоровая сессия — Established. Префиксы обмениваются только после неё.

Состояния FSM — не абстракция для экзамена, а готовый диагноз. По тому, где сессия «застряла», ты сразу знаешь, куда смотреть:

Состояние	Что происходит	Если застряло — диагноз
Idle	сессия выключена / только что сброшена	сосед не сконфигурирован, интерфейс down, административный shutdown, сработал max-prefix (сессия ушла в Idle с пометкой)
Connect	пытаемся открыть TCP до соседа	обычно проскакивает мгновенно; если видишь часто — TCP то открывается, то рвётся
Active	TCP не открылся, пробуем снова (название обманчивое: «активно пытаюсь», а не «работаю»)	❗ самый частый залип: нет IP-связности до соседа, ACL/firewall режет TCP 179, ошибка в peer-IP, для iBGP — нет маршрута до loopback соседа
OpenSent	TCP есть, отправили OPEN, ждём OPEN в ответ	сосед отвечает не тем: несовпадение ASN («BGP: bad remote-as»), кривой router-id
OpenConfirm	OPEN-ы обменяны, ждём первый KEEPALIVE	почти не залипает; если да — смотри NOTIFICATION в логах
Established	✅ сессия работает, идут UPDATE-ы	здоровое состояние; теперь вопросы только к префиксам и политике

Так рождение здоровой сессии выглядит в логах роутера (Cisco, debug ip bgp приглажен до сути):

%BGP-5-ADJCHANGE: neighbor 203.0.113.1 Down Interface flap ← сессия умерла (упал линк) BGP: 203.0.113.1 went from Idle to Active ← пробуем TCP… BGP: 203.0.113.1 open active, local address 203.0.113.2 ← TCP 179 открылся BGP: 203.0.113.1 went from Active to OpenSent ← послали OPEN (наш ASN, hold-time…) BGP: 203.0.113.1 rcv OPEN, remote AS 64500, holdtime 180 ← сосед прислал свой OPEN BGP: 203.0.113.1 went from OpenSent to OpenConfirm BGP: 203.0.113.1 went from OpenConfirm to Established ← 🎉 пошли UPDATE-ы %BGP-5-ADJCHANGE: neighbor 203.0.113.1 Up

В OPEN согласуются таймеры. Каждая сторона предлагает свой hold-time, побеждает меньший. Классика Cisco: keepalive 60 с, hold-time 180 с. Это значит: если линк умер «молча» (без физического down), сессия провисит мёртвой до 3 минут — весь трафик в чёрную дыру. Как жить быстрее — в разделе «Таймеры и BFD».

частая путаница Active ≠ активная сессия! Новички видят «Active» и радуются. На деле Active — это «я активно пытаюсь открыть TCP и у меня не выходит». Работает только Established. Запомни: Active — это плохо. Идёшь проверять связность: ping соседа, telnet <peer-ip> 179 (открылся — значит, TCP проходит и дело в конфиге BGP).

5. Path-атрибуты — категории

Атрибуты маршрута делятся на категории — это любят спрашивать:

Категория	Примеры	Смысл
Well-known mandatory	ORIGIN, AS_PATH, NEXT_HOP	обязаны быть, понимают все
Well-known discretionary	LOCAL_PREF, ATOMIC_AGGREGATE	понимают все, но не обязательны
Optional transitive	COMMUNITY, AGGREGATOR	можно не понимать, но передать дальше
Optional non-transitive	MED, ORIGINATOR_ID	не понял — не передавай дальше

Главные атрибуты — что каждый значит на практике

Атрибут	Кто ставит	Как далеко живёт	Зачем на практике
NEXT_HOP	eBGP-сосед меняет на себя; iBGP — не трогает	переносится	куда физически слать пакет; корень болезни «маршрут есть, а не ставится» (лечится next-hop-self)
AS_PATH	каждая AS дописывает свой ASN на eBGP-выходе	через весь интернет	защита от петель + выбор пути + фильтры по regex
LOCAL_PREF	ты сам на входе (route-map in)	только внутри твоей AS (iBGP)	главный руль исходящего трафика: выше — лучше, default 100
MED	ты сам на выходе (route-map out)	только в соседнюю AS, дальше не идёт	вежливая просьба соседу «заходи ко мне через этот линк»: меньше — лучше
ORIGIN	роутер, породивший маршрут	через весь интернет	IGP (`i`, через network) < EGP (`e`, архаика) < incomplete (`?`, через redistribute)
COMMUNITY	кто угодно по пути (route-map)	пока не срежут (transitive)	стикеры на маршруте: «клиентский», «не отдавай в Европу», «блэкхоль это»
WEIGHT	только Cisco, только локально	не покидает роутер	грубый локальный форс: выше — лучше; в чужих конфигах почти не встретишь

Мнемоника направлений — то, что путают все джуны: LOCAL_PREF управляет тем, как трафик ВЫХОДИТ из твоей AS. Prepend и MED — тем, как он ВХОДИТ. Проверка логикой: LOCAL_PREF дальше твоей AS не уходит — значит, чужие решения он менять не может; а вот AS_PATH видят все — значит, prepend влияет на чужой выбор.

Читаем атрибуты вживую: show ip bgp «про один префикс»

Самая информативная команда при разборе «почему трафик идёт туда» — запрос по конкретному префиксу. Разберём вывод построчно, как ты будешь делать это на смене:

R1# show ip bgp 203.0.113.0/24 BGP routing table entry for 203.0.113.0/24, version 421 Paths: (2 available, best #1, table default) ← два пути, лучший — первый Advertised to update-groups: 1 ← кому мы его перерассказываем 64500 65010 ← AS-PATH пути №1 (2 хопа AS) 198.51.100.1 from 198.51.100.1 (10.0.0.1) ← next-hop и router-id соседа Origin IGP, localpref 200, valid, external, best ← LP 200 — мы «подкрутили» route-map-ом Community: 64500:300 ← сосед пометил: «маршрут клиента» 64510 64509 65010 ← AS-PATH пути №2 (3 хопа AS) 192.0.2.9 from 192.0.2.9 (10.0.0.2) Origin IGP, localpref 100, valid, external ← LP 100 — проиграл на шаге LOCAL_PREF

Вопрос «почему выбран путь №1» здесь отвечается за секунды: у него localpref 200 против 100 — алгоритм best-path дальше даже не пошёл (AS-PATH длиной 2 против 3 уже не важен). Если бы LOCAL_PREF были равны — победил бы №1 по более короткому AS-PATH. Такой разбор — это буквально вопрос №1 в собеседованиях и в реальных заявках «трафик идёт не туда».

6. Best-path selection — порядок «на зубок»

Если до одного префикса пришло несколько вариантов, BGP выбирает один лучший по строгому порядку атрибутов. Это самый частый вопрос на собеседовании по BGP. Порядок (Cisco):

Best-path: проходим сверху вниз, пока не определится победитель

На практике 90% политики — это LOCAL_PREF (исходящий) и AS-PATH prepend (входящий).

Мнемоника: Weight → LOCAL_PREF → AS-PATH → ... . «Weight Loves AS-path». LOCAL_PREF рулит исходящим трафиком из своей AS, AS-PATH prepend намекает чужим AS, каким входом к тебе лучше идти.

Разбор руками: три пути — кто победит?

Роутер R1 (AS 65010) получил префикс 198.18.0.0/24 тремя путями. Пройди алгоритм сам, прежде чем читать разбор:

	Путь A (от ISP-1, eBGP)	Путь B (от ISP-2, eBGP)	Путь C (от R2, iBGP)
Weight	0	0	0
LOCAL_PREF	100	100	100
AS-PATH	64500 64777 65099	64510 65099	64510 65099
ORIGIN	IGP	IGP	IGP
MED	10	50	50

Weight: у всех 0 — не решает, идём дальше.

LOCAL_PREF: везде 100 — дальше.

Locally originated: все пути чужие — дальше.

AS-PATH: A — три ASN, B и C — по два. Путь A выбыл (и заметь: его MED 10 «лучше», но до сравнения MED дело уже не дойдёт — порядок строгий!).

ORIGIN, MED: у B и C одинаковые — дальше. (MED вообще сравнивается только если первый ASN в пути одинаковый — здесь 64510 = 64510, но значения равны.)

eBGP > iBGP: B пришёл по eBGP, C по iBGP. Победил B. Логика: зачем везти трафик через всю свою сеть к другому пограничному роутеру (C), если внешний выход есть прямо здесь (B)? Это называется hot-potato routing — «избавься от чужого трафика как можно раньше».

Читаем таблицу BGP: что значат `*`, `>`, `i`

R1# show ip bgp Network Next Hop Metric LocPrf Weight Path *> 198.18.0.0/24 198.51.100.9 0 100 0 64510 65099 i * 198.18.0.0/24 203.0.113.7 10 100 0 64500 64777 65099 i *i 198.18.0.0/24 10.255.0.2 50 100 0 64510 65099 i

* — путь валиден (next-hop достижим). Нет звёздочки — маршрут «мёртв» и не участвует в выборе.
> — best: именно он идёт в таблицу маршрутизации и анонсируется соседям. На префикс — ровно один >.
i после * — путь пришёл по iBGP; i в конце строки — это ORIGIN=IGP (да, две разные буквы i, все путают).
Колонка Metric — это MED, LocPrf — LOCAL_PREF, Path — AS-PATH.

вопрос с собеседования «Видишь в show ip bgp маршрут без звёздочки — что делаешь?» Ответ: это невалидный путь, почти всегда — недостижимый next-hop. Проверяю show ip route <next-hop>; если это iBGP-маршрут с внешним next-hop — на пограничнике забыли next-hop-self.

7. Инструменты политики

LOCAL_PREF — главный инструмент исходящего выбора. «Через провайдера A выходим в приоритете, B — резерв» → ставим A более высокий LOCAL_PREF. Действует внутри всей твоей AS.
AS-PATH prepend — дописываешь свой ASN несколько раз, путь «удлиняется», чужие AS реже выбирают этот вход. Единственный мягкий способ влиять на входящий трафик.
MED — «metric» для соседней AS: какой из нескольких твоих линков она должна предпочесть на вход. Соседняя AS может его игнорировать.
Communities — теги-метки на маршрутах (например 65000:100). По ним строят политику оптом: провайдеры публикуют community вида «не анонсируй этот префикс в Европу» и т.п.

Well-known communities — знать наизусть

Четыре зарезервированных community понимают все вендоры — их часто спрашивают:

Community	Эффект
`NO_EXPORT`	не анонсировать за пределы своей AS (внутри — можно)
`NO_ADVERTISE`	не анонсировать вообще никому (даже соседям)
`NO_EXPORT_SUBCONFED` (LOCAL_AS)	не выходить за пределы суб-AS в конфедерации
`INTERNET`	анонсировать всем (community по умолчанию)

AS-PATH prepend: «удлиняем» путь, чтобы входящий трафик шёл другим линком

Prepend — мягкий намёк, а не приказ: чужие AS могут иметь свою политику (LOCAL_PREF), которая важнее AS-PATH.

Чем политика пишется: prefix-list, as-path-list, route-map

Сами по себе LOCAL_PREF и prepend — «что сделать». А «к каким маршрутам применить» описывают три инструмента, из которых собирается вся BGP-политика на Cisco (у Juniper это policy-statement, у Huawei — route-policy, идеи те же):

# 1) prefix-list — фильтр по самим префиксам (сеть + длина маски) R1(config)# ip prefix-list OUR-NETS seq 5 permit 192.0.2.0/24 R1(config)# ip prefix-list OUR-NETS seq 10 permit 192.0.3.0/24 # ge/le задают диапазон длин: «все подсети 10.0.0.0/8 от /24 до /32»: R1(config)# ip prefix-list LONG-ONES permit 10.0.0.0/8 ge 24 le 32 # 2) as-path access-list — фильтр по AS-PATH через regex R1(config)# ip as-path access-list 10 permit ^64500$ # только то, что породил сам 64500 R1(config)# ip as-path access-list 20 permit _65099_ # путь проходит через AS 65099 R1(config)# ip as-path access-list 30 permit ^$ # пустой путь = мои собственные маршруты # 3) route-map — «если совпало → сделай»: клей всей политики R1(config)# route-map FROM-ISP-A permit 10 R1(config-route-map)# match ip address prefix-list SOME-NETS R1(config-route-map)# set local-preference 200 R1(config)# route-map FROM-ISP-A permit 20 # «всё остальное — пропустить как есть» # привязка к соседу (in — на приём, out — на отдачу) R1(config-router)# neighbor 203.0.113.1 route-map FROM-ISP-A in

ловушка Route-map заканчивается неявным «deny всё». Забыл пустую секцию permit 20 в конце — и всё, что не совпало с match, молча отброшено. Клиент «внезапно» потерял половину интернета — а это твоя route-map съела маршруты. Вторая классика: изменил политику, но забыл clear ip bgp <peer> soft — политика применяется к новым UPDATE-ам, а старые маршруты лежат как лежали.

Мини-шпаргалка regex для AS-PATH (спрашивают удивительно часто):

Regex	Что ловит
^$	пустой AS-PATH — маршруты, порождённые в моей AS
^64500$	маршруты, которые породил сосед 64500 (и только он в пути)
^64500_	всё, что пришло от соседа 64500 (его клиенты тоже)
_65099$	маршруты, порождённые AS 65099 (она в конце пути)
_65099_	путь проходит через 65099 где угодно
.*	всё (символ `_` означает границу: пробел, начало, конец)

Communities в бою: RTBH и «меню» провайдера

Community — это просто число-стикер ASN:значение, но на них построены целые сервисы. Два примера, которые встретишь в реальной работе:

RTBH (Remote-Triggered Black Hole) — защита от DDoS. Тебя заливают атакой на 192.0.2.77. Ты анонсируешь провайдеру этот /32 с community ASN:666 — и провайдер дропает весь трафик к нему на своей стороне, до того как атака доехала до твоего канала. Жертвуешь одним адресом — спасаешь канал. Значение 666 — общепринятое (RFC 7999, community BLACKHOLE).
Traffic engineering по «меню» — крупные операторы публикуют список community-команд, которые клиент может вешать на свои анонсы: 3216:2000 «не анонсируй в Европу», 3216:70 «сделай prepend ×3 в сторону такого-то стыка». Ищется по запросу «<оператор> BGP communities» — загляни в такой документ ради интереса, это политика BGP во всей красе.

# RTBH на стороне клиента: анонсируем /32 с blackhole-community R1(config)# ip route 192.0.2.77 255.255.255.255 Null0 # маршрут-заглушка, чтобы BGP было что анонсировать R1(config)# route-map RTBH permit 10 R1(config-route-map)# match ip address prefix-list VICTIM-32 R1(config-route-map)# set community 64500:666 # «community для блэкхола» из документации ISP R1(config-router)# neighbor 203.0.113.1 send-community # ⚠ без этого community вообще не уйдут!

Классический фейл: навесил community, а сосед их «не видит». На Cisco community по умолчанию не отправляются — нужна команда neighbor X send-community (на Juniper и Huawei — отправляются сами). Проверь это первым делом.

8. iBGP full-mesh, next-hop-self и route reflector

Правило split-horizon: маршрут, полученный по iBGP, нельзя передавать другому iBGP-соседу (защита от петель, ведь AS-PATH внутри AS не меняется). Значит, все iBGP-роутеры должны быть соединены «каждый с каждым» — full-mesh. При N роутерах это N×(N−1)/2 сессий: 10 роутеров → 45 сессий, 50 → 1225. Не масштабируется.

Решение — Route Reflector (RR): один (или пара) роутеров получает право рефлектить iBGP-маршруты своим клиентам. Клиенты держат сессию только с RR. Петли контролируются атрибутами CLUSTER_LIST и ORIGINATOR_ID. Альтернатива — конфедерации (реже).

Full-mesh против Route Reflector

RR превращает N² сессий в звезду: клиенты держат сессию только с рефлектором.

Настройка RR до смешного простая — одна команда на стороне рефлектора, клиенты вообще не в курсе:

# на рефлекторе: объявляем соседа клиентом RR(config-router)# neighbor 10.255.0.11 route-reflector-client RR(config-router)# neighbor 10.255.0.12 route-reflector-client # на клиентах — обычный iBGP-сосед в сторону RR, никаких спецкоманд

Три правила рефлексии (частый вопрос на уровне CCNP):

от клиента → отражается всем (клиентам и не-клиентам);
от не-клиента → отражается только клиентам;
от eBGP-соседа → всем, как обычно.

Дизайн по-взрослому: RR всегда ставят парой (умер единственный RR — развалился весь iBGP). Каждый клиент держит две сессии — к RR1 и RR2. Чтобы пара не зациклила маршруты друг через друга, у обоих ставят одинаковый bgp cluster-id — по CLUSTER_LIST дубликат распознаётся и отбрасывается. И важно: RR только переносит маршруты, next-hop он не меняет — трафик через сам RR не потечёт (если это не он же и есть P-роутер).

next-hop-self Классика: внешний префикс пришёл по eBGP с next-hop 203.0.113.1 (адрес чужого роутера). По iBGP он разлетается внутри AS с тем же next-hop, но внутренние роутеры не знают, как до него дойти → маршрут не ставится. Лечится командой neighbor X next-hop-self на пограничном роутере — он подменяет next-hop на себя.

Правило анонсирования: что BGP передаёт дальше

Главное правило распространения, которое объясняет половину «почему маршрут не дошёл»: в таблицу BGP-соседям анонсируется только лучший путь (best-path), и только если он установлен в RIB. Плюс два правила против петель:

Маршрут, полученный от eBGP-соседа, передаётся и eBGP-, и iBGP-соседям.
Маршрут, полученный от iBGP-соседа, передаётся только eBGP-соседям (НЕ другому iBGP) — это и есть split-horizon, ради которого нужен Route Reflector.

eBGP multihop: по умолчанию eBGP ждёт соседа в одном хопе (TTL=1). Если пиринг идёт по loopback или через промежуточное устройство — включай neighbor X ebgp-multihop 2, иначе сессия не поднимется.

9. Таймеры, BFD и сходимость — почему «висело три минуты»

Вернёмся к заявке из начала урока: сессия упала в 09:31, а мониторинг заметил падение линка в 09:28. Три минуты трафик улетал в никуда. Это не баг — это таймеры по умолчанию:

Таймер	Default (Cisco)	Что делает
Keepalive	60 с	как часто шлём «я жив»
Hold-time	180 с	не слышали соседа столько — считаем мёртвым, рвём сессию (в OPEN побеждает меньший из двух предложенных)
ConnectRetry	~30–120 с	как часто пытаемся открыть TCP заново
Advertisement-interval	30 с (eBGP) / 0–5 с (iBGP)	минимальная пауза между UPDATE-ами одному соседу

Как ускорить обнаружение падения — три уровня, от простого к правильному:

Fast external fallover (включён по умолчанию для eBGP): физически упал интерфейс, на котором живёт сосед, — сессия рвётся мгновенно, не дожидаясь hold-time. Но не поможет, если между вами свитч или медиаконвертер: твой порт остался up, а сосед уже мёртв. Именно поэтому «висело три минуты» — линк умер где-то посередине.

Агрессивные таймеры: neighbor X timers 10 30 (keepalive 10, hold 30). Просто, работает везде, но 30 секунд — всё ещё вечность, а слишком низкие значения (1/3) на нагруженном CPU дают ложные срабатывания.

BFD (Bidirectional Forwarding Detection) — правильный ответ: отдельный лёгкий протокол-«пульсометр», hello каждые 50–300 мс аппаратно. Умер путь — BFD сообщает BGP за доли секунды, тот рвёт сессию и переключается. Одна сессия BFD обслуживает сразу BGP, OSPF и статику на интерфейсе.

# BFD: интервал 300 мс, множитель 3 (≈0.9 с на обнаружение) R1(config-if)# bfd interval 300 min_rx 300 multiplier 3 R1(config-router)# neighbor 203.0.113.1 fall-over bfd R1# show bfd neighbors NeighAddr LD/RD RH/RS State Int 203.0.113.1 1/1 Up Up Gi0/0

Сходимость ≠ обнаружение. После разрыва сессии роутер ещё должен «прожевать» отзыв сотен тысяч префиксов и пересчитать best-path — на полной таблице интернета (~1 млн префиксов IPv4 в 2026) это секунды–десятки секунд. Поэтому серьёзные сети держат заранее просчитанный запасной путь (BGP PIC, additional-paths) — переключение становится почти мгновенным.

10. Реальный сценарий: multihoming через двух провайдеров

Цель: подключиться к двум ISP для отказоустойчивости. Хотим выходить в приоритете через ISP-A, а ISP-B держать резервом. Управляем исходящим трафиком через LOCAL_PREF, входящим — через prepend.

R1(config)# router bgp 65010 R1(config-router)# bgp router-id 1.1.1.1 # два eBGP-соседа: ISP-A и ISP-B R1(config-router)# neighbor 203.0.113.1 remote-as 64500 # ISP-A R1(config-router)# neighbor 198.51.100.1 remote-as 64501 # ISP-B R1(config-router)# network 192.0.2.0 mask 255.255.255.0 # свой блок R1(config-router)# neighbor 203.0.113.1 maximum-prefix 1000000 # исходящий: маршруты от ISP-A получают LOCAL_PREF 200 (предпочесть) R1(config-router)# neighbor 203.0.113.1 route-map PREFER-A in R1(config)# route-map PREFER-A permit 10 R1(config-route-map)# set local-preference 200 # входящий: к ISP-B анонсируем с prepend (путь длиннее → реже выбирают) R1(config-router)# neighbor 198.51.100.1 route-map PREPEND-B out R1(config)# route-map PREPEND-B permit 10 R1(config-route-map)# set as-path prepend 65010 65010

Агрегация и multipath

# анонсировать один суммарный префикс вместо кучи мелких (чище таблица интернета) R1(config-router)# aggregate-address 192.0.2.0 255.255.254.0 summary-only # BGP multipath — использовать несколько равноценных eBGP-путей (ECMP) R1(config-router)# maximum-paths 2

Тот же сценарий на Juniper и Huawei

Идеи BGP одинаковы у всех вендоров, различается только «грамматика». Умение узнавать конструкции в чужом синтаксисе — обязательный навык: в операторских сетях всегда зоопарк железа.

## Juniper (Junos): всё — иерархия, политика отдельно от соседа [edit] set routing-options autonomous-system 65010 set protocols bgp group ISP-A type external set protocols bgp group ISP-A peer-as 64500 set protocols bgp group ISP-A neighbor 203.0.113.1 import PREFER-A # route-map in ≈ import policy set protocols bgp group ISP-B neighbor 198.51.100.1 export PREPEND-B # route-map out ≈ export policy set policy-options policy-statement PREFER-A term 1 then local-preference 200 set policy-options policy-statement PREPEND-B term 1 then as-path-prepend "65010 65010" commit check && commit # сначала проверка, потом применение user@R1> show bgp summary # аналог show ip bgp summary user@R1> show route receive-protocol bgp 203.0.113.1 # что прислал сосед user@R1> show route advertising-protocol bgp 203.0.113.1 # что отдаём соседу

## Huawei (VRP): синтаксис близок к Cisco, но свои глаголы [R1] bgp 65010 [R1-bgp] router-id 1.1.1.1 [R1-bgp] peer 203.0.113.1 as-number 64500 [R1-bgp] peer 198.51.100.1 as-number 64501 [R1-bgp] network 192.0.2.0 255.255.255.0 [R1-bgp] peer 203.0.113.1 route-policy PREFER-A import [R1-bgp] peer 198.51.100.1 route-policy PREPEND-B export [R1] route-policy PREFER-A permit node 10 [R1-route-policy] apply local-preference 200 [R1] route-policy PREPEND-B permit node 10 [R1-route-policy] apply as-path 65010 65010 additive <R1> display bgp peer # ≈ show ip bgp summary <R1> display bgp routing-table 203.0.113.0 # ≈ show ip bgp <prefix>

Действие	Cisco IOS	Juniper Junos	Huawei VRP
соседи и состояние	`show ip bgp summary`	`show bgp summary`	`display bgp peer`
таблица BGP	`show ip bgp`	`show route protocol bgp`	`display bgp routing-table`
что прислал сосед	`show ip bgp neighbors X received-routes`	`show route receive-protocol bgp X`	`display bgp routing-table peer X received-routes`
что отдаём соседу	`… advertised-routes`	`show route advertising-protocol bgp X`	`… advertised-routes`
мягкий сброс политики	`clear ip bgp X soft`	`—` (политика применяется на commit)	`refresh bgp X import/export`

Чек-лист сдачи multihoming в работу

Обе сессии Established

show ip bgp summary — в колонке State/PfxRcd у обоих соседей числа, не слова.

Свой префикс анонсируется обоим

show ip bgp neighbors X advertised-routes — наш 192.0.2.0/24 в списке у обоих ISP. Пусто у одного — смотри route-map out.

Исходящий уходит через ISP-A

show ip bgp 8.8.8.0 — best-путь (>) с localpref 200 через 203.0.113.1; traceroute 8.8.8.8 первым хопом показывает ISP-A.

Входящий приходит через ISP-A

Проверка снаружи: looking glass (lg.he.net) → путь к нашему 192.0.2.0/24 не должен заканчиваться на 64501. Помни: prepend — намёк, кто-то всё равно может прийти через B.

Failover-тест до сдачи, а не после аварии

Гасим сессию с ISP-A (neighbor X shutdown) в согласованное окно — трафик должен уехать на B за секунды (с BFD) и вернуться после no shutdown.

11. Безопасность BGP

BGP исторически построен на доверии — и это его слабое место. Ключевые угрозы и защиты:

BGP hijacking — чужая AS анонсирует не свой префикс (по ошибке или злонамеренно), и трафик утекает к ней. Так перехватывали трафик целых стран и крали криптовалюту.
RPKI + ROV — криптографическая привязка «какая AS вправе анонсировать какой префикс» (ROA). Роутер с Route Origin Validation отбрасывает невалидные анонсы. Сегодня это базовая гигиена.
Префикс-фильтры и max-prefix — на сессии с соседом принимай только ожидаемые префиксы и ограничь их число (maximum-prefix), чтобы «утечка полного стола» не положила роутер.
BGP TTL Security (GTSM) и MD5/TCP-AO — защита самой сессии от подделки.

# включить проверку RPKI (валидатор по RPKI-RTR) R1(config-router)# bgp rpki server tcp 192.0.2.50 port 3323 refresh 600 # аутентификация TCP-сессии R1(config-router)# neighbor 203.0.113.1 password StrongSecret # GTSM: принимать только пакеты с TTL не ниже 254 (сосед — реально в 1 хопе) R1(config-router)# neighbor 203.0.113.1 ttl-security hops 1

12. show-команды и чтение вывода

R1# show ip bgp summary # соседи, состояние (ждём Established), число префиксов R1# show ip bgp # таблица BGP, лучший путь помечен > R1# show ip bgp 192.0.2.0/24 # все пути до префикса + почему выбран этот R1# show ip bgp neighbors 203.0.113.1 advertised-routes # что я анонсирую R1# show ip bgp neighbors 203.0.113.1 received-routes # что мне прислали

R1# show ip bgp summary Neighbor V AS MsgRcvd MsgSent Up/Down State/PfxRcd 203.0.113.1 4 64500 120451 980 02:14:09 912340 # Established + кол-во префиксов 198.51.100.1 4 64501 98213 975 02:14:01 912340

Учись читать summary как кардиограмму — здесь всё, что нужно для первого диагноза:

State/PfxRcd — число = Established, и это количество принятых префиксов. Слово (Idle, Active…) = сессия лежит, и слово говорит, на чём именно.
Число подозрительно маленькое? Ждал полную таблицу (~1M), а пришло 12? Сосед сменил политику или у тебя фильтр на in. Ровно 0 при Established — сессия есть, маршруты все отфильтрованы.
Up/Down маленький (минуты) при большом аптайме роутера — сессия недавно флапнула. Смотри show logging | i BGP — там будет и причина (hold expired / peer closed / interface flap).
MsgRcvd/MsgSent растут? Если счётчики стоят — сессия «зомби»: числится, но трафика управления нет.
(Idle) с пометкой PfxCt / «Admin» — сработал maximum-prefix или сосед administratively shutdown.

Второй эшелон — «всё про соседа» (сокращено до строк, на которые смотрят):

R1# show ip bgp neighbors 203.0.113.1 BGP neighbor is 203.0.113.1, remote AS 64500, external link BGP state = Established, up for 02:14:09 Last read 00:00:12, hold time is 180, keepalive interval is 60 # согласованные таймеры Neighbor capabilities: Route refresh, 4-byte ASN, IPv4-Unicast Last reset 02:14:31, due to Interface flap # ← причина прошлого падения! Prefix activity: Prefixes Current: 912340 (accepted) Connections established 3; dropped 2 # сколько раз сессия умирала

Золотая строка — «Last reset, due to …». Роутер сам говорит, почему сессия падала в прошлый раз: hold expired (потеря связности), interface flap (физика), peer closed session (сосед сам разорвал — смотри с его стороны), too many prefixes (max-prefix). Половина расследований начинается и заканчивается этой строкой.

13. Плейбуки диагностики — алгоритмы на смену

Три сценария покрывают ~90% BGP-заявок. Прогони каждый мысленно несколько раз — на смене будешь идти по ним на автомате.

Плейбук №1: сессия не поднимается (не Established)

Смотрим состояние

show ip bgp summary. Idle → шаг 2. Active/Connect → шаг 3. OpenSent/OpenConfirm → шаг 5.

Idle: сессию кто-то выключил или добил max-prefix

show run | s router bgp — нет ли neighbor X shutdown; show log | i BGP — нет ли «too many prefixes». После max-prefix сессию часто надо поднимать руками: clear ip bgp X.

Active: проверяем IP-связность

ping <peer> (для iBGP по loopback — ping <peer> source lo0). Не пингуется → это не BGP-проблема, а маршрутизация/линк: решай её. Пингуется → шаг 4.

Пинг есть, TCP нет: ищем, кто режет 179

telnet <peer> 179. Отказ/тишина → ACL на интерфейсе, firewall по пути, или ошибка в update-source/ebgp-multihop (сосед ждёт сессию с другого адреса/TTL). Сравни настройки с двух сторон: peer-IP ↔ source-IP должны зеркалиться.

OpenSent/OpenConfirm: читаем NOTIFICATION

show log | i BGP: «bad remote-as» — несовпадение ASN в конфигах сторон (самая частая опечатка); «connection collision» — обе стороны одновременно открывают TCP, пройдёт само; несовпадение пароля MD5 — «MD5 authentication failed».

Плейбук №2: сессия есть, а маршрута нет

Определи направление

Нам не приходит чужой префикс — или наш не доходит до них? От этого зависит, на чьей стороне копать. Дальше — про «не приходит» (для «не уходит» те же шаги в зеркале: advertised-routes и их политика in).

Сосед вообще присылает?

show ip bgp neighbors X received-routes (нужен soft-reconfiguration inbound, иначе смотри с его стороны advertised). Нет префикса → проблема у соседа: его политика out, отсутствие best-path, префикс не в его RIB. Есть → шаг 3.

Присылает, но мы отбрасываем?

Сравни received-routes (до фильтра) и show ip bgp neighbors X routes (после). Разница → твой фильтр in: prefix-list, route-map, as-path list. Не забудь clear ip bgp X soft in после правки.

Маршрут в BGP, но нет ⭐ или >?

show ip bgp <prefix>. «inaccessible» → next-hop недостижим (next-hop-self!). Best есть, но в RIB маршрут другой → его перебил протокол с меньшим AD (static 1, OSPF 110 против iBGP 200) — смотри show ip route <prefix>.

Best есть, но дальше не анонсируется?

Помни правила: только best уходит соседям; iBGP-маршрут не уйдёт другому iBGP-соседу (нужен RR); в сторону eBGP проверь политику out и агрегацию (suppressed?).

Плейбук №3: маршрут есть, но трафик идёт «криво»

Подтверди факт

traceroute с source-адресом клиента. Помни про асимметрию: туда через A, обратно через B — это нормально для интернета, если не рвёт stateful-файрвол.

Исходящее направление — смотри свой best

show ip bgp <dst-prefix>: почему выбран этот путь? Идёшь по лесенке: weight → localpref → as-path… Чаще всего виноват LOCAL_PREF, который кто-то когда-то поставил и забыл.

Входящее — смотри глазами интернета

Looking glass / bgp.tools на свой префикс: какие AS-PATH видят снаружи, работает ли твой prepend, не анонсировал ли ты более специфичный префикс не туда (longest match бьёт любую политику!).

Проверь «утечку» специфика

Классика кривых путей: где-то анонсируется /25–/32 из твоего блока (RTBH-остаток, тестовый анонс) — и весь мир идёт по нему. show ip bgp | i <твой блок> у себя и в looking glass.

14. Мини-лабы: потрогать BGP руками

Лаба 1 (5 минут, браузер): интернет как на ладони

Попробуй прямо сейчас

Открой stat.ripe.net, вбей свой домашний IP (узнай на 2ip.ru). Виджет Routing — каким префиксом и из какой AS ты анонсирован в мировой BGP прямо сейчас.
На bgp.tools найди эту AS → вкладка Prefixes: сколько всего префиксов анонсирует твой провайдер. Вкладка Connectivity — его аплинки (транзит) и пиры.
Открой bgpstream.crosswork.cisco.com — живая лента BGP-аварий мира: hijack-и и утечки маршрутов в реальном времени. То, от чего защищает RPKI из раздела 11.

Лаба 2 (15 минут, Docker): свой eBGP-стык на FRR

FRR (Free Range Routing) — открытый маршрутизатор, который живёт внутри Calico, Cumulus и половины SDN-решений. CLI почти неотличим от Cisco. Поднимем два «роутера» в двух AS и посмотрим на настоящую сессию:

# 1. Сеть и два контейнера-роутера $ docker network create --subnet 10.10.10.0/24 bgplab $ docker run -d --name r1 --net bgplab --ip 10.10.10.1 --privileged quay.io/frrouting/frr:10.1.0 $ docker run -d --name r2 --net bgplab --ip 10.10.10.2 --privileged quay.io/frrouting/frr:10.1.0 # 2. Включаем демон bgpd и заходим в vtysh (CLI как у Cisco) $ for r in r1 r2; do docker exec $r sed -i 's/bgpd=no/bgpd=yes/' /etc/frr/daemons; docker restart $r; done $ docker exec -it r1 vtysh # 3. R1 = AS 65001, анонсирует «свою сеть» 192.168.100.0/24 r1# configure terminal r1(config)# router bgp 65001 r1(config-router)# neighbor 10.10.10.2 remote-as 65002 r1(config-router)# address-family ipv4 unicast r1(config-router-af)# network 192.168.100.0/24 r1(config-router-af)# end # 4. R2 — зеркально (AS 65002, сеть 192.168.200.0/24), затем проверяем: r2# show ip bgp summary Neighbor V AS MsgRcvd MsgSent Up/Down State/PfxRcd 10.10.10.1 4 65001 8 7 00:02:11 1 ← Established, 1 префикс! r2# show ip bgp *> 192.168.100.0/24 10.10.10.1 0 0 65001 i ← вот он, твой первый выученный маршрут

Что поломать, чтобы понять глубже (каждый пункт — сценарий из плейбуков!):

Поменяй на R2 remote-as на 65099 — увидишь «bad remote-as» и сессию в Active/Idle.
Сделай neighbor 10.10.10.1 shutdown — состояние Idle (Admin).
Повесь prepend: route-map PP permit 10 + set as-path prepend 65001 65001, привяжи out — на R2 путь станет 65001 65001 65001.
Добавь третий контейнер-AS и собери «мини-интернет» с транзитом.

Хочешь стенд посерьёзнее — посмотри containerlab: описываешь топологию YAML-файлом, он поднимает десяток FRR/vEOS-узлов одной командой. Это уже уровень домашней лаборатории CCNP — и одновременно первый шаг в NetDevOps.

15. Мост в DevOps — здесь BGP внезапно рядом

BGP — один из немногих «операторских» протоколов, который ты реально встретишь в DevOps:

Calico (Kubernetes CNI) анонсирует маршруты до подов по BGP — буквально настраиваешь ASN и peer'ов.
MetalLB в bare-metal-кластерах раздаёт LoadBalancer-IP через BGP к роутерам сети.
Облака: VPN/Direct Connect/Cloud Router между твоей сетью и AWS/GCP поднимаются именно по BGP.
Anycast сервисов (DNS, CDN) строится на BGP — один IP анонсируется из многих точек.

# Calico: BGP-конфиг кластера (тот же ASN, тот же best-path — знакомо?) $ cat bgpconfig.yaml apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: { name: default } spec: asNumber: 64512 serviceClusterIPs: [ { cidr: 10.96.0.0/12 } ] # MetalLB: peer к роутеру сети $ cat metallb-peer.yaml apiVersion: metallb.io/v1beta2 kind: BGPPeer metadata: { name: top-of-rack } spec: myASN: 64512 peerASN: 64500 peerAddress: 203.0.113.1

🌉 Это твоё преимущество

Когда DevOps-команда упрётся в «почему Calico не анонсирует маршрут» или «MetalLB не поднял BGP-сессию», ты — человек, который читает show ip bgp summary и видит «застряло в Active → файрвол режет TCP 179». Редкий и дорогой навык.

16. Вопросы с собеседования

❓ Назови порядок best-path в BGP (первые атрибуты).

Weight (Cisco) → LOCAL_PREF → locally originated → AS-PATH (короче) → ORIGIN → MED → eBGP>iBGP → IGP-метрика до next-hop → Router-ID.

❓ Чем eBGP отличается от iBGP?

eBGP — между разными AS (AD 20, добавляет свой ASN в AS-PATH, меняет next-hop, TTL 1). iBGP — внутри одной AS (AD 200, не меняет AS-PATH; split-horizon → нужен full-mesh или route reflector).

❓ Как управлять исходящим и входящим трафиком при multihoming?

Исходящим — LOCAL_PREF (выше = предпочесть этого провайдера). Входящим — AS-PATH prepend (удлиняем путь к нелюбимому провайдеру) и/или MED/communities.

❓ Что такое BGP hijacking и как защищаются?

Анонс чужого префикса для перехвата трафика. Защита: RPKI/ROV (валидация origin), строгие префикс-фильтры, max-prefix, мониторинг (BGPmon-подобные сервисы).

❓ Сессия застряла в Active. Твои действия?

Active = не открывается TCP 179. Проверяю по порядку: ping до peer-IP (есть ли связность вообще; для loopback-пиринга — с правильным source), telnet peer 179 (не режет ли ACL/firewall), совпадение адресов в конфигах двух сторон (peer у него = мой update-source), для eBGP через несколько хопов — ebgp-multihop.

❓ Почему iBGP требует full-mesh и как это обходят?

Внутри AS AS-PATH не меняется, поэтому от петель защищаются правилом split-horizon: iBGP-маршрут не передаётся другому iBGP-соседу. Отсюда full-mesh N(N−1)/2. Обход — Route Reflector (петли контролируют ORIGINATOR_ID и CLUSTER_LIST) или конфедерации.

❓ Чем MED отличается от LOCAL_PREF?

Оба влияют на выбор пути, но LOCAL_PREF — мой выбор исходящего направления, живёт только внутри моей AS, больше — лучше. MED — моя просьба соседней AS о входящем направлении, передаётся только ей, меньше — лучше, и сосед вправе игнорировать.

❓ Маршрут виден в show ip bgp с пометкой best, но в таблице маршрутизации его нет. Как так?

Его вытеснил маршрут с меньшим administrative distance: static (1), OSPF (110) — все «сильнее» iBGP (200). Смотрю show ip route <prefix>, кто реально стоит в RIB. Вторая причина — next-hop стал недостижим между пересчётами.

❓ Зачем BGP работает поверх TCP, а OSPF — нет?

BGP передаёт огромные объёмы (весь интернет ~1M префиксов) между парой вручную заданных соседей — ему нужны надёжность, дозирование и порядок, это готовым даёт TCP. OSPF же должен сам находить соседей мультикастом на линке и быстро флудить мелкие LSA — TCP тут только мешал бы.

❓ Что произойдёт, если на анонсе с community 64500:666 сработает политика провайдера?

Это blackhole-community (RTBH, RFC 7999): провайдер отбросит весь трафик к префиксу на своей стороне. Используется при DDoS: жертвуем атакованным /32, спасаем канал. Главное — не забыть снять анонс после атаки.

17. Частые ошибки джунов

ошибка 1 Сессия в Active/Idle. TCP 179 не устанавливается: ACL/файрвол, неверный peer-IP, нет IGP-маршрута до адреса соседа (особенно для iBGP по loopback).

ошибка 2 iBGP next-hop недостижим. Маршрут пришёл, но не ставится: next-hop из eBGP не известен внутри AS. Лечится next-hop-self на пограничном роутере.

ошибка 3 Ждёт, что iBGP-маршруты «разойдутся» сами. Без full-mesh или RR iBGP не передаёт их дальше — часть AS маршрута не видит.

ошибка 4 Нет фильтров и max-prefix. Сосед «протёк» полным столом интернета (~950k+ префиксов) — память и CPU роутера в потолок. Всегда ограничивай приём.

ошибка 5 Анонсирует то, что не должен. Без исходящих фильтров можно случайно стать транзитом или «угнать» чужой префикс. Анонсируй только свои блоки, фильтруй на out.

18. Задачи — сначала реши, потом раскрывай

1. В show ip bgp summary у соседа в колонке State/PfxRcd стоит «Active». Хорошо это или плохо, и что проверишь первым?

Плохо: Active значит «не могу открыть TCP до соседа». Первым делом — ping <peer-ip>: есть ли связность вообще. Дальше telnet <peer-ip> 179 и сверка peer-IP/source в конфигах сторон.

2. Префикс приходит двумя путями: LOCAL_PREF 100 / AS-PATH из 2 хопов и LOCAL_PREF 150 / AS-PATH из 5 хопов. Какой победит?

Второй. LOCAL_PREF сравнивается раньше AS-PATH, 150 > 100 — длина пути уже не рассматривается. Порядок лесенки строгий: проигравший на верхней ступеньке не реабилитируется на нижней.

3. Ты хочешь, чтобы входящий трафик шёл через ISP-A, а не ISP-B. Поможет ли повысить LOCAL_PREF для маршрутов от ISP-A?

Нет! LOCAL_PREF управляет исходящим трафиком и не покидает твою AS — чужие решения он не меняет. Для входящего: AS-PATH prepend в сторону ISP-B, MED, communities из «меню» провайдера или (жёстко) более специфичные анонсы через ISP-A.

4. Пограничник R1 получил префикс по eBGP. R5 в глубине AS видит его в show ip bgp с пометкой «inaccessible». Что случилось и как чинить?

Next-hop остался адресом внешнего соседа (eBGP-стык), до которого внутри AS нет маршрута. Лечение: neighbor R5 next-hop-self на R1 (или отдать стык-сеть в IGP).

5. В AS восемь iBGP-роутеров без RR. Сколько нужно сессий? А с парой RR?

Full-mesh: 8×7/2 = 28 сессий. С двумя RR: каждый из 6 клиентов держит 2 сессии (к RR1 и RR2) плюс сессия между RR — 13. И главное — новые роутеры добавляются двумя сессиями, а не восемью.

6. После правки route-map соседу «ничего не изменилось». Назови две самые вероятные причины.

(1) Не сделан clear ip bgp X soft — политика применяется только к новым UPDATE-ам. (2) Правило не совпало и сработал неявный deny в конце route-map — или наоборот, всё ушло в финальный permit без set. Проверка: show route-map — счётчики совпадений по секциям.

7. Провайдер жалуется: «вы анонсируете нам 950k префиксов». Что произошло и какой командой ты бы это предотвратил у себя?

Ты стал «случайным транзитом» — переанонсировал полную таблицу от одного аплинка другому (нет фильтра out). Предотвращение: исходящий prefix-list/route-map «только мои сети» на всех eBGP-сессиях (а у провайдера сработал бы maximum-prefix).

8. BFD с параметрами interval 300 multiplier 3 — за какое время BGP узнает о смерти линка? А без BFD с таймерами по умолчанию?

BFD: 300 мс × 3 = ~0.9 секунды. Без BFD — до hold-time, то есть до 180 секунд (если интерфейс физически не упал и fast-fallover не сработал). Разница в 200 раз — вот зачем BFD.

19. Словарик урока

AS / ASNавтономная система — сеть под единым управлением; ASN — её номер (приватные: 64512–65534)

eBGP / iBGPсессия между разными AS (AD 20) / внутри одной AS (AD 200, split-horizon)

peer, соседвручную заданный собеседник BGP-сессии (TCP 179)

NLRI, префиксанонсируемая сеть с маской — «товар», которым торгует BGP

AS-PATHсписок AS, через которые прошёл маршрут: защита от петель + критерий выбора + материал для фильтров

LOCAL_PREFприоритет пути для исходящего трафика; живёт внутри AS; больше — лучше

MEDпросьба соседней AS предпочесть один из твоих входов; меньше — лучше; можно игнорировать

communityчисловой «стикер» ASN:значение на маршруте; основа массовой политики (напр. 666 = blackhole)

best-pathединственный победитель среди путей к префиксу: только он идёт в RIB и анонсируется дальше

RR, route reflectorроутер, которому разрешено пересказывать iBGP-маршруты клиентам — замена full-mesh

next-hop-selfкоманда «подменяй next-hop на себя» на пограничнике — лечит недостижимые внешние next-hop внутри AS

prependискусственное удлинение AS-PATH своими ASN — мягкое управление входящим трафиком

RPKI / ROVкриптографическая проверка «эта AS вправе анонсировать этот префикс» — защита от hijack

BFDсубсекундный «пульсометр» линка, дёргающий BGP/OSPF при падении пути

transit / peeringплатный доступ «во весь интернет» / бесплатный обмен своими сетями между равными

IXточка обмена трафиком (MSK-IX, DE-CIX): одна площадка — сотни пиров

looking glassпубличное окно в BGP-таблицу чужого оператора — смотреть, как мир видит твои анонсы

hot-potatoстратегия «выкинь чужой трафик из своей сети как можно раньше» — отсюда шаг eBGP>iBGP в best-path

Ключевое за этот урок

BGP связывает автономные системы (AS), path-vector, несёт AS-PATH (защита от петель + выбор пути).
eBGP — между AS (AD 20, меняет AS-PATH/next-hop); iBGP — внутри AS (AD 200, split-horizon → нужен RR/full-mesh).
Сессия по TCP 179, соседи задаются вручную; здоровое состояние — Established. 4 сообщения: OPEN/UPDATE/KEEPALIVE/NOTIFICATION.
Best-path: Weight → LOCAL_PREF → AS-PATH → ORIGIN → MED → eBGP>iBGP → IGP metric → Router-ID.
Политика: LOCAL_PREF (исходящий), AS-PATH prepend (входящий), MED, communities.
next-hop-self спасает iBGP; Route Reflector убирает full-mesh.
Безопасность: RPKI/ROV против hijacking, префикс-фильтры, maximum-prefix, GTSM, пароль сессии.
Экономика: транзит платный, пиринг бесплатный; политика оператора = LOCAL_PREF клиент > пир > аплинк.
Скорость обнаружения аварии: hold-time 180 c по умолчанию → таймеры или (правильно) BFD < 1 c.
Диагноз по состоянию: Active — нет TCP; Established + 0 префиксов — фильтры; «Last reset, due to…» — причина прошлого падения.
В DevOps BGP встречается в Calico, MetalLB, облачных VPN/Direct Connect и anycast.

→ Мост к модулю 8

Ты уже знаешь, как оператор изолирует клиентов (VRF, ступень 1) и как AS обмениваются маршрутами (BGP). Следующий модуль соединяет это в главную технологию операторских услуг: MPLS и L3VPN — как по одной магистрали ездят тысячи изолированных клиентских сетей, и почему без BGP (точнее, MP-BGP с его route-target) это не работало бы вовсе. Всё, что ты выучил про атрибуты и RR, там выстрелит.