Resumen

  • Chittagong Multi Channel Limited aparece en una cadena pública de identidad que cruza el directorio de BTW, la membresía de APNIC, registros RDAP de APNIC, PeeringDB y el dominio cmclbd.com. Esa cadena permite tratar el caso como una empresa regional de acceso a Internet vinculada a AS137029, pero no permite afirmar propiedad, ingresos, plantilla, número de abonados, cobertura detallada, arquitectura privada ni acuerdos comerciales.
  • APNIC registra AS137029 y el bloque IPv4 portátil 103.102.136.0/22 en relación con CMCL. RIPEstat observó, en el momento de consulta, seis anuncios IPv4, 1.280 direcciones IPv4, dos vecinos BGP observados y cero prefijos IPv6 observados. Esas cifras describen una vista pública puntual, no un inventario interno ni una prueba de disponibilidad.
  • La validación RPKI consultada fue estrecha: el par origen AS137029 y prefijo agregado 103.102.136.0/22 devolvió estado válido, con maxLength /22. Esa evidencia no autoriza a decir que los anuncios /24 observados estén cubiertos o validados por la misma autorización.
  • Las páginas de CMCL describen paquetes de acceso a Internet y conectividad mediante IIG e IX como copia de capacidad atribuida a la empresa. No son pruebas independientes de velocidad real, latencia, disponibilidad, redundancia, resolución de soporte ni resultados de clientes.

La fotografía asociada muestra bobinas de cable de fibra óptica almacenadas en un entorno industrial. Sirve como contexto físico general para una historia sobre infraestructura de red. No representa a Chittagong Multi Channel Limited, no ubica una instalación en Bangladesh, no muestra una red de cliente y no prueba fiabilidad, interrupciones ni rendimiento.

Identidad exacta de la empresa y límite del caso

El punto de partida no es una búsqueda genérica por el nombre corto de la compañía. El punto de partida es el objeto público del directorio de BTW identificado como “Nizam Uddin Mazud T/A Chittagong Multi Channel Limited”. Para el lector, la forma abreviada práctica es Chittagong Multi Channel Limited, pero la forma larga importa porque conecta la entrada del directorio con registros externos que usan nombres, alias y etiquetas de red diferentes.

La página de membresía de APNIC aporta una unión especialmente importante: muestra la forma larga “Nizam Uddin Mazud T/A Chittagong Multi Channel Limited”, la coloca en la economía BD, la clasifica en una banda de membresía pequeña y enlaza el dominio cmclbd.com. Esa clasificación administrativa de APNIC no debe inflarse. No es una medición de ingresos, capacidad, abonados, kilómetros de fibra, tamaño de red ni influencia comercial. Es una señal de identidad y de relación con el registro regional.

Los registros RDAP de APNIC completan otro tramo. El registro de AS137029 aparece activo bajo la etiqueta CMCL-AS-AP, con Bangladesh como país y Chittagong Multi Channel Limited como organización registrante. El registro del bloque 103.102.136.0/22 identifica el rango 103.102.136.0 a 103.102.139.255 como asignación IPv4 portátil activa asociada a la misma empresa y a contactos operativos. En términos de análisis público, eso permite hablar de un operador con superficie de ASN y recursos IPv4. No permite describir el contenido de su red privada.

PeeringDB aporta una tercera superficie. Su registro de organización identifica a Chittagong Multi Channel Limited, usa CMCL como alias, enlaza el dominio de la empresa y muestra una actualización en 2025. El registro de red para AS137029 vincula el ASN con esa organización y ese dominio. PeeringDB es valioso para coordinación de interconexión, pero es un registro mantenido por operadores y participantes; no sustituye a un registro mercantil, a un contrato de tránsito ni a una auditoría de red.

La cadena de identidad, leída con cautela, es suficiente para este artículo: el objeto de directorio, la membresía de APNIC, RDAP, PeeringDB y el sitio de la empresa convergen sobre CMCL y AS137029. Lo que queda fuera es igual de importante. Las fuentes revisadas no establecen accionistas, beneficiarios finales, ingresos, número de empleados, número de clientes, estructura de grupo, proveedores, equipos, capacidad contratada ni obligaciones de servicio.

Esa separación no es un tecnicismo legal. En redes, los nombres son controles operativos. El nombre que aparece en una factura de proveedor, el alias usado por un NOC, el identificador de un ASN, el dominio que ve un cliente, el contacto de abuso en RDAP y el nombre de un circuito pueden apuntar al mismo servicio, pero solo si alguien mantiene el mapa. Cuando ese mapa se degrada, una avería puede convertirse en un problema de autoridad: nadie sabe quién puede aprobar un cambio de ROA, abrir un caso de operador, recuperar una cuenta del registro o explicar a un cliente qué servicio está afectado.

Lo que las páginas de CMCL sí demuestran

El sitio de CMCL presenta a la empresa como proveedor de soluciones de Internet y publica paquetes de acceso con nombres como CMCL Basic, CMCL Family, CMCL Family Plus y CMCL Super. También describe conectividad mediante pasarelas internacionales de Internet e intercambio de Internet. Esas páginas son evidencia de posicionamiento comercial y de capacidad declarada por la propia empresa: CMCL se presenta al mercado como proveedor de acceso.

La misma evidencia no debe leerse como medición independiente. Un paquete publicado no prueba que cada cliente reciba una velocidad determinada. Una mención de IIG o IX no identifica circuitos, contratos, capacidad, redundancia, política de rutas ni direcciones de pago. Una página de contacto demuestra una superficie pública de comunicación, no un tiempo de respuesta. Un sitio activo tampoco demuestra disponibilidad de la red de acceso.

En la revisión aparece además un detalle instructivo: un enlace de registro o contacto relacionado con el sitio devolvió 404 y fue excluido como fuente probatoria. Un enlace roto no prueba que el alta de clientes esté caída por todos los canales, ni que exista o no exista una aprobación regulatoria concreta. Sí muestra un coste cotidiano de ciclo de vida: las páginas públicas, los formularios, la información de paquetes y los contactos pueden envejecer de manera separada respecto de la red que pretenden describir.

Para un ISP regional, esa divergencia es más que estética. Un cliente puede contratar por una página, ser provisionado por otro sistema, recibir soporte por un tercer canal y depender de una ruta BGP cuya autoridad está en un registro externo. Si la página promete una cosa, el catálogo de facturación contiene otra, el equipo de campo instala una tercera y soporte no puede ver el estado completo, el servicio puede fallar aunque cada subsistema parezca razonable aislado.

Conviene distinguir tres niveles. La capacidad es que exista una oferta, un ASN, un bloque IPv4, conectividad y una operación capaz de entregar acceso. La fiabilidad es que esa capacidad se comporte dentro de límites medidos durante el tiempo: disponibilidad, pérdida, latencia, estabilidad de rutas, tiempos de reparación y recurrencia de incidentes. El resultado de cliente es otra capa: un efecto atribuible en una organización o usuario concreto, con periodo, línea base y medición. Las fuentes revisadas sostienen capacidad atribuida y evidencia pública de enrutamiento; no sostienen fiabilidad longitudinal ni resultados de clientes.

Tampoco hay base pública para insertar afirmaciones sobre IA, modelos de automatización, ahorro operativo o plataformas internas. El hecho de que la empresa sea un caso tecnológico no autoriza a inventar una pila de software. La tecnología relevante aquí es más elemental y más difícil de mantener: números de Internet únicos, rutas observables, seguridad de origen, fibra física, soporte, inventarios, cambios y excepciones.

AS137029 y el registro IPv4 de APNIC

Un número de sistema autónomo no es una descripción completa de una empresa. Es un identificador de política de enrutamiento. AS137029 permite que otras redes y observadores reconozcan un origen o una relación de rutas asociada a CMCL. En el registro RDAP de APNIC, AS137029 aparece activo, con el nombre CMCL-AS-AP y Bangladesh como país. Esa evidencia establece un objeto de registro, no una fotografía completa del tráfico.

El bloque 103.102.136.0/22 añade una superficie más concreta. RDAP lo describe como un rango IPv4 activo, asignado como portátil y asociado a Chittagong Multi Channel Limited. Un /22 equivale matemáticamente a 1.024 direcciones, aunque esa aritmética no dice cuántas están asignadas a clientes, equipos, servicios internos o reservas. La portabilidad tampoco significa que una migración sea simple. Un recurso portátil puede facilitar continuidad, pero solo si las rutas, ROA, filtros, DNS inverso, contratos y contactos se mantienen listos.

El registro regional funciona como libro de referencia. Ayuda a preservar unicidad, responsabilidad, contactos y metadatos de seguridad. No opera los routers. Una entrada RDAP exacta no garantiza que un prefijo esté anunciado. Una ruta visible no corrige un contacto de abuso inactivo. La continuidad depende de la reconciliación: lo que el registro dice, lo que la red anuncia y lo que el operador pretende deben coincidir dentro de un margen controlado.

El bloque IPv4 también genera costes por escasez. Un proveedor con direcciones finitas debe mantener un inventario vivo: qué subred se usa para qué servicio, qué cliente o plataforma la tiene asignada, qué política de seguridad se aplica, qué DNS inverso corresponde, cuándo se recupera una dirección y qué dependencias quedan antes de retirarla. Las fuentes públicas no muestran el inventario interno de CMCL. La inferencia razonable es más limitada: cualquier ISP que administra espacio IPv4 portátil asume trabajo recurrente de asignación, protección, recuperación y documentación.

Los contactos publicados son otra parte del coste. Un contacto administrativo, técnico o de abuso solo sirve si llega a una cola activa, con responsables, suplentes y trazabilidad. La dirección puede existir sintácticamente y estar muerta operativamente. El control real consiste en probar entrega, preservar autoridad, mantener suplentes, retirar cuentas antiguas y poder actuar durante una emergencia sin depender de una sola persona o de un sistema inaccesible.

El mismo principio se aplica a cambios de rutas. Antes de anunciar un prefijo, el operador debe saber si el origen está autorizado, si los filtros aguas arriba aceptarán el anuncio, si el prefijo aparece en inventarios, si hay una ROA coherente, si existe un plan de reversión y si los clientes afectados están identificados. La frontera entre registro y red no es burocrática: es el lugar donde muchas interrupciones se vuelven difíciles de diagnosticar.

Estado BGP observado, IPv6 y alcance de RIPEstat

RIPEstat proporciona observaciones públicas desde colectores y fuentes de routing. Para AS137029, la vista revisada mostró seis anuncios IPv4, resumidos como 1.280 direcciones IPv4, cero prefijos IPv6 observados y dos vecinos BGP observados. Entre los prefijos visibles aparecen el agregado 103.102.136.0/22, más específicos /24 dentro de ese espacio y 114.130.72.0/24.

Hay que leer esa lista con precisión. Un agregado y sus más específicos no son seis asignaciones independientes. La cifra de 1.280 direcciones describe el espacio cubierto por los anuncios observados en esa vista, no un recuento de clientes, dispositivos, hogares, sesiones o direcciones utilizables. Un colector puede ver rutas que otros no ven, y una ruta puede cambiar después de la consulta. La observación es útil porque muestra estado público; no sustituye al inventario interno.

La coexistencia de un agregado y más específicos plantea una pregunta operativa legítima: ¿qué rutas son intencionales? Los más específicos pueden usarse para ingeniería de tráfico, aislamiento de fallos, políticas por enlace o situaciones temporales. También pueden aparecer por configuración heredada, fuga, filtro incompleto o cambio de emergencia no retirado. Las fuentes públicas no permiten escoger una explicación. El operador debería tener un registro de intención que diga qué prefijo puede originarse, desde qué ASN, con qué máxima especificidad, en qué condición y por cuánto tiempo.

La ausencia observada de IPv6 requiere la misma cautela. La frase correcta es que RIPEstat no observó prefijos IPv6 para AS137029 en la consulta revisada. Eso no prueba que CMCL no tenga planes IPv6, laboratorios, acuerdos, direcciones no anunciadas, túneles o trabajo de preparación. Sí identifica una pregunta de continuidad: cuál es el estado aprobado de IPv6 y cómo se evita tanto una dependencia indefinida de IPv4 como una activación pública antes de que DNS, seguridad, monitoreo, soporte y equipos de cliente estén preparados.

La visibilidad BGP tampoco mide la experiencia de usuario. Un prefijo puede estar anunciado mientras hay pérdida de paquetes, congestión, problemas de autenticación, cortes de fibra, errores de DNS o fallos de soporte. También puede haber rutas temporalmente invisibles desde una vista pública sin que todos los clientes estén caídos. BGP es una capa necesaria para entender alcance global, pero el servicio de acceso vive en una cadena más larga.

Por eso, la supervisión útil no pregunta solo “¿hay ruta?”. Pregunta “¿la ruta observada coincide con la intención aprobada, la seguridad de origen está alineada, los enlaces físicos y lógicos esperados están vivos, el cliente puede autenticar, resolver nombres, pasar tráfico y recibir soporte?”. Cuando esas preguntas quedan separadas en herramientas distintas, el coste operativo aparece en cada incidente.

RPKI estrecho y vecinos observados

La consulta de validación RPKI para AS137029 y 103.102.136.0/22 devolvió estado válido en el momento revisado. La autorización relevante tenía maxLength /22. Ese dato es valioso, pero su valor está en su precisión. Significa que el origen AS137029 y el agregado 103.102.136.0/22 estaban cubiertos según esa consulta. No significa que todos los anuncios más específicos estuvieran cubiertos. En particular, un /24 no queda autorizado por una ROA cuyo máximo es /22.

La diferencia entre agregado y más específicos es una fuente clásica de coste de mantenimiento. Si la red necesita anunciar /24 por ingeniería de tráfico o contingencia, la política RPKI debe reflejarlo de manera explícita y segura. Si no los necesita, las autorizaciones no deberían abrir más superficie de la necesaria. Una ROA demasiado estrecha puede convertir una ruta legítima en inválida. Una ROA demasiado amplia puede facilitar anuncios que la política operativa no pretendía permitir. En ambos casos, el problema aparece cuando el metadato de seguridad y el routing real dejan de coincidir.

Un control maduro probaría cada cambio de rutas antes de ejecutarlo y lo verificaría después desde validadores independientes. Las autorizaciones temporales deberían tener vencimiento y revisión. Las credenciales de RPKI y del registro regional deberían contar con suplentes y recuperación. La validez observada un día no garantiza que el proceso seguirá alineado durante una emergencia.

RIPEstat también observó AS17806 y AS58717 como vecinos de AS137029. La palabra “vecinos” importa. No son, por esa sola evidencia, proveedores de tránsito confirmados, contratos, enlaces físicos independientes, rutas de pago, capacidades, SLA ni redundancia garantizada. El sitio de CMCL menciona conectividad mediante IIG e IX; PeeringDB da una identidad de red. Juntas, las fuentes muestran que las interconexiones externas son relevantes, pero no revelan su diseño completo.

La redundancia exige más que dos números ASN visibles. Dos vecinos pueden compartir ducto, edificio, energía, proveedor mayorista, router, configuración, personal de operación o plataforma de soporte. También pueden ser técnicamente distintos pero comercialmente dependientes. La independencia real se prueba por capas: física, lógica, operacional, contractual y humana. Las fuentes públicas no dan ese mapa, así que no debe inventarse.

Cada handoff externo trae integración. Hay circuitos, puertos, niveles ópticos, sesiones BGP, límites de prefijos, comunidades, filtros, avisos de mantenimiento, contactos y procedimientos de escalamiento. Los identificadores comerciales y técnicos rara vez coinciden naturalmente. Un aviso de mantenimiento debe poder traducirse en rutas, servicios y clientes afectados. Si esa traducción falla, el proveedor pierde tiempo justo cuando más necesita claridad.

Capacidad, fiabilidad y resultados de cliente

El caso CMCL permite afirmar capacidades acotadas. Existe una identidad de empresa y red coherente en registros públicos. AS137029 está asociado a la organización en APNIC. El bloque 103.102.136.0/22 aparece como recurso IPv4 portátil activo. RIPEstat observó rutas IPv4 originadas por AS137029. La consulta RPKI del agregado devolvió válido. El sitio de CMCL presenta paquetes de acceso e indica conectividad externa.

Nada de eso equivale a una afirmación de fiabilidad. La fiabilidad requiere una frontera de servicio y mediciones repetidas: disponibilidad, pérdida, latencia, jitter, congestión, estabilidad de rutas, tiempo de detección, tiempo de reparación, recurrencia, proporción de clientes afectados y calidad de comunicación. Una ruta visible a una hora concreta no dice cómo se comporta la red en hora pico. Una ROA válida no repara una fibra cortada. Un paquete publicado no mide el soporte.

Los resultados de clientes son una tercera categoría. Para decir que un ISP mejoró el rendimiento de un negocio, redujo interrupciones o elevó productividad, harían falta cliente, periodo, línea base, medición y atribución. Las fuentes revisadas no contienen esa evidencia. La ausencia de pruebas públicas no es una acusación contra la empresa; muchas redes no publican métricas internas o casos de clientes. Simplemente impide convertir capacidad en resultado.

Esta escalera protege al lector. Capacidad describe lo que la empresa puede ofrecer o lo que los registros muestran. Fiabilidad describe comportamiento medido durante el tiempo. Resultado describe impacto atribuido. Mezclarlas produce textos atractivos y decisiones pobres. Separarlas crea mejores preguntas: qué hay registrado, qué está anunciado, qué se valida, qué se mide, qué afecta al cliente y qué permanece desconocido.

Costes de supervisión, integración, mantenimiento y excepciones

La supervisión es el coste de saber qué estado debería existir y detectar cuándo se aparta. Para CMCL, las superficies públicas sugieren varias familias de control: identidad corporativa, dominio, ASN, bloque IPv4, ROA, rutas observadas, vecinos, contactos de registro, páginas de paquetes, soporte y enlaces de cliente. Cada una necesita propietario, revisión, evidencia temporal y forma de actuar.

La integración es el coste de hacer que identificadores distintos apunten al mismo objeto operativo. La forma larga del miembro APNIC, la marca CMCL, el ASN, el nombre CMCL-AS-AP, el dominio, el registro de PeeringDB, la cuenta de cliente, el circuito, el puerto y la subred pueden vivir en sistemas distintos. Sin una tabla de correspondencias mantenida, un incidente obliga a reconstruir identidad bajo presión.

El mantenimiento es el coste de conservar los controles cuando cambia la red. Las ROA caducan o se vuelven insuficientes. Los filtros se actualizan. Las rutas temporales deberían retirarse. Las páginas de paquetes envejecen. Los contactos cambian de equipo. Los enlaces físicos se reparan, se migran o se documentan con nombres distintos. Las fuentes no muestran proveedores ni versiones de CMCL, por lo que no se pueden describir rutinas internas; sí muestran la clase de trabajo que un proveedor de acceso debe sostener.

Las excepciones son el coste más subestimado. Un prefijo inesperado, una autorización RPKI que no cubre una emergencia, un enlace público roto, un contacto que no responde, un cliente con dirección heredada, un aviso de mantenimiento que no se puede mapear a clientes o una sesión BGP que cambia de vecino requieren juicio. Cada excepción debería tener dueño, impacto, fecha, siguiente acción y condición de cierre. Si una excepción vive demasiado, deja de ser una anomalía y se convierte en deuda operativa.

Modos concretos de fallo y controles

  1. La identidad larga de APNIC, el nombre corto de CMCL, el dominio y el ASN dejan de apuntar a la misma autoridad actual. El control es un mapa de identidad con alias, fechas, propietarios y derechos de aprobación.

  2. Un contacto RDAP existe, pero no llega a una cola operativa. El control es prueba periódica de entrega, suplentes y una ruta de escalamiento fuera del buzón principal.

  3. Un prefijo esperado desaparece por filtro, mantenimiento, error de configuración o retirada accidental. El control es monitoreo externo contra intención aprobada y procedimiento de recuperación.

  4. Un ASN no autorizado origina espacio de CMCL. El control es vigilancia de origen, filtros con proveedores, contacto de emergencia y revisión posterior basada en evidencia.

  5. Los anuncios más específicos y el maxLength de RPKI no coinciden. El control es validar cada par prefijo-origen antes y después de cambios, sin asumir que el agregado cubre los /24.

  6. La visibilidad BGP se trata como prueba de disponibilidad. El control es medir routing, reachability, autenticación, DNS, calidad de paquetes y experiencia de cliente por separado.

  7. Dos vecinos observados se interpretan como redundancia independiente. El control es mapear riesgos compartidos de fibra, instalación, energía, router, proveedor y operación.

  8. La ausencia de IPv6 observada se convierte en afirmación absoluta. El control es un estado IPv6 aprobado que distinga planificación, pruebas, anuncio público y soporte real.

  9. El inventario IPv4 interno se separa de clientes y servicios. El control es ciclo de vida de asignación con propósito, propietario, fechas, DNS inverso, política y recuperación.

  10. Un paquete comercial publicado no coincide con el perfil de provisión. El control es un catálogo único probado contra pedido, facturación, instalación y soporte.

  11. Un enlace público roto se considera cosmético aunque afecte una ruta de alta o contacto. El control es clasificar enlaces por impacto, propietario y alternativa actual.

  12. Los registros de fibra no coinciden con campo. El control es verificación física, referencia cruzada entre ducto, empalme, puerto, servicio y responsable.

  13. El sistema de monitoreo depende de la misma red que debe vigilar. El control es observación independiente, alerta fuera de banda y pruebas de modo degradado.

  14. Solo una persona o cuenta puede cambiar RDAP, ROA, DNS, router o caso de proveedor. El control es acceso por roles, suplentes, credenciales de emergencia y auditoría.

  15. Una ruta temporal o excepción de cliente se vuelve permanente. El control es registro de excepciones con vencimiento, revisión y cierre por evidencia.

  16. Un mantenimiento externo no puede mapearse a clientes afectados. El control es una relación actual entre circuito, puerto, vecino, prefijo, servicio y grupo de comunicación.

  17. La copia de capacidad se reutiliza como prueba de rendimiento. El control es una disciplina editorial y operativa que separe capacidad, fiabilidad y resultado.

  18. Una foto o documento revela información sensible. El control es revisión de publicación, uso de imágenes contextuales y separación entre documentación pública y registros protegidos.

Preguntas para un operador responsable

La primera pregunta es quién tiene autoridad actual sobre AS137029, el bloque 103.102.136.0/22, el dominio cmclbd.com, los contactos públicos y los contratos de conectividad. La segunda es qué prefijos debe originar AS137029 ahora, cuáles son permanentes, cuáles temporales y cuáles existen solo para ingeniería de tráfico. La tercera es qué ROA deberían existir y cómo se comprueba que el maxLength coincide con la política real.

La cuarta pregunta mira los handoffs externos: qué rutas físicas y lógicas hay detrás de los vecinos observados, de las menciones de IIG y de las conexiones de intercambio. La quinta mira al cliente: qué incluye cada paquete, dónde termina la responsabilidad de CMCL y qué mediciones separan una capacidad comercial de una fiabilidad demostrada. La sexta mira IPv6: cuál es el estado aprobado y qué falta antes de una activación pública responsable.

La séptima mira continuidad física: si un enlace falla fuera de horario, ¿puede el equipo localizar fibra, puerto, circuito, energía, repuesto y contacto de campo? La octava mira información pública: quién mantiene paquetes, contactos, formularios y enlaces. La novena mira deuda: qué excepciones de routing, direcciones, clientes, facturación o soporte siguen abiertas, cuánto tiempo llevan y qué evidencia las cerrará.

Incógnitas y conclusión

La evidencia pública establece una empresa y una identidad de red suficientemente coherentes para un análisis tecnológico. Establece la relación entre el objeto de directorio, el nombre CMCL, APNIC, AS137029, un bloque IPv4 portátil, PeeringDB, rutas observadas y un sitio de servicios de Internet. También establece límites: no hay base pública para afirmar topología privada, SLA, capacidad contratada, clientes, incidentes, personal, ingresos, pruebas de rendimiento ni resultados.

El caso muestra una lección práctica. La continuidad de un ISP no nace de un único registro, una única ruta ni una página de paquetes. Nace de mantener relaciones exactas entre autoridad, recursos numéricos, rutas, seguridad de origen, fibra, interconexión, provisión, soporte y comunicación. Un registro regional es un libro de referencia necesario. BGP muestra parte del estado en ejecución. RPKI añade metadatos de seguridad. El sitio comunica capacidad. Ninguno de esos elementos, por sí solo, prueba el servicio completo.

Chittagong Multi Channel Limited, visto a través de AS137029, es por tanto un caso de disciplina operativa. La evidencia disponible no justifica adornos ni promesas. Sí justifica observar cómo una empresa regional de acceso debe alinear recursos IPv4, routing público, ROA, contactos, handoffs externos, paquetes de cliente y mantenimiento. En esa alineación se encuentran los verdaderos costes de continuidad: supervisar, integrar, mantener y cerrar excepciones antes de que se conviertan en fallos visibles.

Fuentes

  1. Directorio BTW: Nizam Uddin Mazud T/A Chittagong Multi Channel Limited
  2. Directorio de miembros de APNIC
  3. Página principal de CMCL
  4. Página de paquetes de CMCL
  5. Página de contacto de CMCL
  6. APNIC RDAP: AS137029
  7. APNIC RDAP: 103.102.136.0/22
  8. PeeringDB organización: Chittagong Multi Channel Limited
  9. PeeringDB red: AS137029
  10. RIPEstat AS overview: AS137029
  11. RIPEstat announced prefixes: AS137029
  12. RIPEstat routing status: AS137029
  13. RIPEstat RPKI validation: AS137029 y 103.102.136.0/22
  14. RIPEstat observed ASN neighbours: AS137029
  15. Wikimedia Commons: bobinas de fibra óptica en almacenamiento