Um vizinho BGP visível, três /24 IPv4 e sem IPv6: teste de failover da Cactus Network Solutions

Resumo

• Às 08:00 UTC de 16 de julho de 2026, o RIPE RIS observou o AS135632 originando103.77.9.0/24,116.206.164.0/24e116.206.167.0/24: 768 endereços IPv4 em três rotas, sem IPv6 originado. Cada um dos 1.063 caminhos AS coletados colocou AS141421, MUX Broadband, imediatamente antes da Cactus.
• As evidências estabelecem um sistema autônomo vizinho visível, não um cabo físico. Não revela quantas sessões BGP, handoffs, circuitos, roteadores, edifícios, relays em telhados, dutos ou domínios de energia estão abaixo dessa relação lógica.
• O conjunto de rotas mudou materialmente. O RIPE viu oito prefixos IPv4 e um vizinho em julho de 2025, nenhuma rota originada pela Cactus em um snapshot de meados de outubro, sete prefixos via AS141421 em abril de 2026 e três em maio. Essas observações provam mudanças de roteamento, não perda de clientes, migração física ou capacidade instalada reduzida.
• O site e o e-mail da Cactus estão hospedados no AS31898, não no AS135632, portanto, essas superfícies de contato público podem permanecer acessíveis durante uma retirada das rotas originadas pela Cactus. O acesso do cliente, serviços locais, switching interno e operações de suporte dependeriam de arranjos que não são visíveis no roteamento público ou no material da empresa.

A sessão para às 08:00 UTC

Comece pela falha, não pelo folheto.

Às 08:00 UTC, a sessão de borda que transporta os três prefixos públicos da Cactus Network Solutions para o AS141421 para de trocar acessibilidade utilizável. A causa pode ser uma interface com falha, um erro de manutenção upstream, uma reinicialização do roteador, um circuito de acesso danificado, um erro de configuração ou perda de energia em qualquer extremidade. Assim que qualquer intervalo de retenção de rota expirar, e se nenhuma segunda sessão ou vizinho começar a anunciar os mesmos prefixos, o efeito fora da rede é simples: outros sistemas autônomos param de aprender como alcançar103.77.9.0/24,116.206.164.0/24e116.206.167.0/24.

Isso não é uma topologia hipotética inventada a partir de um nome de empresa. Osnapshot de status de roteamento do RIPEstatda data de publicação contou três rotas IPv4 originadas, 768 endereços, nenhuma rota IPv6 e um vizinho observado. Acaptura de estado BGPcorrespondente continha 1.063 caminhos de coletores. AS135632 era a origem em todos eles, e AS141421 era o sistema autônomo imediatamente precedente em todos eles.

O que permanece acessível no momento da falha é mais revelador do que o que desaparece.

O domínio público da Cactus resolveu para192.185.56.104naresposta A retornada pelo Google Public DNS. Aresposta de informação de rede do RIPEpara esse endereço colocou sua rota de cobertura no AS31898, fora do AS135632. Otroca de e-maildo domínio eramail.cactuspk.com,que resolveu para o mesmo endereço IPv4 hospedado externamente. Seusservidores de nomes autoritativostambém usavam o namespacewebsitewelcome.com. Portanto, a retirada das próprias rotas da Cactus não retiraria, por si só, o prefixo de hospedagem do site público ou o prefixo do servidor de e-mail.

O site ainda pode carregar. Um servidor de e-mail ainda pode aceitar mensagens. Um chamador ainda pode alcançar o número de telefone publicado por meio de um serviço de telecomunicações separado. Nenhum desses resultados prova que um assinante da Cactus pode alcançar a internet mais ampla. Funcionários dentro de um escritório atendido pela Cactus podem não conseguir alcançar os sistemas de suporte hospedados externamente, mesmo enquanto esses sistemas permanecem disponíveis para todos os outros.

Um cliente e um engenheiro de suporte podem, assim, ver lados opostos da mesma falha: a página de suporte está online do exterior, enquanto o circuito do cliente não tem rota utilizável para sair.

A comunicação local é uma incógnita separada. Se os rádios de acesso do cliente, switches, endereçamento e serviços locais permanecerem energizados, os pacotes entre dois pontos dentro do mesmo domínio de roteamento podem continuar a se mover sem uma rota global. Eles também podem depender de sistemas centrais ou caminhos que falham com o handoff upstream. As evidências públicas não mostram a topologia interna, se os assinantes usam endereçamento público ou privado, onde ocorre a autenticação ou se o tráfego local é comutado localmente.

A resposta correta para “o que permanece acessível?” é, consequentemente, uma lista a ser medida, não uma suposição confiante.

O que a tabela de roteamento pública estabelece

BGP é um protocolo de alcance entre domínios. Aespecificação BGP basedescreve a troca de prefixos e informações de caminho AS entre sistemas de roteamento. Ela não codifica uma rota de rua, desenho de fibra, localização de telhado, alimentação de energia, velocidade de porta ou contrato de reparo. As evidências da Cactus têm que ser mantidas nessas camadas.

No corte da publicação, oresultado de prefixos anunciados do RIPE para 1 a 16 de julhomostrou os mesmos três /24s continuamente desde o início do intervalo solicitado até a observação mais recente disponível às 08:00 UTC de 16 de julho. O resultado de status de roteamento informou que 320 dos 326 peers IPv4 do RIS viram as rotas. Nenhum prefixo IPv6 era visível para qualquer um dos 321 peers IPv6 naquele snapshot.

A evidência de caminho por prefixo é excepcionalmente consistente. O RIPE retornou360 caminhos para103.77.9.0/24,360 para116.206.164.0/24e343 para116.206.167.0/24. Cada caminho capturado para cada prefixo terminava emAS141421 AS135632. Não houve nenhum caminho coletado em que outro sistema autônomo aparecesse diretamente antes da Cactus.

Essa descoberta é mais forte do que dizer que um diretório comercial lista um provedor. É uma observação rota por rota em centenas de vistas de coletores. No entanto, seu limite é igualmente importante. Vários links físicos ou várias sessões BGP podem existir entre os mesmos dois sistemas autônomos enquanto produzem o mesmo caminho AS. Por outro lado, uma sessão BGP pode ser transportada sobre infraestrutura com proteção oculta dentro da rede de um fornecedor. O caminho AS sozinho não pode distinguir esses casos.

Operfil PeeringDB para AS135632, mantido pelo operador, identifica a Cactus, também usando o nome Sprint Broadband, como uma rede Cable/DSL/ISP do Paquistão. Ele não publica linhas de exchange ou instalações. Essa ausência restringe o que pode ser verificado por meio do PeeringDB; não prova que a Cactus não tenha equipamentos em uma instalação compartilhada, nenhuma interconexão privada, nenhum acesso remoto a exchange e nenhum serviço atacadista protegido.

Oregistro de organização do APNIC para ORG-CNSP1-APidentifica a Cactus Network Solutions (CNS) Pvt Ltd como um registro local de internet do Paquistão e fornece um endereço em New Garden Town, Lahore. Oregistro de mantenedore oregistro de contato de resposta a incidentespreservam a mesma identidade organizacional e manutenção de contato atual. São boas evidências de que a empresa continua sendo um titular ativo de recursos. Um endereço administrativo não é evidência de um roteador central, relay, armazém, ponto de agregação de clientes ou handoff upstream naquele edifício.

Três /24s não são capacidade nem contagem de clientes

Um /24 contém 256 endereços IPv4. Três /24s contêm, portanto, 768 endereços. Essa aritmética é exata e operacionalmente limitada.

O número não revela assinantes. Uma residência pode receber um endereço público, muitas residências podem compartilhar um através de tradução de portadora, uma empresa pode receber vários, e interfaces de infraestrutura podem consumir parte do pool. Endereços também podem ser reservados, roteados mas ociosos, usados para equipamentos de rede ou atribuídos dinamicamente. Nenhuma fonte pública estabelece a política atual de endereçamento da Cactus.

Nem a contagem de endereços revela largura de banda. Um compromisso de trânsito de 100 Mbps e um compromisso de trânsito de 10 Gbps podem originar os mesmos três prefixos. As rotas dizem para onde os pacotes devem ir; não informam quanto tráfego o handoff pode transportar antes de congestionar, quais classes são priorizadas, quais termos de rajada se aplicam ou quanta capacidade excedente existe após uma falha.

Cada /24 tem sua própria história, mas a mesma saída atual

As três rotas atuais não devem ser tratadas como uma estatística indivisível. Cada uma é anunciada independentemente, pode ser retirada independentemente e pode transportar uma mistura diferente de endereços de infraestrutura ou assinantes. Dados públicos não revelam essa mistura, mas tornam o comportamento de roteamento de cada /24 observável separadamente.

O menor número de caminhos para116.206.167.0/24não é evidência de menor largura de banda ou pior serviço ao cliente. Significa que menos caminhos de coletores estavam presentes naquela resposta capturada. Participação de coletores, filtragem e temporização podem diferir. O que é comum entre os três resultados é mais importante: cada caminho capturado usava AS141421 no limite final de AS externo.

Também não havia nenhuma rota de cobertura observada para absorver a perda de um anúncio mais específico. O RIPE não retornou estado BGP para a rota de cobertura103.77.8.0/22ou116.206.164.0/22no mesmo timestamp. Portanto, na tabela pública capturada, a retirada de103.77.9.0/24não deixaria uma rota /22 originada pela Cactus cobrindo-a. O mesmo vale para os dois /24s visíveis de116.206.

Esse detalhe dá à Cactus dois problemas diferentes de resiliência.

O primeiro é falha compartilhada. Se o limite AS135632-AS141421 parar de transportar todas as exportações, as três rotas podem desaparecer juntas porque compartilham o mesmo vizinho visível. O segundo é falha seletiva. Um filtro de rota, erro de política específico de prefixo ou problema de originação local pode remover um /24 enquanto os outros dois permanecem saudáveis. Os clientes na faixa afetada podem ficar inacessíveis mesmo enquanto um painel agregado diz que o AS135632 ainda está online.

É por isso que um monitor externo deve testar pelo menos um endereço controlado em cada prefixo originado. Uma única sonda para o site da empresa seria inútil porque o site está fora do ASN da Cactus. Uma única sonda dentro de116.206.167.0/24perderia uma retirada seletiva de103.77.9.0/24. A acessibilidade deve ser testada a partir de várias redes independentes, com o resultado vinculado ao estado BGP no mesmo momento. Isso distinguiria pelo menos três eventos: rota ausente, rota presente mas endpoint indisponível, e endpoint acessível com entrega de pacotes degradada.

O histórico de rotas também fornece ao operador um caso de teste natural.103.77.9.0/24retornou após quase quatro semanas de ausência em abril e maio de 2026, enquanto116.206.164.0/24e116.206.167.0/24eram visíveis em ambos os lados desse intervalo. Dados públicos não podem dizer se a rota de retorno transportava assinantes, infraestrutura ou espaço não utilizado. A Cactus pode. Ela poderia usar o evento para explicar se a retirada foi planejada, como os usuários de endereço foram tratados, quais alarmes dispararam e por que a rota retornou.

Os quatro /24s não mais visíveis após 16 de abril merecem a mesma redação disciplinada.103.77.10.0/24,103.77.11.0/24,116.206.165.0/24e116.206.166.0/24apareceram no histórico do RIPE e estavam ausentes na publicação. Isso é um fato de anúncio. Não é evidência de que o espaço de endereço registrado correspondente foi vendido, abandonado, revogado ou desconectado fisicamente. Um inventário atual de prefixos deve rotular cada bloco como roteado, reservado, usado internamente, atribuído por outro arranjo ou aposentado, com a data e a autoridade para o estado.

Para um comprador, isso não é detalhe burocrático. Se um endereço estático prometido está em um /24 que às vezes é retirado independentemente, a questão de nível de serviço é específica da rota. Se equipamentos críticos estão espalhados por dois dos /24s atuais, isso pode proteger contra um erro específico de prefixo, mas não contra o limite comum AS141421. Se todos os pools de tradução de clientes, resolvedores DNS e sistemas de gerenciamento estão em um /24, as outras duas rotas podem oferecer menos separação prática do que a contagem de rotas sugere. A tabela pública não pode revelar esses posicionamentos.

A pegada de três rotas é, portanto, pequena o suficiente para auditar com precisão. A Cactus pode publicar um inventário não sensível, monitorar cada prefixo, testar exportações normais e alternativas e preservar um registro de eventos quando qualquer rota mudar. Isso seria mais informativo do que uma ampla porcentagem de disponibilidade, pois mostraria exatamente qual população de endereços permaneceu acessível sob qual falha.

A página inicial da empresa faz alegações de maior escala, incluindo serviço gigabit, uma rede sem fio all-IP, linhas alugadas institucionais e mais de 20.000 usuários confiáveis. Mas apágina inicial ao vivo da Cactustambém contém texto de vendas sobre planos de banda larga na Índia, depoimentos de temas e linguagem genérica não relacionada ao operador de Lahore. Apágina de contatoinclui uma alegação de popularidade do Aivahthemes ao lado do endereço de Lahore. Umapágina de contatos separadatem detalhes de amostra de Chicago e Nova York. Esses resíduos tornam as alegações de escala numérica do site inadequadas como fatos operacionais.

A conclusão mais segura é menor. O site está acessível, apresenta a Cactus como provedora de internet residencial e empresarial, publica detalhes de contato de Lahore e discute serviços sem fio, fibra e linhas alugadas. Não fornece um total confiável atual de assinantes, mapa de cobertura encomendável, inventário ativo de torres, capacidade de trânsito, série de utilização ou registro auditado de disponibilidade. A pegada de 768 endereços não deve ser inflada com números de texto de vendas comprometido.

Umapágina IPinfo para AS135632corrobora a visão atual de três prefixos, 768 endereços e zero IPv6 e rotula a rede como ISP consumidor. Ela também relata um pequeno conjunto de endereços Cactus que respondem a ping. Essas sondas apoiam a proposição de que endpoints nas rotas respondem do Paquistão; não identificam clientes, áreas de serviço ativas, locais de rádio, congestionamento ou resiliência. Umperfil independente no bgp.toolsainda lista sete prefixos IPv4 e o mesmo ASN upstream. Sua contagem maior reflete um inventário mais amplo ou com temporização diferente da visão do RIPE na data de publicação. A diferença é uma razão para carimbar data nas alegações, não para selecionar o número maior.

O conjunto de rotas já mudou

A evidência mais útil sobre failover não é uma promessa. É o que as rotas já fizeram.

Em16 de julho de 2025, o RIPE observou o AS135632 originando oito prefixos IPv4, cobrindo 2.048 endereços, sem IPv6 e com um vizinho. O vizinho visível naquele dia era AS24499, Telenor Pakistan, conforme mostrado pelaresposta de vizinhos históricos. Isso é evidência de um limite upstream público diferente do visto em julho de 2026.

Ohistórico de anúncios de um anoregistra então uma quebra acentuada. Os prefixos visíveis no verão de 2025 terminaram em 26 de setembro. Ofluxo de atualizações para103.77.9.0/24mostra retiradas generalizadas após caminhos via AS24499. Nenhum prefixo originado pelo AS135632 aparece no snapshot de status de roteamento de meados de outubro.

Em 22 de outubro, os anúncios retornaram. Ofluxo de atualizações em torno da restauraçãomostra novos caminhos terminando emAS141421 AS135632. Em15 de abril de 2026, sete /24s IPv4 eram visíveis através de um vizinho observado, AS141421. Quatro desses sete pararam de aparecer em 16 de abril.103.77.9.0/24também desapareceu e retornou em 12 de maio. Osnapshot de 13 de maiohavia se estabilizado no total atual de três.

Esses timestamps estabelecem três coisas.

Primeiro, o AS135632 mudou seu limite upstream visível. Segundo, seu conjunto de rotas públicas contraiu de oito para sete para três ao longo do período observado. Terceiro, houve um intervalo de aproximadamente 26 dias entre a retirada de setembro e a restauração de outubro durante o qual o RIPE não viu um anúncio do AS135632.

Eles não estabelecem o porquê. Uma ausência visível ao coletor pode coincidir com uma migração de provedor, uma mudança deliberada de roteamento, uso de endereços atribuídos pelo provedor, um erro de política, serviço suspenso ou outra condição. Não nos diz se os clientes de varejo estavam offline, movidos para trás de um espaço público diferente, atendidos por outro ASN, usando conectividade privada ou ainda não ativos. Da mesma forma, a retirada de quatro /24s em abril de 2026 não prova que a Cactus perdeu clientes ou descomissionou equipamentos.

Esses endereços podem estar não utilizados, mantidos, roteados de forma diferente ou aguardando outro propósito.

O histórico, no entanto, importa para um comprador. Prova que a configuração pública não é estática e que uma mudança de vizinho ocorreu. Uma explicação crível de resiliência deve, portanto, responder não apenas “quem está upstream hoje?”, mas também “como o tráfego continuou durante a última transição upstream, quais prefixos se moveram, quanto tempo levou a convergência e o que os clientes experimentaram?”

Um vizinho pode ocultar vários circuitos, mas não um segundo caminho AS

AS141421 é identificado peloregistro de sistema autônomo do APNICcomo MUX Broadband (Private) Limited no Paquistão. No mesmo corte da publicação,status de roteamento do RIPEda MUX mostrava cinco prefixos IPv4 originados, três prefixos IPv6 e sete vizinhos observados. Suavisão de vizinhosincluía três sistemas autônomos aparecendo antes da MUX nos caminhos observados e quatro aparecendo depois dela, um deles AS135632.

A conectividade mais ampla da MUX pode tornar o serviço que ela vende mais resiliente do que um único link externo. Essa resiliência não pode ser transferida automaticamente para a Cactus. O limite de falha em questão é o limite entre AS135632 e AS141421. Se a MUX mantém excelentes rotas para a internet mais ampla, mas a Cactus não consegue entregar seus prefixos à MUX, essas opções upstream não ajudam os endereços da Cactus. O mesmo se aplica se um roteador de borda compartilhado da Cactus, handoff local, fonte de alimentação ou configuração falhar antes que o tráfego alcance a MUX.

Ao mesmo tempo, o resultado de um vizinho não justifica desenhar uma linha em um mapa da cidade. A Cactus pode ter dois circuitos para a MUX em locais diferentes, dois roteadores em um circuito, duas sessões sobre um serviço protegido ou um handoff desprotegido. A MUX pode transportar tráfego sobre infraestrutura redundante internamente. Nenhum desses projetos é visível no caminho AS. A rota física exata entre as empresas, incluindo se cruza Lahore, Multan ou qualquer instalação nomeada, é desconhecida.

Uma avaliação oficial de aquisição de saúde do Punjab cria uma tensão útil. Orelatório de proposta técnica de 19 de julho de 2023marcou a Cactus como “Sim” contra um requisito de que um licitante tivesse dois provedores upstream, escritos como PIE e TW1. A mesma tabela a marcou como conforme para licenciamento LL/CVAS e, finalmente, responsiva.

Esse documento é uma forte evidência do que os avaliadores de aquisição aceitaram em 2023. Não é um diagrama BGP atual. Não identifica os circuitos, ASNs, sites, anúncios de rota, períodos de contrato ou comportamento de failover por trás da resposta de dois upstreams. O requisito pode ter concernido um serviço gerenciado em particular, fornecedores atacadistas por trás de outro provedor, capacidade comercial então atual ou evidência não reproduzida na avaliação de duas páginas.

A visão atual do RIPE, por outro lado, responde a uma pergunta mais restrita: qual sistema autônomo apareceu diretamente antes do AS135632 nos caminhos públicos em 16 de julho de 2026? A resposta foi apenas AS141421.

O “Sim” da aquisição e o snapshot de roteamento não são, portanto, mutuamente exclusivos. Juntos, eles definem a questão de due diligence. A Cactus pode resolvê-la identificando os dois domínios de falha atuais, mostrando quais prefixos públicos cada um carrega e demonstrando que uma perda controlada de um faz com que o outro anuncie e encaminhe rotas utilizáveis dentro de um intervalo declarado.

IPv6 está faltando, mas não seria um backup mágico

O conjunto atual de rotas da Cactus não tem segunda família de endereços visível. O RIPE contou zero prefixos IPv6 originados em julho de 2025, abril de 2026, maio de 2026 e no snapshot da data de publicação. IPinfo e bgp.tools relatam independentemente a mesma ausência. O domínio público da Cactus também não retornou endereço naresposta AAAA do Google Public DNS.

IPv6 é um protocolo de camada de rede distinto, especificado naRFC 8200, com um espaço de endereço muito maior que o IPv4. Em um serviço dual-stack adequadamente projetado, um cliente e aplicação podem ter alcance tanto IPv4 quanto IPv6. Técnicas de cliente descritas peloHappy Eyeballs Versão 2podem tentar as famílias disponíveis de uma forma destinada a reduzir o atraso visível ao usuário quando um caminho é ruim.

Mas IPv6 não é um substituto automático para uma rota IPv4 com falha. O dispositivo do cliente deve receber configuração IPv6 funcional. A rede de acesso deve transportá-lo. O DNS deve publicar um destino IPv6 quando apropriado. O destino deve estar disponível via IPv6. A Cactus deve anunciar um prefixo IPv6, e o relacionamento upstream deve transportá-lo. Nenhuma dessas evidências de rota pública existe para o AS135632 no corte.

Mesmo que a Cactus adicione IPv6 amanhã, a diversidade de família de endereços não criaria necessariamente diversidade física. IPv4 e IPv6 podem atravessar o mesmo roteador, o mesmo rádio, a mesma fibra, o mesmo handoff e o mesmo ASN upstream. Uma perda de energia ou corte nesse ponto comum removeria ambos. Por outro lado, IPv6 entregue sobre um caminho com energia e roteamento independentes poderia preservar algumas aplicações dual-stack durante uma falha de roteamento específica do IPv4. O benefício depende da implementação, não apenas da presença de uma alocação IPv6.

O próprio status de rota da MUX prova que o vizinho visível é capaz de originar IPv6. Não prova que a MUX oferece à Cactus um serviço IPv6, que a Cactus solicitou um ou que o equipamento do cliente está pronto. A ausência na data de publicação é, portanto, específica: nenhuma rota IPv6 originada pela Cactus era visível. A razão, plano de implantação e efeito no cliente são desconhecidos.

Isso importa economicamente tanto quanto tecnicamente. Um pequeno pool IPv4 pode incentivar o compartilhamento de endereços, complicando serviços de entrada, tratamento de abuso e atribuição de clientes. IPv6 pode reduzir a escassez de endereços e melhorar a acessibilidade ponta a ponta para serviços compatíveis. No entanto, a implantação requer suporte ao equipamento do cliente, monitoramento, política de segurança, prática da equipe e preparação do help desk. Para um provedor regional, o teste não é “o upstream suporta IPv6?”, mas “um cliente pode usá-lo, as operações podem diagnosticá-lo e ele sobrevive a uma falha definida?”

A última milha é sugerida, não mapeada

A Cactus se apresenta como um provedor de acesso local, não uma casca de roteamento puro. Suapágina de serviçossepara conectividade residencial, empresarial e personalizada. Apágina de serviços empresariaisdiscute banda larga dedicada, gerenciamento de rede e conectividade segura. A página inicial refere-se a uma rede sem fio all-IP e pede aos usuários que verifiquem torres em sua localidade.

Essas descrições apoiam uma inferência ampla de que a Cactus comercializou acesso de última milha e empresarial, incluindo entrega sem fio. Elas não estabelecem uma contagem atual de torres, rota de fibra, parque de postes, posse de espectro licenciado, inventário de equipamentos do cliente ou limite de serviço. O resíduo de tema do site torna suas porcentagens, totais de assinantes e linguagem de cobertura ampla especialmente fracos.

Um documento mais concreto, porém histórico, é umaproposta da Cactus datada de 25 de setembro de 2020, publicamente carregada no Scribd. Ela propunha um link ponto a ponto com taxa de informação comprometida de 20 Mbps em Lahore usando duas antenas de 34 dBi e duas unidades AirFiber de 5 GHz. Permitia dois dias para instalação, incluía manutenção recorrente de link e torre, referia-se ao registro de frequência e atribuía energia e aterramento adequados no local do cliente ao cliente.

A proposta é útil porque descreve um projeto comercial real sob o nome Cactus. É limitada porque tem seis anos, é específica para um circuito proposto, é hospedada por terceiros e não é prova de que o link foi encomendado, instalado ou permanece ativo. Não pode ser extrapolada para um mapa atual das torres da Cactus. No entanto, identifica superfícies de falha que permanecem tecnicamente plausíveis para wireless fixo: linha de visada, alinhamento de antena, acesso ao telhado, saúde do rádio, interferência, energia no local do cliente, aterramento e disponibilidade de equipamento de reposição.

Nenhuma fonte revisada fornece coordenadas para um relay ou torre operacional da Cactus. Os endereços de Garden Town nos registros da empresa e do APNIC são locais de contato administrativo. O endereço Al-Qadir na proposta de 2020 é um endereço de escritório histórico. Nenhum deve ser plotado como um nó de rede sem evidência separada.

A fibra é igualmente não resolvida. O site ao vivo usa linguagem de fibra, e um fornecedor pode fornecer acesso de fibra sem possuir cada cabo, duto ou poste. O material público não identifica se a Cactus possui fibra de acesso, arrenda tails, revende outra operadora, combina wireless e fibra, ou entrega clientes à infraestrutura de terceiros. Um caminho BGP através da MUX não pode responder a essa pergunta. A adjacência lógica pode estar acima de qualquer um desses arranjos físicos.

Energia e reparo em campo decidem se uma rota é utilizável

A diversidade de roteamento é valiosa apenas se o equipamento que a utiliza permanecer energizado e reparável.

Considere quatro falhas. Se um rádio de telhado perder energia, mas a borda da Cactus continuar anunciando todos os três prefixos, a tabela de roteamento global pode parecer saudável enquanto os clientes atrás desse relay estão offline. Se a sessão de borda para a MUX falhar enquanto a rede de acesso permanece energizada, os links locais podem permanecer ativos, mas os destinos externos podem desaparecer. Se ambos os circuitos nominal e alternativo entrarem no mesmo edifício e um evento de energia local desabilitar o roteador compartilhado, dois contratos não produzem diversidade utilizável.

Se uma tempestade mover uma antena ponto a ponto, a capacidade upstream excedente não restaura a linha de visada.

A proposta wireless de 2020 explicitamente tornou a energia e o aterramento no local do cliente uma condição de comissionamento e excluiu danos causados por surtos, flutuações ou aterramento inadequado. Esse limite contratual é operacionalmente importante. Sugere que pelo menos um projeto histórico da Cactus dependia parcialmente de condições elétricas controladas pelo cliente. Não revela se a Cactus fornecia energia ininterrupta, baterias ou proteção contra surtos em outro lugar, ou quanto tempo de autonomia qualquer sistema de backup tinha.

Umacordo de serviços de suporte datado de dezembro de 2020, também carregado publicamente, descrevia diagnóstico remoto primeiro e uma visita ao local se o trabalho remoto falhasse. Listava um número de suporte, vários contatos técnicos e uma sequência de escalonamento de gestão. Isso é evidência de que a Cactus documentou uma prática de escalonamento em campo para um cliente naquela época. Não é um quadro de pessoal atual, um compromisso de falha de rede ou prova de que as mesmas pessoas, horários e tempos de resposta cobrem clientes de banda larga em 2026.

Apágina de contato atual da Cactuslista um endereço Awami Complex em Garden Town, um número de telefone, e-mail e horário de expediente das 9h às 17h. O site em outros lugares afirma suporte extenso ou 24 horas. Como as mesmas páginas contêm conteúdo de estoque não relacionado, a promessa exata de suporte requer confirmação em um contrato de cliente atual.

Para um operador pequeno, a mão de obra local pode ser a reserva efetiva. Um rádio sobressalente em um armário é útil apenas se alguém puder identificar a unidade com falha, obter acesso ao telhado, viajar por Lahore, alinhar a substituição com segurança e encerrar a falha. Uma segunda sessão de trânsito é útil apenas se alguém a monitorar, manter paridade de política e perceber quando ela parou silenciosamente de aceitar um prefixo. O número de técnicos é menos importante do que a cobertura testada de habilidades, turnos, permissões de acesso e peças de reposição.

Nenhuma dessas quantidades é pública para a Cactus. Não há série atual de tempo médio para reparo, escala de plantão, inventário de peças de reposição, plano de acesso ao telhado, tempo de autonomia de bateria, política de gerador, reserva de combustível, janela de manutenção, cobertura de monitoramento ou relatório pós-incidente. Sua ausência do material público não é prova de operações fracas. Significa que um cliente não pode precificar a resiliência apenas a partir do site e da tabela BGP.

Segurança de origem de rota é um teste diferente

Todos os três prefixos atuais retornaram um resultadodesconhecidodo serviço de validação de origem de rota do RIPE:103.77.9.0/24,116.206.164.0/24e116.206.167.0/24. Nenhuma autorização de origem de rota validada foi retornada.

A validação de origem, descrita naRFC 6811, permite que um roteador compare um prefixo anunciado e ASN de origem com dados de autorização verificáveis criptograficamente. Um estado desconhecido não é uma rota inválida. Significa que o sistema de validação não encontrou uma autorização de cobertura que tornasse o anúncio válido ou inválido.

Publicar autorizações corretas poderia reduzir uma classe de risco de roteamento: outra rede originando acidental ou maliciosamente o espaço da Cactus. Não criaria um segundo upstream, adicionaria largura de banda, energizaria um rádio ou encurtaria uma jornada de reparo. Disponibilidade e segurança de origem de rota devem, portanto, ser medidas separadamente. Uma rede resiliente ainda pode ter proteção de origem fraca, e uma rota perfeitamente autorizada ainda pode desaparecer quando seu único handoff utilizável falhar.

Uma afirmação de resiliência testável tem cinco partes

A Cactus não precisa revelar diagramas sensíveis para tornar sua resiliência avaliável. Ela precisa publicar ou fornecer respostas verificáveis nos limites onde as falhas se propagam.

1. Exporte as mesmas rotas por uma alternativa genuinamente utilizável

Para cada um dos três /24 atuais, identifique os arranjos de roteamento externo normal e alternativo. Se ambas as sessões forem com AS141421, declare se terminam em roteadores Cactus diferentes, dispositivos MUX diferentes, locais de handoff diferentes e circuitos de acesso fisicamente independentes. Se um segundo sistema autônomo existir, mostre que cada prefixo é aceito e propagado através dele.

Em seguida, realize uma retirada controlada da sessão normal. Meça o tempo até que as sondas externas recuperem alcance estável através da alternativa. Teste todas as três rotas, não um endereço representativo. Registre se as sessões de cliente com estado sobrevivem, se os pools de tradução mudam e se os caminhos de retorno permanecem utilizáveis.

A resposta de aquisição de 2023 sobre dois upstreams torna este teste especialmente razoável. Um comprador deve pedir evidências atuais, não assumir que uma resposta de licitação de três anos ainda descreve a borda de produção.

2. Separe a diversidade lógica da diversidade física

Documente locais de handoff e pontos de falha comuns em um nível adequado para o cliente. Duas sessões BGP em um roteador não são diversidade de roteador. Dois circuitos em um duto não são diversidade de rota. Dois rádios em uma fonte de alimentação não protegida não são diversidade de energia. Dois fornecedores que ambos dependem do mesmo tail atacadista podem não ser diversidade de fornecedor no ponto que importa.

O caminho AS público não pode resolver nenhuma dessas condições. A Cactus e seus fornecedores podem, através de identificadores de circuito, registros de demarcação, declarações de entrada diversa e um exercício de falha controlada.

3. Trate o IPv6 como um serviço operacional

Um plano IPv6 deve incluir espaço alocado, autorização de rota, transporte upstream, delegação ao cliente, comportamento do resolvedor, política de firewall, monitoramento e suporte. Um piloto deve provar que clientes dual-stack alcançam destinos de teste independentes sobre ambas as famílias e que uma falha específica de família não causa atraso inaceitável na aplicação.

Se IPv4 e IPv6 compartilham o mesmo handoff físico, diga isso. A segunda família ainda melhora a disponibilidade de endereço e alcance de protocolo, mas não deve ser vendida como proteção contra uma falha comum de circuito ou energia.

4. Meça a energia em cada dependência

Declare o tempo de autonomia do backup sob carga para o roteador de borda, handoff upstream, switch de acesso, rádio relay e equipamento no local do cliente incluído no serviço. Teste baterias em vez de citar capacidade nominal. Identifique qual lado é responsável pelo aterramento, proteção contra surtos e substituição. Se um gerador for usado, registre o comportamento de partida, disponibilidade de combustível e a carga que realmente pode ser suportada.

A proposta histórica mostra por que esse limite importa: um serviço pode ser tecnicamente comissionado enquanto deixa uma dependência elétrica decisiva com o cliente.

5. Coloque a recuperação em campo na promessa de serviço

Defina quando o relógio de reparo começa, que evidência abre uma falha, quais horários são cobertos e quais eventos pausam o relógio. Mantenha rádios, unidades de energia, óptica e roteadores compatíveis em quantidades conhecidas. Verifique o acesso a telhados e locais de clientes fora do horário comercial. Exercite o escalonamento quando o diagnóstico remoto falhar.

Um compromisso de suporte atual deve substituir a inferência do acordo de 2020 e do site de qualidade mista. Os clientes precisam da resposta aplicável ao seu circuito, não de uma matriz de contato antiga para outro serviço.

Quem arca com a falha

O efeito de uma borda estreita difere por cliente.

Um usuário residencial por trás de tradução de endereço pode ver todas as aplicações externas falharem de uma vez quando as rotas públicas desaparecem, enquanto um vizinho em uma rede móvel ainda pode carregar o site de suporte da Cactus. Uma empresa usando um endereço Cactus público pode perder VPN de entrada, serviços hospedados ou câmeras remotas assim que a rota for retirada. Um cliente de conectividade gerenciada pode reter um link de acesso e gerenciamento de rede local, mas perder o caminho de internet incluído no contrato.

Uma instituição que compra um serviço ponto a ponto pode permanecer conectada entre dois locais locais mesmo que o trânsito global falhe, dependendo de onde esse circuito é comutado. Nenhum desses projetos de serviço é confirmado para um cliente atual nomeado.

O operador também corre um risco peculiar de comunicação. Como seu site e e-mail são hospedados externamente, a superfície de status público pode sobreviver a uma interrupção do AS135632. Isso é potencialmente útil: a Cactus pode postar atualizações a partir de uma conexão não afetada. Também pode ser enganoso se nenhuma página de status distinguir “nosso site está online” de “nossas rotas de assinante estão acessíveis”. Um serviço de status simples hospedado externamente com sondas independentes para todos os três prefixos transformaria essa separação em uma vantagem operacional.

A economia é igualmente assimétrica. Manter um segundo upstream, roteador sobressalente, baterias e estoque de campo custa dinheiro mesmo quando nada falha. Um pequeno patrimônio de endereços públicos não revela se a base de receita pode suportar essa reserva. Nem prova que a Cactus é pequena em termos de assinantes; a tradução pode colocar muitos usuários por trás de poucos endereços. O que pode ser dito é que três rotas públicas concentram a falha observável em um conjunto compacto. Monitorar cada prefixo a partir de várias redes externas é tecnicamente simples.

O grau de evidência é Médio, com um limite físico nítido

A Cactus Network Solutions tem mais evidências operacionais públicas do que seu site enxuto sugere inicialmente. AS135632 está atualmente visível. Três /24s IPv4 foram continuamente observados na primeira quinzena de julho. Centenas de caminhos de coletores alcançavam cada rota. O APNIC mantém os registros de organização e contato de resposta. O domínio público e canais de contato funcionam. Documentos comerciais históricos mostram a Cactus oferecendo links sem fio e suporte no local, e uma avaliação oficial de aquisição registra a empresa como licitante de telecomunicações responsiva em 2023.

A evidência de rota é forte para a proposição restrita que apoia. AS135632 originou três /24s IPv4 às 08:00 UTC de 16 de julho de 2026; nenhuma rota IPv6 era visível; e todo caminho coletado entrava através de AS141421. O histórico também é claro que tanto o vizinho quanto a contagem de rotas mudaram.

A evidência física e de recuperação é fraca. Não há mapa verificado atual de fibra de acesso, torres, relays em telhados, edifícios de handoff ou caminhos de entrada diversos. Não há compromisso de trânsito público, nível de utilização, contagem de clientes, tempo de autonomia de backup, estoque de peças ou desempenho de reparo. A proposta antiga e o acordo de suporte identificam dependências plausíveis sem provar o projeto atual.

Essa combinação é exatamente a razão pela qual o título é um teste, não um veredito. Um vizinho visível não prova um cabo. Três /24s não provam um pequeno negócio. Nenhum IPv6 não prova falha iminente. Mas se a sessão que carrega essas rotas parar e nenhum anúncio alternativo aparecer, o espaço de endereço público da Cactus não tem para onde ir visivelmente. O site pode permanecer online em outro ASN; o destino da rede do cliente será decidido por circuitos, roteadores, rádios, energia e pessoas que a Cactus não tornou publicamente inspecionáveis.

A evidência decisiva seria um failover controlado observado de fora: cada /24 permanece acessível por uma alternativa independentemente utilizável, o tráfego do cliente continua dentro de um intervalo de recuperação declarado, o serviço dual-stack é testado onde oferecido e o equipamento abaixo de ambos os caminhos sobrevive ao mesmo exercício. Até lá, a resiliência da Cactus não é refutada. É simplesmente uma afirmação operacional esperando o único teste que sua tabela de roteamento pública torna impossível evitar.