Resumen

  • El RFC 1461, de mayo de 1993, definió objetos de gestión SNMP para el tráfico multiprotocolo sobre X.25. Contaba por separado la búsqueda saliente sin número X.121 y la llamada entrante cuyo número X.121 no revelaba una dirección encapsulada.
  • Cada sentido conservaba la última dirección fallida y el valor del tiempo de actividad del equipo. El texto ordenaba registrar el fallo aun cuando su atribución a una interfaz fuera incierta.

Un paquete IP no traía en el sobre el número que necesitaba la red X.25. Esa diferencia, pequeña en un dibujo de arquitectura y enorme para quien intentaba entregar tráfico, es el centro del RFC 1461. Mark Throop escribió una base de información de gestión para los nodos que seguían las reglas de RFC 1356, la especificación que llevaba IP y otros protocolos por X.25. El documento muestra qué podía medirse y configurarse; no documenta un apagón concreto.

El diseño empieza por no confundir presencia con servicio. La tabla de interfaces incluye solo las X.25 que transportan tráfico multiprotocolo. La tabla de pares contiene el número X.121, la interfaz elegida y una referencia a los parámetros de llamada. Otra tabla dice qué encapsulaciones admite cada par. Tener cable, tener destinatario y hablar el protocolo esperado son respuestas distintas.

El contador de fallos salientes aumenta cuando la dirección encapsulada no encuentra número X.121 en la tabla o mediante un algoritmo. La última dirección queda guardada. Si era IP, la representación tenía cinco octetos: 0xCC para indicar el tipo y cuatro para la dirección. Se guardaba además el sysUpTime del fallo más reciente. Ese reloj sirve para situar el episodio en la vida del equipo; no es una fecha de calendario.

El camino de vuelta tampoco queda escondido. Al recibir una llamada, el nodo puede no reconocer el X.121 de quien llama como dirección encapsulada. Un segundo contador, otro último número y otro tiempo registran ese caso. Las conexiones cerradas por un fallo del bit Q van por una serie distinta. Esa separación impide que tres problemas operativos terminen bajo una vaga etiqueta de «X.25 averiado».

Hay una frase poco cómoda y muy útil: si el agente no sabe a qué interfaz adjudicar el fallo de traducción saliente, debe asignarlo a la primera entrada probable y contarlo de todos modos. La cifra no desaparece por falta de una etiqueta perfecta; la etiqueta, en cambio, merece cautela. RFC 1382 ya daba visibilidad a los circuitos X.25. El RFC 1461 añadió la pregunta que el circuito no podía responder: qué par correspondía a esa dirección.