Мережі: BGP для малих мереж — безпечна мінімальна настройка

Що вам насправді потрібно (і що не потрібно)

Малим мережам не потрібен «просунутий BGP». Їм потрібен передбачуваний BGP. Якщо ви мультихомитеся з двома апстрімами,
ваша мета: зберегти досяжність власних префіксів, зберегти маршрути інших у здоровому стані й переключатися без того, щоб стати заголовком про витік маршрутів.

Ось безпечне мінімальне визначення:

• Один ASN (ваш власний або ASN, призначений провайдером, якщо ви справді не можете отримати свій).
• Одна або більше сесій з провайдерами (eBGP), ідеально — на різних маршрутизаторах.
• Анонсуйте лише те, що вам належить (точні префікси, правильний origin AS).
• Приймайте лише те, що ви маєте намір (повна таблиця, якщо потрібно; тільки маршрут за замовчуванням, якщо можете).
• Жорсткі фільтри як на вхід, так і на вихід.
• Ліміти (max-prefix, обмеження швидкості та захист сесій).
• Набір спостережуваності, який показує стан сесій, кількість маршрутів і фактичні шляхи трафіку.
• Документований план відкату, який працює о 3 ранку.

Що вам не потрібно у перший день:

• Трафік-інженерія через десять шарів communities, яких ви не розумієте.
• Екзотичне полювання за шляхами з AS-path prepends у п’яти місцях «для надійності».
• Повсюдна Graceful restart тільки тому, що хтось сказав, що це «чистіше».
• Route reflector-и та iBGP-меш-гіманстика у мережі, яка вміщується на одній дошці для записів.

Мала мережа може запускати BGP як ремінь безпеки: просто, нудно і рідко помітно. Ось у чому сенс.

Короткий історичний контекст і цікаві факти

Трохи контексту корисно, бо поведінка BGP часто здається «дивною», поки ви не згадаєте, для чого його створили: політики, а не
ідеальна короткість шляху.

1. BGP замінив EGP, коли Інтернет перейшов від деревоподібної топології до складної сітки автономних систем.
2. BGP — це протокол path-vector: він не несе повний граф топології, а шлях AS, щоб уникати циклів.
3. CIDR та BGP виросли разом на початку 1990-х, щоб уповільнити вибух таблиць маршрутизації шляхом агрегації.
4. «Зона без дефолту» стала популярною, коли багато ядерних маршрутизаторів не мали дефолтного маршруту взагалі.
5. Витоки маршрутів трапляються постійно, бо модель довіри BGP передбачає, що пірингові партнери поводяться чесно — а люди часто ні.
6. Communities додали можливість мережам тегувати маршрути для політики без переписування базового протоколу.
7. MP-BGP дозволив масштабувати VPN (як L3VPN) і IPv6 без винайдення зовсім нового протоколу.
8. RPKI — відносно нове і ще нерівномірно впроваджене, але це один з перших широковживаних механізмів для зменшення підмін origin.

Висновок: BGP достатньо старий, щоб голосувати, а деякі його припущення старші за ваш стек моніторингу.

Модель загроз для малих мереж: що може піти не так

Для малих мереж «безпека BGP» — це не про державних акторів. Це про щоденні відмови:
людські помилки, непорозуміння та дефолти від вендорів, які здаються нешкідливими, поки ними не стануть.

Режим відмови: ви анонсуєте те, що вам не належить

Це класика. Друк у префікс-листі, надто широка агрегація або «тимчасовий тест», який ніколи не повернули назад.
Апстріми можуть фільтрувати, але не варто покладатися на їхню ретельність як на вашу безпеку.

Режим відмови: ви приймаєте сміття і самі себе зануляєте

Взяти повну таблицю і встановити її в невеликому маршрутизаторі з недостатньою пам’яттю — надійний рецепт нових
втрат пакетів. Брати тільки дефолт, але забути зафіксувати next-hop чи local-pref може створити дивні флапи.

Режим відмови: витік маршрутів через транзитні політики

Витік маршруту — це коли ви випадково надаєте транзит між двома мережами, які цього не домовлялися. Ваша мережа стає
ненавмисним коридором. Трафік йде коридором, поки він не обвалиться.

Режим відмови: контрольна площина каже «up», а плоскость даних горить

Сесії BGP можуть бути Established і щасливими, поки MTU, ACL або асиметрія тихо вбивають пропускну здатність.
BGP — це протокол контрольної площини. Він не терапевт.

Цитата, яку варто пам’ятати: «Надія — це не стратегія.» — Gene Kranz.

Жарт №1: BGP — єдине місце, де «довіра» — це опція налаштування, а не статус стосунків.

Безпечний мінімальний дизайн: рішення, які ви берете на себе

1) Виберіть модель маршрутизації: тільки дефолт або повна таблиця

Якщо ваша мережа мала, вам, ймовірно, не потрібна повна інтернет-таблиця. Тільки дефолт (0.0.0.0/0 та ::/0) зменшує
навантаження на пам’ять і операційні ризики. Повна таблиця дає більше контролю і іноді кращу продуктивність, але також
дає 900k+ способів отримати проблему.

Моє упереджене правило:

• Якщо у вас один крайовий маршрутизатор: зазвичай правильний вибір — тільки дефолт.
• Якщо у вас два крайові маршрутизатори і реальні потреби в інженерії трафіку: розгляньте повну таблицю, але лише на апаратурі, що її витримає.
• Якщо ви робите DDoS-скрабінг, складний multi-exit або великий CDN-трафік: повна таблиця стає більш обґрунтованою.

2) Два маршрутизатори, якщо можете собі дозволити

Один маршрутизатор — це єдина точка відмови. Два маршрутизатори — це багато паперової роботи. Однак: якщо можете поставити два скромні бокси,
зробіть це. Розмістіть їх на різному живленні, різних uplink-ах і бажано з різними апстрім-ручками.

3) Тримайте iBGP малим і очевидним

Якщо ви маєте два крайові маршрутизатори, ймовірно, ви запустите iBGP між ними. Тримайте його простим:
одна сесія в кожен бік, чіткі політики маршрутів і один IGP (або статичні маршрути) для next-hop.
Ви не будуєте магістраль рівня 1. Дійте відповідно.

4) Відокремлюйте політику від інфраструктури

Ваш BGP-демон може бути FRR, BIRD, Junos, IOS, EOS — це не так важливо, як ваша дисципліна.
Створіть структуру політик, яку можна аудиту:

• Inbound-фільтр: що приймаєте, що відхиляєте і що тегуєте.
• Outbound-фільтр: що ви походжуєте, що експортуєте і як маркуєте.
• Охоронні механізми сесій: max-prefix, TTL security (де доречно), MD5/TCP-AO якщо підтримується, і адекватні таймери.

5) Визначте стратегію анонсів: спочатку точні префікси

Почніть з точних префіксів. Анонсуйте лише конкретні блоки, які ви маєте і плануєте походжувати. Агрегації можуть з’явитися пізніше,
і тільки коли ви впевнені, що не випадково «поглинете» адреси, які вам не належать.

Фільтрація: ваш справжній файрвол — це політика

У BGP фільтрація — це різниця між «мережею» та «катастрофою».
Вам потрібні вихідні фільтри, щоб запобігти витокам, і вхідні, щоб запобігти сміттю в таблиці.

Вихідна фільтрація: анонсуйте лише свої префікси

Для малої мережі вихідна політика зазвичай така:

• Дозвольте ваші власні префікси (і тільки їх).
• Встановіть свої communities, якщо ви їх використовуєте.
• Відхиліть усе інше.

Якщо ви клієнт (не провайдер транзиту), не експортуйте повну таблицю, яку ви навчились від ISP A, до ISP B.
Це архетип витоку маршрутів.

Вхідна фільтрація: приймайте те, що ви здатні обробити

Ваша вхідна політика залежить від того, чи берете ви тільки дефолт, чи повну таблицю:

• Тільки дефолт: приймайте 0.0.0.0/0 і ::/0 від кожного апстріму, плюс можливо невеликий набір провайдер-специфічних маршрутів, якщо потрібно.
• Повна таблиця: приймайте все після відсікання bogon-ів, martian-ів, надто довгих префіксів і RPKI-invalid префіксів.

Базові ідеї щодо bogon/martian

Як мінімум, відкидайте маршрути для RFC1918, простору carrier-grade NAT, loopback, link-local, multicast та інших очевидних не-ґлобальних діапазонів.
Також можна відкидати занадто-специфічні маршрути (наприклад IPv4 довше за /24 і IPv6 довше за /48), якщо вони вам не потрібні.

Ваш апстрім може вже фільтрувати це. Чудово. Однак фільтруйте й ви самі. Надлишковість — це не тільки про живлення.

RPKI: дешева безпека з високою віддачею

RPKI-валідaція перевіряє, чи авторизований origin AS анонсувати префікс (на основі ROA).
Вона не вирішує всі проблеми безпеки BGP. Але зменшує радіус ураження помилок у origin і деяких підмін.

Мінімальна RPKI-позиція для малих мереж:

• Запустіть валідатор (наприклад Routinator) локально.
• Налаштуйте маршрутизатори/демони на виконання origin-валідaції.
• Відхиляйте RPKI-invalid маршрути на вході від транзитів (або принаймні суттєво знижуйте їх пріоритет).
• Публікуйте ROA для своїх префіксів коректно (і тримайте їх в актуальному стані).

Якщо ви зробите лише одну «модернізацію», зробіть цю. Це найближче до шолома для BGP.

Ліміти та таймери: уникати неочікуваної насиченості

Ліміти — це не про обережність. Це про те, щоб відмови відбувались швидко, голосно та в межах контролю.

Max-prefix ліміти

Якщо ви берете тільки дефолт, ваш max-prefix має бути малим (наприклад 10–100, залежно від додаткових маршрутів апстріма).
Якщо ви берете повну таблицю, встановіть його відповідно до очікуваної таблиці плюс запас, але не безкінечний запас.

Ваш вибір філософський: ви хочете, щоб сесія обривалася, коли трапляється щось дивне (fail-closed),
чи щоб вона залишалася і ви просто сподівалися, що коробка виживе (fail-open)? Для малих мереж fail-closed зазвичай кращий.

Keepalives і hold-таймери

Дефолтні значення зазвичай підходять. Налаштування таймерів для «швидшого» переключення часто просто робить вас більш схильними до флапів.
Якщо вам потрібне підсекундне сходження, це вже не «безпечна мінімальна» зона; це «інженеруйте весь стек» територія.

Graceful restart: корисно, але легко зловживати

Graceful restart може приховати перезапуски контрольної площини, але також може зберегти застарілу переадресацію і ускладнити діагностику.
Якщо вмикаєте його — протестуйте. Потім протестуйте знову при часткових відмовах.

Жарт №2: Graceful restart — це як поставити маршрутизатор у режим «Не турбувати». Спокійно, поки ви не помітите, що пропустили сигнал тривоги.

Перевірки плоскості даних: не довіряйте лише контрольній площині

BGP охоче обмінюється маршрутами через TCP-сесію, поки ваш фактичний трафік помирає через MTU, ACL,
асиметрію або апстрім, який мовчки чорнує трафік під час захисту.

Мінімальна операційна позиція:

• Завжди перевіряйте досяжність своїх префіксів із зовні (не лише зсередини).
• Тримайте відомий робочий тестовий хост в іншій мережі (дешевий VM десь підходить).
• Відстежуйте втрати пакетів і затримку по кожному uplink-у, а не лише «BGP Established».

Практичні завдання: команди, виводи та рішення (12+)

Це реальні завдання, які можна виконати на маршрутизаторі на базі Linux, route server-і або на коробці для діагностики.
Я буду використовувати FRR-стиль vtysh і звичайні Linux-інструменти, бо вони широко доступні.
Ключ — це робочий процес: команда → інтерпретація виводу → прийняття рішення.

Завдання 1: Перевірте, що BGP-сесії Established (FRR)

cr0x@server:~$ vtysh -c "show ip bgp summary"
BGP router identifier 203.0.113.2, local AS number 64512
BGP table version is 128, main routing table version 128
Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
198.51.100.1    4      65001    9132    9050      128    0    0 2d03h        1
203.0.113.1     4      65002    8321    8204      128    0    0 2d03h        1

Що це означає: Обидва сусіди працюють приблизно 2 дні і кожен надсилає по 1 префіксу (ймовірно, тільки дефолт).
Рішення: Якщо ви очікували повні маршрути, а бачите «1», ваша вхідна політика — тільки дефолт (або зламана).
Якщо ви очікували тільки дефолт, а бачите «900000», ваші фільтри неправильні або апстрім дає повну таблицю.

Завдання 2: Перевірте отримані маршрути від апстріму і підтвердіть фільтрацію

cr0x@server:~$ vtysh -c "show ip bgp neighbor 198.51.100.1 received-routes" | head
BGP table version is 128, local router ID is 203.0.113.2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0/0        198.51.100.1             0    100      0 65001 i

Що це означає: Ви отримуєте лише дефолт. Це відповідає дизайну «тільки дефолт».
Рішення: Якщо тут бачите RFC1918 або інші сміттєві маршрути, негайно посильте вхідні фільтри.

Завдання 3: Підтвердіть, що ви анонсуєте лише заплановані префікси

cr0x@server:~$ vtysh -c "show ip bgp neighbor 198.51.100.1 advertised-routes"
BGP table version is 128, local router ID is 203.0.113.2

   Network          Next Hop            Metric LocPrf Weight Path
*> 203.0.113.0/24   0.0.0.0                  0         32768 i

Що це означає: Ви анонсуєте лише 203.0.113.0/24. Добре.
Рішення: Якщо ви бачите 0.0.0.0/0 або повну таблицю тут як клієнт, ви витікаєте. Вимкніть експорт, потім виправляйте політику.

Завдання 4: Перевірте RIB маршрутизатора проти BGP RIB (Linux)

cr0x@server:~$ ip route show default
default via 198.51.100.1 dev eth1 proto bgp metric 20

Що це означає: Дефолтний маршрут у ядрі встановлений через BGP на eth1.
Рішення: Якщо ваш бажаний uplink має бути ISP2, але це вказує на ISP1, відрегулюйте local-pref (preferred) або weight (вендорно).

Завдання 5: Перевірте підрахунок маршрутів швидко (BIRD)

cr0x@server:~$ birdc show protocols all | sed -n '1,14p'
BIRD 2.0.12 ready.
Name       Proto      Table      State  Since         Info
up_isp1    BGP        master4    up     2026-02-04    Established
  BGP state:          Established
  Neighbor address:   198.51.100.1
  Neighbor AS:        65001
  Routes:             1 imported, 1 exported, 1 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:         2          0          0          0          2
    Export updates:         2          0          0          0          2

Що це означає: BIRD підтверджує вашу намірену форму «тільки дефолт».
Рішення: Якщо «rejected» різко зростає, ваш фільтр щось ловить; з’ясуйте, чи це коректне блокування, чи випадкова заборона.

Завдання 6: Перевірте, що ваш префікс видимий зовні (через віддалений пробник)

cr0x@server:~$ whois -h whois.radb.net 203.0.113.0/24 | head
route:          203.0.113.0/24
origin:         AS64512
descr:          Example Network
mnt-by:         EXAMPLENET-MNT
changed:        noc@example.net 20250101
source:         RADB

Що це означає: Існує об’єкт маршруту (routing registry), який вказує на ваш намір походжувати цей префікс.
Рішення: Якщо ваш апстрім використовує IRR-фільтрацію і цей об’єкт відсутній/неправильний, ваші оголошення можуть фільтруватися. Виправте реєстраційний об’єкт або узгодьте з апстрімом авторизацію.

Завдання 7: Перевірте стан ROA для вашого префіксу (Routinator)

cr0x@server:~$ routinator validate 203.0.113.0/24 | head
203.0.113.0/24 AS64512 valid (maxLength 24)

Що це означає: Ваш префікс має валідний ROA для вашого ASN.
Рішення: Якщо статус «invalid» або «notfound», виправте ROA. Якщо апстрім відкидає invalid, ви зникнете так, що «BGP вгору, але ніхто не може дістатися».

Завдання 8: Перевірте стан RPKI-валідaції на маршрутизаторі (приклад FRR)

cr0x@server:~$ vtysh -c "show bgp rpki summary"
RPKI cache servers:
1) 127.0.0.1:3323  pref 1  state Established  uptime 2d03h  serial 12981
Prefix records: 214532

Що це означає: Ваш маршрутизатор спілкується з локальним валідатором, і в нього є RPKI-дані.
Рішення: Якщо стан не Established, ваша політика «відхиляти invalid» може перестати працювати непомітно. Спочатку виправте зв’язок з RTR.

Завдання 9: Перевірте, чи не «плавиться» ваш маршрутизатор (швидка перевірка пам’яті/CPU)

cr0x@server:~$ top -b -n1 | head -n 8
top - 10:12:54 up 32 days,  4:19,  1 user,  load average: 0.22, 0.18, 0.15
Tasks: 134 total,   1 running, 133 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.4 us,  0.5 sy,  0.0 ni, 97.8 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
MiB Mem :   7984.2 total,   4231.7 free,    912.4 used,   2840.1 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   6589.4 avail Mem

Що це означає: Багато вільних ресурсів. Підходить для повних маршрутів? Можливо. Для тільки дефолту — точно.
Рішення: Якщо відбувається свопінг або CPU зашиває під час оновлень, зменшіть прийом маршрутів (тільки дефолт), збільшіть апаратні ресурси або перенесіть BGP на відокремлену контрольну коробку з чистим підходом до FIB-програмування.

Завдання 10: Перевірте втрати пакетів на інтерфейсі uplink

cr0x@server:~$ ip -s link show dev eth1
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:11:22:33 brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  9123456  0       12       0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    1234567890  7345678  0       0        0       0

Що це означає: Деякі RX-dropped є. Може бути політика полісінгу, тиск на буфери або проблема драйвера.
Рішення: Якщо падіння зростає під навантаженням, ймовірно, у вас перевантаження або невідповідність шейпінгу. Не «вирішуйте» це через BGP. Вирішіть через збільшення пропускної здатності, QoS або налаштування інтерфейсу.

Завдання 11: Перевірте MTU за допомогою ping без фрагментації

cr0x@server:~$ ping -M do -s 1472 -c 3 198.51.100.1
PING 198.51.100.1 (198.51.100.1) 1472(1500) bytes of data.
1472 bytes from 198.51.100.1: icmp_seq=1 ttl=64 time=0.61 ms
1472 bytes from 198.51.100.1: icmp_seq=2 ttl=64 time=0.58 ms
1472 bytes from 198.51.100.1: icmp_seq=3 ttl=64 time=0.60 ms

--- 198.51.100.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Що це означає: Path MTU виглядає нормальним для Ethernet з MTU 1500.
Рішення: Якщо це не проходить, а менші розміри проходять — у вас ризик MTU-ямної діри. Виправте MTU/MSS-clamping перед тим, як звинувачувати BGP у «випадковій» повільності.

Завдання 12: Перевірте фактичний шлях виходу за допомогою traceroute

cr0x@server:~$ traceroute -n -w 1 -q 1 1.1.1.1 | head
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  198.51.100.1  0.530 ms
 2  198.51.100.254  1.212 ms
 3  203.0.113.254  2.891 ms

Що це означає: Ви виходите через ISP1.
Рішення: Якщо ви хотіли, щоб ISP2 був основним, змініть local-pref/weight або пріоритет дефолтного маршруту. Не просто робіть prepend і сподівайтесь; контролюйте вхідний і вихідний трафік окремо.

Завдання 13: Підтвердіть, що ядро бачить очікувані BGP-вивчені маршрути (перевірка розміру)

cr0x@server:~$ ip route | grep -c "proto bgp"
1

Що це означає: Ви встановили саме один BGP-маршрут (ймовірно дефолт). Це ваша заявлена мета в режимі тільки дефолт.
Рішення: Якщо цей рахунок несподівано зростає, ваш демон може встановлювати повні маршрути. Перевірте політики і чи не варто використовувати окремий VRF/таблицю.

Завдання 14: Помітити патерн витоку маршрутів, перевіряючи AS-path на несподіваних маршрутах

cr0x@server:~$ vtysh -c "show ip bgp 8.8.8.0/24"
BGP routing table entry for 8.8.8.0/24
Paths: (1 available, best #1, table default)
  65001 15169
    198.51.100.1 from 198.51.100.1 (198.51.100.1)
      Origin IGP, localpref 100, valid, external, best

Що це означає: Ви навчились цього маршруту від ISP1. Нормально, якщо ви берете повні маршрути.
Рішення: Якщо ви на режимі тільки дефолт, але бачите такі конкретики встановленими, ваш вхідний фільтр не робить те, що ви думаєте.

Завдання 15: Перевірте історію флапів BGP, щоб виявити переривчасті проблеми транспорту

cr0x@server:~$ vtysh -c "show ip bgp neighbor 198.51.100.1"
BGP neighbor is 198.51.100.1, remote AS 65001, local AS 64512, external link
  BGP version 4, remote router ID 198.51.100.1
  BGP state = Established, up for 2d03h
  Last read 00:00:19, Last write 00:00:21
  Connections established 3; dropped 2
  Last reset 1d01h, due to Hold Timer Expired

Що це означає: Сесія впала двічі, останній раз через прострочення Hold Timer. Часто це транспортні втрати або виснаження CPU.
Рішення: Якщо прострочення співпадають з перевантаженням або DDoS — підвищуйте надійність транспорту перш за все (QoS, координація полісінгу, захист контрольної площини).

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через хибне припущення

Середньостатистична SaaS-компанія мультихомилась вперше. Два апстріми, один маршрутизатор, FRR. Мали вікно змін,
план дій і Slack-канал з впевненою назвою на кшталт #bgp-cutover.

Хибне припущення: «Наш апстрім відфільтрує все, що ми не повинні анонсувати.» Інженер написав вихідну політику,
котра мала анонсувати лише їх /24, але одночасно він також редистриб’ював connected-мережі. Підмережа управління
виявилася публічною через попереднє поглинання і була все ще на інтерфейсі. Вона була анонсована.

Всередині все здавалоcя в порядку. BGP було Established. Їхні сервісні IPи лишалися вгору. Єдиним знаком був дивний сплеск
вхідного трафіку на інтерфейсі управління і кілька алертів про підвищення CPU.

Потім апстрім помітив це. Апстрім жорстко вимкнув BGP-сесію. Вихідне підключення переключилося на другого ISP,
але вхідний трафік не відновився гладко. Частина клієнтів все ще потрапляла на відкликаний шлях кілька хвилин, бо кешування і propagation
не зобов’язані співпадати з вашим вікном обслуговування.

Виправлення було простим і принизливим: явні outbound prefix-list-и, заборона редистрибуції в eBGP і передзміночна перевірка,
яка друкує анонсовані маршрути і вимагає ручного підтвердження. Кращий ряд постмортему був: «Ми аутсорснули правильність комусь
з іншими стимулами.»

Міні-історія 2: Оптимізація, яка відкотилась

Рітейл-компанія хотіла «швидше переключення». Прочитали про BFD і агресивні таймери. На краю були два маршрутизатори, кожен з двома сесіями.
Команда вклала коротші keepalive і hold-таймери, а також увімкнула BFD повсюди.

Тиждень виглядав чудово. Відмова лінка відбувалася швидко. Усі почувались хитро. Потім планове обслуговування в апстрімі
привнесло переривчасті мікроскопічні втрати пакетів на одному каналі. Не достатньо, щоб пошкодити TCP-потоки суттєво. Достатньо, щоб
дратувати BFD.

Результат — режим відмови, який важко пояснити нетехнарям: сесії почали флапати, маршрути сильніше змінювалися,
CPU підскочив, і втрата пакетів погіршилась, бо контрольна площина їла ресурси на переконвергенцію. «Оптимізація» створила
самоподіяну нестабільність. Мережа швидко відмовляла, повільно відновлювалася.

Вони відкотилися до консервативніших таймерів і вмикали BFD лише там, де транспорт був чистим і добре зрозумілим.
Урок: збіжність — це системна властивість. Якщо ви надто стискаєте одну частину, інша щось компенсує.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Малий хостинг-провайдер роками підтримував мінімальний BGP-набір: строгі prefix-list-и, max-prefix ліміти, RPKI-валідaція
і нічне завдання, що дифує «анаонсовані маршрути по сусіду» з очікуваним файлом. Це не було гламурно. Але саме через це вони спали.

Одного дня апстрім подзвонив: «Ми бачимо незвичну кількість префіксів з вашої сесії.» Внутрішній моніторинг вже сповістив.
Скрипт-див виявив, що маршрутизатор збирався експортувати більше ніж очікувані два префікси.
Max-prefix на експорт не скрізь застосовується, але їхня політика була жорсткою: забороняйте все, крім явного списку.

Корінь проблеми був у помилці управління конфігом: розгортання шаблону зробило ширший prefix-list на одному маршрутизаторі.
Строга політика «deny all else» завадила експортувати щось небажане, тому радіус ураження обмежився «ми не анонсували один із запланованих префіксів кілька хвилин» замість «ми витекли таблицю».

Вони виправили шаблон, перевиконали розгортання і закрили інцидент майже без впливу на клієнтів. Порятунок не був геніальним.
Це була нудьга: явні allowlist-и, дифовані очікування і відмова покладатися на жалобу апстріма.

План швидкої діагностики

Коли щось не так, ваше завдання — швидко знайти вузьке місце, а не милуватися розвалом. Ось порядок, який швидко дає відповіді.

По-перше: це контрольна площина, плоскость даних чи політика?

• Перевірка контрольної площини: сесії Established? Кількість префіксів отриманих/відправлених відповідає очікуванню?
• Перевірка плоскості даних: Чи можна пінгувати/трасувати назовні? Чи можуть інші дістатися ваших префіксів? Є втрати/помилки?
• Перевірка політики: Чи змінилися local-pref/weight? Нові фільтри, зміни в RPKI або події max-prefix?

По-друге: підтвердіть свої власні анонси

• На маршрутизаторі: перевірте, що оголошувані маршрути по сусіду відповідають вашому allowlist-у.
• Зовні: переконайтеся, що ROA валідні і записи в реєстрах збігаються з тим, що апстрім очікує.
• Перевірте, що origin AS правильний і стабільний.

По-третє: перевірте симетрію вхідних маршрутів та next-hop-и

• Чи отримуєте ви дефолт від обох? Який з них переважає?
• Чи повертається трафік тим же ISP, який ви очікуєте? Якщо ні, чи мають стейт-файрволи проблеми з асиметрією?
• Чи узгоджена ваша IGP/статична маршрутизація з BGP next-hop-ами?

По-четверте: пошукайте виснаження ресурсів і сильну зміну

• Піки CPU під час оновлень можуть спричиняти прострочення hold timer-ів.
• Тиск пам’яті може викликати затримки обробки маршрутів і дивні лаги при програмуванні FIB.
• Логи: скидання сесій, події prefix-limit, відключення RPKI-кеша.

По-п’яте: ізолюйте проблему, вимкнувши один uplink (обережно)

Якщо у вас два апстріми, тимчасово вимкніть одну BGP-сесію (або змініть local-pref) і спостерігайте.
Якщо проблема зникає — скоріше за все апстрім-специфічна або політична. Якщо лишається — швидше за все ваш край або внутрішня мережа.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: Інтернет «працює», але деякі сайти таймаутять

Корінь: MTU-ямна діра або зла PMTUD, часто через тунелі або провайдерські handoff-и.

Виправлення: Перевірте MTU за допомогою DF-ping; реалізуйте MSS-clamping на краю для TCP; вирівняйте MTU на handoff-ах.

2) Симптом: BGP Established, але ніхто не може дістатися ваших IP

Корінь: Ви фактично не анонсуєте свій префікс (помилка політики), або апстрім фільтрує його (IRR/RPKI-невідповідність).

Виправлення: Перевірте advertised-routes; підтвердіть origin AS; валідaцію ROA; переконайтеся, що реєстр збігається з вимогами апстріма.

3) Симптом: CPU маршрутизатора підскакує і сесії флапають у пікові моменти

Корінь: Перевантаження контрольної площини від оновлень повної таблиці, надмірно агресивних таймерів або змін маршрутів.

Виправлення: Поверніть таймери до розумних значень; зменшіть кількість маршрутів (тільки дефолт); забезпечте захист контрольної площини; розгляньте окреме апаратне рішення для маршрутизації.

4) Симптом: Раптово ви отримуєте значно більше маршрутів ніж зазвичай

Корінь: Апстрім витікнув повні маршрути у вашу дефолт-сесію, або змінився ваш вхідний фільтр.

Виправлення: Застосуйте вхідні фільтри; встановіть строгий max-prefix; погодьтеся з апстрімом; розгляньте відхилення всього, крім дефолту, якщо це ваш дизайн.

5) Симптом: Апстрім загрожує відключенням за «витік маршрутів»

Корінь: Ви експортували вивчені маршрути іншому сусідові або редистриб’ювали IGP/connected в eBGP.

Виправлення: Приберіть редистрибуцію в eBGP; реалізуйте явний outbound allowlist; перевіряйте advertised routes перед включенням сесій.

6) Симптом: Failover працює вихідний трафік, але вхідний трафік лишається на мертвому ISP

Корінь: Вхідний трафік залежить від вибору шляху віддаленими мережами; ваші зміни анонсів не миттєві чи не пріоритетні.

Виправлення: Використовуйте провайдерські communities; переконайтеся, що обидва апстріми бачать ваші анонси; розгляньте контрольовані більш-специфічні анонси для переключення (акуратно).

7) Симптом: RPKI «зламав Інтернет» після увімкнення

Корінь: Ви відхиляли invalid, але ваші ROA були неправильні, або зв’язок з валідатором впав і політика за замовчуванням спрацювала несподівано.

Виправлення: Спочатку валідaйте свої префікси; переконайтеся в стабільному RTR-з’єднанні; якщо потрібно, використовуйте поетапну політику (давати пріоритет валідним, знижувати пріоритет невідомим, відхиляти invalid).

8) Симптом: Асиметрична маршрутизація ламає stateful-файрволи

Корінь: Різні uplink-и для вхідного і вихідного трафіку плюс файрвол, що очікує симетрії.

Виправлення: Або спроектуйте симетрію (політика/local-pref), або розгорніть синхронізацію стану / файрвол з розумінням маршрутизації; уникайте «випадкового» ECMP через stateful-пристрої.

Чеклісти / покроковий план

Фаза 0: Перед тим, як торкатися BGP

• Упорядкуйте адресний простір і ASN: хто за що відповідає, хто що походжує.
• Вирішіть — тільки дефолт чи повна таблиця; підійміть апаратні вимоги відповідно.
• Побудуйте OOB (out-of-band) шлях управління, який не залежить від нового BGP-дизайну.
• Напишіть allowlist префіксів, які ви будете анонсувати (точні префікси, коректні довжини масок).
• Визначте ваші max-prefix значення для кожного сусіда і задокументуйте їх.

Фаза 1: Піднімайте сесії безпечно (по одній)

1. Налаштуйте сусіда з тимчасовим outbound deny-all.
2. Встановіть BGP-сесію і підтвердіть, що вона залишається Established щонайменше 15–30 хвилин.
3. Увімкніть вхідну політику (тільки дефолт або повна таблиця) і підтвердіть, що кількість отриманих префіксів відповідає очікуванню.
4. Увімкніть outbound allowlist і підтвердіть, що advertised prefix list відповідає очікуваному файлу.
5. Перевірте зовнішню досяжність ваших префіксів через віддалений пробник.

Фаза 2: Додайте захисні механізми

• Встановіть max-prefix і визначте поведінку при перевищенні (попередження vs shutdown; для малих мереж я віддаю перевагу shutdown).
• Увімкніть RPKI-валідaцію і виберіть політику (reject invalid — поширена; будьте обережні з «notfound»).
• Відкидайте bogon-и/martian-и на вході; забороніть занадто-специфічні префікси, якщо не потрібні.
• Переконайтеся, що немає редистрибуції connected/IGP в eBGP, якщо це не було явним наміром і відфільтровано.

Фаза 3: Резервування і контрольований failover

• Підніміть другий апстрім з тією ж дисципліною: deny-all, потім allowlist.
• Визначте вихідну пріоритетність (local-pref/weight) і протестуйте failover, відключивши одну сесію.
• Для вхідної пріоритетності використовуйте провайдерські communities або контрольовані більш-специфічні анонси.
• Тестуйте в низькоризиковий час; вимірюйте збіжність і вплив на додатки.

Фаза 4: Експлуатуйте як production

• Моніторинг: стан сесій, кількість префіксів, швидкість оновлень, CPU/пам’ять, помилки/дропи інтерфейсів.
• Алерти на: сесія down, відхилення кількості префіксів, відключення RPKI-валідатора, події max-prefix.
• Контроль змін: зміни політик пірингу вимагають diff-а і другої пари очей.
• Тримайте план відкату: вимкнути експорт, закрити сесії, повернути конфіг, перевірити досяжність.

Питання та відповіді (FAQ)

Чи потрібен мені BGP, якщо я маю одного провайдера?

Зазвичай ні. Якщо у вас один ISP і немає портованого адресного простору, BGP здебільшого додає додаткові режими відмов.
Використовуйте статичну/дефолт- маршрутизацію і зосередьтесь на іншій надлишковості.

Тільки дефолт чи повна таблиця: що обрати?

Тільки дефолт, якщо ви малі і хочете стабільності. Повна таблиця, якщо у вас є вагомі причини: потреби в трафік-інженерії,
кілька виходів з значущою політикою або ви працюєте в масштабі, де дефолт призводить до істотної неоптимізації.

Чи можна безпечно мультихомитись з одним маршрутизатором?

Можна, але ви отримуєте часткову надлишковість. Маршрутизатор лишається єдиною точкою відмови. Якщо робите так, тримайте дизайн мінімальним
і обов’язково майте доступ OOB, якщо ви самі себе відріжете.

Чи варто використовувати BFD для швидшого failover?

Лише якщо ваш транспорт чистий і ви протестували його в умовах реальних втрат. Агресивне виявлення може спричинити флапи,
а флапи можуть бути гірші за трохи повільніше переключення.

Що таке BGP communities і чи потрібні вони мені?

Communities — це теги, які ви додаєте до маршрутів, щоб просити апстрім про поведінку (наприклад prepending, blackholing або зміна local-pref).
Вони не потрібні для безпечного мінімуму, але стануть чистим способом впливу на вхідний трафік, коли ви зрозумієте семантику провайдера.

RPKI обов’язковий?

Не обов’язковий, але це одна з найкращих апгрейдів безпеки за годину роботи. Почніть із валідації і моніторингу; потім переходьте до відхилення invalid,
коли впевнені, що ваші ROA коректні.

Який найпростіший спосіб запобігти витоку маршрутів?

Outbound allowlist-и. Дозволяйте лише свої префікси. Відхиляйте все інше. Не редистриб’юйте connected або IGP в eBGP, якщо це не відфільтровано тим же allowlist-ом.

Чому вхідний failover іноді займає хвилини?

Бо вхідний трафік залежить від того, що вважає Інтернет. Поширення відкликів, dampening та віддалене кешування існують.
Ви можете впливати на це communities, більш-специфічними анонсами і вибором апстрімів, але не можете змусити миттєву глобальну конвергенцію.

Як зрозуміти, чи проблема на вашому краї чи у апстріма?

Зіставте контрольну площину і плоскость даних. Якщо сесії стабільні і оголошення коректні, але є втрати або затримки — перевірте статистику інтерфейсів, MTU і якість шляху апстріма.
Якщо ви можете перемкнутися на другого апстріма і проблема зникає — ймовірно апстрім-специфіка.

Чи варто запускати iBGP між двома крайовими маршрутизаторами?

Якщо обидва походжують ті самі префікси і ви хочете координованого вибору виходу — так, але тримайте його мінімальним і явним.
Якщо ваша мережа дуже мала і ви можете працювати з незалежними дефолтами, можна уникнути iBGP, але розумійте компроміси.

Висновок: наступні кроки, які вам не зашкодять

Безпечний мінімум BGP — це не про хитрощі. Це про стриманість: явні allowlist-и, строгі вхідні фільтри, розумні ліміти
і достатню спостережуваність, щоб помічати помилки раніше, ніж ваш апстрім.

Практичні наступні кроки:

1. Випишіть ваші плановані анонси (точні префікси) і ставтеся до цього списку як до production-коду.
2. Визначте — тільки дефолт чи повна таблиця — і підберіть апарат відповідно; апаратні обмеження — це обмеження політики.
3. Реалізуйте outbound allowlist-и і inbound-фільтри (bogons, max-lengths, max-prefix).
4. Увімкніть RPKI-валідaцію, перевірте свої ROA і виберіть усвідомлену політику для invalid/notfound.
5. Побудуйте у моніторингу цикл швидкої діагностики: стан сесій, кількість префіксів, помилки інтерфейсів і зовнішню досяжність.

Якщо ви захочете робити трафік-інженеринг після цього — будь ласка. Заробіть його. Спочатку переконайтеся, що ваша мережа не може випадково стати провайдером транзиту у вівторок.