Summary

  • A RFC 1574, publicada em fevereiro de 1994, estabeleceu três capacidades de diagnóstico para hosts e roteadores com serviço OSI em CLNP: eco, traceroute e extração da tabela de rotas.
  • Com a sinalização de relatório de erro ligada, um nó CLNP que não conhecesse o novo seletor de eco podia devolver um erro. A resposta apontava para um nó alcançado pela sonda, sem garantir passagem até o destino.

O plantonista envia uma sonda e recebe uma reclamação: o roteador não reconhece a função pedida. O painel de controle marcaria falha. Quem procura a causa da pane lê algo mais útil: o pacote chegou longe o bastante para provocar uma resposta. Susan Hares e Cathy Wittbrodt construíram a RFC 1574 em torno desse tipo de diagnóstico preciso. Em 1994, diziam, ferramentas de depuração para a camada de rede OSI quase não existiam; quando existiam, diferentes implementações frequentemente não se entendiam.

O primeiro item da caixa de ferramentas era o eco CLNP. A RFC 1575 definiu os seletores hexadecimais 1E, para pedido, e 1F, para resposta. A RFC 1574 exigia que a sonda ativasse o sinalizador de relatório de erro. Um equipamento que entendesse CLNP, mas desconhecesse a nova função, deveria tentar mandar um pacote de erro. Há uma diferença enorme entre receber o eco, receber uma objeção e não ouvir nada. A especificação mandava mostrar o código do erro e os tempos de ida e volta de cada tentativa, além do mínimo, máximo e média de várias sondas.

Quando a pergunta mudava de «quem me ouve?» para «por onde o pacote anda?», entrava o segundo item. O campo Lifetime do CLNP cumpria papel parecido com o TTL do IP. Uma sonda com valor 1 esgotava sua vida no primeiro salto, que devolvia um erro; com valor 2, podia responder o segundo. O operador aumentava o valor e montava uma sequência de respostas. Os códigos preservavam as diferenças: A0 e A1 apontavam situações de vida esgotada, B0 uma opção não suportada, 80 e 81 destino inalcançável ou desconhecido. Cada mensagem mudava o lugar provável da próxima investigação.

Havia um sucesso enganoso. Uma sonda podia pedir rota de origem parcial, exigindo passagem por um ponto intermediário. Se um nó não suportasse a opção, ISO 8473 permitia que ele encaminhasse o pacote normalmente, ignorando o pedido. Chegar ao destino não provava a passagem pelo ponto escolhido. A RFC também queria que erros de rota de origem — endereço desconhecido ou caminho inaceitável — aparecessem para o usuário. Sem isso, o teste poderia comemorar uma viagem diferente da que o plantonista havia solicitado.

O terceiro item era o próprio estado do roteador. Cada host ou roteador OSI deveria oferecer algum meio fora de banda para extrair sua tabela de rotas. Entradas podiam vir de ES-IS, IS-IS, IDRP, configuração estática ou outra fonte. O texto sugeria show osi routes com filtros e acesso por SNMP ou CMIP, reconhecendo que a MIB CLNS disponível não trazia tudo o que se desejava. A tabela mostrava as escolhas guardadas por uma máquina; o traceroute registrava as respostas vistas no caminho. Um não substituía o outro.

A RFC é uma especificação Informational, sem registro de uma pane específica ou medição de adoção. Para saber como uma implementação se comportou, seriam necessárias sondas, rastros e tabelas datados. O desenho da investigação, porém, é claro: a primeira mensagem de erro já pode estreitar o problema, desde que a ferramenta não a enterre sob um botão vermelho chamado «falhou».