Resumo

  • A RFC 7313 transforma o refresh em uma janela delimitada: BoRR marca como obsoletas as rotas do vizinho para uma AFI/SAFI, os anúncios repetidos as substituem e EoRR remove somente as que continuam marcadas.
  • O procedimento depende do recebimento da capacidade Enhanced Route Refresh. Ele preserva a sessão, mas não autentica as rotas nem torna inofensivo o estado obsoleto.

Uma repetição sem fim não prova o que falta

A RFC 2918 permite solicitar que um vizinho volte a anunciar seu Adj-RIB-Out. Isso evita reiniciar a sessão apenas para aplicar certas mudanças de política. O refresh normal, porém, não tem começo e fim explícitos. O receptor vê UPDATEs chegando, mas o protocolo não informa quando a repetição completa terminou nem quando a ausência de uma rota pode ser tratada como retirada.

O problema aparece nas retiradas perdidas. Uma rota antiga pode permanecer na RIB local embora os novos anúncios estejam corretos. Sem sinal de fechamento, o operador compara estados fora de linha, infere a conclusão pelo silêncio ou reconstrói a sessão. A RFC 7313 troca essa suposição por uma sequência delimitada.

O sistema anuncia primeiro a capacidade 70. Antes da repetição, o emissor envia BoRR; depois de reanunciar todo o Adj-RIB-Out existente no início, envia EoRR. Os marcadores não certificam a verdade da rota. Eles definem quando a reconciliação começa e quando uma omissão pode justificar ação.

BoRR torna o estado provisório; EoRR encerra a autoridade

Ao receber BoRR, o receptor marca como obsoletas todas as rotas daquele vizinho na AFI/SAFI indicada, sem removê-las imediatamente. Cada reanúncio substitui a cópia marcada. Quando EoRR chega, as rotas ainda obsoletas são eliminadas de imediato. A sessão e as demais famílias ficam fora da operação.

É uma autoridade forte, porém estreita. O receptor só pode interpretar a não reaparição como retirada dentro do escopo negociado. A capacidade prova suporte aos subtipos; não autoriza mudar a política do vizinho, aceitar uma rota indesejada ou ampliar a limpeza para outras famílias.

A implementação pode estabelecer um limite local para a retenção. Se EoRR não chegar, as rotas restantes podem ser removidas quando o prazo expira. O limite impede que o provisório vire permanente, mas a RFC não define uma duração universalmente segura. O operador responde pela escolha entre continuidade e certeza.

Continuidade transfere custo

O benefício é reconciliar a RIB on-line sem derrubar a adjacência. Rotas válidas podem permanecer, retiradas ausentes aparecem e destinos sem relação evitam uma reconvergência desnecessária.

O emissor ainda repete o Adj-RIB-Out inicial da família; o receptor mantém estado obsoleto, processa o fluxo e separa replay de mudança ao vivo. Um prazo longo pode conservar uma rota errada; um prazo curto pode remover um caminho útil antes de um EoRR atrasado. Evitar reset reduz o impacto, não elimina a incerteza.

Graceful Restart cria outra fronteira. BoRR não deve ser enviado antes do End-of-RIB da mesma AFI/SAFI, e o receptor deve ignorar BoRR prematuro quando recebeu a capacidade de reinício gracioso. Um mecanismo de recuperação não pode autorizar limpeza antes que o outro conclua sua fase de estado obsoleto.

Erros não recebem poder implícito

Uma mensagem de subtipo 1 ou 2 com comprimento inválido provoca ROUTE-REFRESH Message Error, código 7 e subcódigo 1. Subtipos diferentes de 0, 1 e 2 devem ser ignorados e deveriam ser registrados. EoRR sem BoRR associado também pode ser ignorado e registrado. Um marcador desconhecido ou malformado não ganha silenciosamente poder para apagar rotas.

Evidências e limites

A RFC 7313 sustenta capacidade, marcadores, ciclo do estado obsoleto, prazo, ordem com Graceful Restart e erros. As RFCs 2918, 4271, 4724 e 5492 dão a base; a IANA confirma o código 70. A leitura em termos de autoridade delegada é análise. As fontes não provam implantação em operador nomeado, não fixam um prazo seguro universal e não garantem autenticidade ou reparo completo.

Fontes