Summary

  • BGP End-of-RIB informa o fim da atualização inicial de uma família após o estabelecimento da sessão; não é certificado global para todos os AFI/SAFI.
  • Graceful Restart permite reter rotas marcadas como stale enquanto o encaminhamento continua. Substituição, remoção, seleção local, FIB e viabilidade do plano de dados continuam sendo provas distintas.
  • É preciso um recibo por peer e família que una causa do reinício, capacidade negociada, conjunto retido, EOR, limpeza, FIB e testes reais de caminho.

A sessão voltou antes das evidências

Considere uma sessão BGP restabelecida após reinício. O EOR de IPv4 unicast chega e o monitor muda a sessão para verde. Ao mesmo tempo, outra família ainda contém rotas retidas da sessão antiga, e um fluxo usa uma entrada de encaminhamento criada antes do reinício.

Não há contradição. O primeiro EOR encerra a atualização inicial de uma família específica. Não fala pelas demais famílias negociadas nem testa se o encaminhamento preservado continua viável. O erro não é confiar em EOR; é ampliar um fato de protocolo delimitado até virar veredito de atualidade para toda a rede.

Isso é tentador porque Graceful Restart existe para preservar continuidade. Reter encaminhamento evita churn e perdas transitórias. Porém, o mesmo mecanismo cria um período em que “ainda encaminha” e “foi validado novamente” são estados diferentes.

O que EOR realmente encerra

A RFC 4724 define EOR de IPv4 unicast como UPDATE sem NLRI alcançável nem retirado. Para outras famílias, usa MP_UNREACH_NLRI sem rotas retiradas para o <AFI, SAFI> específico. O speaker envia o marcador ao concluir a atualização inicial daquela família, inclusive quando não há atualização a transmitir.

O escopo está na codificação. Um EOR IPv4 não declara nada sobre IPv6, VPN, EVPN ou outra família. Mesmo na família indicada, diz que o emissor terminou o que pretendia enviar. O receptor ainda deve aplicar updates, substituir rotas stale, apagar as restantes, executar seleção local e programar forwarding.

A RFC também separa a geração de EOR da capacidade de preservar forwarding. Um speaker pode anunciar Graceful Restart sem família alguma apenas para informar que produzirá EOR e apoiará um peer em reinício. Capability ou marcador não provam que ele preservou estado utilizável.

O bit Restart State resolve outro problema de coordenação. O speaker em reinício o ativa no novo OPEN, e o peer não deve esperar o EOR desse speaker antes de voltar a anunciar rotas para ele. Restabelecida a sessão, o speaker adia a seleção de uma família até receber EOR dos peers relevantes ou até expirar Selection_Deferral_Timer. Só então seleciona rotas, atualiza o encaminhamento, remove seu próprio estado stale e envia o EOR da família. Um horário de EOR sem essa sequência mistura o fim das atualizações dos peers com a conclusão do encaminhamento local.

Rotas retidas são explicitamente stale

Ao detectar a perda de sessão de um peer que anunciou Graceful Restart para uma família, o receptor retém as rotas dessa família e as marca stale. Durante o encaminhamento, não as diferencia das demais. É continuidade deliberada, não declaração de atualidade.

As regras de limpeza fornecem o relógio. Se a sessão não volta dentro de Restart Time, as rotas retidas são removidas. Após o retorno, também são apagadas de imediato quando a nova capability omite a família, o bit Forwarding State não está ativo ou a capability não chega. Novos updates substituem rotas stale; ao receber EOR da família, o receptor remove qualquer resto stale.

Assim, importam a identidade e o destino das rotas, não a cor do painel. Antes de EOR pode haver rotas aguardando substituição. EOR cria o limite para limpar o restante. Depois dele, seleção local e FIB ainda precisam produzir um resultado utilizável.

Viabilidade de forwarding é outra observação

O bit Forwarding State por família trata da preservação do encaminhamento durante o reinício. A RFC 4724 o vincula à preservação real, com ressalva de configuração. Não é um teste de pacote. A RFC deixa fora de escopo o mecanismo que decide se o forwarding do peer ainda é viável, citando BFD e monitoramento de camada 2 apenas como exemplos.

Um next hop preservado pode falhar enquanto as rotas seguem retidas. O FIB local pode atrasar em relação ao RIB. Pode haver blackhole ou loop mesmo depois do retorno da sessão e de EOR. No sentido inverso, a marca stale não prova falha: o estado retido pode cumprir exatamente a função de continuidade.

A RFC 8538 estende o tratamento graceful a certas NOTIFICATION e ao fim de Hold Time quando os peers trocam o bit N. Ambos passam a agir como receptores e retêm as rotas do outro. Hard Reset pede reinício total. Quando o bit N foi trocado, a regra que apagava uma rota já stale em reinícios consecutivos é relaxada; o stale timer passa, portanto, a ser o limite essencial contra retenção indefinida. A extensão exige esse timer configurável, sugere 180 segundos e alerta para problemas de retenção longa ou infinita.

Fontes