Теоретические основы и архитектура
Конвергенция IGP определяет скорость восстановления сервисов при авариях. Стандартные таймеры Hello/Dead в OSPF (10с/40с) или IS-IS неприемлемы для операторского SLA: при тихом отказе трафик теряется до 40 секунд. Для субсекундного обнаружения сбоев на уровне физических линков и оптоволоконных трасс применяется BFD (Bidirectional Forwarding Detection, RFC 5880). BFD работает независимо от IGP с миллисекундными интервалами (например, передача каждые 50-100 мс с множителем 3) и на многих платформах выносится на линейные карты (ASIC/NPU). При трёх потерянных пакетах (Detection Time = 150-300 мс) BFD переводит сессию в состояние Down и сразу уведомляет клиентский протокол (OSPF, IS-IS, BGP, LDP); итоговое время восстановления складывается из обнаружения, SPF и перепрограммирования FIB. Одновременно с этим правильный расчёт метрик линков ядра позволяет настроить ECMP (Equal-Cost Multi-Path): если метрики основного и резервного путей равны, трафик распределяется между ними с помощью хэширования потоков (IP 5-tuple / MPLS entropy).
Метрика как инженерное решение
IGP выбирает путь с минимальной суммой метрик, поэтому метрика - единственный рычаг управления трафиком в ядре без TE. В OSPF стоимость интерфейса по умолчанию считается как reference-bandwidth / bandwidth, где reference-bandwidth равен 100 Мбит/с (Cisco, Huawei, Junos - одинаково). Любой интерфейс быстрее 100 Мбит/с получает cost 1: 1G, 10G и 100G становятся "равными", и IGP считает 1G-линк равноценным 100G-линку. Исправление - увеличить reference-bandwidth на всех узлах одновременно (Cisco auto-cost reference-bandwidth 100000, Huawei bandwidth-reference 100000, Junos reference-bandwidth 100g); либо задавать cost на интерфейсах вручную. Если значение изменено лишь на части узлов, стоимости одного и того же линка в двух направлениях разойдутся, а пути станут асимметричными.
| Скорость линка | cost при 100 Мбит/с | cost при 100 Гбит/с | cost при 1 Тбит/с |
|---|---|---|---|
| 1G | 1 | 100 | 1000 |
| 10G | 1 | 10 | 100 |
| 100G | 1 | 1 | 10 |
| 400G | 1 | 1 | 2 |
Результат деления усекается до целого и не может быть меньше 1, поэтому для сетей 100G/400G берут 1 Тбит/с (1000000 на Cisco). Поле метрики интерфейса в Router-LSA имеет 16 бит (до 65535), в IS-IS wide - 24 бита на линк и 32 бита на путь. Для IS-IS reference-bandwidth не существует: метрика по умолчанию 10 для любого интерфейса, и её всегда проектируют вручную.
Принципы разметки
Метрика отражает не "красоту", а политику: либо обратную пропускную способность, либо задержку (для длинных трасс), либо административное предпочтение. Основной линк PE1-P1 получает 10, резервный PE1-P2 - 50: пока основной жив, резервный не нужен, при отказе трафик уходит на резерв без дополнительных действий. Симметрия: метрика одного линка должна быть одинакова с обеих сторон, иначе прямой и обратный пути разойдутся, а трассировка и SLA-измерения будут вводить в заблуждение. Равные метрики на нескольких путях дают ECMP: трафик делится между всеми путями с равной суммарной стоимостью.
ECMP распределяет потоки, а не пакеты: хэш по 5-tuple (src/dst IP, порты, протокол) выбирает один путь на поток, чтобы не переупорядочивать пакеты. Для MPLS-трафика LSR хэширует стек меток и, на многих платформах, заголовок IP под ним; для псевдопроводов добавляют flow-label (RFC 6391) или entropy label (RFC 6790). Максимум равноценных путей зависит от платформы: на Cisco IOS-XE maximum-paths по умолчанию 4 (до 32), на Huawei настраивается maximum load-balancing. В Junos несколько next-hop устанавливаются в RIB, но в FIB балансировка включается только политикой load-balance per-packet в forwarding-table export (название исторически вводит в заблуждение - на современных платформах хэш считается per-flow). Типичная проблема - polarization: на всех hop-ах используется одинаковая хэш-функция, поток снова выбирает одну сторону, и часть линков остаётся пустой.
BFD: что именно измеряет
BFD (RFC 5880, одно-hop: RFC 5881) - лёгкий протокол двунаправленного обнаружения отказа, независимый от среды и от IGP. Контрольные пакеты идут по UDP на порт назначения 3784 (multi-hop - 4784, echo - 3785). Сессия проходит Down -> Init -> Up по трёхстороннему обмену, а в пакете передаются Desired Min TX, Required Min RX, Detect Mult и различители (My/Your Discriminator). Время обнаружения в асинхронном режиме: Detect Mult удалённой стороны × максимум из своего Required Min RX и удалённого Desired Min TX. Для 100 ms × 3 это 300 мс; при несовпадении интервалов действует более консервативный. До перехода в Up пакеты идут не чаще 1 раза в секунду (slow start).
BFD не вычисляет маршруты. Он сообщает зарегистрированным клиентам (OSPF, IS-IS, BGP, LDP, статические маршруты) о смерти сессии, и клиент сразу рушит соседство, не дожидаясь dead timer (40 с в OSPF по умолчанию, 30 с hold-time в IS-IS). Если клиент не зарегистрирован (на Cisco нет ip ospf bfd), BFD-сессия может быть Up, но маршрутизация обнаружит обрыв только по обычному таймеру.
Бюджет сходимости
Полное время потери трафика = обнаружение сбоя + генерация и флудинг LSA/LSP + задержка SPF + пересчёт и запись в FIB. При BFD 300 мс обнаружение занимает 300 мс, генерация LSA и SPF с throttling (initial 50 мс) добавляют 50-100 мс, флудинг и установка FIB - ещё десятки миллисекунд; итого 400-600 мс вместо 40 с у OSPF по умолчанию. Для сравнения: fast hello в OSPF (dead-interval minimal hello-multiplier 4, 4 Hello в секунду) даёт около 1 с, но нагружает CPU на всех интерфейсах; carrier-delay msec 0 на Cisco и hold-time up ... down 0 на Junos ускоряют реакцию на явное падение линка, но не помогают при "тихом" отказе через L2-сегмент или транспондер. Именно для скрытых отказов нужен BFD.
