Resumo

  • A RFC 9107 permite ao reflector calcular interior cost a partir de uma IGP location configurada para um cliente, grupo ou reflector inteiro, em vez de sua posição física.
  • “Optimal” significa o caminho que essa perspectiva escolheria entre os mesmos candidatos e sob a policy aplicável; não garante latência, custo ou congestionamento mínimos.
  • Operação segura prova root assignment, topology epoch, candidate completeness, compute capacity, backup, anúncio recebido pelo cliente e egress na FIB.

Considere um virtual route reflector em um data centre atendendo routers de três cidades. Dois borders anunciam o mesmo prefix. Local preference, AS_PATH e outros attributes empatam; a decisão chega ao IGP cost. Para o cliente leste uma saída é próxima. Para o reflector no oeste, a outra.

O reflector responde corretamente à pergunta “qual next hop fica mais perto de mim?” e anuncia a saída oeste a todos. O cliente leste nunca vê a alternativa. Seus packets cruzam o backbone até um egress ótimo apenas para uma máquina de controle que não os encaminha.

Nenhum componente precisa estar quebrado. IGP, BGP Decision Process e session podem estar corretos. O erro está no ponto de vista. Um algoritmo exato executado na cidade errada produz a resposta errada para quem a utiliza.

A RFC 4456 reconhece o trade-off. Route reflection escala resumindo informação e normalmente refletindo só o próprio best path. Como métricas IGP variam por router, algumas topologias não repetem a escolha do full mesh. O desenho tradicional aproxima reflection topology de forwarding topology.

Centralização e virtualização afrouxam essa relação. O vRR vive onde compute e operação são convenientes, fora do data path. Sua coordenada IGP vira input acidental de traffic engineering. Mover o serviço pode alterar egresses sem qualquer update externo.

A RFC 9107 introduz uma logical IGP root, identificada por um endereço como loopback. O reflector constrói um shortest-path tree a partir dela e usa os custos até cada BGP next hop na comparação interior.

A root é viewpoint, não waypoint. Traffic não precisa passar por ela. BGP next hop, recursive resolution e FIB do cliente definem o caminho. Mostrar a root como salto físico confunde cálculo e forwarding.

Granularity pode ser por reflector, client group ou client. Uma implementação compatível precisa suportar pelo menos uma categoria. Compliance não significa precisão per-client.

Cada modo aceita aproximação. Uma root global economiza recursos e pode repetir o bias antigo. Uma regional representa o centro, não todos os edges. Uma por cliente aproxima a posição e multiplica SPFs e partes do Decision Process. Precision e capacity são uma decisão conjunta.

O alcance de optimal é limitado. No modo básico, ORR troca o custo usado no step e da Phase 2 da RFC 4271. Preferências anteriores continuam dominando. Local preference maior pode escolher o egress distante.

IGP cost não mede diretamente latency, congestion, loss, transit price ou manutenção. ORR ajuda hot-potato quando a policy anterior deixa candidatos comparáveis. A descrição correta é “mais próximo por esta métrica depois desta policy”.

Se client groups precisam de policies distintas, a RFC 9107 permite repetir mais ou todo o Decision Process. Group assignment pode delegar perspectiva topológica e comercial. Mover um cliente entre grupos pode alterar milhares de Adj-RIB-Out sem IGP event ou external UPDATE.

O mapping precisa de version, review, bounded rollout, exact diff e rollback. Não é inventory passivo; é route policy em outra forma.

O candidate set deve estar completo. O reflector não escolhe a route que o cliente escolheria se nunca a aprendeu. A RFC 9107 exige caminhos elegíveis nos reflectors e ADD-PATH entre eles para completar a visão entre clusters.

Uma capability não prova isso. Direção e AFI/SAFI precisam coincidir, o sender set precisa conter a alternativa, import policy deve retê-la e Adj-RIB-In deve mostrá-la. SPF perfeito sobre conjunto incompleto continua errado.

ORR realoca state. Entregar múltiplos paths ao edge dá decisão local com mais RIB e updates. ORR mantém candidatos ricos no centro, calcula por perspectiva e envia um resultado menor. O ganho distribuído concentra informação, CPU e confiança.

Topology também precisa de provenance. A RFC 9107 cita IS-IS, OSPF e BGP-LS. Uma database existente pode estar stale, no area errado, sem root ou divergente entre reflectors. Feed presente não é view correta.

BGP-LS transporta link state e não certifica freshness. Registre epoch, coverage, source-session health e compare com o IGP dos forwarding routers. Como RFC 7752 foi substituída pela RFC 9552, o sistema atual deve nomear a specification realmente usada.

Recursive next hop impõe outra fronteira. Se um BGP next hop resolve por BGP, interessa o IGP cost final. A RFC 9107 manda implementations incapazes de fornecê-lo tratar esses paths como least preferred nessa comparação, embora ainda valid em Phase 2. Uma route válida pode perder porque a computação não vê a recursão final.

Vendor restrictions ficam no produto. Junos documenta limites quando MPLS é a primary resolution; Cisco cita rSPF, BGP-LU e multiple IGP topologies em sua versão. Não são novas regras do RFC e precisam de teste por release e family.

Uma afirmação de “melhor caminho garantido” também não fecha a cadeia. O software pode calcular certo para a root errada, topology velha ou candidate set incompleto. Product correctness não é system correctness.

Backup roots mudam o observador. A RFC 9107 recomenda locais reserva; Junos documenta primary e backup. Quando primary some, reachability pode continuar e muitos egresses mudar. O backup precisa de predicted route-set diff, SPF switch e FIB test.

Hop-by-hop forwarding exige topology cuidadosa para evitar loops em redes com vários reflectors sem encapsulation. Uma escolha racional sob uma root pode interagir mal com o sistema completo.

Compute faz parte do control contract. Centenas de roots podem exigir centenas de árvores e decisões sobre grande tabela. Fine granularity aumenta CPU, memory, queue e convergence justamente durante falhas.

Capacity testing combina routes, clients, roots, IGP nodes e failure fan-out. Mede steady state, full recalculation, incremental change e atraso de IGP event até client advertisement. Correção apenas em laboratório tranquilo não basta.

O primeiro artefact é um perspective registry com client, AFI/SAFI, primary, backup, group, policy, owner e aproximação aceita. O segundo prova candidates e ADD-PATH. O terceiro guarda topology epoch, custos e winning step.

O quarto vem do cliente: received route, import, best reason, recursion, FIB e measured egress. Se outra fonte vence, esse running fact precisa ser explicado.

Teste group move, root loss, backup, hidden candidate, stale topology, recursion, higher policy e compute saturation. Cada cenário possui expected diff e time envelope.

Rollback restaura a perspectiva. Remover ORR pode voltar ao ponto físico do reflector, mas reverse updates precisam alterar client e FIB. Topology e candidates podem mudar durante a janela, impedindo restauração exata.

Divida authority. IGP owners validam roots; BGP owners, groups e policy; reflector operators, capacity e rollout; traffic owners, egress. Independent review deve poder contestar que uma root representa um cliente.

Minimum initial specification de Heng Lu favorece um mecanismo estreito: logical point e decision stage comuns, com granularity e adoption locais. Running-code primacy exige topology, set, advertisement, FIB e packet. Data sovereignty é poder inspecionar e contestar a decisão, não só possuir o grafo.

ORR corrige um defeito de centralização com uma centralização direcionada. Liberta o reflector de sua cidade física e transforma o root map em nova routing authority. O nome optimal não encerra a prova; os olhos usados e os packets observados encerram.

Fontes