HardТеория4 min

BGP и Anycast routing

Border Gateway Protocol, autonomous systems, Anycast для DNS/CDN, BGP hijack, GeoDNS vs Anycast

NetworkingSysdesign

Интернет как сеть сетей

"Интернет" -- это не одна сеть, а 100 000+ автономных систем (AS), соединённых друг с другом. Каждая AS -- это независимо управляемая сеть (провайдер, корпорация, облако), имеющая уникальный номер (ASN).

Примеры ASN:

  • AS15169 -- Google
  • AS16509 -- Amazon (AWS)
  • AS13335 -- Cloudflare
  • AS8075 -- Microsoft
  • AS32934 -- Facebook/Meta

BGP (Border Gateway Protocol, RFC 4271) -- единственный протокол, который маршрутизирует между AS. Когда вы обращаетесь к 8.8.8.8, BGP решил, через какие AS ваш пакет дойдёт.

Как работает BGP

Базовая идея

Каждая AS анонсирует соседям, какие префиксы она может доставить. Соседи распространяют это дальше. В результате у каждого роутера есть полная таблица -- 900К+ префиксов IPv4 и 170К+ IPv6 (на 2026).

AS A (10.1.0.0/16) ─── peering ─── AS B
  │                                   │
  │                                   │
  ↓ anonserving 10.1.0.0/16 to        ↓ anonserving 10.1.0.0/16 via AS B to
  AS C                                AS D

AS D получает два пути до 10.1.0.0/16:
  1. AS D → AS C → AS A       (AS path length = 2)
  2. AS D → AS B → AS A       (AS path length = 2)

Выбирает по tie-breaker (local pref, AS path, MED, origin, ...)

BGP update message

Сообщение содержит path attributes:

NLRI (Network Layer Reachability Info): 203.0.113.0/24

Attributes:
  AS_PATH:      [AS13335, AS174]          ← откуда пришло
  NEXT_HOP:     192.0.2.1                  ← куда слать пакет
  LOCAL_PREF:   100                        ← приоритет внутри AS
  MED:          50                         ← подсказка снаружи
  ORIGIN:       IGP | EGP | Incomplete
  COMMUNITIES:  [13335:666]                ← теги (blackhole, no-export)

Выбор пути

При нескольких путях до префикса BGP использует decision process:

  1. Наибольший LOCAL_PREF (внутренняя политика).
  2. Кратчайший AS_PATH.
  3. Тип origin (IGP > EGP > Incomplete).
  4. Наименьший MED (только от того же соседа).
  5. eBGP > iBGP (внешний путь предпочтительнее внутреннего).
  6. Наименьший IGP cost до next-hop.
  7. Router ID tiebreaker.

eBGP vs iBGP

  • eBGP (external) -- BGP между разными AS. TTL=1, обычно напрямую linked.
  • iBGP (internal) -- BGP внутри одной AS для распространения внешних маршрутов между своими роутерами. Full-mesh или route reflectors.

Propagation time: не мгновенно

BGP -- policy-based протокол, конвергенция занимает минуты:

Change event: AS A anonser перестаёт рекламировать 10.1.0.0/16 (outage)

t=0s     AS A shuts down the announce
t=5s     Direct peers (AS B, AS C) remove route
t=20s    Tier-2 peers update via their BGP sessions
t=60s    Tier-1 transit providers converge
t=180s   Remote AS (on other side of world) may still try old path
t=300s+  Full convergence

Поэтому DNS с коротким TTL может реагировать быстрее, чем BGP withdrawal. На практике BGP convergence 3-5 минут -- норма.

BGP hijack: безопасность дырявая

BGP не имеет аутентификации маршрутов. Любая AS может анонсировать чужой префикс, и соседи поверят, пока не отфильтруют.

Исторические случаи

  • 2008, Pakistan Telecom -- в попытке заблокировать YouTube внутри страны анонсировали 208.65.153.0/24 (часть YouTube) как свой. Утекло в upstream, YouTube стал недоступен по всему миру на 2 часа.
  • 2018, BGP hijack Amazon Route 53 -- злоумышленники перехватили DNS Amazon и увели трафик клиентов MyEtherWallet, украли $150K в крипте.
  • 2021, Facebook outage -- Facebook случайно withdrawed все свои BGP routes во время maintenance, выключив себя на 6 часов.
  • Ежедневные -- мелкие route leaks в десятках AS.

Защита

  1. RPKI (Resource Public Key Infrastructure, RFC 6480) -- криптографические сертификаты: "AS X имеет право анонсировать префикс Y". Роутеры с ROV (Route Origin Validation) отбрасывают invalid. Покрытие ~40% префиксов в 2026.
  2. IRR filters -- фильтры на основе Internet Routing Registry. Провайдер должен зарегистрировать свои префиксы.
  3. BGPsec (RFC 8205) -- подписывает каждый AS_PATH hop. Не развёрнут массово.
  4. MANRS (Mutually Agreed Norms for Routing Security) -- набор best practices для операторов.

Anycast: один IP, много локаций

Anycast -- несколько серверов разных геолокаций анонсируют один и тот же IP. BGP сам маршрутизирует клиента в ближайший (по своим метрикам).

                    IP 1.1.1.1 анонсируется из 300+ локаций
                          │
     ┌────────────────────┼────────────────────────┐
     │                    │                        │
Cloudflare LA       Cloudflare Frankfurt     Cloudflare Tokyo
(AS13335)           (AS13335)                (AS13335)
     │                    │                        │
Клиент в США     Клиент в Европе          Клиент в Азии
Маршрутизируется Маршрутизируется         Маршрутизируется
в LA             во Frankfurt             в Tokyo

BGP routing по AS_PATH length и LOCAL_PREF обычно совпадает с географической близостью -- но не всегда. Иногда пакет из Германии уходит в Лондон или США, если так дешевле для провайдера.

Классические use case

DNS (8.8.8.8, 1.1.1.1)

Любой resolver в мире получает ответ от ближайшей реплики -- Google DNS (AS15169) отвечает одним IP из сотен дата-центров.

# Посмотреть, куда реально попадает ваш запрос:
dig TXT +short o-o.myaddr.l.google.com @8.8.8.8
# "2a00:1450:4010:c0b::65"  ← IPv6 of the nearest Google POP

# CloudFlare 1.1.1.1
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep colo
# colo=FRA  ← Frankfurt

CDN (Cloudflare, Fastly)

Весь edge network слушает одни и те же anycast IP (например, 104.16.x.x для Cloudflare). Ближайший POP обрабатывает TLS handshake, отдаёт кеш, проксирует к origin.

Это даёт:

  • Low latency (клиент к edge обычно 5-30 мс).
  • DDoS absorption (атака распределяется по сотням локаций).
  • Failover без DNS change (если POP падает, BGP уводит трафик в соседний за минуту).

Kubernetes on-prem LoadBalancer

Cilium/MetalLB с BGP mode анонсируют Service IP со всех nodes. Внешний роутер балансирует между ними через ECMP (Equal-Cost Multi-Path).

# Cilium BGP Control Plane example
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
  name: bgp-peering
spec:
  nodeSelector:
    matchLabels:
      bgp: "enabled"
  virtualRouters:
    - localASN: 64512
      exportPodCIDR: true
      neighbors:
        - peerAddress: "10.0.0.1/32"
          peerASN: 64513
      serviceSelector:
        matchLabels:
          bgp-advertise: "true"

Anycast vs GeoDNS

Альтернативный подход -- GeoDNS: DNS-сервер отдаёт разный A-record в зависимости от источника запроса.

Свойство Anycast GeoDNS
Механизм Routing (L3) DNS resolution
Точность геолокации Сеть-близость по BGP По IP resolver'а
Failover time ~1 минута (BGP convergence) TTL DNS (30s-5min)
Client pinning Нет, сеть может перебросить TTL
Требования Свой AS, peering agreements DNS с geo-поддержкой
Стоимость Высокая (PoP в каждом регионе) Средняя
DDoS resilience Высокая (distribution) Низкая (одна цель)
Stateful connections Проблема (TCP может перебросить) Стабильнее внутри TTL

В реальности крупные игроки комбинируют оба: GeoDNS выбирает регион, внутри региона -- Anycast на POP.

Проблема Anycast для TCP

Anycast -- это stateless L3 routing. Если в середине TCP-соединения путь BGP изменится (другой POP стал ближе), пакеты пойдут к другой реплике, которая не знает про это TCP state -- RST.

Решения:

  • Session stickiness внутри POP -- консистентный хеш по client IP.
  • QUIC Connection ID -- позволяет relocate connection при смене пути (см. HTTP/3).
  • Короткие соединения -- HTTP request/response проходят до реконфигурации BGP.

Поэтому для коротких запросов (DNS, HTTP) Anycast идеален, а для долгих TCP-сессий нужны workaround.

Traceroute: видим AS path

$ traceroute -A 8.8.8.8
 1  192.168.1.1 [*]                     1.2 ms
 2  10.0.0.1 [*]                        5.8 ms
 3  isp-gw.ru [AS29124]                12.3 ms
 4  m9-core1.isp.ru [AS29124]          15.2 ms
 5  google-peering.ix.ru [AS15169]     18.7 ms
 6  108.170.251.193 [AS15169]          19.5 ms
 7  216.239.56.19 [AS15169]            20.1 ms
 8  8.8.8.8 [AS15169]                  20.8 ms

traceroute -A (Linux) показывает AS для каждого hop. Можно видеть, в какой AS переходит трафик.

ASCII диаграмма: типичный путь

 Home                ISP (Russia)        IX (MSK-IX)      Google Anycast
 │                   AS29124             AS6695           AS15169
 │                   │                   │                │
 [client]──────→[isp-core]──────→[peering-point]──────→[google-edge]──────→[8.8.8.8 POP]
 10ms                +5ms                +3ms              +2ms                +1ms

 BGP increment: 4 AS hops
 Geographical: клиент в Москве → ближайший Google POP в Варшаве или Москве

Практика: look at real BGP

Публичные BGP looking glass

Посмотреть маршрут своего IP

# Через whois
whois -h whois.cymru.com " -v 8.8.8.8"
# AS      | IP        | AS Name
# 15169   | 8.8.8.8   | GOOGLE - Google LLC, US

# Свой public IP + AS
curl ifconfig.co/json
# {"ip": "203.0.113.7", "asn": "AS29124", "asn_org": "..."}

# RPKI validation status
curl https://rpki-validator.ripe.net/api/v1/validity/AS15169/8.8.8.0/24

BGP-инструменты для self-hosting

  • BIRD 2 -- легковесный BGP/OSPF демон. Используется Cloudflare, Vultr.
  • FRR (Free Range Routing) -- форк Quagga, активно развивается.
  • GoBGP -- BGP в Go, RPC API.

Пример BIRD-конфига для anycast:

# /etc/bird/bird.conf
router id 10.0.0.1;

protocol device { }

protocol static {
    # Our anycast service IP
    route 192.0.2.1/32 reject;
}

protocol bgp upstream {
    local as 64512;
    neighbor 10.0.0.254 as 64513;
    export filter {
        # Only anonser anycast prefix
        if net = 192.0.2.1/32 then accept;
        reject;
    };
    import none;
}

Сервис biding на 192.0.2.1 делает health-check -- если падает, BIRD снимает route, трафик перетечёт в другой POP через BGP.

Проблемы и операционные нюансы

  1. Routing asymmetry: путь туда и обратно могут отличаться. Ломает stateful firewalls. Типично для мульти-homed сетей.
  2. Route leak: AS случайно рекламирует чужие routes своим peers. Вызывает outage.
  3. Route flap damping: частая реклама/withdraw приводит к тому, что upstream начинает игнорировать AS на 15-60 минут.
  4. Prefix deaggregation: анонс /16 через 256 /24 забивает глобальную таблицу (900К+ routes уже). Провайдеры фильтруют > /24 для IPv4.
  5. IPv6: таблица меньше (170K), но растёт быстрее. Anycast работает так же.

Выводы

  • BGP -- policy-based протокол между AS, единственный способ маршрутизации в интернете между сетями.
  • AS_PATH показывает путь по автономным системам, выбор маршрута по LOCAL_PREF и длине пути.
  • Конвергенция BGP -- минуты, не секунды. DNS c низким TTL реагирует быстрее.
  • BGP не имеет встроенной аутентификации -- hijack возможен. RPKI покрывает ~40% префиксов.
  • Anycast -- одинаковый IP в разных локациях, BGP выбирает ближайшую. Идеален для stateless DNS/CDN.
  • TCP + Anycast работает для коротких запросов, для долгих нужен QUIC connection migration или session stickiness.
  • GeoDNS -- DNS-альтернатива Anycast. На практике комбинируют: GeoDNS → regional Anycast.
  • Kubernetes on-prem LoadBalancer через BGP (Cilium, MetalLB) -- дата-центровый вариант anycast для Service IP.

Связанные темы

Unicast, Broadcast, Multicast, Anycast

Связанная тема