Кратко

  • BGP PIC связывает множество префиксов с общими иерархическими объектами next hop; при покрываемом отказе изменение нескольких pathlist или указателей заменяет перепрограммирование FIB для каждого префикса.
  • Быстрое переключение требует, чтобы пригодный альтернативный путь был изучен, выбран и установлен до инцидента. Вторая route или другой BGP next hop сами по себе не доказывают физическую независимость, ёмкость и наличие состояния в оборудовании.
  • Управление должно охватывать всю предварительную авторизацию: видимость кандидатов, пригодность, shared fate, полномочия детектора, аппаратную иерархию, наблюдаемые пакеты и возврат к стабильному состоянию.

В 02:14 ingress PE теряет предпочтительный выход. BGP ещё обрабатывает VPN routes, а route reflectors не закончили распространять новое состояние. Тем не менее трафик сотен тысяч префиксов уже выходит через другой PE.

Операторы спрашивают, почему сеть так быстро сошлась. Важнее спросить, кто выбрал новый путь. Возможно, в момент аварии его никто не выбирал: решение было принято за несколько часов до неё.

Маршрутизатор уже получил альтернативу, признал её допустимой согласно policy, разрешил next hop и связал с общими forwarding objects. Когда detector объявил основную зависимость непригодной, forwarding plane изменила несколько указателей, а не каждую destination entry.

Такова точная граница BGP Prefix Independent Convergence. Название не обещает независимость всей конвергенции от масштаба. Оно означает, что одна локальная стадия — активация подготовленного резерва после обнаружения покрываемого отказа — может не расти вместе с числом затронутых BGP prefixes.

На дату публикации основным текстом IETF остаётся draft-ietf-rtgwg-bgp-pic-23. Это активный Internet-Draft с предполагаемым статусом Informational: незавершённая работа, не RFC и не новый протокол обмена. Он описывает внутреннюю архитектуру из иерархической FIB, recursive resolution и заранее рассчитанных backups.

В плоской FIB каждый prefix leaf может содержать копию полных данных пересылки. Если 500 тысяч routes разрешаются через один egress, его изменение может потребовать 500 тысяч обновлений. В иерархии листья указывают на общую BGP pathlist, затем на разрешённый IGP object и в конце на adjacency, интерфейс или stack меток.

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

Следовательно, prefix independent — заявление о масштабировании с чёткой границей. Failure detection занимает время. Reflector может скрыть альтернативу. Control plane продолжает отзывать, выбирать и объявлять. Удалённые routers сходятся отдельно. Обратный путь может не работать, а backup — не выдержать нагрузку. PIC исключает число префиксов из одной локальной стадии, но не из всей аварии.

Скорость оплачивается предварительным расчётом. Пока primary здоров, защищающий router должен иметь альтернативу, допустимую по policy, достижимую, достаточно отличающуюся для нужного failure domain и установленную в hardware chain. Аварийное решение отчасти является историческим.

Меняется и аудит. При обычном выборе после отказа видны UPDATE, победившие attributes и новая запись FIB. PIC требует проверять спящее намерение. Backup может не использоваться неделями, а при активации полагаться на старую оценку topology, policy и ресурсов.

Сначала доказывают поставку кандидатов. Draft упоминает ADD-PATH, best-external, diverse-path и разные Route Distinguishers в некоторых VPN. Это возможные каналы получения альтернатив, а не одинаковые гарантии.

Route reflection может убрать путь до его попадания на PE. Строки ADD-PATH capability тоже недостаточно: важны направление send/receive, AFI/SAFI, политика отправителя, количество paths, import policy и фактическая Adj-RIB-In. Кандидат доказывается на устройстве переключения.

Затем оценивается пригодность. Текущая документация Nokia SR Linux требует для Edge PIC валидного, достижимого кандидата с BGP next hop, отличным от primary, и выбирает лучший обычным BGP decision process. Это ясное правило продукта, но не сертификат независимости.

Два next-hop address могут разрешаться через одно волокно, line card, tunnel, помещение электропитания или provider. Два PE могут зависеть от общего service node. Логическое различие не устраняет общее физическое будущее.

Разнообразие нужно определять для конкретного failure class. Второй интерфейс может защитить от порта, но не от потери всей карты. Второй path через тот же PE не защищает от отказа PE. Две сессии к одному provider не доказывают коммерческую или географическую независимость.

Core PIC и Edge PIC показывают слой ремонта. При Core PIC BGP next hop остаётся достижимым, а IGP или transport path под ним меняется через общий recursive object. При Edge PIC исчезает egress next hop и активируется другой заранее рассчитанный BGP next hop, возможно с другой VPN label, tunnel или service path.

Термины и охват неодинаковы у разных продуктов. Address family, service, software release, ASIC и line card проверяются отдельно. Draft подчёркивает, что выгода связана с forwarding-plane design, а не с изменением BGP protocol.

Ключ активации находится у detector. Физический сигнал, interface state, IGP adjacency, BGP session и BFD наблюдают разные сбои. RFC 5880 вычисляет BFD Detection Time независимо для каждого направления из согласованных intervals и multiplier. Значения могут различаться.

Надпись «BFD 50 ms» скрывает эту асимметрию. Агрессивные timers также несут риск. Congestion, control-plane starvation, filtering или атака могут удалить легитимные BFD packets. Ложные down и up способны вызвать denial of service. Чем меньше пропусков достаточно для решения, тем больше власть детектора над массовым трафиком.

Сигнал должен покрывать реальную зависимость. Local carrier быстро видит прямой обрыв, но не удалённую black hole. Single-hop BFD проверяет adjacency, а не весь service. Путь multi-hop probe следует сравнивать с защищаемым трафиком.

IGP summarisation тоже скрывает отказ. RFC 9929 определяет Unreachable Prefix Announcement, поскольку component prefix под summary может стать недостижимым без отзыва summary, и называет BGP PIC среди задач быстрой конвергенции. Это не всеобщий мандат на UPA. Это доказательство того, что точка решения не ремонтирует невидимую зависимость.

Аппаратная иерархия образует ещё одну границу. Draft предполагает несколько уровней indirection. Ограниченная platform может flatten цепочку при программировании, дублируя state и уменьшая sharing. Это расходует FIB и может вернуть per-prefix work в некоторые сценарии.

Поэтому два routers с одинаковой RIB могут реагировать по-разному. Один меняет общую pathlist, другой переписывает множество плоских entries. Обещание измеряется для каждой platform, line card, release, route family и encapsulation.

В L3VPN альтернативный egress может требовать другую VPN label и иной LDP или Segment Routing stack. Смена next hop с устаревшей меткой даёт быстрый неправильный результат. Проверка должна доходить до реальной adjacency и исходящей инкапсуляции.

Заранее рассчитанный state стареет. Изменение import, withdrawal, resolution, label, частичной reachability или давления на аппаратные ресурсы может сделать его непригодным. Самый опасный backup — не отсутствующий, а устаревший и всё ещё помеченный ready.

Нужно фиксировать время получения candidate, последней проверки eligibility, FIB programming и topology/policy epoch, обосновавшей состояние. После существенного изменения standby chain проверяется снова. Наличие в RIB не доказывает свежесть.

Ёмкость входит в разрешение. Path может быть loop-free и reachable, но слишком мал. Если много primaries делят один standby, один отказ концентрирует огромную нагрузку. При одновременных сбоях отдельно пригодные backups могут столкнуться. Transit или peering contract также может запрещать технически допустимый путь.

RFC 5714 разделяет local repair и distributed convergence. Fast reroute переносит пакеты, пока protocols распространяют отказ и строят конечное состояние. Repair — мост, а не обязательно финальный маршрут.

Измерять следует шесть часов: detection, доставка события, FIB activation, первый успешный packet, control-plane convergence и окончательная steady-state FIB. Одно число «конвергенции» стирает ответственность и не доказывает доставку.

Data-plane probes должны фиксировать interface, next hop и label stack до, во время и после переключения. Обратное направление испытывается отдельно: stateful firewall, NAT и service chain могут потерять сессию при идеальном прямом failover.

Матрица испытаний включает local link, remote transport, egress PE, BGP session, задержанное или ложное BFD, предварительный withdrawal backup, изменение policy, давление на FIB, рестарт line card и возвращение primary. Для каждого случая заранее задаются detector, object, ожидаемый backup, loss budget и final state.

False positive мгновенно отправляет огромный prefix set в непригодный путь. False negative оставляет мнимую защиту, когда backup не попал в hardware или trigger связан не с тем object. Общий state одновременно создаёт эффективность и умножает ошибку.

Поэтому выбор и сертификацию разделяют. Routing задаёт eligibility; transport подтверждает физическое разделение; platform owner показывает настоящую FIB; service owner проверяет ёмкость и оба направления; независимый reviewer разрешает расширение.

Первый операционный артефакт — protection matrix по failure class, route family, platform и service: primary dependency, candidate source, backup, diversity evidence, detector, timer, hardware object, capacity и owner.

Второй — dormant-state ledger, различающий backup в RIB и backup в hardware. Третий — временная трасса, связывающая detector event, изменение pathlist и наблюдаемые пакеты, включая переход от repair к converged state.

Возврат primary требует такого же контроля. Немедленный возврат может вызвать reordering, oscillation или вторую потерю. Hold-down, период проверки или одобренный revert безопаснее. Rollback — не выключение PIC, а восстановление доказанного стабильного состояния.

Принцип minimum initial specification Лу Хэна соответствует этой архитектуре: общий механизм остаётся узким, а route families, platforms, failure classes и timers оператор выбирает локально. Running-code primacy задаёт порядок доказательств: config, RIB и FIB — утверждения; packet — результат.

Практический data sovereignty означает возможность просмотреть, проверить, состарить и отменить заранее рассчитанное решение в proprietary hardware. Владение config repository без видимости спящего backup даёт лишь символический контроль.

BGP PIC переносит работу из аварии в мирное время. Чтобы механизм оставался управляемым, туда же нужно перенести доказательства. Происхождение, разнообразие, trigger, аппаратная реализация, ёмкость и срок годности backup должны быть известны до тревоги.

Источники