Кратко

  • RFC 9107 позволяет reflector считать interior cost от настроенной IGP location для клиента, группы или всего reflector, а не от своего физического положения.
  • «Optimal» — маршрут, который эта перспектива выбрала бы из тех же допустимых кандидатов под данной policy; это не гарантия минимальных latency, cost или congestion.
  • Безопасность доказывает root assignment, topology epoch, полноту кандидатов, compute capacity, backup, полученный клиентом путь и egress в FIB.

Virtual reflector в data centre обслуживает routers трёх городов. Два borders объявляют один prefix. Local preference, AS_PATH и ранние attributes равны, решение доходит до IGP cost. Восточному client ближе восточный выход, западному reflector — западный.

Reflector правильно отвечает «какой next hop ближе ко мне?» и посылает запад всем. Восточный клиент не видит альтернативу. Его packets пересекают backbone к egress, оптимальному только для control-plane машины без forwarding.

Компоненты не сломаны. IGP, Decision Process и session корректны. Ошибочна перспектива. Точный algorithm из неправильного города стабильно выдаёт неверный для пользователя результат.

RFC 4456 признаёт цену scaling. Route reflection суммирует информацию и обычно отражает собственный best path. IGP metrics различаются по routers, поэтому некоторые topologies не повторяют full mesh. Традиционный дизайн сближает reflection и forwarding topology.

Центральные vRR ослабили связь. Они живут вне data path там, где удобен compute. Их IGP position становится случайным traffic-engineering input. Перенос сервиса способен изменить egresses без external UPDATE.

RFC 9107 задаёт logical IGP root — node в link-state topology, идентифицированный, например, loopback. Reflector строит rooted shortest-path tree и использует cost до BGP next hops при внутреннем сравнении.

Root — viewpoint, а не waypoint. Traffic не обязан идти через неё. BGP next hop, recursive resolution и client FIB создают реальный путь. Нельзя описывать root как физический hop.

Granularity бывает на reflector, client group или client. Совместимому implementation достаточно одной категории. Compliance не обещает per-client precision.

Каждый режим — приближение. Одна root дешева и сохраняет старый bias. Региональная точна для центра, не краёв. Per-client точнее и умножает SPF и Decision Process. Precision оплачивается capacity.

Optimal ограничен. Базовый ORR меняет cost на шаге e Phase 2 RFC 4271. Более ранние policies сохраняют власть. Высокая local preference может выбрать далёкий выход.

IGP cost не равен latency, congestion, loss, transit price или maintenance risk. ORR поддерживает hot potato после предшествующей policy. Верное утверждение — «ближайший допустимый по этой метрике».

Если groups требуют разных BGP policies, RFC 9107 разрешает повторить больше или весь Decision Process. Group assignment делегирует топологическую и коммерческую перспективу. Перемещение клиента может изменить тысячи Adj-RIB-Out без IGP event или external update.

Mapping — production policy с version, review, bounded rollout, exact diff и rollback.

Candidate set должен быть полным. Reflector не выберет route, которой не знает. RFC 9107 требует все eligible paths и ADD-PATH между reflectors для полноты между clusters.

Capability не является доказательством. Нужны правильные direction и AFI/SAFI, sender set, import policy и реальный Adj-RIB-In. Идеальный SPF по неполному множеству остаётся неправильным.

ORR перераспределяет state. Multiple paths до edge дают local decision ценой RIB и updates. ORR держит candidates в центре, считает по perspectives и отправляет меньше. Экономия распределённого состояния концентрирует информацию, CPU и trust.

Topology требует provenance. RFC 9107 называет IS-IS, OSPF и BGP-LS. Database может быть stale, ограничена неправильным area, не иметь root или расходиться между reflectors. Feed не доказывает верный view.

BGP-LS переносит link state, но не удостоверяет freshness. Записывайте epoch, coverage, source-session health и сравнение с IGP forwarding routers. RFC 7752 заменена RFC 9552, поэтому фактическая specification должна быть названа.

Recursive next hop создаёт границу. Если BGP next hop разрешается через BGP route, нужен final IGP cost. RFC 9107 требует от implementation без него считать path least preferred в сравнении, сохраняя valid в Phase 2. Допустимая route может проиграть из-за невидимой рекурсии.

Vendor restrictions не являются protocol. Junos документирует ограничения MPLS resolution; Cisco — rSPF, BGP-LU и multiple IGP topologies. Проверка нужна по release и family.

Обещание «гарантирует best» не закрывает цепочку. Software может правильно считать для неверной root, старой topology или неполного set. Product correctness не равна system correctness.

Backup roots меняют наблюдателя. RFC 9107 рекомендует backup locations, Junos имеет primary и backup. Reachability может сохраниться, а множество egresses смениться. Backup требует predicted route-set diff, SPF и FIB test.

Hop-by-hop forwarding с несколькими reflectors без encapsulation требует тщательной topology, чтобы не создать loops. Рациональный выбор одной root не гарантирует системную безопасность.

Compute входит в контракт. Сотни roots означают множество SPF trees и решений над большой table. Fine granularity увеличивает CPU, memory, queue и convergence во время сбоя.

Capacity test соединяет routes, clients, roots, IGP nodes и failure fan-out. Измеряются steady state, full recalculation, incremental event и время от IGP change до client advertisement. Лабораторной тишины недостаточно.

Первый artefact — perspective registry: client, AFI/SAFI, primary, backup, group, policy, owner и допустимое приближение. Второй доказывает candidates и ADD-PATH. Третий хранит topology epoch, costs и winning step.

Четвёртый идёт от client: received route, import, best reason, recursion, FIB и measured egress. Если победил другой source, этот running fact объясняется.

Тестируйте group move, root loss, backup, hidden candidate, stale topology, recursion, higher policy и compute saturation. Каждому сценарию нужны expected diff и time envelope.

Rollback возвращает перспективу. Удаление ORR может вернуть физическую позицию reflector, но reverse updates должны изменить client и FIB. Изменившиеся topology или candidates могут сделать точное восстановление невозможным.

Разделите authority. IGP owners проверяют roots, BGP owners — groups и policy, reflector operators — capacity, traffic owners — egress. Independent reviewer должен оспаривать заявление, что root представляет client.

Minimum initial specification Heng Lu поддерживает узкий механизм: logical point и decision stage общие, granularity и adoption локальны. Running-code primacy требует topology, set, advertisement, FIB и packet. Data sovereignty — возможность проверить и оспорить решение.

ORR исправляет дефект централизации более направленной централизацией. Он освобождает reflector от физического города и превращает root map в новую routing authority. Доказательство закрывает не слово optimal, а использованная перспектива и наблюдаемые packets.

Источники