Три тысячи филиалов звучат как задача маршрутизации, но ведут себя как задача бухгалтерии. Сумма префиксов считается за десять минут, и это редко та цифра, которая болит. Болит работа на каждую сессию, волна обновлений при отказе общего компонента, и время до того, как пересылка снова совпадёт с новой топологией.

Поэтому проходите арифметику в правильном порядке. Посчитайте связи, посчитайте префиксы и альтернативы, затем посчитайте, что происходит в плохой час, и только после этого сравнивайте протоколы и платформы. В обратном порядке упражнение превращается в спор о лимитах маршрутов, который никто не может закрыть информацией на столе.

Четыре бюджета, а не один

Каждый бюджет отвечает на свой вопрос, и каждый может быть ограничивающим фактором на другой платформе. Записанные отдельно, они не дают одной большой цифре префиксов заменить весь проект.

BudgetWhat you are really counting
SessionsPeers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count
PrefixesAlternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see
ChurnUpdates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event
RecoveryTime 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

Записывайте, что платформа делает на пике волны, а не в покое, и повторите это с включёнными функциями безопасности. Доказательство концепции, показывающее только тихую таблицу, — это тест памяти, а память никогда не была интересной цифрой.

Похожие статьи