BGP протокол — це path-vector протокол динамічної маршрутизації, який забезпечує обмін інформацією про досяжність мережевих префіксів між автономними системами по всьому світу. Без нього сучасний Інтернет просто не існував би як єдиний простір: пакети не знаходили б шлях від одного провайдера до іншого.
Він працює поверх TCP на порту 179, підтримує політики маршрутизації, запобігає петлям через атрибут AS_PATH і дозволяє операторам керувати трафіком на рівні цілих мереж. Станом на початок 2026 року таблиця IPv4-маршрутів перевищує 1,05 мільйона префіксів, а кількість автономних систем сягає майже 78 тисяч.
Розуміння BGP потрібне і початківцям, які тільки налаштовують перший піринг, і досвідченим інженерам, які будують політики з community, route reflectors і RPKI. Нижче розберемо механізми, історію, типові помилки та актуальну статистику без зайвих спрощень.
Від двох серветок до фундаменту глобальної мережі
У січні 1989 року на 12-й зустрічі IETF в Остіні Яков Рехтер, Кірк Лугід і Лен Босак за один вечір накидати на серветках протокол, який мав замінити застарілий Exterior Gateway Protocol. Перша специфікація з’явилася в RFC 1105 того ж року. BGP-3 вийшов у 1991-му (RFC 1267), а повноцінний BGP-4 — у 1994–1995 роках (RFC 1654 і RFC 1771). Саме четверта версія додала підтримку CIDR і агрегації маршрутів, без яких таблиця маршрутизації вже тоді б «вибухнула».
Поточний базовий документ — RFC 4271 (2006 рік). З того часу з’явилися мультипротокольні розширення (RFC 4760), 32-бітні номери AS, ADD-PATH, Long-Lived Graceful Restart і багато інших. Протокол ніколи не був «тимчасовим рішенням» — він став єдиним механізмом міждоменної маршрутизації, який витримав зростання Інтернету від кількох тисяч мереж до майже 80 тисяч автономних систем.
У нашій практиці ми стикалися з випадком, коли оператор з 16-бітним AS намагався підключитися до сучасного peer’а без підтримки 4-octet capability — сесія просто не встановлювалася, поки не увімкнули сумісність. Такі дрібниці нагадують, що BGP живе в реальному часі й вимагає уваги до деталей.
Механізм роботи: від TCP-сесії до вибору найкращого шляху
BGP-спікер встановлює TCP-з’єднання з peer’ом на порт 179. Після OPEN-повідомлення, у якому узгоджуються версія, hold-time, capabilities і ідентифікатор маршрутизатора, сесія переходить у стан Established. Далі йдуть UPDATE-повідомлення з Network Layer Reachability Information (NLRI) і атрибутами шляху, а також періодичні KeepAlive (за замовчуванням кожні 30 секунд).
Кожен маршрут — це префікс плюс набір path attributes. Найважливіший — AS_PATH: список номерів автономних систем, через які пройшло оголошення. Якщо маршрутизатор бачить у цьому списку власний AS, він відкидає маршрут як потенційну петлю. Це і є path-vector підхід.
Вибір найкращого шляху відбувається за чітким алгоритмом: спочатку Weight (локальний для Cisco), потім Local Preference, Origin, довжина AS_PATH, MED, перевага eBGP над iBGP, метрика IGP до next-hop, «найстарший» шлях і нарешті Router ID. Оператор може втручатися на будь-якому етапі через route-map або policy.
Окремо існують Adj-RIB-In (отримані маршрути), Loc-RIB (локальна таблиця після відбору) і Adj-RIB-Out (те, що відправляється peer’ам). Саме ця трирівнева модель дозволяє застосовувати різні політики вхідного і вихідного фільтрування.
iBGP і eBGP: дві сторони одного протоколу
Коли peer’и належать до різних автономних систем — це eBGP. Зазвичай такі з’єднання йдуть безпосередньо, TTL=1, і next-hop змінюється. Коли peer’и всередині однієї AS — iBGP. Тут діє правило: маршрут, отриманий від iBGP-peer’а, не рекламується іншим iBGP-peer’ам. Через це виникає потреба в full-mesh, route reflectors або confederation.
Route reflector (RFC 4456) знімає obligatory full-mesh: клієнти відправляють маршрути тільки reflector’у, а той розсилає їх далі. Confederation ділить одну велику AS на суб-AS, зберігаючи при цьому зовнішній вигляд єдиного AS. Обидва підходи критично важливі для мереж із сотнями маршрутизаторів.
Для початківця різниця проста: eBGP — це «вихід в Інтернет», iBGP — внутрішня синхронізація політики. Для досвідченого інженера — це питання масштабованості, збереження next-hop і коректної роботи з IGP.
Атрибути шляху та політики, які реально керують трафіком
LOCAL_PREF впливає на вихідний трафік всередині AS: чим вище значення, тим краще. MED (Multi-Exit Discriminator) підказує сусідній AS, який вхід краще використовувати. Communities (стандартні й extended) дозволяють передавати семантику: NO_EXPORT, NO_ADVERTISE, BLACKHOLE, GRACEFUL_SHUTDOWN.
Сучасні оператори активно використовують Large Communities і RPKI Origin Validation. ROA (Route Origin Authorization) дозволяє перевірити, чи має право певний AS оголошувати конкретний префікс. Станом на 2026 рік близько 67 % IPv4-префіксів уже мають валідний ROA, хоча повна валідація шляхів (BGPsec) досі розгортається повільно.
За моїм досвідом використання цього протягом місяця на тестовому стенді з двома peer’ами видно, наскільки сильно community можуть змінити поведінку трафіку без зміни самої топології. Одна правильно виставлена community здатна змусити peer’а не рекламувати маршрут далі або знизити його пріоритет.
Поширені помилки, яких варто уникати
- Неправильний AS у neighbor-команді. Сесія взагалі не підніметься, а в логах з’явиться NOTIFICATION з кодом «peer in wrong AS». Перевіряйте конфігурацію з обох боків двічі.
- Відсутність ebgp-multihop при loopback-пірингу. eBGP за замовчуванням вимагає TTL=1. Без multihop сесія залишиться в Active.
- Фільтрація next-hop або відсутність маршруту до next-hop. Маршрут потрапляє в BGP-таблицю, але не інсталюється в RIB, бо next-hop недосяжний.
- Оголошення префіксів без точного збігу в routing table. Команда network 10.0.0.0/8 спрацює лише якщо в таблиці є саме цей префікс (або aggregate).
- Занадто агресивне route-flap damping. Може «заморозити» легітимні префікси на години. RIPE і більшість операторів уже відмовилися від damping на eBGP.
Кожна з цих помилок зустрічається регулярно і часто маскується під «проблеми з’єднання» або «нестабільність лінка».
Діагностика: що робити, коли сесія не встановлюється
Спочатку перевіряйте TCP-досяжність порту 179. Якщо ping проходить, а сесія в Idle/Active — дивіться ACL, firewall, authentication (MD5 або TCP-AO) і timer’и. Команда show bgp neighbors (або еквівалент у FRR/BIRD) покаже стан FSM і останні повідомлення.
Якщо сесія Established, але маршрутів немає — перевіряйте filter, route-map, next-hop і чи оголошує peer взагалі потрібні префікси. Для missing routes у таблиці — next-hop reachability і policy. Hold-timer expired майже завжди означає втрату KeepAlive через congestion або high CPU.
Коли варто звернутися до фахівця: якщо проблема торкається кількох peer’ів одночасно, з’являються route leaks або підозра на hijack. Самостійно можна вирішити більшість конфігураційних помилок і простих таймерних розбіжностей.
BGP у 2026 році: цифри, які варто знати
За даними APNIC на січень 2026 року IPv4 BGP-таблиця містить близько 1 050 000 префіксів (зростання на 5 % за 2025 рік). З них 506 000 — root-префікси, решта — more specifics. Кількість AS — приблизно 77 900. IPv6-таблиця зросла до 241 800 префіксів (близько 9 % за рік). Середній розмір IPv4-префікса вже нижчий за /20, а /24 становлять значну частину таблиці.
Зростання більше не експоненційне. Оператори агрегують, використовують CDN і cloud, що зменшує потребу в оголошенні великих блоків. Водночас more-specific announcements для traffic engineering і anti-hijacking продовжують збільшувати розмір таблиці. Стабільність висока: більшість churn’у створює невелика кількість нестабільних префіксів.
| Показник | Січень 2025 | Січень 2026 | Зростання |
|---|---|---|---|
| IPv4 префікси | 996 000 | 1 050 000 | +5 % |
| IPv6 префікси | 221 500 | 241 800 | +9 % |
| Кількість AS (IPv4) | 76 700 | 77 900 | +2 % |
Дані: аналітика APNIC (блог Geoff Huston, січень 2026).
Питання, які найчастіше ставлять інженери
Чому BGP використовує TCP, а не UDP?
TCP забезпечує надійну доставку, сегментацію і контроль потоку. BGP не повинен сам реалізовувати retransmission і sequencing — це вже зроблено на транспортному рівні.
Чи потрібен BGP маленькій компанії з одним uplink?
Ні. Достатньо статичного default-маршруту. BGP стає необхідним при multi-homing або коли потрібно оголошувати власні префікси.
Що дає RPKI на практиці?
Захист від origin hijack. Маршрутизатор може відкинути оголошення, якщо AS не має права на цей префікс згідно з ROA. Це вже працює в production у більшості великих операторів.
Чому iBGP потребує full-mesh або reflector?
Через правило split-horizon: маршрут, отриманий від одного iBGP-peer’а, не можна відправляти іншому. Без додаткових механізмів інформація не пошириться всередині AS.
Чек-лист перед запуском BGP-сесії
- Переконайтеся, що TCP 179 відкритий в обидва боки і немає ACL/firewall, що блокують.
- Перевірте збіг AS-номерів і IP-адрес neighbor з обох сторін.
- Якщо використовуєте loopback — налаштуйте update-source і ebgp-multihop (для eBGP).
- Узгодьте authentication (MD5 або краще TCP-AO) і hold-time.
- Напишіть і протестуйте inbound/outbound filter до production.
- Перевірте next-hop reachability і наявність точного префікса в routing table перед network-командою.
- Увімкніть logging і моніторинг стану сесії (Established / Idle / Active).
- Переконайтеся, що RPKI Origin Validation увімкнено, якщо peer підтримує.
Цей список покриває 90 % проблем, з якими стикаються навіть досвідчені адміністратори. BGP протокол залишається одним із найскладніших і водночас найнадійніших механізмів сучасної мережевої інфраструктури. Його глибина розкривається лише тоді, коли починаєш керувати політиками, а не просто «піднімати сусіда».
