Планування великої VPN «зіркою»: спершу порахуйте, потім обирайте BGP
Префікси — це просте число. Сесії, хвиля оновлень і відновлення після відмови концентратора вирішують, чи витримає проєкт кілька тисяч філій.
Три тисячі філій звучать як задача маршрутизації, але поводяться як задача бухгалтерії. Сума префіксів рахується за десять хвилин, і це рідко те число, яке болить. Болить робота на кожну сесію, хвиля оновлень, коли відмовляє спільний компонент, і час, поки пересилання знову збігнеться з новою топологією.
Тож проходьте арифметику в правильному порядку. Порахуйте зв'язки, порахуйте префікси й альтернативи, потім порахуйте, що відбувається в погану годину, і лише після цього порівнюйте протоколи та платформи. У зворотному порядку вправа перетворюється на суперечку про ліміти маршрутів, яку ніхто не може закрити наявною на столі інформацією.
Чотири бюджети, а не один
Кожен бюджет відповідає на інше питання, і кожен може бути обмежувальним чинником на іншій платформі. Записані окремо, вони не дають одному великому числу префіксів замінити весь проєкт.
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
Останні два — ті, що їх пропускають на огляді проєкту. Мережа, яка в усталеному стані комфортно вміщується в пам'ять, усе одно може поводитися погано, коли чотириста філій перепідключаються за дві хвилини, бо робота надходить швидше, ніж площина керування встигає її розібрати. Запишіть розмір хвилі числом, разом із тим, скільки часу сервіс може залишатися деградованим. Це перетворює неясний неспокій на тест, який хтось справді може виконати.
У всіх чотирьох ховається ще одне питання про платформу: чи шифрування, пересилання й маршрутизація ділять один процесор, чи мають окремі шляхи. Два пристрої з однаковою ємністю маршрутів можуть поводитися дуже по-різному під хвилею, і в специфікації рідко сказано, яке саме ви купуєте.
Зробіть розрахунок на своїх числах
Візьміть вигаданий проєкт: 3,000 філій, по три префікси до агрегації та два концентратори на філію для резервування. Парі концентраторів треба тримати приблизно 9,000 філіальних префіксів до підсумовування, а проєкт передбачає 6,000 сесій філія–концентратор, якщо кожна філія з'єднується з обома.
Тепер додайте частини, які не є префіксами. Кожна сесія несе стан і періодичні повідомлення, навіть коли нічого не змінюється. Кожен концентратор може тримати більше одного шляху на префікс, якщо очікується швидке перемикання, тож кількість альтернатив може перевищити кількість вибраних. І вигляд кожного променя — окреме рішення політики: дати кожній філії маршрути всіх інших — означає помножити роботу так, чого підрахунок на боці концентратора не показує.
Це планові числа для розмови про проєкт, а не вимірювання якогось продукту. Корисний результат вправи — форма кривої, а не твердження про те, де конкретний маршрутизатор здається.
Що дає вам BGP і що дає IGP
BGP розділяє те, що маршрутизатор отримав, що вибрав і що анонсує, і кожним із цього керує політика. Саме це потрібно філіальній мережі, бо промінь зазвичай має бачити маршрут за замовчуванням, центральні сервіси й дуже мало чого іншого. Якщо рахувати лише підсумкову таблицю, приховуються альтернативи й анонси, а саме вони зростають, коли додаєте резервування.
IGP не обов'язково неправильний. Коли топологія, структура областей і модель сусідства підходять сервісу, протокол стану зв'язків сходиться швидко й потребує менше політичних риштувань. Пастка — припускати, що він може виразити такий самий контроль експорту на сусіда, як BGP: область OSPF — це межа затоплення, а не фільтр, який можна повісити на одну філію.
У будь-якому разі спершу визначте модель видимості. Маршрути за замовчуванням, зведення для центральних сервісів або повні деталі філій — це три різні продукти, і зведення, що приховує конкретнішу відмову, є проєктним рішенням, яке треба записати, а не виявити під час збою.
Перевіряйте хвилю, а не усталений стан
Будуйте порівняння навколо відмови, якої справді чекаєте: концентратор упав, регіональна подія WAN або вікно обслуговування, що одразу відключає половину майданчиків. Вимірюйте відновлення з погляду філії, включно з застосунком, бо площина керування, що сходиться за секунди, мало що означає, якщо сесії потрібні хвилини на відновлення.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFЗаписуйте, що платформа робить на піку хвилі, а не в спокої, і повторіть це з увімкненими функціями безпеки. Доказ концепції, що показує лише тиху таблицю, — це тест пам'яті, а пам'ять ніколи не була цікавим числом.