Resumo

  • O tempo de recuperação depende do número de LSPs, da capacidade de sinalização e da velocidade de mudança. Um temporizador comum não produz risco comum entre sessões estáveis e dinâmicas.
  • Estado preservado continua sendo estado provisório. Ele precisa ser reconciliado com o par, protegido contra reutilização concorrente e confirmado por observação do plano de dados.

A fila invisível atrás do mesmo rótulo

No primeiro enlace, uma sessão direcionada troca poucas associações e passa longos períodos estável. No segundo, a descoberta LDP reage à topologia e às decisões do IGP. Os dois perdem TCP por trinta segundos. O painel mostra a mesma ocorrência; a fila de trabalho que se forma atrás dela é completamente diferente.

RFC 3612 liga a velocidade de recuperação ao número de LSPs, ao rendimento do canal e à taxa de mudança. RFC 3479 pode confirmar operações frequentemente ou usar checkpoints mais espaçados. O primeiro reduz a cauda recente não confirmada, com custo operacional maior. O segundo simplifica a implementação, mas deixa mais diferenças para reconstruir.

Publicado em setembro de 2003 como RFC Informativa da IETF, RFC 3612 compara o graceful restart de RFC 3478 com a tolerância a falhas de RFC 3479. Não é relato de implantação nem garantia de resultado. A especificação LDP RFC 3036 citada à época foi depois substituída por RFC 5036.

O comportamento básico desmontava LSPs e liberava etiquetas quando a sessão TCP falhava. As extensões permitem que parte do estado sobreviva enquanto a relação de controle volta. Essa sobrevivência compra tempo; não prova que a associação continua correta.

Controle ausente, dados talvez presentes

RFC 3612 distingue falha de sessão e falha de nó. Na primeira, os pares continuam ativos e a sessão reinicia. O documento ressalta que perder a sessão não implica perder o canal de dados, mesmo com sinalização em banda. Na segunda, o nó ou componente LDP reinicia, enquanto o hardware de encaminhamento pode ou não guardar entradas.

Assim, capacidade negociada, estado efetivamente preservado e tráfego observado precisam de recibos próprios. Para que o tráfego não seja afetado, os dois extremos devem pelo menos preservar encaminhamento. Se só um preserva, RFC 3478 pode acelerar a reconstrução depois, mas não demonstra continuidade durante a falha.

Proteção de enlace, túnel ou caminho fica fora do escopo. Uma rede pode precisar de proteção e reinício; uma marca comercial que reúne os dois não une suas provas.

O orçamento do temporizador

O FT Reconnect Timeout pede ao vizinho que retenha o estado existente após a perda de comunicação. O Recovery Time indica por quanto tempo o nó reiniciado mantém o que salvou. Zero informa que o estado não sobreviveu ou deixou de estar disponível.

Entradas preservadas tornam-se stale. Novos mapeamentos podem validá-las; as restantes são removidas quando o prazo termina. Um intervalo longo acomoda uma base maior e prolonga erros. Um intervalo curto limita exposição e pode apagar estado antes do fim. O valor deve vir de distribuições medidas de recuperação, não de uma expectativa nominal.

RFC 5919 acrescentou End-of-LIB para marcar o fim de uma fase de anúncios. A notificação não é garantida, e um timeout pode substituí-la. Ela não comprova instalação no hardware remoto, coerência com outros alocadores nem entrega de pacotes.

Confirmado ainda não quer dizer executado

RFC 3479 numera operações protegidas, registra ACKs, permite checkpoint e pausa mudanças antes de desligamento controlado. Exige os dois pares e auditoria entre controle reconstruído e encaminhamento.

Um ACK pode ser enviado depois de registrar a mensagem com segurança e antes do processamento completo. Logo, pedido armazenado não é mapeamento produzido; mapeamento processado não é entrada instalada; entrada instalada não é serviço observado. Um sistema que resume todos como “aplicado” apaga exatamente a fronteira necessária numa falha.

O procedimento de cork torna uma manutenção planejada mais limpa ao fechar o checkpoint e impedir novas mudanças. Ele não corrige uma tabela que já estava errada. RFC 3612 adverte que preservação pode manter estado incorreto, inclusive o estado que causou a falha.

Quando a dívida vira conflito

Enquanto a base antiga é reconciliada, um upstream pode continuar usando uma etiqueta para uma FEC e o downstream pode atribuir o mesmo número a outra. Os dois relatos locais parecem válidos; o pacote encontra significados incompatíveis.

Configuração estática, outra instância LDP ou outro protocolo também pode compartilhar o espaço. Uma autoridade comum ou espaços segmentados precisam impedir reutilização enquanto a licença antiga vive. Sem isso, a consequência pode ser entrega errada, serviço sem autorização ou negação de serviço. Esses são riscos descritos, não alegações de ataque real.

Medir a dívida por época

O recibo deve identificar par, época, tipo de falha, capacidades e prazos. Para cada entrada, guarda alocador, espaço, FEC, próximo salto, estado stale e desfecho. Registra ainda recebimento, persistência, processamento, instalação, checkpoint, reemissão e End-of-LIB real ou presumido.

Depois acrescenta o que nenhum protocolo de controle pode fornecer sozinho: sondas bidirecionais, contadores nas duas pontas e amostras de FECs representativas. Sem isso, o resultado permanece não observado.

A organização deve comparar a dívida máxima medida com o orçamento do temporizador por classe de sessão. A mesma etiqueta “graceful” pode cobrir perfis incompatíveis; o que torna a decisão responsável é expor essa diferença antes da falha.

Fontes