Теоретические основы и архитектура
Даже при мгновенном IP FRR в ядре сходимость BGP остаётся самой медленной частью сервиса: отказ egress PE или его линка к CE обнуляет сотни тысяч VPN-префиксов, и без оптимизаций каждый из них перепрограммируется отдельно, из-за чего время потерь растёт с числом префиксов и достигает секунд и десятков секунд. Prefix Independent Convergence (PIC) устраняет эту зависимость: FIB иерархична, тысячи префиксов указывают на общий объект BGP next-hop, а тот - на путь IGP, поэтому смена пути обновляет один указатель независимо от числа префиксов. PIC Core реагирует на отказ в ядре, PIC Edge переключает на заранее установленный резервный BGP-путь. Чтобы резервный путь вообще существовал, RR должен его отдать: используйте уникальные RD, BGP Add-Path (RFC 7911), best-external и мультипуть. Урок объясняет иерархическую FIB, добавление путей, ECMP в VPNv4 и таймеры MRAI, next-hop tracking и scan interval. Предполагается знание iBGP, RR и L3VPN из предыдущих модулей.
Почему BGP сходится медленно
В классической схеме каждый VPN-префикс имеет в FIB собственный next-hop, а отказ egress PE означает один и тот же next-hop для сотен тысяч записей. Маршрутизатор должен обработать withdraw или потерю next-hop для каждого префикса, заново выбрать лучший путь и перепрограммировать FIB. Если запись обновляется за 10-50 мкс, то 500 тысяч префиксов дают от нескольких секунд до десятков секунд потерь, а на программных платформах ещё больше. Время растёт линейно с числом префиксов, и именно эту зависимость убирает PIC.
Иерархическая FIB и PIC Core
При PIC FIB становится двухуровневой (на практике это "chain"/indirect next-hop): префикс указывает на общий объект BGP next-hop (адрес PE2), а этот объект - на путь IGP до PE2 (метка транспорта, интерфейс). Если сломался путь внутри ядра, меняется только нижний объект, например, ECMP-набор до 10.255.0.2: десятки тысяч префиксов не трогаются. Эта защита называется PIC Core: время переключения не зависит от числа префиксов и определяется скоростью IGP/IP FRR. Она не требует дополнительных путей BGP и обычно включена по умолчанию на современных платформах, но зависит от платформы и версии ПО.
PIC Edge и резервный путь
PIC Edge отвечает на отказ egress PE или его линка к CE. Для него нужен установленный в FIB резервный путь: объект BGP next-hop хранит основной и backup next-hop (PE2 и PE3), и при потере PE2 все префиксы переключаются указателем на PE3. Резервный путь должен быть доступен в таблице BGP, а его next-hop - достижим и не должен пересекаться с основным (в идеале - другой PE). Триггером служит исчезновение /32 next-hop в IGP: поэтому loopback PE нельзя суммировать на границах областей, иначе PE1 не увидит отказ и будет ждать hold timer BGP (по умолчанию 180 с у Cisco, 90 с у Junos), что решается в следующем уроке через BGP-LU и необобщённые /32.
Откуда берётся второй путь
RR выбирает один лучший путь на префикс и отражает только его, если не настроено иначе, поэтому клиент не видит запасной. Варианты. Первый: уникальный RD на VRF и PE (65000:2 и 65000:3): NLRI различаются, оба маршрута отражаются как разные VPNv4, а импорт по RT складывает их в VRF. Это самый простой и повсеместно поддерживаемый способ, но он увеличивает таблицу VPNv4 в RR (каждый префикс умножается на число PE). Второй: BGP Add-Path (RFC 7911): capability 69 согласует send/receive на уровне AFI/SAFI, а в NLRI добавляется 4-байтовый Path Identifier, который делает каждый путь отдельным "ключом" (префикс + path ID); implicit withdraw работает на уровне пары, а не префикса. RR выбирает N лучших или все пути (например, best 2) или diverse-путь (RFC 6774), чтобы второй путь не шёл через тот же отказывающий узел. Третий: best-external - PE, чей лучший путь внутренний (от RR), всё равно объявляет внешний (от CE). Add-Path требует поддержки на RR и на клиентах и увеличивает память и нагрузку на обновления, поэтому выбирайте число путей осознанно.
Мультипуть и ECMP в VPNv4
При равенстве local-pref, длины AS-path, origin, MED и метрики IGP до next-hop iBGP-мультипуть (maximum-paths ibgp, multipath) устанавливает в VRF несколько путей и распределяет трафик по ним (балансировка по потоку, не по пакетам). Для разных RD пути попадают в VRF как независимые импортированные маршруты, и мультипуть работает на уровне VRF. Равенство метрик IGP обычно не выполняется для PE2 и PE3, поэтому ECMP потребует равных метрик или поддержки unequal-cost (Junos: vpn-unequal-cost, Huawei: load-balancing и др.). Мультипуть и PIC дополняют друг друга: при ECMP отказ одного пути убирает лишь его долю потока.
Таймеры BGP
MRAI (Minimum Route Advertisement Interval) ограничивает частоту объявлений одним соседям: для eBGP по умолчанию 30 с, для iBGP у Cisco обычно 0 (на других платформах значения отличаются). Большой MRAI замедляет фоновую сходимость, но не влияет на PIC-переключение. Next-hop tracking (NHT) - событийная реакция BGP на изменения в RIB: bgp nexthop trigger delay по умолчанию 5 с (Cisco), и для быстрой сходимости его уменьшают до 0 (или 1-2 с) на PE. Scan interval (bgp scan-time, 60 с в классических реализациях) проверяет достижимость next-hop периодически; сегодня его роль выполняет NHT, поэтому полагаться на сканер нельзя. Hold timer BGP (например 180 с у Cisco) нужен как последний уровень защиты. Отдельно BFD (single-hop на линках) и IGP следят за ядром, а BGP за достижимостью next-hop. Учтите, что ускорение за счёт малых таймеров увеличивает нагрузку на CPU при флапах: используйте dampening/RIB flap защиту.
