Resumo

  • O Graceful Shutdown da RFC 8326 reduz a preferência de uma rota antes de encerrar deliberadamente uma sessão EBGP; o Graceful Restart da RFC 4724 mantém estado de encaminhamento e rotas stale durante a volta do plano de controle.
  • A ordem de mudança precisa nomear o mecanismo, declarar se o encaminhamento sobreviverá e ligar essa premissa a política, evidência de convergência, temporizadores e rollback.

Retirar tráfego ou preservar tráfego

A RFC 8326 trata da manutenção que afetará o plano de encaminhamento. Em vez de retirar a rota no mesmo instante em que a sessão cai, o iniciador usa a comunidade GRACEFUL_SHUTDOWN. A política do receptor reconhece o sinal e baixa a LOCAL_PREF, permitindo que uma alternativa seja selecionada e propagada antes do encerramento. O valor recomendado é zero.

No momento da intervenção, o iniciador marca as rotas anunciadas, baixa também a preferência das rotas recebidas pela sessão, espera a readvertência e a convergência e só depois encerra EBGP. Esse mecanismo quer esvaziar o caminho que deixará de encaminhar.

O Graceful Restart começa com outra premissa. A RFC 4724 permite preservar o encaminhamento durante um reinício de BGP. A capacidade é negociada; rotas podem permanecer temporariamente marcadas como stale; a sessão volta; novas atualizações substituem o estado antigo; e End-of-RIB encerra a reconstrução. O objetivo é continuidade limitada, não drenagem.

Portanto, Shutdown pede que o tráfego saia. Restart pede que ele continue confiando em um estado preservado. A palavra “graceful” sozinha não escolhe entre essas duas ações.

O sinal não controla o vizinho

A comunidade usada pela RFC 8326 é 65535:0. A RFC 1997 define comunidades como atributo opcional transitivo e permite que o receptor as modifique conforme sua política local. O AS iniciador comunica intenção, mas não impõe o resultado dentro do AS vizinho.

A LOCAL_PREF, descrita pela RFC 4271, é uma preferência interna; o maior valor vence e o atributo normalmente não é enviado a pares externos. O vizinho transforma o sinal recebido em sua própria decisão. A drenagem só está comprovada quando a rota alternativa aparece selecionada e instalada, não quando uma linha de configuração existe.

O sinal também não cria capacidade no caminho alternativo. Nem certifica que o equipamento em manutenção perderá o encaminhamento. Intenção, estado físico e capacidade precisam de evidências diferentes.

Rotas stale têm prazo de validade

No Graceful Restart, a retenção depende de condições negociadas. Se a sessão não voltar dentro do Restart Time, o receptor deve remover as rotas stale. Se o novo OPEN não confirmar o estado de encaminhamento pertinente, a remoção também é obrigatória. Após End-of-RIB, rotas antigas que não foram substituídas não podem sobreviver indefinidamente.

A própria RFC 4724 registra o risco de loops ou blackholes transitórios quando o encaminhamento não foi realmente preservado ou a topologia muda antes da convergência. Ver apenas a sessão BGP subir não prova continuidade. É preciso observar o plano de dados, as famílias de endereços, os temporizadores e a conclusão das atualizações.

Uma ordem de mudança testável

O registro deve dizer: qual modo será usado; o que acontecerá ao encaminhamento; qual política ou capacidade foi verificada no par; qual alternativa existe e com que capacidade; qual evento comprova a convergência; e quem pode abortar ou reverter.

Há custos de automação, telemetria, coordenação e tempo de drenagem. Eles pertencem ao operador que escolhe a mudança. Sem esse investimento, o custo passa ao cliente em perda de pacotes e à equipe técnica em uma investigação sem prova suficiente.

Fontes e fronteira da evidência

A análise usa a RFC 8326, a RFC 4724, a RFC 1997 e a RFC 4271. Elas demonstram os procedimentos normativos, mas não comprovam adoção global, uniformidade entre fornecedores, capacidade de um caminho específico ou conformidade de qualquer rede nomeada.