Resumo

  • RFC 2918 permite solicitar o Adj-RIB-Out atual de um peer capaz para um AFI/SAFI negociado; o peer preserva sua própria export policy.
  • RFC 7313 delimita a repetição com BoRR e EoRR, marca entradas antigas como stale, substitui as que voltam e remove as ausentes no fim.
  • Comando bem-sucedido ou sessão estável não prova efeito: prefixes, attributes, seleção, FIB e tráfego precisam ser comparados.

Um operador corrige um inbound filter que rejeitava duzentos prefixes legítimos. O commit entra, mas os anúncios descartados não reaparecem por vontade própria. Sem cópia bruta, a nova regra não tem inputs para julgar.

Uma policy mais restritiva sofre o mesmo problema: as rotas já aceitas podem continuar em estado local até uma nova avaliação. O arquivo pode estar correto e a RIB ainda representar a decisão anterior.

Inbound soft reconfiguration guardava todos os updates sem alteração, inclusive os rejeitados. Isso dava independência local para reprocessar, ao custo permanente de memória e CPU.

RFC 2918 troca a localização desse custo. Capability code 2 informa que o speaker recebe ROUTE-REFRESH. O requester só envia depois de receber a capability do peer e escolhe um AFI/SAFI negociado.

O peer reanuncia o Adj-RIB-Out atual conforme seu outbound filtering. O solicitante não lê banco remoto nem exige rota filtrada. Ele ouve de novo apenas o que o vizinho decide exportar hoje.

Não é arquivo histórico. Rotas antigas podem ter sido retiradas, novos caminhos podem existir, atributos e policy remota podem ter mudado. A saída combina dois presentes.

Por isso, contagem não atribui causa. Quinhentas rotas a menos podem vir do novo filtro local, de withdraw remoto ou de export diferente. Prefixes e attributes exatos, com tempo, são necessários.

RFC 2918 básico não marcava o começo e o fim de uma repetição completa. UPDATE normais podiam se misturar; a ausência temporária não dizia se uma rota sumiu ou ainda viria.

RFC 7313 cria Enhanced Route Refresh, code 70. BoRR abre a época; EoRR fecha. Ao receber BoRR, o receptor marca stale todas as rotas daquele peer e AFI/SAFI. As que voltam substituem entradas; EoRR remove as restantes.

O fluxo continua vivo. Mudanças durante o ciclo podem ser anunciadas. EoRR prova conclusão da época, não correção de cada rota nem restauração do passado.

O receptor pode impor limite local para stale e limpar sem esperar indefinidamente. Um limite curto demais, porém, remove rotas saudáveis durante replay lento.

EoRR difere do End-of-RIB do Graceful Restart. Um fecha reanúncio; outro coordena continuidade de control plane. RFC 7313 separa os dois para impedir limpeza prematura.

Inbound e outbound soft reset têm donos diferentes. Inbound pede replay remoto ou usa cópia local; outbound regenera anúncios próprios. A mesma palavra “soft” não significa a mesma fonte de estado.

Documentação Cisco mostra três caminhos: refresh dinâmico com capability, reprocessamento de cópia armazenada ou hard reset quando nenhum existe. O último derruba a session e amplia o dano a toda a reachability.

A escolha contrapõe recurso e dependência. Armazenar input compra autonomia com memória. Route Refresh economiza estado contínuo, mas depende do peer e de seu export atual. Hard reset expande o blast radius.

FRRouting observa que controles que precisam contar rotas rejeitadas ainda podem exigir soft-reconfiguration inbound. Pedir o fluxo atual não cria inventário durável para qualquer finalidade.

RFC 5291 define ORF como capability separada. O receptor pode comunicar alguns filtros ao sender, mas ROUTE-REFRESH comum não edita a política remota.

Antes da mudança, registre basic e enhanced capability anunciada e recebida por sentido e AFI/SAFI. Suporte local não prova resposta do vizinho; suporte básico não prova BoRR/EoRR.

Crie baseline com prefix/attribute, conjunto aceito, best paths, policy version, uptime e FIB next hop. Se as rotas rejeitadas forem invisíveis, declare a lacuna.

Comece com um peer e uma família. Registre request, BoRR, EoRR e duração. Observe ausência de fim, stale timeout, CPU, reset, withdraw e mudança de best path.

Compare conjuntos, não totais. Dez remoções e dez inclusões mantêm o número. Aggregate e more-specifics mudam escala. Community alterada pode mudar resultado sem mudar NLRI.

Verifique forwarding. Uma rota aceita pode perder seleção, ter next hop sem resolução ou conduzir a enlace sem capacidade. Refresh entrega input, não pacotes.

Rollback também requer replay. Restaurar o texto antigo não restaura decisões automaticamente. Se o peer mudou seu export, retornar à fotografia exata pode ser impossível.

Automação deve limitar concorrência. Refresh de muitos peers produz UPDATE e recomputação. “Soft” evita teardown deliberado; não elimina trabalho.

A especificação mínima de Heng Lu aparece no pedido estreito: peer, família, reanúncio. Cada AS conserva policy. Running-code primacy exige capability negociada, época observada, RIB diff e FIB, não a mensagem de sucesso.

Route Refresh separa correção de policy e destruição de sessão. Não separa correção e prova. Só as rotas que voltaram, foram julgadas e alteraram forwarding mostram autoridade efetiva da regra nova.

Sources