Resumo

  • O operador escolhe Uniform, Pipe ou Short Pipe e configura o TTL da nova etiqueta empurrada. O RFC 3443 não define um mecanismo de sinalização do modelo; a escolha fica na configuração operacional por interface de linha de comando ou de gerenciamento.
  • Uniform propaga o estado de TTL de MPLS e do pacote transportado, mantendo os LSRs internos visíveis para o tráfego externo. Pipe pretende fazer o túnel parecer um único salto; Short Pipe muda o tratamento na saída.
  • A regra comum de encaminhamento continua valendo: salvo indicação do modelo, o TTL de saída é o TTL de entrada menos um, e uma falha na verificação do TTL impede o encaminhamento. Pipe e Short Pipe não são criptografia, autenticação, controle de acesso ou autorização de rota.

O mecanismo aparece nas fronteiras de etiquetas. No ingresso, o LSR faz push e trata o TTL IP abaixo da etiqueta segundo o modelo. No trânsito, o LSR faz swap, verifica e decrementa o TTL conforme as regras aplicáveis. No egresso, o LSR faz pop e entrega o pacote transportado à semântica de encaminhamento seguinte. O RFC 3032 descreve a codificação de pilhas de etiquetas; o RFC 3443 esclarece como push, swap e pop preservam ou ocultam o estado de limite de saltos. “Ocultar” significa que saltos internos podem não aparecer na observação externa; não significa que os LSRs internos deixem de controlar TTL.

No Uniform, o estado de hop-limit atravessa a fronteira de etiquetas, de modo que um traceroute externo pode revelar LSRs de trânsito do túnel. No Pipe, o TTL da nova etiqueta é um valor configurado pelo operador, e não uma cópia do TTL do cabeçalho abaixo dela; a intenção é que o túnel apareça como um salto para o tráfego externo, independentemente da quantidade de LSRs atravessados. O RFC 3443 registra que muitas implementações usavam 255 na época da publicação, mas não transforma 255 em valor universal obrigatório.

O Short Pipe também usa um TTL configurado no push, mas na saída trata o cabeçalho transportado como se o egresso fosse um salto comum de encaminhamento, incluindo o decremento especificado. Com ou sem PHP, o RFC apresenta o mesmo resultado de decremento fim a fim.

PHP é uma questão de correção, não apenas uma otimização. Quando o salto penúltimo remove a etiqueta externa, o egresso recebe uma pilha diferente daquela recebida sem PHP; ainda assim, deve aplicar o processamento de TTL correspondente ao pacote e à pilha efetivamente recebidos. Pilhas hierárquicas exigem consistência em cada push, swap e pop. Uma configuração divergente nas bordas pode decrementar TTL a mais ou a menos, ou verificar no lugar errado, produzindo descartes e resultados de traceroute difíceis de explicar.

Os RFCs não fornecem padrões universais de fabricantes, prevalência de implantação, redução medida de incidentes ou limiares obrigatórios de telemetria.

Um cenário de verificação deve usar um pacote com TTL IP conhecido e registrar: o TTL da etiqueta após a inserção no ingresso; o decremento e a verificação após cada troca em trânsito; e o TTL do cabeçalho após a retirada no egresso. Repita com PHP ativado e desativado, e com pilha simples e hierárquica. Execute também o rastreamento de rota em Uniform, Pipe e Short Pipe, registrando que a ausência de saltos internos não prova, sozinha, qual modelo foi configurado, qual caminho foi usado ou se todos os dispositivos o implementaram de modo consistente. Compare os procedimentos do RFC 3443 com a codificação de pilha do RFC 3032.

O RFC 3270 oferece contexto operacional de tratamento de serviços diferenciados, mas não transforma TTL em autorização.

Caminho de decisão do operador

  1. Confirme que a decisão é de visibilidade e limite de saltos, não de criação de LSP, autorização de rota, autenticação de peer, concessão de acesso ou mudança de política de encaminhamento.
  2. Se o diagnóstico externo precisa enxergar os saltos internos, avalie Uniform; se o túnel deve parecer um salto, avalie Pipe; se a saída precisa do tratamento adicional de um salto comum, avalie Short Pipe.
  3. Registre o TTL inicial configurado para a etiqueta. Não trate 255 como exigência universal.
  4. Verifique push, swap, pop, PHP, pilhas hierárquicas e comportamento de descarte quando a checagem falhar.
  5. Preserve observações de traceroute, TTL e pilha como evidência; não transforme uma única observação em identificação determinística do modelo ou do caminho.

Fontes