Resumen

  • El objeto RDAP de APNIC abarca exactamente AS136022 y vincula el registro administrativo con Janani Technology. La etiqueta active describe el objeto registral, no una ruta, un equipo ni un servicio.
  • La respuesta de PeeringDB contiene una fila para el ASN, sin conexiones netixlan y con varios campos vacíos. Eso delimita las declaraciones disponibles en la ficha; no demuestra que la red carezca de peering, prefijos o presencia en intercambios.
  • La respuesta congelada de RIPE RIS, con tiempo de consulta del 7 de agosto de 2026 a las 00:00 UTC, informa de visibilidad entre los pares listados bajo un umbral explícito. No prueba alcance universal, autorización de rutas, capacidad, resiliencia ni experiencia de cliente.

El ASN fija el sujeto de la investigación

Un sistema autónomo es una red o un conjunto de redes que presenta una política común de enrutamiento hacia internet. El número de sistema autónomo, o ASN, identifica ese dominio cuando las redes intercambian información de alcance mediante el Border Gateway Protocol, conocido como BGP.

En este expediente, AS136022 permite reunir documentos que usan el nombre Janani Technology sin depender únicamente de una coincidencia textual. El número ayuda a un equipo de operaciones a confirmar qué objeto debe revisar, a un posible socio a formular una pregunta de interconexión y a un equipo de respuesta a dirigir una consulta al registro correcto.

Sin embargo, el identificador no contiene un diagnóstico. No muestra por sí mismo si una ruta se anuncia, si otra red la acepta o si una aplicación responde. Su función es mantener un referente inequívoco mientras cada fuente responde a una pregunta diferente.

APNIC registra identidad y acontecimientos administrativos

RDAP, sigla de Registration Data Access Protocol, ofrece datos estructurados sobre recursos numéricos de internet. La respuesta de APNIC tiene 136022 tanto como valor inicial como final, de modo que cubre un único ASN. Usa el identificador AS136022, el nombre de objeto JANANITECHNOLOGY-AS-AP e incluye Janani Technology entre los nombres de entidades asociados.

El objeto figura como active. Su historial registra el 3 de febrero de 2019 a las 08:31:56 UTC como fecha de registro y el 18 de enero de 2021 a las 03:52:25 UTC como último cambio. Estos datos hacen que el objeto administrativo sea localizable y permiten revisar cuándo cambió su ficha pública.

No son telemetría. Active no significa que un router esté encendido, que un anuncio BGP sea visible, que una sesión esté establecida o que un producto responda. Del mismo modo, la fecha de modificación del registro no tiene por qué coincidir con un cambio de configuración de red.

El valor del registro está en otra parte: mantiene un número único, una asociación administrativa y un historial. Esa base reduce ambigüedades y facilita la coordinación. Para saber qué hace el sistema en funcionamiento hace falta observarlo con una herramienta diseñada para esa tarea.

Una ficha incompleta no es una medición negativa

PeeringDB es un directorio de coordinación mantenido por sus participantes. La respuesta congelada devuelve una sola fila para el ASN 136022, con id 40097, nombre Janani Technology y estado de ficha ok. El campo de actualización indica el 4 de abril de 2026 a las 16:50:22 UTC.

La fila aporta pocas declaraciones. No contiene registros netixlan, utilizados para declarar conexiones de una red a una LAN de intercambio. También deja vacíos o nulos los campos de sitio web, tipo de red, política general de peering, conjunto IRR y número de prefijos IPv4 e IPv6.

La ausencia de esos datos no describe una ausencia operacional. Solo indica que la respuesta capturada no incluye esas declaraciones. Cero filas de intercambio no prueba que Janani Technology no tenga peering privado, conexiones bilaterales o presencia en otro contexto. Un campo de política vacío no permite clasificarla como abierta, selectiva o restrictiva. Un contador de prefijos sin rellenar no demuestra que el ASN no origine espacio de direcciones.

Tampoco ok es una señal de salud de la red. Es el estado de la ficha en el directorio. No vigila sesiones BGP, rutas, interfaces ni aplicaciones. Si una decisión necesita esos datos, el siguiente paso es pedir información autorizada o consultar una fuente de observación, no completar los huecos mediante inferencias.

Esta lectura permite aprovechar incluso un perfil escaso. El formulario señala qué información pública no está disponible y qué preguntas siguen abiertas. La falta de una declaración es relevante para la coordinación, pero no es un fallo medido ni una descripción completa de la arquitectura.

La observación RIS responde a otra pregunta

RIPE RIS, el Routing Information Service, recopila información BGP desde puntos de observación participantes. La respuesta routing-status conservada aquí tiene un tiempo de consulta del 7 de agosto de 2026 a las 00:00 UTC. Los valores pertenecen a esa instantánea y no se presentan como una promesa sobre otro momento.

Para IPv4, la respuesta muestra rutas que cumplen el criterio de inclusión ante 326 de los 327 pares full-feed de RIS listados, es decir, 326/327. Para IPv6, la relación es 320/320. Los campos de espacio anunciado contabilizan un prefijo IPv4 que representa 256 direcciones y dos prefijos IPv6 equivalentes a dos bloques /48.

La misma respuesta informa de un vecino observado. Ese número surge del modelo de los colectores. No debe convertirse en un par directo, un contrato comercial, una sesión de intercambio, una instalación ni un camino físicamente independiente. Una relación visible desde un colector tampoco revela automáticamente su naturaleza técnica o comercial.

El endpoint señala que excluye rutas vistas por menos de diez pares full-feed de RIS. Los resultados reflejan, por tanto, las rutas que superan ese umbral dentro del conjunto indicado. Puede haber observaciones de menor alcance fuera de la respuesta, y el conjunto de colectores no representa cada posible punto de internet.

Los cocientes son evidencia útil sobre visibilidad BGP dentro de ese método. No acreditan alcance universal, autorización de origen, preferencia de camino, baja latencia, tráfico, capacidad libre, redundancia ni disponibilidad de una aplicación. Que una ruta aparezca en BGP y que un usuario complete una operación son comprobaciones distintas.

Las marcas de tiempo conservan significados distintos

El tiempo de consulta no es la única fecha incluida. El campo de última observación nombra 103.134.41.0/24, con origen 136022, a las 00:00 UTC del 7 de agosto de 2026. El campo de primera observación menciona 103.134.42.0/24, con el mismo origen, a las 16:00 UTC del 13 de febrero de 2019.

Aunque el tiempo de consulta y el de última observación coincidan, no son un único campo. El primero describe el contexto temporal de la respuesta; el segundo corresponde a un prefijo seleccionado por el endpoint. El dato de primera observación pertenece a otro prefijo y tampoco demuestra propiedad, autorización o anuncio continuo desde 2019.

Para construir una cronología de rutas se necesitaría una serie histórica adecuada. Fusionar estas tres etiquetas produciría una historia que la respuesta no cuenta. La forma responsable de citarlas es conservar el nombre del campo, el prefijo y la hora exacta.

Una secuencia práctica para verificar sin exagerar

La investigación empieza confirmando AS136022. Después se comprueba que el objeto de APNIC y la entrada de Janani Technology se refieren al mismo sujeto. Este paso protege contra errores de identidad antes de interpretar cualquier dato técnico.

El registro responde entonces a preguntas administrativas: qué número abarca el objeto, qué nombre publica y qué acontecimientos constan. Si la pregunta es si una ruta fue observada, el registro no basta.

PeeringDB puede leerse como una lista de declaraciones disponibles. En este caso, los campos vacíos se convierten en preguntas para el operador o para un posible par: ¿qué política se aplica?, ¿qué contactos deben usarse?, ¿qué prefijos y conexiones desea declarar? La respuesta pública debe mantener esas preguntas abiertas.

Para analizar rutas hay que conservar la fuente colectora, el tiempo de consulta, la familia de direcciones, el denominador de pares y el umbral. Una decisión importante puede requerir más puntos de observación. La autorización de origen requiere datos específicos de autorización. El comportamiento de un servicio exige pruebas de extremo a extremo y evidencia de la aplicación.

El registro de APNIC, la ficha de PeeringDB y la instantánea congelada de RIPE RIS son capas diferentes. Ninguna demuestra por sí sola una sesión de peering activa, alcance universal, autorización de rutas, capacidad, resiliencia o servicio al cliente.

Límites del expediente público

Las cuatro fuentes permiten describir la identidad administrativa de AS136022, el contenido de una ficha de coordinación escasa y una observación acotada de rutas. No permiten afirmar cuáles son los servicios de Janani Technology, dónde opera, quiénes son sus clientes, qué instalaciones o equipos utiliza, quiénes son sus proveedores ascendentes o cuál es su escala comercial.

Tampoco prueban presencia en un intercambio, relación con un servidor de rutas, estado de una sesión, volumen de tráfico, rendimiento, latencia, diversidad física, capacidad, continuidad o resultado para un usuario. Un campo vacío no es un incidente. Una visibilidad alta entre colectores no es una garantía universal. El número de prefijos no es una medición de capacidad.

La conclusión defendible es precisa: APNIC asocia administrativamente AS136022 con Janani Technology; la ficha de PeeringDB capturada contiene pocas declaraciones; y la respuesta congelada de RIS muestra rutas admisibles ante sus pares listados, con una hora y un umbral definidos.

Qué vigilar

  • cambios en el nombre, la entidad, el estado administrativo o el historial del objeto AS136022 en APNIC;
  • nuevas declaraciones de contacto, política, prefijos o conexiones en la ficha de PeeringDB;
  • observaciones de rutas que publiquen su hora, familia de direcciones, denominador y umbral;
  • evidencia de origen cuando la pregunta sea la autorización de una ruta;
  • telemetría autorizada de sesiones o pruebas de servicio cuando la pregunta sea operacional.

Fuentes