Resumo

  • Route Refresh pede ao vizinho que reanuncie um AFI/SAFI sem reiniciar o BGP; Enhanced Route Refresh pode marcar início e fim da repetição.
  • BoRR e EoRR comprovam limites do intercâmbio, não a versão da configuração, o sentido da política, a seleção, o FIB ou a entrega.
  • A conclusão exige um recibo que una commit, refresh, prefixo controlado, encaminhamento, tráfego, exceções e rollback.

O protocolo termina antes da pergunta operacional

Imagine uma alteração de política de importação para rejeitar uma rota conhecida de um provedor. A plataforma registra o commit. O roteador solicita Route Refresh; chegam Beginning-of-RIB, os anúncios e End-of-RIB. A sequência parece limpa e o chamado é encerrado.

Uma checagem encontra o prefixo controlado ainda selecionado em um edge. Os marcadores podem estar corretos. O erro foi interpretar “o vizinho terminou de reanunciar” como “a política local entregou o resultado esperado”.

A RFC 2918 criou Route Refresh para reaplicar políticas sem reiniciar a sessão BGP. A capacidade é anunciada na abertura. Depois, a mensagem identifica AFI e SAFI, e o vizinho reanuncia o estado de saída dessa família.

A mensagem não transporta hash da política local, transação de configuração, aprovador nem resultado obrigatório para um prefixo. Ela inicia uma ação de protocolo, não certifica intenção operacional.

O limite preciso de BoRR e EoRR

A RFC 7313 acrescenta Enhanced Route Refresh. Beginning-of-RIB e End-of-RIB delimitam o conjunto reanunciado e ajudam o receptor a tratar estado obsoleto que não reaparece.

Essa evidência é específica: o refresh daquele vizinho e daquela família começou e terminou. Não demonstra que a nova configuração estava ativa antes do primeiro UPDATE, que alcançou toda a frota ou que foi aplicada na direção correta. Também não comprova instalação no FIB ou entrega de pacotes.

Um refresh IPv4 unicast não reconcilia IPv6, VPN ou outro SAFI. Uma sessão não cobre outro peer, refletor ou grupo de edges. Usar um EoRR como sinal verde de toda a rede elimina o escopo que dá significado ao marcador.

Importação e exportação pedem provas diferentes

A RFC 4271 separa rotas recebidas, rotas escolhidas no Loc-RIB e rotas preparadas para anúncio. Após mudança de importação, o receptor precisa de novos anúncios para reaplicar regras. Após mudança de exportação, o emissor precisa mostrar que usou a nova política para o vizinho nomeado.

São cadeias distintas. O peer repete seu estado de saída enquanto o equipamento local refaz o processamento de entrada. Um refresh não atesta as intenções de configuração dos dois lados.

A RFC 5291 acrescenta Outbound Route Filtering. Capacidade ORF, tipo, modo e estado instalado são controles separados. Observar um refresh posterior não prova que o filtro esperado estava presente e atual.

Um prefixo controlado conecta as camadas

Uma alegação de rejeição na importação deve ser verificada na rota recebida e no resultado da política. Uma alegação de nova melhor rota exige Loc-RIB. Uma alegação de mudança de tráfego exige FIB, resolução de próximo salto e teste representativo.

Essas visões podem divergir. Um prefixo rejeitado de um peer pode chegar por outro. Uma rota pode vencer no BGP e falhar na resolução. Um FIB pode existir enquanto túnel, ACL ou falha a jusante impede o serviço. Route Refresh não foi projetado para condensar tudo em um indicador.

Escolha um prefixo com resultado esperado conhecido. Registre estado antes do commit, durante BoRR–EoRR e depois: origem, peer, AS path, atributos, motivo de decisão e próximo salto. Complete com tráfego compatível com a família e o serviço afetados.

Esse limite preserva a utilidade do mecanismo. Um refresh concluído é evidência forte de repetição de um conjunto delimitado. Com evidências vizinhas, a equipe distingue versão errada, distribuição parcial, família incorreta, capacidade ausente, ORF divergente ou falha de encaminhamento após uma decisão BGP correta.