← Back to notes

BGP: best path, eBGP
policy и route leak

2026-02-21

#bgp#routing

Теория

BGP

BGP-4 (RFC 4271) — междоменный протокол маршрутизации между автономными системами (AS), path-vector: вместе с префиксом передаются атрибуты и AS_PATH. Работает поверх TCP/179. В отличие от IGP, BGP не выбирает "кратчайший путь", а применяет policy.

Decision Process (RFC 4271 §9.1)

Три фазы:

  1. Phase 1 — вычисление LOCAL_PREF (degree of preference) для полученных маршрутов на основе import-policy.
  2. Phase 2 — выбор best path для каждого destination, установка в Loc-RIB.
  3. Phase 3 — распространение маршрутов соседям через export-policy в Adj-RIBs-Out.

Best-path в реальных реализациях включает RFC decision process и vendor-specific tie-breakers. Упрощённая практическая цепочка: highest LOCAL_PREF → shortest AS_PATH → lowest ORIGIN → MED по правилам вендора/policy → eBGP > iBGP → lowest IGP cost → tie-break.

RFC 8212: безопасные дефолты для eBGP

RFC 8212 (2017) обновляет RFC 4271: на eBGP без явной import/export policy маршруты не должны импортироваться или экспортироваться. Защита от случайных route leak из-за permissive defaults вендоров.

Route leak (RFC 9234)

Route leak — распространение маршрутов с нарушением business relationships (provider/customer/peer). Типичные причины:

  • отсутствие prefix-filter / AS-path filter;
  • неконсистентная export-policy;
  • ошибочная роль на eBGP-сессии.

RFC 9234 вводит BGP Roles (Provider / Customer / RS / RS-Client / Peer) и Only to Customer (OTC) атрибут. При поддержке на обеих сторонах соседи согласуют роль в OPEN, а OTC помогает предотвращать/детектировать часть route leak-сценариев.

RPKI Origin Validation (RFC 6811)

RPKI присваивает маршруту состояние Valid / Invalid / NotFound на основе ROA (Route Origin Authorization). Что делает:

  • проверяет, что origin AS уполномочен анонсировать данный префикс;
  • не валидирует корректность AS_PATH (для этого — BGPsec, RFC 8205, почти не deployed);
  • не заменяет prefix-filtering и роли.

Связанные RFC: RFC 8481 (clarifications), RFC 8893 (export). Типичная политика: Invalid → reject, Valid/NotFound — дальше по local policy и бизнес-риску.

Практика

1. Явно задайте import/export policy на каждом eBGP-соседе

Минимальный шаблон (vendor-agnostic идея):

neighbor <peer>:
  import-policy: ONLY_EXPECTED_PREFIXES + RPKI_POLICY
  export-policy: ONLY_OWN_AND_ALLOWED_CUSTOMER_PREFIXES

Если policy не задана, сессия не должна обмениваться маршрутами (модель RFC 8212).

2. Добавьте защитные лимиты на прием префиксов

Из практик BGP OPSEC (RFC 7454):

  • ограничить max-prefix на сессию;
  • фильтровать по префиксам/AS-path там, где это применимо;
  • использовать community-политику осознанно, без "прозрачного транзита всего подряд".

3. Включите RPKI origin validation в policy

Базовый подход:

  • Invalid: reject;
  • Valid: prefer (или пропускать с приоритетом policy);
  • NotFound: обрабатывать отдельно по рисковой модели.

4. Настройте мониторинг route leak-индикаторов

Контрольные сигналы:

  • внезапный рост количества принятых маршрутов от соседа;
  • неожиданная смена origin AS для критичных префиксов;
  • резкое изменение AS_PATH и транзитных направлений.

Вывод

Надежный BGP строится не на "дефолтах", а на явной политике.
База для production:

  • explicit import/export policy (RFC 8212),
  • фильтры и лимиты (RFC 7454),
  • route leak prevention/detection через роли (RFC 9234),
  • RPKI как слой валидации origin там, где операционная модель это поддерживает.

Ссылки

Проверка источников

BGP: best path, eBGP policy и route leak | Aleksandr Suprun