Resumo

  • RFC 3277 usa o bit Overload para manter um roteador IS-IS fora do trânsito enquanto protocolos associados, como BGP, recuperam estado; “N segundos após o boot” é apenas um possível gatilho local.
  • O relógio não prova que o self-LSP pertence à encarnação atual, que o conjunto de rotas exigido chegou, que next hops foram resolvidos, que a FIB foi programada ou que pacotes alcançaram o serviço.

No desenho do RFC 3277, RtrB era o caminho mais curto entre RtrA e uma rede externa atrás de RtrD. Quando RtrB falhou, RtrA passou a usar RtrC. Esse desvio já tinha uma FIB completa e rotas externas aprendidas por BGP. RtrB voltou; IS-IS recuperou adjacências rapidamente; o custo baixo tornou RtrB atraente de novo. BGP, porém, ainda não conhecia o destino D.1. Os pacotes retornaram antes das rotas e foram descartados.

O RFC, publicado em abril de 2002 como Informational, propõe um uso operacional de um mecanismo já existente. O roteador que volta mantém o LSP Overload durante a recuperação. Outros sistemas preservam alcance aos prefixos diretamente conectados, mas não calculam caminhos de trânsito por ele. Depois, um novo LSP limpa o bit.

O texto deixa o disparador ao implementador. Um timer é uma das sugestões. Isso não transforma o tempo em evidência de completude.

O timer mede a espera, não o trabalho concluído

Um período fixo pode ser uma proteção simples. Ele evita liberar trânsito imediatamente e funciona sem instrumentação sofisticada. Seu limite está naquilo que observa: somente a passagem do tempo.

Durante o mesmo intervalo, um peer pode não estabelecer sessão, uma address family pode ficar ausente, route policy pode rejeitar um prefixo fundamental, next-hop resolution pode falhar ou o hardware pode atrasar programação. O timer termina sem enxergar nenhum desses estados.

O valor também envelhece. Crescimento da tabela, CPU mais ocupada, mudança de reflectors, novos filtros ou um software diferente alteram o tempo necessário. Um intervalo obtido em um teste antigo ganha autoridade permanente se ninguém conservar a medição que o justificou.

Usar um número de prefixos na Loc-RIB, outra possibilidade citada pelo RFC, aproxima o gatilho de BGP, mas não resolve identidade. A mesma contagem pode representar outro conjunto. Rotas sem importância podem preencher a meta enquanto default, infraestrutura ou um cliente crítico continuam ausentes. Presença na Loc-RIB não prova resolução nem FIB.

Gatilhos simples continuam úteis quando a organização limita a reivindicação. O recibo deveria registrar o peer e AFI/SAFI esperados, as rotas obrigatórias, a versão ou digest do conjunto, next hops, comparação RIB/FIB, capacidade de caminho e um teste controlado. Se o timer for uma salvaguarda máxima, que não seja apresentado como certificado de BGP.

Uma corrida pode liberar o roteador antes do timer começar a importar

O antigo LSP de RtrB pode continuar nas bases IS-IS depois que ele some. Ao voltar, RtrB forma adjacências. RtrA e RtrD geram novos LSPs que anunciam essas relações. RtrB talvez ainda não tenha gerado o seu novo LSP com Overload.

O domínio junta arestas novas ao registro antigo do nó e executa SPF. Cada peça tem origem plausível, mas o grafo cruza duas encarnações do processo. O timer que deveria proteger a recuperação não ajuda se o estado Overload atual ainda não chegou e o LSP anterior foi reativado.

Por isso RFC 3277 recomenda atualizar e inundar o self-LSP imediatamente a cada adjacência, antes da sincronização da base. A ordem garante que a advertência atual chegue antes que o anúncio do vizinho transforme memória antiga em decisão corrente.

“Adjacency UP” não é “self-LSP atual recebido”. “LSP não expirado” não é “estado desta vida”. Auditoria precisa de boot identity, sequência e origem, ordem de adjacências, recibo de flooding, geração usada por SPF e rota resultante.

O loopback precisa sobreviver à quarentena de trânsito

Enviar um LSP vazio parece mais seguro, mas normalmente remove o alcance ao loopback usado por sessões iBGP. O roteador ficaria incapaz de reconstruir o protocolo que deveria torná-lo pronto.

Overload expressa um estado intermediário: o próprio nó pode ser destino, porém ainda não é corredor. O bit dá ao domínio uma instrução estreita. Não explica a causa, não prova que forwarding foi preservado e não certifica saúde geral.

Limpar o bit também tem significado estreito: readmitir o nó no cálculo de trânsito. Concluir “serviço restaurado” exige recibos posteriores.

O RFC 3137 oferece contexto OSPF semelhante e já possui cobertura própria em BTW. Essa peça anterior é dona de MaxLinkMetric, manutenção de alcance próprio e comportamento de caminho único. Este artigo não repete essa tese; seu objeto é o timer como autoridade imperfeita e a composição entre nova adjacência e LSP da vida anterior.

Fail closed pode remover a única rota

Com Overload, nenhum caminho de trânsito é calculado pelo roteador. Em uma topologia redundante, RtrC sustenta o tráfego enquanto RtrB se recupera. Se RtrB for o único caminho para nós downstream, o mesmo mecanismo pode deixar nenhum caminho factível.

A política conservadora em relação à integridade pode ser agressiva contra disponibilidade. A escolha precisa ser explícita: aceitar um caminho possivelmente incompleto ou ficar sem caminho. Não existe um timer universal que elimine o trade-off.

Mesmo quando o diagrama mostra alternativa, capacidade e independência não estão provadas. O desvio pode compartilhar falha, estar congestionado, aplicar outra policy ou ter FIB igualmente incompleta.

RFC 3277 também alerta para loops se sistemas do domínio não implementarem Overload corretamente. Autenticação confirma a origem do LSP dentro do modelo usado; não comprova interpretação uniforme ou estado do hardware.

O SA bit retém a nova aresta

RFC 5306 padronizou restart signaling para IS-IS em 2008. RFC 8706 o substituiu em 2020 e separa restart com forwarding mantido de start sem forwarding preservado.

No start, LSPs da encarnação anterior podem permanecer e parecer mais novos do que os primeiros LSPs após reinicialização de sequence numbers. O Restart TLV dispõe do bit SA: o roteador pede aos vizinhos que suprimam a publicidade da adjacência. Enquanto não receberem uma IIH com SA limpo, não anunciam a aresta e não a usam em SPF.

RFC 3277 tenta fazer o novo LSP Overload vencer a corrida. RFC 8706 também permite segurar a aresta que tornaria o velho LSP utilizável. O avanço reforça que geração e ordem são parte da segurança do cálculo.

Um planned restart só pode manter topologia se forwarding realmente sobrevive. Sinalizá-lo sem esse estado é proibido pelo RFC mais recente porque a mensagem não cria a FIB perdida.

Nenhuma publicação comprova suporte universal. Versão, configuração, timers, mistura de capacidade e comportamento em falha precisam de validação local.

Recuperação rápida não funde os estados

BGP Graceful Restart pode preservar algumas rotas durante retomada do controle. IP Fast Reroute pode selecionar reparo local. Ordered FIB convergence pode sequenciar atualizações. Cada mecanismo trata uma fronteira diferente.

Uma rota stale não identifica o LSP IS-IS corrente. Um repair path não completa a tabela BGP. Uma sequência correta não instala informação ausente. FIB populada não prova entrega ao destino.

O registro defensável mantém separado: encarnação, custódia de forwarding, adjacência, self-LSP, flooding, Overload, sincronização IS-IS, peers e conjunto BGP exigido, resolução, FIB, admissão controlada, pacote observado, resultado e rollback.

A doutrina de Heng Lu no pacote de fontes favorece um núcleo comum mínimo e autoridade verificada no estado executado. Aqui, o padrão pode dar semântica interoperável a “não me use para trânsito”. A decisão local sobre quando retirar essa condição continua sendo local e deve continuar auditável.

O roteador não fica pronto porque o relógio venceu. Fica pronto para uma função quando as evidências dessa função, na encarnação corrente, satisfazem a política assumida pela rede.

Incerteza

O artigo analisa textos de protocolo, não um incidente nomeado, vendor ou levantamento de implantação. RFC 3277 afirma que a técnica havia sido usada em várias redes IS-IS grandes, mas não identifica redes nem mede ganhos. Suporte a RFC 8706, tempos, conjunto esperado, programação de FIB e capacidade alternativa devem ser verificados no ambiente específico. Nenhum volume de perda ou melhoria é atribuído.

Fontes