Resumo

  • BGP Graceful Restart permite que um vizinho compatível retenha rotas durante o reinício da sessão, mas esse estado de controle não comprova sozinho que o roteador continua encaminhando o tráfego afetado.
  • A proteção operacional é um recibo por família que vincula capacidades, temporizadores, continuidade observada de pacotes, End-of-RIB e destino final das rotas obsoletas.

Considere uma manutenção explicitamente hipotética. Um roteador reinicia o BGP, o vizinho mantém os prefixos aprendidos e o painel mostra recuperação organizada em vez de retirada imediata. Mesmo assim, o tráfego de uma família para. O vizinho continua escolhendo a rota obsoleta até que um temporizador ou evento posterior a remova. O mecanismo criado para esconder uma breve interrupção de controle fez a falha durar tanto quanto a retenção.

Isso não prova defeito no Graceful Restart. Mostra que recuperação do controle e preservação do encaminhamento foram tratadas como uma coisa só. O protocolo coordena a primeira; o uso seguro exige que a segunda permaneça verdadeira enquanto o vizinho age sobre informação obsoleta.

O que a capacidade realmente anuncia

A RFC 4724 define a capacidade Graceful Restart. Restart State informa que o emissor reiniciou. Para cada AFI/SAFI, Forwarding State informa se o estado de encaminhamento foi preservado. A promessa não cobre automaticamente toda a plataforma.

Quando o estado não foi preservado para uma família, a RFC 4724 exige remover suas rotas obsoletas. Quando a preservação foi indicada, o ajudante pode mantê-las durante o retorno da sessão e a atualização das rotas. Essa diferença é a fronteira de segurança.

Restart Time estima o retorno da sessão. O ajudante também usa um limite local de retenção. Nenhum valor mede continuidade de pacotes; eles limitam por quanto tempo o plano de controle confia na declaração de preservação.

End-of-RIB encerra outra pergunta

Após o retorno, End-of-RIB mostra que a atualização inicial da família terminou. Rotas atualizadas permanecem e as não atualizadas podem sair. Isso encerra a reconciliação de roteamento, não comprova a entrega durante o intervalo anterior.

Retorno da sessão, End-of-RIB e tráfego bem-sucedido são três observações. Resumi-las como “reinício concluído” impede saber se o serviço foi protegido ou se apenas uma rota ficou instalada.

Retenção longa aumenta o ônus da prova

A RFC 9494 acrescenta Long-Lived Graceful Restart. Ela define retenção mais longa e a marca LLGR_STALE, e recomenda reduzir a preferência dessas rotas para que uma alternativa possa vencer. Isso ajuda quando o encaminhamento realmente sobrevive; também prolonga uma suposição errada quando a preservação terminou.

Um temporizador longo não é sempre incorreto. Ele, a preferência e o caminho alternativo precisam de evidência da plataforma e topologia operadas. Uma família ou placa não valida outra.

Uma NOTIFICATION não comprova encaminhamento

A RFC 8538 permite aplicar Graceful Restart após determinadas mensagens BGP NOTIFICATION. A mensagem pode explicar por que a sessão terminou e qual procedimento o vizinho seguirá, mas não comprova que pacotes atravessaram o equipamento durante o evento. A ausência de retirada pode ser o comportamento solicitado ao ajudante, não um resultado de entrega.

Criar um recibo por família

Registre os pares, AFI/SAFI, capacidades, Restart State, Forwarding State, Restart Time, limite local, política LLGR e caminho alternativo. Acrescente horários de perda e retorno da sessão, primeiro pacote bem-sucedido, End-of-RIB e retirada ou atualização final.

A observação deve representar o serviço. Ping de loopback não comprova prefixos de clientes nem outra tabela. Sucesso IPv4 não valida IPv6; uma placa, FIB, VRF ou grupo de serviço não valida outro. O recibo deve corresponder à família, plataforma, tabela e tráfego cujo estado o ajudante retém.

Fontes