Resumo

  • O HoldTimer tradicional mede a chegada de mensagens BGP válidas; ele pode permanecer renovado mesmo quando UPDATEs, retiradas e KEEPALIVEs locais estão bloqueados no sentido oposto.
  • A RFC 9687 acrescenta um SendHoldTimer configurado localmente. Sem uma transmissão BGP bem-sucedida no intervalo, o roteador registra a causa, libera recursos, fecha TCP e volta a Idle.
  • Uma implantação segura separa geração, avanço de envio, processamento remoto e encaminhamento, usa valor maior que o HoldTime negociado e limita ciclos de reconexão.

O roteador de borda já retirou uma rota falha de sua decisão local e produziu a retirada para o par. Mesmo assim, o vizinho envia KEEPALIVE a cada trinta segundos, reiniciando o HoldTimer. No sentido contrário, a aplicação remota não lê o fluxo TCP. A fila local cresce e a última rota entregue continua orientando tráfego no outro AS.

Não falta uma decisão correta. Falta a capacidade de torná-la compartilhada.

Bidirecional não significa progresso simétrico

TCP oferece um fluxo em cada direção, mas uma pode avançar enquanto a outra para. O exemplo clássico da RFC 9687 é uma janela remota de recepção igual a zero. O par ainda consegue escrever em direção ao roteador local, embora não aceite bytes dele. Sobrecarga, leitor travado ou fila interna defeituosa criam a mesma assimetria.

Na RFC 4271, receber UPDATE ou KEEPALIVE reinicia o HoldTimer. Isso prova atividade de entrada, não entrega no sentido inverso. Gerar UPDATE não prova saída; gravar no buffer do kernel não prova leitura remota; TCP Established não prova que o processo BGP consome mensagens.

Uma retirada bloqueada preserva autoridade para uma rota obsoleta. Por isso, o instante da última transmissão BGP bem-sucedida é tão importante quanto a última mensagem recebida.

O relógio local da RFC 9687

A RFC 9687 inclui SendHoldTime, SendHoldTimer e o evento 29 SendHoldTimer_Expires. O valor é política local por par, e não uma capacidade negociada. O vizinho não precisa implementar o recurso para que o emissor bloqueado proteja sua sessão.

Ao entrar em Established vindo de OpenConfirm, o temporizador começa se SendHoldTime não for zero. Cada mensagem BGP enviada com sucesso o reinicia. Ele para ao sair de Established ou quando SendHoldTime ou o HoldTime negociado é zero. Qualquer valor não nulo deve ser maior que o HoldTime negociado.

A recomendação é habilitar por padrão e usar o maior entre oito minutos e duas vezes o HoldTime. Isso não torna todos os pares iguais. Refletores, servidores de rotas, trânsito e equipamentos limitados têm cargas e custos de reinício diferentes.

Na expiração, é obrigatório registrar Send Hold Timer Expired, liberar recursos BGP, fechar TCP, atualizar a retomada e transitar para Idle. A NOTIFICATION só pode ser tentada se não atrasar o encerramento. A IANA atribui código 8, subcódigo 0. Como o bloqueio pode impedir a entrega do aviso, o registro local é essencial.

Cada detector responde a uma pergunta

HoldTimer observa recepção BGP. SendHoldTimer observa progresso de envio BGP. BFD testa continuidade do caminho de encaminhamento. Retransmissão e keepalive TCP tratam do transporte. Resultados diferentes podem estar todos corretos.

BFD e TCP podem permanecer saudáveis, e KEEPALIVEs de entrada podem renovar HoldTimer, enquanto SendHoldTimer expira porque nenhuma mensagem local avança. A investigação deve manter quatro fatos separados: recebimento local, envio local, processamento remoto da rota e encaminhamento de pacotes.

O SendHoldTimer não detecta todo zumbi BGP e não demonstra falha de dados. Ele limita a espera diante de incapacidade persistente de transmitir.

Fechar a sessão também custa

O reset invalida rotas aprendidas, aciona nova seleção, FIB e anúncios alternativos. A reconexão pode transferir a tabela completa. Expirações simultâneas em refletor ou servidor de rotas formam uma onda de convergência.

Um valor curto transforma atraso passageiro, contrapressão ou janela zero breve em corte evitável. Se o receptor continuar sobrecarregado, reconexões e tabelas completas aumentam a pressão e criam oscilação. Um valor longo prolonga rotas obsoletas.

A escolha deve considerar HoldTime, pausas medidas, rajadas de UPDATE, CPU, volume de rotas, filas e custo de retomada. Classes de pares merecem margens próprias. Amortecimento pode reduzir tentativas, mas não conserta capacidade insuficiente.

O canário deve manter o caminho ativo

Desligar a interface testaria BFD ou HoldTimer antes do mecanismo pretendido. O ensaio válido conserva o caminho e BGP de entrada, enquanto impede de forma controlada a leitura remota.

O BIRD 3.3.0 documenta disable rx somente para testes e alerta contra uso em produção. Em laboratório isolado, registre antes versão, HoldTime, SendHoldTime, estado e filas normais. Durante a falha, prove KEEPALIVEs contínuos, parada do último envio, fila ou janela zero e uma retirada controlada presa.

Na expiração, capture causa, tempo, tentativa de NOTIFICATION, fechamento TCP e Idle. Depois, verifique reconexão sem ciclo, rota corrigida, FIB e pacotes. A lista do FRRouting e a opção do BIRD são alegações de implementação; o build implantado precisa de prova própria.

Autoridade e custódia de evidência

Quem pode derrubar uma interconexão crítica deve guardar última mensagem gerada, último envio bem-sucedido, idade e profundidade da fila, janela TCP, retransmissões, entradas, histórico do temporizador e motivo final. Também deve identificar retiradas presas, duração da visão obsoleta e convergência posterior.

Esses dados costumam estar no daemon, sistema operacional, coletor, portal do par e NOC. Soberania prática é poder uni-los, retê-los e decidir. Autoridade sem evidência é arbitrária; evidência sem direito de agir não corrige a rota.