Resumo

  • O LLST do RFC 9494 cria um segundo período de retenção por AFI/SAFI, mas o valor anunciado pelo peer não prova que next hop, FIB ou serviço permaneçam válidos.
  • Uma operação defensável liga capacidade, limite local, comunidades, seleção e propagação a evidências de pacotes e a uma saída inequívoca por EoR, expiração ou intervenção do operador.

Considere um incidente ilustrativo. A sessão BGP de um vizinho cai e o tempo do Graceful Restart comum termina. Mesmo assim, o helper conserva por mais seis horas uma rota mais específica. Ela é marcada como stale e passa a ter a menor preferência. Há uma rota agregada recente disponível. Para os destinos cobertos pelo prefixo retido, porém, o longest-prefix match ainda conduz os pacotes pelo caminho antigo. A tabela mantém uma resposta; o serviço já não a confirma.

O cenário não depende de bug. O RFC 9494 foi criado para permitir uma retenção muito mais longa quando a reconstrução do controle demora ou quando a informação BGP se parece mais com configuração distribuída do que com alcance convencional. A mesma tolerância pode preservar um black hole, uma escolha inconsistente ou um vínculo de serviço vencido.

A pergunta relevante não é se o equipamento exibe suporte a LLGR. É quem pode prolongar a consequência de uma rota aprendida no passado, quem limita o orçamento aceito e qual observação pode encerrar a tolerância antes do relógio.

A segunda fase reutiliza a primeira

O RFC 4724 define o Graceful Restart do BGP. A capability 64 transporta Restart Time e estado por família. Quando uma sessão termina, o receiving speaker pode reter temporariamente as rotas do speaker em reinício. O End-of-RIB delimita a conclusão da atualização inicial de cada AFI/SAFI.

O motivo do reset faz diferença. O RFC 8538 permite que peers que trocaram o bit N apliquem procedimentos de GR a muitas NOTIFICATION e à expiração do Hold Time. Um Cease com o subcódigo Hard Reset pede encerramento completo. A trilha de auditoria deve guardar código, subcódigo e horário, não apenas “sessão indisponível”.

O RFC 9494 adiciona a capability 71. Cada tupla contém AFI, SAFI, flags e um Long-Lived Stale Time de 24 bits. O LLST é expresso em segundos e não possui padrão universal. Alcance IP, Route Target constraints, FlowSpec e descoberta não compartilham a mesma vida segura.

LLGR não funciona como atalho independente. Se a capability LLGR chegar sem a capability GR, ela precisa ser ignorada. O mecanismo reaproveita EoR, máquina de estados e lógica de reset. Ver o código 71 em uma tela sem o 64, a família e os parâmetros bilaterais não demonstra que a retenção se aplica.

As duas fases podem ocorrer em série. Durante GR, a retenção não reduz por si só a preferência das rotas. No período LLGR, elas se tornam least preferred. Antes do restabelecimento da sessão, a borda máxima é a soma do Restart Time recebido e do LLST recebido, sujeita aos limites configurados localmente.

Qualquer fase pode durar zero. O receptor pode reduzir o LLST oferecido. O peer propõe um orçamento; o helper cria a exposição local ao aceitá-lo. Valor anunciado e valor aceito precisam aparecer separadamente em toda prova operacional.

Menor preferência ainda pode ganhar

Ao entrar em LLGR, o helper inicia um timer por AFI/SAFI e anexa LLGR_STALE. A IANA registra o valor como 0xFFFF0006, ou 65535:6. A rota deve perder para qualquer candidata que não seja least preferred. Se todas forem least preferred, voltam os critérios normais de desempate.

Depreferência não equivale a retirada. Se uma rota stale for a única candidata exata, ela ainda poderá ser best path. Se a alternativa recente cobrir apenas um prefixo menos específico, o FIB pode continuar usando a rota stale mais específica. O RFC 9494 alerta que essa situação pode eliminar a conectividade dos destinos cobertos.

Num núcleo iBGP com encaminhamento hop-by-hop, a diferença de visão cria outro risco. Cada roteador observa suas próprias sessões. Um pode depreferir a rota; outro ainda pode tratá-la como fresca. As escolhas divergentes podem fazer os pacotes circular entre os dois. O RFC não recomenda LLGR para esses conjuntos de rotas.

Encaminhamento por túneis limita essa classe de loop, mas não certifica o destino. A resolubilidade exigida pelo RFC 4271 continua valendo. O RFC 9494 cita BFD como sinal adicional possível para a viabilidade do next hop. BFD não comprova a aplicação nem toda a cadeia de serviço.

LLGR adia a retirada; não autentica origem, não autoriza prefixo, não comprova programação de hardware e não garante entrega. A presença no RIB continua sendo uma afirmação do plano de controle.

Uma rota pode recusar a retenção longa

NO_LLGR, registrado como 0xFFFF0007 ou 65535:7, identifica rotas que não devem entrar no período prolongado. O próprio speaker pode anexá-lo, ou uma política local pode fazê-lo. Quando LLGR começa, essas rotas precisam ser removidas segundo o comportamento normal.

A comunidade é um canal de política, não uma assinatura. O RFC 1997 define Communities como atributo de caminho. O valor não autentica quem o escreveu. Políticas intermediárias podem substituir, retirar ou acrescentar comunidades; por isso, received e advertised precisam ser preservados em cada fronteira relevante.

Rotas LLGR_STALE não deveriam ser anunciadas a vizinhos que não tenham anunciado LLGR. A restrição mantém o estado antigo dentro de um perímetro capaz de entender a menor preferência. Reter localmente e propagar são decisões diferentes.

Há uma exceção estreita para implantação parcial. Um speaker pode anunciar a um vizinho iBGP ou de confederação sem LLGR se anexar NO_EXPORT e definir LOCAL_PREF como zero. O AS deve manter o mesmo tratamento. A finalidade é coerência de seleção, não mera decoração de atributos.

O retorno da sessão não renova a dívida

O bit F por família informa se o estado realmente foi preservado no reinício anterior. Ele não é um indicador geral de saúde. Se a sessão restabelecida omitir a família, não marcar F ou deixar de apresentar as capabilities GR e LLGR necessárias, o helper deve apagar imediatamente as rotas stale daquele AFI/SAFI.

Reinícios sucessivos não recarregam o timer livremente. Sem intervenção manual, um LLST em andamento não é atualizado até que o peer estabeleça e sincronize uma nova sessão. A sincronização acontece por família com EoR ou com a expiração do Selection_Deferral_Timer.

O LLST continua correndo depois de Established até a chegada de EoR. Se vencer durante a sincronização, as rotas não refrescadas precisam ser retiradas. Uma sessão verde pode coexistir com um conjunto stale que encolhe. A pergunta correta é quais rotas retornaram no prazo, não apenas se o vizinho voltou.

EoR encerra a atualização inicial de uma família; não prova o plano de dados. Uma rota renovada ainda pode falhar na resolução, ficar fora do FIB, referenciar um label vencido ou terminar num serviço indisponível. Conclusão de protocolo e resultado para o usuário exigem provas distintas.

Quando o estado se parece com configuração

BGP também distribui Route Target constraints, FlowSpec, descoberta e estado de VPN. A reconstrução pode ser demorada, e a retirada imediata pode gerar churn ou perder configuração ainda útil. Uma janela longa pode ser racional quando o estado inferior continua válido.

Mesmo assim, o RFC 9494 exige habilitação afirmativa por AFI/SAFI e proíbe ativação padrão. LLGR não é uma melhoria universal de disponibilidade. É uma exceção que depende do significado da informação, do modelo de encaminhamento e da menor vida segura entre suas dependências.

Em MPLS VPN, a dependência pode ser um label. Uma rota stale pode continuar apontando para um label retirado. Se o PE o reutilizar para outra VPN antes de todos os ingress abandonarem a rota antiga, a falha cruza a fronteira de isolamento. O RFC exige que o menor prazo de reutilização seja superior ao maior LLST.

As documentações atuais de Cisco, Juniper e Nokia também impõem prova por produto e versão. Cisco separa stale time enviado e aceito. Juniper distingue receiver, restarter, família, política e clear manual. Nokia mostra famílias e estados próprios do SR OS. Nenhum padrão de um fabricante vale como regra universal.

A trilha de uma retenção stale

Primeiro, preserve os dois OPEN ou uma saída de vizinho autoritativa: GR, LLGR, AFI/SAFI, Restart Time, LLST e bits N/F. Registre o valor anunciado ao lado do limite aceito. Eles representam decisões de partes diferentes.

Depois, registre causa e subcódigo do reset, fim de GR e começo de LLGR. Por rota, mostre a adição de LLGR_STALE, a exclusão NO_LLGR, a decisão Loc-RIB e os anúncios enviados. Uma comunidade visível sem seu efeito de política é evidência incompleta.

A terceira camada é o encaminhamento: resolução recursiva, FIB ou estado de serviço, label e encapsulamento quando necessários, além de pacotes ou sondas de aplicação durante a janela. Best path sem resultado observado continua sendo intenção.

Por fim, associe EoR, expiração ou clear às rotas não refrescadas que saíram. Com serviço restaurado, prove a nova publicidade; sem restauração, prove a retirada até as fronteiras materiais. O dono do limite e do rollback precisa estar definido antes do incidente.

Fontes