Resumo

  • RFC 1267 mandava a tabela BGP inteira no início e apenas mudanças depois; cada speaker precisava, portanto, guardar a versão corrente da tabela do par durante a conexão.
  • RFC 4271 tratou o fechamento como retirada implícita. RFC 4724 abriu uma exceção negociada, por AFI/SAFI, na qual rotas stale sobrevivem até substituição, End-of-RIB ou expiração.
  • RFC 8538 criou o limite explícito de Hard Reset e um timer obrigatório; RFC 9494 exigiu marca LLGR, preferência mínima, propagação limitada e ativação afirmativa para uma retenção ainda mais longa.

O primeiro envio financiava todos os seguintes

RFC 1267 descrevia o BGP-3 como uma troca assimétrica no tempo. Depois de estabelecer o transporte e concluir as mensagens iniciais, os dois speakers enviavam a tabela de roteamento BGP completa. O tráfego posterior levava somente incrementos.

Economizar repetições exigia conservar contexto. Uma mudança não explica sozinha o estado ao qual se aplica. Cada speaker tinha de manter a versão corrente da tabela de cada par enquanto a conexão durasse. A memória era parte do significado do protocolo, não apenas um cache conveniente.

A mesma frase também delimitava a validade. KEEPALIVE testava a conexão. Um erro levava a NOTIFICATION e encerramento; a máquina de estados liberava recursos da conexão e caminhava de volta para Idle ou Active.

Esse registro não era uma identidade durável, um direito sobre prefixos ou uma autorização permanente. Era entrada do plano de controle, recebida de um par em uma conversa definida. Sessão viva não provava rota correta; linha retida não provava FIB correspondente; nenhum dos dois provava entrega.

O fechamento quitava a memória normal

RFC 4271 separou Adj-RIBs-In, Loc-RIB e Adj-RIBs-Out. Aprender uma rota, escolhê-la localmente e prepará-la para anúncio tornaram-se recibos conceitualmente distintos.

Também enumerou três formas de retirar uma rota: NLRI explicitamente retirado, substituição por uma nova rota ou fechamento da conexão BGP. No terceiro caso, todas as rotas anunciadas pelo par são implicitamente removidas de serviço.

Ao fechar por erro, a implementação limpa a Adj-RIB-In ligada à conexão, invalida escolhas locais dependentes daquele par, recalcula melhores rotas e anuncia retiradas ou substitutas. Isso não diz que o equipamento vizinho deixou de existir. Diz que a evidência de controle daquela sessão deixou de ser corrente pela regra básica.

Uma entrada de encaminhamento talvez ainda sobreviva por algum intervalo. Essa persistência pertence a outra camada. O simples fato de não ter sido apagada não renova a autoridade do anúncio que a originou.

Graceful Restart emitiu uma validade temporária

RFC 4724 permitiu atravessar o término e a reabertura do TCP quando o processo BGP reiniciava, mas o estado de encaminhamento talvez continuasse. A permissão começa em Graceful Restart Capability e é delimitada por famílias AFI/SAFI.

Suporte à capability, Restart State e Forwarding State são campos independentes. Entender a extensão não significa estar reiniciando. Estar reiniciando não significa ter preservado encaminhamento. Declarar preservação não comprova o percurso de um pacote.

O receptor só pode conservar rotas das famílias negociadas e precisa marcá-las stale. A palavra registra que a rota perdeu sua confirmação de sessão e está sendo usada sob tolerância. Não é selo de qualidade.

O prazo pode acabar de várias formas. Se a sessão não retorna dentro de Restart Time, as rotas stale são removidas. Se a nova sessão não confirma encaminhamento, não inclui a família ou não anuncia a capability, a remoção é imediata. UPDATEs novos substituem os registros antigos correspondentes.

End-of-RIB fecha a prestação de contas. Mesmo quando uma família não tem rotas, um UPDATE vazio pode declarar que a carga inicial terminou. Depois dele, toda rota ainda stale naquela família deve ser descartada. O timer mede a chance de restabelecer; End-of-RIB mede o fim da substituição inicial. Não são o mesmo relógio.

RFC 4724 alerta para loops ou blackholes transitórios e para benefício reduzido quando IGP e BGP reiniciam juntos sem continuidade compatível. Completar a troca de controle, manter encaminhamento e recuperar serviço continuam sendo resultados separados.

Hard Reset recusou a renovação

RFC 8538 negociou o bit N para aplicar Graceful Restart após NOTIFICATION ou expiração de Hold Time quando ambos os pares concordaram. Dessa forma, certas falhas puderam receber tratamento graceful sem transformar toda falha em candidata automática.

Cease/Hard Reset preserva a decisão oposta: aplicar o reset completo da regra básica. A causa registrada na notificação e a ação de não conservar o estado precisam permanecer separadas. Hard Reset não descobre sozinho a causa raiz, mas cancela a autorização de memória.

O documento tornou obrigatório um timer configurável para rotas stale, sugeriu 180 segundos e proibiu retenção infinita como padrão. Um relógio sem vencimento permitiria que reinícios repetidos renovassem indefinidamente uma rota nunca confirmada de novo.

LLGR alongou o prazo e a exposição

RFC 9494 criou Long-Lived Graceful Restart para continuar além do Restart Time normal. O helper adiciona a community transitiva LLGR_STALE; rotas NO_LLGR ficam de fora; as retidas recebem a menor preferência e, em regra, não seguem para pares sem LLGR.

Long-Lived Stale Time é definido por AFI/SAFI e pode ser reduzido localmente. Cada família exige configuração afirmativa, e o recurso não pode vir habilitado por padrão. A duração extra precisa ser uma escolha observável.

O alerta é direto: uma rota stale de longa duração usada para alcançabilidade convencional pode provocar perda de conectividade. Menor preferência só ajuda quando existe alternativa. Limitar propagação diminui o alcance do risco, mas não verifica next hop, política, encaminhamento ou resultado do usuário.

Fontes