Resumen
- A las 08:00 UTC del 16 de julio de 2026, RIPE RIS observó a AS135632 originando
103.77.9.0/24,116.206.164.0/24y116.206.167.0/24: 768 direcciones IPv4 en tres rutas, sin IPv6 originado. Cada uno de los 1,063 caminos AS recopilados colocó a AS141421, MUX Broadband, inmediatamente antes de Cactus. - La evidencia establece un sistema autónomo vecino visible, no un cable físico. No revela cuántas sesiones BGP, traspasos, circuitos, enrutadores, edificios, repetidores en azoteas, conductos o dominios de energía se encuentran debajo de esa relación lógica.
- El parque de rutas ha cambiado materialmente. RIPE vio ocho prefijos IPv4 y un vecino en julio de 2025, ninguna ruta originada por Cactus en una instantánea de mediados de octubre, siete prefijos a través de AS141421 para abril de 2026, y tres para mayo. Esas observaciones prueban cambios de enrutamiento, no pérdida de clientes, migración física o reducción de capacidad instalada.
- El sitio web y el correo de Cactus están alojados en AS31898, no en AS135632, por lo que esas superficies de contacto público podrían permanecer accesibles durante una retirada de las rutas originadas por Cactus. El acceso de los clientes, los servicios locales, la conmutación interna y las operaciones de soporte dependerían de acuerdos que no son visibles en el enrutamiento público ni en el material de la empresa.
La sesión se detiene a las 08:00 UTC
Comience con el fallo, no con el folleto.
A las 08:00 UTC, la sesión de borde que transporta los tres prefijos públicos de Cactus Network Solutions a AS141421 deja de intercambiar accesibilidad utilizable. La causa podría ser una interfaz fallida, un error de mantenimiento ascendente, un reinicio del enrutador, un circuito de acceso dañado, un error de configuración o una pérdida de energía en cualquiera de los extremos. Una vez que expire cualquier intervalo de retención de rutas, y siempre que no comience a anunciar los mismos prefijos una segunda sesión o vecino, el efecto fuera de la red es simple: otros sistemas autónomos dejan de aprender cómo llegar a103.77.9.0/24,116.206.164.0/24y116.206.167.0/24.
Esa no es una topología hipotética inventada a partir de un nombre de empresa. Lainstantánea de estado de enrutamiento de RIPEstaten la fecha de publicación contó tres rutas IPv4 originadas, 768 direcciones, ninguna ruta IPv6 y un vecino observado. Lacaptura de estado BGPcorrespondiente contenía 1,063 caminos de colectores. AS135632 era el origen en todos ellos, y AS141421 era el sistema autónomo inmediatamente precedente en todos ellos.
Lo que permanece accesible en el momento del fallo es más revelador que lo que desaparece.
El dominio público de Cactus se resolvió a192.185.56.104en larespuesta A devuelta por Google Public DNS. Larespuesta de información de red de RIPE para esa direccióncolocó su ruta de cobertura en AS31898, fuera de AS135632. Elintercambiador de correodel dominio eramail.cactuspk.com, quese resolvió a la misma dirección IPv4 alojada externamente. Susservidores de nombres autoritativostambién usaban el espacio de nombreswebsitewelcome.com. Por lo tanto, la retirada de las rutas propias de Cactus no retiraría, por sí misma, el prefijo de alojamiento del sitio web público ni el prefijo del host de correo.
El sitio web podría seguir cargando. Un servidor de correo podría seguir aceptando correo. Un llamante podría seguir llegando al número de teléfono publicado a través de un servicio de telecomunicaciones separado. Ninguno de esos resultados prueba que un suscriptor de Cactus pueda llegar a Internet en general. El personal dentro de una oficina atendida por Cactus podría no poder llegar a los sistemas de soporte alojados externamente incluso mientras esos sistemas permanecen disponibles para todos los demás.
Un cliente y un ingeniero de soporte podrían así ver lados opuestos del mismo fallo: la página de soporte está en línea desde el extranjero, mientras que el circuito del cliente no tiene ruta utilizable de salida.
La comunicación local es una incógnita separada. Si las radios de acceso al cliente, los conmutadores, las direcciones y los servicios locales permanecen alimentados, los paquetes entre dos puntos dentro del mismo dominio de enrutamiento podrían continuar moviéndose sin una ruta global. También podrían depender de sistemas centrales o caminos que fallan con el traspaso ascendente. La evidencia pública no muestra la topología interna, si los suscriptores usan direccionamiento público o privado, dónde ocurre la autenticación, o si el tráfico local se conmuta localmente.
La respuesta correcta a "¿qué permanece accesible?" es consecuentemente una lista a medir, no una suposición segura.
Lo que establece la tabla de enrutamiento pública
BGP es un protocolo de accesibilidad entre dominios. Laespecificación básica de BGPdescribe el intercambio de prefijos e información de camino AS entre sistemas de enrutamiento. No codifica una ruta callejera, dibujo de fibra, ubicación en azotea, alimentación eléctrica, velocidad de puerto o contrato de reparación. La evidencia de Cactus debe mantenerse en esas capas.
| Palabra de evidencia | Qué significa aquí | Qué no significa |
|---|---|---|
| Registrado | Un registro de un registro público asocia una organización, contacto o recurso numérico con Cactus. | El recurso está actualmente enrutado, ocupado, físicamente en Lahore o transportando clientes. |
| Anunciado | AS135632 originó un prefijo en BGP durante un intervalo declarado. | Cada dirección estaba activa, la capacidad estaba disponible, o cada cliente podía pasar tráfico. |
| Observado | Los colectores de RIPE recibieron una ruta o camino AS en un momento declarado. | Toda red en el mundo vio el mismo camino, o el camino se mapea a un circuito físico. |
| Desconocido | El material público no estableció el hecho. | El activo o salvaguarda está ausente, defectuoso o sin uso. |
En el corte de publicación, elresultado de prefijos anunciados de RIPE para el 1-16 de juliomostró los mismos tres /24 continuamente desde el inicio del intervalo solicitado hasta la observación más reciente disponible a las 08:00 UTC del 16 de julio. El resultado de estado de enrutamiento dijo que 320 de 326 pares IPv4 de RIS vieron las rutas. No se visible ningún prefijo IPv6 para ninguno de los 321 pares IPv6 en esa instantánea.
La evidencia de camino por prefijo es inusualmente consistente. RIPE devolvió360 caminos para103.77.9.0/24,360 para116.206.164.0/24y343 para116.206.167.0/24. Cada camino capturado para cada prefijo terminabaAS141421 AS135632. No hubo ningún camino recopilado en el que apareciera otro sistema autónomo directamente antes de Cactus.
Ese hallazgo es más fuerte que decir que un directorio comercial enumera un proveedor. Es una observación ruta por ruta a través de cientos de vistas de colectores. Sin embargo, su límite es igualmente importante. Varios enlaces físicos o varias sesiones BGP pueden existir entre los mismos dos sistemas autónomos mientras producen el mismo camino AS. Por el contrario, una sesión BGP puede transportarse sobre infraestructura con protección oculta dentro de la red de un proveedor. El camino AS solo no puede distinguir esos casos.
Elperfil de PeeringDB mantenido por el operador para AS135632identifica a Cactus, también usando el nombre Sprint Broadband, como una red de cable/DSL/ISP de Pakistán. No publica filas de intercambio o instalación. Esa ausencia limita lo que se puede verificar a través de PeeringDB; no prueba que Cactus no tenga equipos en una instalación compartida, ninguna interconexión privada, ningún acceso remoto a intercambio y ningún servicio mayorista protegido.
Elregistro de organización de APNIC para ORG-CNSP1-APidentifica a Cactus Network Solutions (CNS) Pvt Ltd como un registro local de Internet de Pakistán y da una dirección en New Garden Town, Lahore. Elregistro de mantenedory elregistro de contacto de respuesta a incidentespreservan la misma identidad organizativa y el mantenimiento de contacto actual. Estos son buena evidencia de que la empresa sigue siendo un titular de recursos activo. Una dirección administrativa no es evidencia de un enrutador central, repetidor, almacén, punto de agregación de clientes o traspaso ascendente en ese edificio.
Tres /24 no son ni capacidad ni recuento de clientes
Un /24 contiene 256 direcciones IPv4. Tres /24 contienen por lo tanto 768 direcciones. Esta aritmética es exacta y operativamente limitada.
El número no revela suscriptores. Un hogar podría recibir una dirección pública, muchos hogares podrían compartir una a través de traducción de operador, una empresa podría recibir varias, e interfaces de infraestructura podrían consumir parte del grupo. Las direcciones también pueden estar reservadas, enrutadas pero inactivas, usadas para equipos de red o asignadas dinámicamente. Ninguna fuente pública establece la política de direccionamiento actual de Cactus.
Tampoco el recuento de direcciones revela ancho de banda. Un compromiso de tránsito de 100 Mbps y un compromiso de tránsito de 10 Gbps pueden originar los mismos tres prefijos. Las rutas dicen hacia dónde deben ir los paquetes; no indican cuánto tráfico puede transportar el traspaso antes de la congestión, qué clases se priorizan, qué términos de ráfaga se aplican, o cuánta capacidad de repuesto existe después de un fallo.
Cada /24 tiene su propia historia pero la misma salida actual
Las tres rutas actuales no deben tratarse como una estadística indivisible. Cada una se anuncia independientemente, puede retirarse independientemente y puede transportar una mezcla diferente de direcciones de infraestructura o suscriptores. Los datos públicos no revelan esa mezcla, pero hacen que el comportamiento de enrutamiento de cada /24 sea observable por separado.
| Ruta actual | Caminos capturados a las 08:00 UTC | Continuidad observada reciente | Vecino inmediato actual | Resultado de validación de origen |
|---|---|---|---|---|
103.77.9.0/24 | 360 | Visible durante todo el 1-16 de julio; ausente del 16 de abril al 12 de mayo antes de regresar | AS141421 | Desconocido |
116.206.164.0/24 | 360 | Visible durante todo el 1-16 de julio; continuamente visible desde el 8 de enero hasta el corte de publicación después de breves lagunas a principios de enero | AS141421 | Desconocido |
116.206.167.0/24 | 343 | Visible durante todo el 1-16 de julio; continuamente visible desde el 1 de noviembre de 2025 hasta el corte de publicación | AS141421 | Desconocido |
El menor número de caminos para116.206.167.0/24no es evidencia de menor ancho de banda o peor servicio al cliente. Significa que menos caminos de colectores estaban presentes en esa respuesta capturada. La participación, el filtrado y la sincronización de los colectores pueden diferir. Lo que es común en los tres resultados es más importante: cada camino capturado usó AS141421 en el límite AS externo final.
Tampoco había ninguna ruta de cobertura observada para absorber la pérdida de un anuncio más específico. RIPE no devolvió estado BGP para la cobertura103.77.8.0/22o116.206.164.0/22en la misma marca de tiempo. Por lo tanto, en la tabla pública capturada, la retirada de103.77.9.0/24no dejaría una ruta /22 originada por Cactus cubriéndolo. Lo mismo es cierto para los dos /24 de116.206visibles.
Ese detalle le da a Cactus dos problemas de resiliencia diferentes.
El primero es el fallo compartido. Si el límite AS135632-AS141421 deja de transportar todas las exportaciones, las tres rutas pueden desaparecer juntas porque comparten el mismo vecino visible. El segundo es el fallo selectivo. Un filtro de ruta, un error de política específico de prefijo o un problema de originación local pueden eliminar un /24 mientras los otros dos permanecen saludables. Los clientes en el rango afectado podrían ser inalcanzables incluso mientras un panel de agregado dice que AS135632 sigue en línea.
Por eso un monitor externo debería probar al menos una dirección controlada en cada prefijo originado. Una única sonda al sitio web de la empresa sería inútil porque el sitio está fuera del ASN de Cactus. Una única sonda dentro de116.206.167.0/24pasaría por alto una retirada selectiva de103.77.9.0/24. La accesibilidad debe probarse desde varias redes independientes, con el resultado vinculado al estado BGP al mismo tiempo. Eso distinguiría al menos tres eventos: ruta ausente, ruta presente pero punto final no disponible, y punto final accesible con entrega de paquetes degradada.
El historial de rutas también le da al operador un caso de prueba natural.103.77.9.0/24regresó después de casi cuatro semanas de ausencia en abril y mayo de 2026, mientras que116.206.164.0/24y116.206.167.0/24eran visibles en ambos lados de ese intervalo. Los datos públicos no pueden decir si la ruta que regresa transportaba suscriptores, infraestructura o espacio no utilizado. Cactus puede. Podría usar el evento para explicar si la retirada fue planificada, cómo se manejaron los usuarios de direcciones, qué alarmas sonaron y por qué regresó la ruta.
Los cuatro /24 que ya no son visibles después del 16 de abril merecen la misma redacción disciplinada.103.77.10.0/24,103.77.11.0/24,116.206.165.0/24y116.206.166.0/24aparecieron en el historial de RIPE y estaban ausentes en la publicación. Eso es un hecho de anuncio. No es evidencia de que el espacio de direcciones registrado correspondiente se haya vendido, abandonado, revocado o desconectado físicamente. Un inventario de prefijos actual debería etiquetar cada bloque como enrutado, reservado, usado internamente, asignado a través de otro acuerdo o retirado, con la fecha y la autoridad del estado.
Para un comprador, esto no es un detalle administrativo. Si una dirección estática prometida se encuentra en un /24 que a veces se retira independientemente, la pregunta de nivel de servicio es específica de la ruta. Si los equipos críticos están distribuidos en dos de los /24 actuales, eso puede proteger contra un error específico de prefijo pero no contra el límite común AS141421. Si todos los grupos de traducción de clientes, resolutores DNS y sistemas de gestión se encuentran en un /24, las otras dos rutas pueden ofrecer menos separación práctica de lo que sugiere el recuento de rutas. La tabla pública no puede revelar esas ubicaciones.
La huella de tres rutas es por lo tanto lo suficientemente pequeña como para auditarse con precisión. Cactus puede publicar un inventario no sensible, monitorear cada prefijo, probar exportaciones normales y alternativas, y preservar un registro de eventos cuando cambie cualquier ruta. Eso sería más informativo que un amplio porcentaje de tiempo de actividad porque mostraría exactamente qué población de direcciones permaneció accesible bajo qué fallo.
La página de inicio de la empresa hace afirmaciones de apariencia mucho más grande, incluyendo servicio de gigabit, una red inalámbrica todo IP, líneas arrendadas institucionales y más de 20,000 usuarios de confianza. Pero lapágina de inicio en vivo de Cactustambién contiene texto de ventas sobre planes de banda ancha en India, testimonios de proveedores de temas y lenguaje genérico no relacionado con el operador de Lahore. Lapágina de contactoincluye una afirmación de popularidad de Aivahthemes junto con la dirección de Lahore. Unapágina de contactosseparada tiene detalles de muestra de Chicago y Nueva York. Esos residuos hacen que las afirmaciones de escala numérica del sitio no sean adecuadas como hechos operativos.
La conclusión más segura es más pequeña. El sitio es accesible, presenta a Cactus como un proveedor de Internet residencial y empresarial, publica datos de contacto de Lahore, y discute servicios inalámbricos, de fibra y líneas arrendadas. No proporciona un total de suscriptores actual confiable, mapa de cobertura ordenable, inventario de torres activo, capacidad de tránsito, serie de utilización o registro de tiempo de actividad auditado. La huella de ruta de 768 direcciones no debe inflarse con números de textos de ventas comprometidos.
Unapágina de IPinfo independiente para AS135632corrobora la vista actual de tres prefijos, 768 direcciones y cero IPv6, y etiqueta la red como un ISP de consumo. También informa un pequeño conjunto de direcciones de Cactus que responden a ping. Esas sondas apoyan la proposición de que los puntos finales en las rutas responden desde Pakistán; no identifican clientes, áreas de servicio activo, sitios de radio, congestión o resiliencia. Unperfil de bgp.tools independientetodavía enumera siete prefijos IPv4 y el mismo ASN ascendente. Su recuento más grande refleja un inventario más amplio o con diferente sincronización que la vista de RIPE en la fecha de publicación. La diferencia es una razón para marcar la hora de las afirmaciones, no para seleccionar el número más grande.
El parque de rutas ya ha cambiado
La evidencia más útil sobre la conmutación por error no es una promesa. Es lo que han hecho las rutas.
El16 de julio de 2025, RIPE observó a AS135632 originando ocho prefijos IPv4, cubriendo 2,048 direcciones, sin IPv6 y un vecino. El vecino visible ese día era AS24499, Telenor Pakistan, como muestra larespuesta de vecinos históricos. Esto es evidencia de un límite ascendente público diferente del visto en julio de 2026.
Elhistorial de anuncios de un añoregistra entonces una ruptura brusca. Los prefijos visibles en el verano de 2025 terminaron el 26 de septiembre. Elflujo de actualizaciones de RIPE para103.77.9.0/24muestra retiradas generalizadas después de caminos a través de AS24499. Ningún prefijo originado por AS135632 aparece en la instantánea de estado de enrutamiento de mediados de octubre.
El 22 de octubre, los anuncios regresaron. Elflujo de actualizaciones alrededor de la restauraciónmuestra nuevos caminos que terminanAS141421 AS135632. Para el15 de abril de 2026, siete /24 IPv4 eran visibles a través de un vecino observado, AS141421. Cuatro de esos siete dejaron de aparecer el 16 de abril.103.77.9.0/24también desapareció y regresó el 12 de mayo. Lainstantánea del 13 de mayose había establecido en el total actual de tres.
Estas marcas de tiempo establecen tres cosas.
Primero, AS135632 ha cambiado su límite ascendente visible. Segundo, su conjunto de rutas públicas se ha contraído de ocho a siete a tres en el período observado. Tercero, hubo un intervalo de aproximadamente 26 días entre la retirada de septiembre y la restauración de octubre durante el cual RIPE no vio un anuncio de AS135632.
No establecen por qué. Una ausencia visible para el colector podría coincidir con una migración de proveedor, un cambio de enrutamiento deliberado, el uso de direcciones asignadas por el proveedor, un error de política, un servicio suspendido u otra condición. No nos dice si los clientes minoristas estaban desconectados, movidos detrás de otro espacio público, atendidos a través de otro ASN, usando conectividad privada, o aún no activos. Del mismo modo, la retirada de cuatro /24 en abril de 2026 no prueba que Cactus perdiera clientes o desmantelara equipos.
Esas direcciones podrían no estar en uso, mantenidas, enrutadas de manera diferente o esperando otro propósito.
El historial, sin embargo, importa a un comprador. Prueba que la configuración pública no es estática y que ha ocurrido un cambio de vecino. Una explicación de resiliencia creíble debería responder no solo "¿quién es el ascendente hoy?" sino también "¿cómo continuó el tráfico durante la última transición ascendente, qué prefijos se movieron, cuánto tiempo tomó la convergencia y qué experimentaron los clientes?"
Un vecino puede ocultar varios circuitos, pero no un segundo camino AS
AS141421 es identificado por elregistro de sistema autónomo de APNICcomo MUX Broadband (Private) Limited en Pakistán. En el mismo corte de tiempo de publicación, elestado de enrutamiento de RIPE para MUXmostró cinco prefijos IPv4 originados, tres prefijos IPv6 y siete vecinos observados. Suvista de vecinosincluía tres sistemas autónomos que aparecían antes de MUX en caminos observados y cuatro que aparecían después, uno de ellos AS135632.
La conectividad más amplia de MUX puede hacer que el servicio que vende sea más resiliente que un solo enlace externo. Esa resiliencia no puede transferirse automáticamente a Cactus. El límite de fallo en cuestión es el límite entre AS135632 y AS141421. Si MUX mantiene excelentes rutas a Internet en general pero Cactus no puede entregar sus prefijos a MUX, esas opciones ascendentes no ayudan a las direcciones de Cactus. Lo mismo se aplica si un enrutador de borde compartido de Cactus, traspaso local, fuente de alimentación o configuración falla antes de que el tráfico llegue a MUX.
Al mismo tiempo, el resultado de un vecino no justifica dibujar una línea en un mapa de la ciudad. Cactus podría tener dos circuitos a MUX en diferentes ubicaciones, dos enrutadores en un circuito, dos sesiones sobre un servicio protegido, o un traspaso no protegido. MUX podría transportar tráfico sobre infraestructura redundante internamente. Ninguno de esos diseños es visible en el camino AS. La ruta física exacta entre las empresas, incluido si cruza Lahore, Multan o cualquier instalación nombrada, se desconoce.
Una evaluación oficial de adquisiciones de atención médica de Punjab crea una tensión útil. Elinforme técnico de ofertas del 19 de julio de 2023marcó a Cactus "Sí" contra un requisito de que un licitador tenga dos proveedores ascendentes, escritos como PIE y TW1. La misma tabla lo marcó como conforme para la licencia LL/CVAS y finalmente receptivo.
Ese documento es una fuerte evidencia de lo que los evaluadores de adquisiciones aceptaron en 2023. No es un diagrama BGP actual. No identifica los circuitos, ASN, sitios, anuncios de ruta, períodos de contrato o comportamiento de conmutación por error detrás de la respuesta de dos ascendentes. El requisito puede haber concernido a un servicio gestionado particular, proveedores mayoristas detrás de otro proveedor, capacidad comercial entonces actual o evidencia no reproducida en la evaluación de dos páginas.
La vista actual de RIPE, por el contrario, responde una pregunta más estrecha: qué sistema autónomo apareció directamente antes de AS135632 en caminos públicos el 16 de julio de 2026. La respuesta fue solo AS141421.
El "Sí" de la adquisición y la instantánea de enrutamiento no son, por lo tanto, mutuamente excluyentes. Juntos, definen la pregunta de diligencia debida. Cactus puede resolverla identificando los dos dominios de fallo actuales, mostrando qué prefijos públicos transporta cada uno, y demostrando que una pérdida controlada de uno hace que el otro anuncie y reenvíe rutas utilizables dentro de un intervalo declarado.
IPv6 está ausente, pero no sería un respaldo mágico
El parque de rutas actual de Cactus no tiene una segunda familia de direcciones visible. RIPE contó cero prefijos IPv6 originados en julio de 2025, abril de 2026, mayo de 2026 y la instantánea de la fecha de publicación. IPinfo y bgp.tools informan independientemente la misma ausencia. El dominio público de Cactus también devolvió ninguna dirección en larespuesta AAAA de Google Public DNS.
IPv6 es un protocolo de capa de red distinto, especificado enRFC 8200, con un espacio de direcciones mucho mayor que IPv4. En un servicio de doble pila correctamente diseñado, un cliente y una aplicación pueden tener accesibilidad tanto IPv4 como IPv6. Las técnicas de cliente descritas porHappy Eyeballs Version 2pueden probar las familias disponibles de una manera destinada a reducir la latencia visible para el usuario cuando un camino es pobre.
Pero IPv6 no es un sustituto automático para una ruta IPv4 fallida. El dispositivo del cliente debe recibir una configuración IPv6 funcional. La red de acceso debe transportarla. DNS debe publicar un destino IPv6 cuando corresponda. El destino debe estar disponible sobre IPv6. Cactus debe anunciar un prefijo IPv6, y la relación ascendente debe transportarlo. Ninguna de esa evidencia de ruta pública existe para AS135632 en el corte.
Incluso si Cactus agregara IPv6 mañana, la diversidad de familias de direcciones no crearía necesariamente diversidad física. IPv4 e IPv6 pueden atravesar el mismo enrutador, la misma radio, la misma fibra, el mismo traspaso y el mismo ASN ascendente. Una pérdida de energía o corte en ese punto común eliminaría ambos. Por el contrario, IPv6 entregado sobre un camino con energía independiente y enrutado independiente podría preservar algunas aplicaciones de doble pila durante un fallo de enrutamiento específico de IPv4. El beneficio depende de la implementación, no de la presencia de una asignación IPv6 sola.
El propio estado de ruta de MUX prueba que el vecino visible es capaz de originar IPv6. No prueba que MUX ofrezca a Cactus un servicio IPv6, que Cactus haya solicitado uno, o que el equipo del cliente esté listo. La ausencia en el momento de la publicación es, por lo tanto, específica: ninguna ruta IPv6 originada por Cactus era visible. La razón, el plan de implementación y el efecto en el cliente son desconocidos.
Esto importa económicamente además de técnicamente. Un grupo pequeño de IPv4 puede fomentar el intercambio de direcciones, complicando los servicios entrantes, el manejo de abusos y la atribución de clientes. IPv6 puede reducir la escasez de direcciones y mejorar la accesibilidad de extremo a extremo para servicios compatibles. Sin embargo, la implementación requiere soporte en las instalaciones del cliente, monitoreo, política de seguridad, práctica del personal y preparación del servicio de ayuda.
Para un proveedor regional, la prueba no es "¿soporta el ascendente IPv6?" sino "¿puede un cliente usarlo, puede el personal de operaciones diagnosticarlo, y sobrevive a un fallo definido?"
La última milla está sugerida, no mapeada
Cactus se presenta como un proveedor de acceso local más que un mero caparazón de enrutamiento. Supágina de serviciossepara la conectividad residencial, empresarial y personalizada. Lapágina de servicios empresarialesdiscute banda ancha dedicada, gestión de red y conectividad segura. La página de inicio se refiere a una red inalámbrica todo IP y pide a los usuarios que verifiquen si hay torres en su localidad.
Esas descripciones apoyan una inferencia amplia de que Cactus ha comercializado acceso de última milla y empresarial, incluyendo entrega inalámbrica. No establecen un recuento actual de torres, ruta de fibra, parque de postes, tenencia de espectro con licencia, inventario de instalaciones del cliente o límite de servicio. El residuo de tema predeterminado del sitio hace que sus porcentajes, totales de suscriptores y lenguaje de cobertura amplia sean especialmente débiles.
Un documento más concreto pero histórico es unapropuesta de Cactus fechada el 25 de septiembre de 2020, cargada públicamente en Scribd. Proponía un enlace punto a punto de 20 Mbps de tasa de información comprometida en Lahore usando dos antenas de 34 dBi y dos unidades AirFiber de 5 GHz. Permitía dos días para la instalación, incluía mantenimiento recurrente del enlace y la torre, se refería al registro de frecuencia, y asignaba la alimentación y puesta a tierra adecuadas en el sitio del cliente al cliente.
La propuesta es útil porque describe un diseño comercial real bajo el nombre de Cactus. Es limitada porque tiene seis años, es específica de un circuito propuesto, está alojada por un tercero y no es prueba de que el enlace se ordenara, instalara o siguiera activo. No puede extrapolarse a un mapa actual de torres de Cactus. Sin embargo, identifica superficies de fallo que siguen siendo técnicamente plausibles para inalámbrico fijo: línea de visión, alineación de antenas, acceso a azoteas, salud de la radio, interferencia, energía en el sitio del cliente, puesta a tierra y disponibilidad de equipos de repuesto.
Ninguna fuente revisada proporciona coordenadas de un repetidor o torre operativa de Cactus. Las direcciones de Garden Town en los registros de la empresa y APNIC son ubicaciones de contacto administrativo. La dirección de Al-Qadir en la propuesta de 2020 es una dirección de oficina histórica. Ninguna debe trazarse como un nodo de red sin evidencia separada.
La fibra está igualmente sin resolver. El sitio en vivo usa lenguaje de fibra, y un proveedor puede ofrecer acceso de fibra sin poseer cada cable, conducto o poste. El material público no identifica si Cactus posee fibra de acceso, arrienda colas, revende a otro operador, combina inalámbrico y fibra, o entrega clientes a infraestructura de terceros. Un camino BGP a través de MUX no puede responder esa pregunta. La adyacencia lógica podría sentarse sobre cualquiera de esos arreglos físicos.
La energía y la reparación en campo deciden si una ruta es utilizable
La diversidad de enrutamiento es valiosa solo si el equipo que la utiliza permanece alimentado y reparable.
Considere cuatro fallos. Si una radio de azotea pierde energía pero el borde de Cactus continúa anunciando los tres prefijos, la tabla de enrutamiento global puede verse saludable mientras los clientes detrás de ese repetidor están desconectados. Si la sesión de borde a MUX falla mientras la red de acceso permanece alimentada, los enlaces locales pueden mantenerse pero los destinos externos pueden desaparecer. Si tanto el circuito nominal como el alternativo entran al mismo edificio y un evento de energía local deshabilita el enrutador compartido, dos contratos no producen diversidad utilizable.
Si una tormenta mueve una antena punto a punto, la capacidad ascendente de repuesto no restaura la línea de visión.
La propuesta inalámbrica de 2020 hizo explícitamente de la energía y puesta a tierra en el sitio del cliente una condición de puesta en servicio y excluyó daños causados por sobretensiones, fluctuaciones o puesta a tierra inadecuada. Ese límite contractual es operativamente importante. Sugiere al menos un diseño histórico de Cactus en el que la disponibilidad del servicio dependía en parte de condiciones eléctricas controladas por el cliente. No revela si Cactus suministró energía ininterrumpida, baterías o protección contra sobretensiones en otros lugares, o qué tiempo de funcionamiento tenía cualquier sistema de respaldo.
Unacuerdo de servicios de soporte separado con fecha de diciembre de 2020, también cargado públicamente, describía diagnóstico remoto primero y una visita al sitio si el trabajo remoto fallaba. Enumera un número de soporte, varios contactos técnicos y una secuencia de escalamiento de gestión. Esto es evidencia de que Cactus documentó una práctica de escalamiento en campo para un cliente en ese momento. No es un lista de personal actual, un compromiso de fallo de red o una prueba de que las mismas personas, horas y tiempos de respuesta cubren a los clientes de banda ancha en 2026.
Lapágina de contacto actual de Cactusenumera una dirección en Awami Complex en Garden Town, un número de teléfono, correo electrónico y horario de oficina de 9 a 17 horas. El sitio en otros lugares afirma soporte extenso o las 24 horas. Debido a que las mismas páginas contienen contenido predeterminado no relacionado, la promesa exacta de soporte requiere confirmación en un contrato de cliente actual.
Para un operador pequeño, la mano de obra local puede ser la reserva efectiva. Una radio de repuesto en un armario es útil solo si alguien puede identificar la unidad fallida, obtener acceso a la azotea, viajar por Lahore, alinear el reemplazo de manera segura y cerrar el fallo. Una segunda sesión de tránsito es útil solo si alguien la monitorea, mantiene la paridad de políticas y nota cuando ha dejado silenciosamente de aceptar un prefijo. El número de técnicos es menos importante que la cobertura probada de habilidades, turnos, permisos de acceso y repuestos.
Ninguna de esas cantidades es pública para Cactus. No hay una serie actual de tiempo medio de reparación, horario de guardia, inventario de repuestos, plan de acceso a azotea, tiempo de funcionamiento de baterías, política de generadores, reserva de combustible, ventana de mantenimiento, cobertura de monitoreo o informe posterior al incidente. Su ausencia del material público no es prueba de operaciones débiles. Significa que un cliente no puede valorar la resiliencia solo desde el sitio web y la tabla BGP.
La seguridad de origen de ruta es una prueba diferente
Los tres prefijos actuales devolvieron un resultadodesconocidodel servicio de validación de origen de ruta de RIPE:103.77.9.0/24,116.206.164.0/24y116.206.167.0/24. No se devolvieron autorizaciones de origen de ruta validadas.
La validación de origen, descrita enRFC 6811, permite a un enrutador comparar un prefijo anunciado y el ASN de origen con datos de autorización criptográficamente verificables. Un estado desconocido no es una ruta inválida. Significa que el sistema de validación no encontró una autorización de cobertura que hiciera el anuncio válido o inválido.
Publicar autorizaciones correctas podría reducir una clase de riesgo de enrutamiento: que otra red origine accidental o maliciosamente el espacio de Cactus. No crearía un segundo ascendente, agregaría ancho de banda, alimentaría una radio o acortaría un viaje de reparación. La disponibilidad y la seguridad de origen de ruta deben medirse por separado. Una red resiliente puede tener una protección de origen débil, y una ruta perfectamente autorizada puede desaparecer cuando su único traspaso utilizable falla.
Una afirmación de resiliencia comprobable tiene cinco partes
Cactus no necesita revelar diagramas sensibles para hacer su resiliencia evaluable. Necesita publicar o proporcionar respuestas verificables en los límites donde los fallos se propagan.
1. Exportar las mismas rutas sobre un alternativo genuinamente utilizable
Para cada uno de los tres /24 actuales, identificar los arreglos de enrutamiento externo normal y alternativo. Si ambas sesiones son con AS141421, declarar si terminan en diferentes enrutadores de Cactus, diferentes dispositivos de MUX, diferentes sitios de traspaso y circuitos de acceso físicamente independientes. Si existe un segundo sistema autónomo, mostrar que cada prefijo es aceptado y propagado a través de él.
Luego realizar una retirada controlada de la sesión normal. Medir el tiempo hasta que las sondas externas recuperen la accesibilidad estable a través del alternativo. Probar las tres rutas, no una dirección representativa. Registrar si las sesiones de cliente con estado sobreviven, si los grupos de traducción cambian, y si los caminos de retorno siguen siendo utilizables.
La respuesta de adquisición de 2023 sobre dos ascendentes hace esta prueba especialmente razonable. Un comprador debería pedir evidencia actual en lugar de asumir que una respuesta de oferta de hace tres años todavía describe el borde de producción.
2. Separar la diversidad lógica de la diversidad física
Documentar los sitios de traspaso y los puntos de fallo comunes a un nivel adecuado para el cliente. Dos sesiones BGP en un enrutador no son diversidad de enrutadores. Dos circuitos en un conducto no son diversidad de ruta. Dos radios en una fuente de alimentación no protegida no son diversidad de energía. Dos proveedores que dependen de la misma cola mayorista pueden no ser diversidad de proveedores en el punto que importa.
El camino AS público no puede resolver ninguna de estas condiciones. Cactus y sus proveedores pueden, a través de identificadores de circuito, registros de demarcación, declaraciones de entrada diversa y un ejercicio de fallo controlado.
3. Tratar IPv6 como un servicio operativo
Un plan IPv6 debe incluir espacio asignado, autorización de ruta, transporte ascendente, delegación de clientes, comportamiento del resolutor, política de cortafuegos, monitoreo y soporte. Un piloto debe probar que los clientes de doble pila alcanzan destinos de prueba independientes sobre ambas familias y que un fallo específico de familia no causa un retraso inaceptable en la aplicación.
Si IPv4 e IPv6 comparten el mismo traspaso físico, decirlo. La segunda familia aún mejora la disponibilidad de direcciones y el alcance del protocolo, pero no debe venderse como protección contra un fallo común de circuito o energía.
4. Medir la energía en cada dependencia
Declarar el tiempo de funcionamiento del respaldo bajo carga para el enrutador de borde, traspaso ascendente, conmutador de acceso, radio de repetidor y equipo en las instalaciones del cliente incluido en el servicio. Probar las baterías en lugar de citar la capacidad nominal. Identificar qué lado es responsable de la puesta a tierra, la protección contra sobretensiones y el reemplazo. Si se usa generación, registrar el comportamiento de arranque, la disponibilidad de combustible y la carga que realmente puede soportarse.
La propuesta histórica muestra por qué este límite importa: un servicio puede comisionarse técnicamente mientras se deja una dependencia eléctrica decisiva con el cliente.
5. Poner la recuperación en campo en la promesa de servicio
Definir cuándo comienza el reloj de reparación, qué evidencia abre un fallo, qué horas están cubiertas y qué eventos pausan el reloj. Mantener radios compatibles, unidades de potencia, ópticas y enrutadores en cantidades conocidas. Verificar el acceso a azoteas y sitios de clientes fuera del horario laboral. Ejercitar la escalación cuando el diagnóstico remoto falla.
Un compromiso de soporte actual debería reemplazar la inferencia del acuerdo de 2020 y el sitio web de calidad mixta. Los clientes necesitan la respuesta aplicable a su circuito, no una matriz de contacto antigua para otro servicio.
Quién soporta el fallo
El efecto de un borde estrecho difiere según el cliente.
Un usuario residencial detrás de la traducción de direcciones puede ver todas las aplicaciones externas fallar a la vez cuando las rutas públicas desaparecen, mientras que un vecino en una red móvil aún puede cargar el sitio de soporte de Cactus. Un negocio que usa una dirección pública de Cactus puede perder VPN entrantes, servicios alojados o cámaras remotas tan pronto como la ruta se retira. Un cliente de conectividad gestionada puede retener un enlace de acceso y la gestión de red local pero perder la ruta a Internet incluida en el contrato.
Una institución que compra un servicio punto a punto podría permanecer conectada entre dos sitios locales incluso si el tránsito global falla, dependiendo de dónde se conmute ese circuito. Ninguno de estos diseños de servicio está confirmado para un cliente actual nombrado.
El operador también soporta un riesgo de comunicación peculiar. Debido a que su sitio web y correo están alojados externamente, la superficie de estado pública puede sobrevivir a una interrupción de AS135632. Eso es potencialmente útil: Cactus puede publicar actualizaciones desde una conexión no afectada. También puede ser engañoso si ninguna página de estado distingue "nuestro sitio web está en línea" de "las rutas de nuestros suscriptores son accesibles". Un servicio de estado externo simple con sondas independientes para los tres prefijos convertiría esa separación en una ventaja operativa.
La economía es igualmente asimétrica. Mantener un segundo ascendente, enrutador de repuesto, baterías y existencias de campo cuesta dinero incluso cuando nada falla. Un parque de direcciones públicas pequeño no revela si la base de ingresos puede soportar esa reserva. Tampoco prueba que Cactus sea pequeño en términos de suscriptores; la traducción puede colocar a muchos usuarios detrás de pocas direcciones. Lo que se puede decir es que tres rutas públicas concentran el fallo observable en un conjunto compacto. Monitorear cada prefijo desde varias redes externas es técnicamente sencillo.
El grado de evidencia es Medio, con un límite físico agudo
Cactus Network Solutions tiene más evidencia operativa pública de lo que sugiere su sitio web delgado. AS135632 es actualmente visible. Tres /24s IPv4 fueron observados continuamente en la primera mitad de julio. Cientos de caminos de colectores llegaron a cada ruta. APNIC mantiene los registros de organización y contacto de respuesta. El dominio público y los canales de contacto funcionan. Los documentos comerciales históricos muestran a Cactus ofreciendo enlaces inalámbricos y soporte en el sitio, y una evaluación oficial de adquisiciones registra a la empresa como un licitador de telecomunicaciones receptivo en 2023.
La evidencia de ruta es sólida para la proposición estrecha que apoya. AS135632 originó tres /24s IPv4 a las 08:00 UTC del 16 de julio de 2026; ninguna ruta IPv6 era visible; y cada camino recopilado entraba a través de AS141421. El historial también es claro de que tanto el vecino como el recuento de rutas han cambiado.
La evidencia física y de recuperación es débil. No hay un mapa verificado actual de fibra de acceso, torres, repetidores en azoteas, edificios de traspaso o caminos de entrada diversos. No hay un compromiso de tránsito público, nivel de utilización, recuento de clientes, tiempo de funcionamiento de respaldo, stock de repuestos o rendimiento de reparación. La propuesta anterior y el acuerdo de soporte identifican dependencias plausibles sin probar el diseño actual.
Esa combinación es exactamente por qué el título es una prueba más que un veredicto. Un vecino visible no prueba un cable. Tres /24 no prueban un negocio minúsculo. Sin IPv6 no prueba un fallo inminente. Pero si la sesión que transporta esas rutas se detiene y no aparece ningún anuncio alternativo, el espacio de direcciones públicas de Cactus no tiene a dónde más ir visiblemente. El sitio web puede permanecer en línea en otro ASN; el destino de la red del cliente será decidido por circuitos, enrutadores, radios, energía y personas que Cactus no ha hecho públicamente inspeccionables.
La evidencia decisiva sería una conmutación por error controlada observada desde fuera: cada /24 permanece accesible a través de un alternativo utilizable independientemente, el tráfico del cliente continúa dentro de un intervalo de recuperación declarado, el servicio de doble pila se prueba donde se ofrece, y el equipo debajo de ambos caminos sobrevive al mismo ejercicio. Hasta entonces, la resiliencia de Cactus no está refutada. Es simplemente una afirmación operativa que espera la única prueba que su tabla de enrutamiento pública hace imposible de evitar.

