Summary

  • La RFC 1574, de febrero de 1994, definió tres herramientas básicas para hosts y routers con servicio OSI sobre CLNP: eco, traceroute y un modo de extraer su tabla de rutas.
  • Con el indicador de informe de error activado, un nodo CLNP que no reconociera el nuevo selector debía devolver un paquete de error. La respuesta identificaba al equipo que recibió la sonda; había que seguir probando más allá para comprobar si respondía el destino.

Para quien busca una caída, un ping mudo mezcla dos posibilidades: la sonda nunca llegó a un equipo o llegó a uno que no entendió el nuevo selector de eco. La diferencia indica dónde poner la siguiente prueba. En febrero de 1994, Susan Hares y Cathy Wittbrodt describieron el problema más amplio: escaseaban las herramientas para depurar redes OSI y las disponibles a menudo no interoperaban. Su RFC convirtió el error en una pista de alcance. Con el informe de error activado, un nodo que admitía CLNP pero no el nuevo selector debía devolver un paquete de error. El ping seguía fallando; el equipo que había recibido la sonda quedaba identificado.

El primer instrumento era el eco de CLNP. La RFC 1575 definía los selectores 1E y 1F, en hexadecimal, para pedir y devolver la respuesta. La RFC 1574 exigía activar el indicador de informe de error. Un nodo que comprendiera CLNP pero no el nuevo selector debía intentar devolver un paquete de error. La herramienta tenía que mostrar el código recibido, además de los tiempos de ida y vuelta de cada paquete y sus valores mínimo, máximo y medio. Ocultar todo bajo una luz roja habría borrado la pista que acababa de llegar.

El segundo instrumento seguía la ruta. CLNP llevaba un campo Lifetime comparable al TTL de IP. Una solicitud de eco con valor 1 provocaba una respuesta desde el primer salto cuando la duración se agotaba; con 2 podía contestar el siguiente. Subiendo el valor aparecía una secuencia de equipos y códigos. A0 y A1 indicaban expiración en distintas circunstancias; B0, opción no admitida; 80 y 81, destino inalcanzable o desconocido. Una lista de saltos que contestan no equivale a comprobar que la aplicación en el extremo está sana. Sirve para colocar la investigación sobre el tramo correcto.

La ruta solicitada también podía jugar una mala pasada. ISO 8473 permitía pedir un encaminamiento de origen parcial, pasando por un punto elegido. Si un nodo no admitía la opción, debía reenviar el paquete como si nadie la hubiese pedido; el destino podía responder por otra ruta. La RFC mandaba informar de errores como una dirección desconocida en la ruta de origen o un camino inaceptable. El resultado del eco y el itinerario ordenado eran dos datos distintos.

Quedaba una tercera fuente: lo que el propio router creía saber. La RFC 1574 requería que hosts y routers OSI pudieran volcar sus tablas de rutas mediante algún mecanismo fuera de banda. Las rutas podían proceder de ES-IS, IS-IS, IDRP o configuración estática. Se sugería una familia de comandos show osi routes y acceso por SNMP o CMIP. La MIB de CLNS de entonces no mostraba todo lo deseado. El volcado respondía qué rutas conservaba el router y de dónde procedían; comprobar la aplicación en el extremo requería otra prueba.

Para saber cómo se comportaron los tres instrumentos en una implementación real, falta una traza fechada y atribuible a un equipo concreto. El diseño mantuvo separadas las pruebas: el eco localizaba quién respondía, traceroute qué saltos daban señal y el volcado qué rutas guardaba el router. Tres preguntas; un diagnóstico menos ciego.