Resumo

  • O Departamento de Telecomunicações da Índia listou a Cloudnet Internet Service Private Limited como detentora de uma autorização de serviço de internet Categoria B para Tamil Nadu, com efeito em 10 de abril de 2023. Páginas de dados corporativos vinculam o mesmo endereço e dados de contato a uma empresa de Chennai incorporada em 2021. Isso estabelece uma identidade de ISP regulamentado, não um portfólio de produtos de computação em nuvem.
  • O AS150069 estava ativo em 10 de julho de 2026, originando103.21.6.0/23, ambas as rotas componentes/24e2001:df1:66c0::/48. O agregado IPv4 estava visível desde outubro de 2022 e a rota IPv6 desde novembro de 2022. A autorização de rota atual era válida sob RPKI, e os registros do registro haviam sido mantidos recentemente.
  • Os coletores de rotas públicas mostraram apenas um vizinho imediato para o AS150069: o AS132774 da Niss Internet Services Private Limited. Isso é evidência de um caminho de roteamento externo visível, não prova de que a Cloudnet não possui interconexão privada ou circuito de backup. Também não é evidência de diversidade de rotas físicas, failover automático ou capacidade ociosa.
  • O IPinfo caracteriza o AS150069 como um ISP de consumo com um ritmo de tráfego diurno/noturno pronunciado e relata apenas um domínio hospedado no espaço de endereçamento. Esses são sinais úteis, não números auditados de clientes ou produtos. Nenhum catálogo de serviços, localização de data center, inventário de racks, oferta de máquinas virtuais, oferta de bare-metal, serviço de armazenamento, compromisso de uptime, política de backup ou procedimento de migração da Cloudnet foi encontrado.
  • O rebaixamento responsável é, portanto, de um suposto operador de serviços de nuvem para um pequeno ISP de Tamil Nadu atualmente roteado, cuja pegada exata de varejo e rede física permanecem não divulgadas. Sua resiliência depende da infraestrutura de acesso local, equipamentos de agregação energizados, a entrega para a Niss, a conectividade subsequente da Niss e a mão de obra de suporte. Seria necessária evidência de cargas de trabalho hospedadas reais antes de discutir a Cloudnet como um provedor de nuvem.

A hipótese de nuvem falha na primeira pergunta sobre produto

A palavra “Cloudnet” pode fazer trabalho demais se for permitida. Ela combina duas peças da moda do vocabulário de rede, e a empresa controla recursos de numeração da internet. Nenhum desses fatos mostra que um cliente possa comprar uma máquina virtual, um banco de dados gerenciado, um bucket de armazenamento, um servidor bare-metal ou mesmo uma conta de hospedagem web convencional. A distinção é importante porque um serviço de nuvem tem obrigações de falha e recuperação que um provedor de acesso pode nunca ter assumido.

O documento público mais forte específico da empresa não é um catálogo de nuvem. É a lista de autorizações de serviço de internet do Departamento de Telecomunicações de 31 de janeiro de 2025. A entrada identifica a Cloudnet Internet Service Private Limited, número de licençaDS-11/401/2022-DS-III, Categoria B, área de serviço Tamil Nadu, com data de vigência em 10 de abril de 2023. O contato autorizado, endereço da sede e número de telefone coincidem com os registros corporativos e de registro da internet da empresa.

A página de serviço de internet do Departamento explica o que significa Categoria B. É autorização para fornecer serviço de internet em uma área de serviço licenciada, definida como um círculo de telecomunicações ou área metropolitana. O Compêndio da Licença Unificada descreve acesso à internet, IPTV e formas especificadas de telefonia IP dentro do escopo da autorização. A licença é evidência material de que a Cloudnet pode operar como ISP em Tamil Nadu. Ela não certifica que a empresa construiu cobertura em todo o estado, e não transforma uma autorização de acesso em evidência de computação hospedada.

O registro de rede aponta na mesma direção. A visão geral do AS150069 no IPinfo classifica a rede como ISP de consumo e encontra um ritmo de atividade diário pronunciado, do tipo associado a pessoas usando uma conexão durante as horas de vigília. Ele relata um domínio hospedado, em comparação com 512 endereços IPv4. As contagens de domínios hospedados têm limites de medição: um domínio pode estar atrás de uma rede de entrega de conteúdo, um endereço pode hospedar muitos nomes, um serviço privado pode não ser detectável, e clientes de acesso podem executar servidores.

Mesmo com essas ressalvas, um domínio observado não é evidência afirmativa de um patrimônio de hospedagem.

A pegada pública da Cloudnet não fornece preços ou especificações para computação, armazenamento, backup, colocation ou infraestrutura gerenciada. Nenhum endereço de data center é nomeado. Nenhum fornecedor de servidor, contagem de racks, projeto de energia, certificação, zona de disponibilidade, portal do cliente, acordo de nível de serviço, adendo de processamento de dados, histórico de incidentes, objetivo de restauração ou formato de exportação é descrito. Uma empresa pode vender privadamente sem documentar todos os serviços na web aberta, mas o ônus da prova não se inverte.

Na ausência de um produto e uma superfície operacional, a alegação de nuvem deve ser descartada em vez de embelezada.

Isso deixa uma história diferente e mais fundamentada. A Cloudnet tem um sistema autônomo ativo, uma autorização de ISP de Tamil Nadu, uma pequena alocação IPv4, uma alocação IPv6 e uma dependência upstream visível. Esses são os ossos de uma rede de acesso. A infraestrutura física por trás deles está em grande parte não exposta, o que torna a resiliência mais difícil de avaliar, mas não torna a rede imaginária.

Uma empresa de Chennai e uma autorização de Tamil Nadu

Agregadores corporativos identificam a Cloudnet Internet Service Private Limited pelo Número de Identificação CorporativaU64120TN2021PTC142654. A página da empresa no Tofler data a incorporação em 8 de abril de 2021, fornece capital social autorizado de Rs 1 milhão e capital integralizado de Rs 100.000, e nomeia Logasundari e Gopikrishnan como diretores. O registro do ZaubaCorp fornece o mesmo CIN, registro em Chennai e endereço em Kottivakkam, embora alguns campos de data em seus resumos renderizados sejam inconsistentes e não devam ser tratados como substitutos de um registro atual.

O endereço é extraordinariamente útil para resolução de identidade. A lista de licenças coloca a empresa no terceiro andar do lote 11/236A, Vivekanandar Third Street, Kottivakkam, Chennai. O registro do AS150069 na APNIC usa o nome legal abreviado, CLOUDNET INTERNET SERVICE PVT LTD, e sua função administrativa repete o mesmo endereço e número de telefone. O registro de alocação IPv4 e o registro de alocação IPv6 carregam o mesmo nome de rede,CNISPL, e a mesma cadeia de contatos. Não se trata meramente de negócios semelhantes compartilhando um nome genérico; os registros convergem para uma única empresa.

Essa convergência também mantém vários homônimos fora de cena. Uma Cloudnet Broadband Services Private Limited separada aparece em material de licenciamento mais antigo de Haryana, e a Cloudnet Communications Private Limited aparece em tabelas de assinantes. Outros negócios em outros lugares usam Cloud Net ou Cloudnet como nome fantasia. Eles não devem ser usados para preencher lacunas no catálogo de serviços, contagem de clientes ou histórico desta empresa. A âncora de identidade aqui é a licença de Tamil Nadu, CIN, endereço em Kottivakkam e AS150069.

A lista do DoT de 2025 é evidência de uma autorização naquela data de relatório. Não é um certificado operacional diário para julho de 2026. Por outro lado, as rotas ativas e os objetos de registro da internet mantidos recentemente fornecem evidências técnicas muito mais recentes. Portanto, a empresa não deve ser descrita como meramente registrada ou historicamente licenciada. Seu sistema autônomo estava carregando um anúncio globalmente visível no momento da observação.

O endereço ainda não responde onde o equipamento de rede está localizado. Um escritório registrado pode ser um escritório administrativo, um ponto de presença, ambos ou nenhum. O registro IPv4 inclui as coordenadas13.427804, 80.14154212, mas a geolocalização de registro é metadados fornecidos pelo operador, não um levantamento de uma sala de roteadores. O IPinfo coloca vários endereços ou roteadores observados em Chennai e Nagari e arredores, enquanto suas sondagens recentes alcançaram endereços responsivos a partir de pontos de vantagem da área de Chennai. Essa geolocalização é probabilística. Ela não pode identificar um terminal de linha óptica, provar a propriedade de uma rota de fibra ou estabelecer que um cliente é atendido em uma rua específica.

A afirmação geográfica defensável é, consequentemente, restrita. A Cloudnet é autorizada para a área de serviço de Tamil Nadu, registrada em Chennai e opera espaço de endereçamento que medições independentes associam à Índia e à região de Chennai. Evidências públicas não mapeiam sua pegada de varejo dentro de Tamil Nadu, mostram que atende toda Chennai ou revelam um ponto de presença além do endereço registrado.

AS150069 fornece evidência operacional atual

Um sistema autônomo é uma unidade de política de roteamento, não um negócio completo. Ainda assim, o AS150069 é a evidência mais clara de que a Cloudnet opera algo agora. A visão geral do AS no RIPEstat relatou o ASN como anunciado em 10 de julho de 2026. Sua resposta de prefixos anunciados listou o agregado IPv4103.21.6.0/23, as duas rotas mais específicas103.21.6.0/24e103.21.7.0/24, e o prefixo IPv62001:df1:66c0::/48.

O agregado IPv4 contém 512 endereços. O status de roteamento atual mostrou o AS150069 como a única origem visível para o/23, visto por 326 dos 327 peers IPv4 reportados. Também mostrou ambos os/24s sob o agregado. Respostas de status separadas para103.21.6.0/24e103.21.7.0/24registraram a mesma origem e visibilidade. Não foi um rastro visível para apenas um observador.

A cronologia é substancial. O histórico de roteamento para o/23inicia o anúncio agregado da Cloudnet em outubro de 2022 e o mantém até a data da pesquisa. Os dois/24s apareceram pela primeira vez em dezembro de 2022. Sua visibilidade caiu acentuadamente por um período a partir de março de 2025, enquanto o/23de cobertura permaneceu amplamente visível, depois retornou à ampla visibilidade em maio de 2026. Isso é uma mudança na granularidade e propagação de rotas, não evidência de que o serviço ao cliente parou. O tráfego endereçado aos dois blocos ainda poderia seguir o agregado de cobertura quando uma rota mais específica não estava visível.

O IPv6 não é apenas uma reserva de registro. O status de roteamento para2001:df1:66c0::/48mostrou o AS150069 originando o prefixo para todos os 321 peers IPv6 reportados em 10 de julho. A rota foi vista pela primeira vez em novembro de 2022. O objeto de rota da APNIC foi modificado em 8 de julho de 2026, dois dias antes da observação, e o registro de contato associado também havia sido atualizado em junho. Essas datas mostram administração contínua de recursos. Elas não nos dizem quanto tráfego de clientes usa IPv6 ou quantos usuários o recebem.

A distinção entre capacidade instalada e utilizável é essencial. Um/23é um pool de endereços, não uma compra de largura de banda. Quinhentos e doze endereços IPv4 não significam 512 clientes, servidores, portas ou megabits. Um provedor pode usar endereços para interfaces de roteador, pools NAT de classe de operadora, circuitos comerciais, infraestrutura ou inventário de reposição. Uma residência pode usar vários endereços públicos; muitas residências podem compartilhar um único endereço. A contagem quase incompreensivelmente maior de endereços numéricos dentro de um/48IPv6 é ainda menos útil como medida de capacidade.

Nem três anúncios IPv4 simultâneos triplicam a rede. O/23e seus dois/24s componentes cobrem o mesmo espaço de endereçamento. Anúncios mais específicos podem apoiar políticas de roteamento, engenharia de tráfego ou transição operacional, mas os dados de roteamento visíveis não revelam qual propósito se aplica. Contar o agregado e os componentes como 1.024 endereços IPv4 únicos seria contar duas vezes os mesmos 512 endereços.

As rotas atuais suportam uma rede real e ativa. Elas não mostram a tecnologia de acesso do assinante, contagem de portas, trânsito agregado, utilização de pico, contenção, backhaul, capacidade de cache ou velocidade do serviço. Essas grandezas determinam se uma conexão vendida é utilizável no pico noturno. Nenhuma pode ser calculada a partir do ASN.

Um vizinho imediato é a fronteira externa visível

A visão de vizinhos de AS do RIPEstat encontrou um vizinho imediato em 10 de julho de 2026: AS132774. A APNIC identifica esse ASN como Niss Internet Services Private Limited, uma rede de Tamil Nadu registrada em Tirunelveli. A visão do AS150069 no Relatório CIDR mostra independentemente a mesma adjacência e nenhum AS downstream.

Coletores de rotas veem topologia, não contratos. Um AS diretamente precedendo a Cloudnet nos caminhos observados é consistente com a Niss fornecendo trânsito, roteamento gerenciado ou outra forma de alcançabilidade upstream. Isso não revela preço, largura de banda comprometida, termos de burst, entrega física, fornecedor de fibra, prazo de aviso, obrigação de restauração ou se a Cloudnet compra o serviço diretamente. O rótulo comercial “upstream” é uma inferência sensata aqui, mas o resultado público é estritamente um vizinho BGP externo visível.

A distinção se torna importante ao discutir redundância. Um vizinho visível é evidência contra a alegação de diversidade upstream publicamente demonstrada. Não é prova de que a Cloudnet tem apenas um cabo. A Cloudnet poderia ter dois circuitos fisicamente separados em diferentes roteadores da Niss, apresentando o mesmo caminho de ASN. Poderia ter uma sessão de backup que estava inativa no momento da observação. Poderia receber uma rota padrão por uma conexão não visível para os coletores. Por outro lado, várias sessões BGP para um provedor poderiam convergir em um único duto, prédio, roteador ou domínio de energia.

Contagem de sessões e diversidade física são coisas diferentes.

A própria Niss tem uma topologia mais ampla. Sua entrada no PeeringDB lista peering NIXI Chennai e instalações em Chennai e Tirunelveli, enquanto o bgp.tools lista vários upstreams para o AS132774. Esses são fatos autorrelatados e observados sobre a Niss, não propriedades herdadas da Cloudnet. Um pacote da Cloudnet pode se beneficiar das opções subsequentes da Niss após alcançar o AS132774, mas a Niss ter vários upstreams não prova que a Cloudnet tem duas maneiras independentes de alcançar a Niss.

A visão looking-glass ao vivo do RIPEstat do/23repetidamente colocou o AS132774 imediatamente antes do AS150069 nos caminhos coletados. Muitos caminhos então passaram pelo AS9498 da Bharti Airtel além da Niss. Isso indica a cadeia visível naquele momento: Cloudnet, Niss e, em seguida, redes de trânsito maiores. Isso não significa que a Cloudnet tenha um contrato direto com a Airtel, e não estabelece onde a entrega física ocorre.

Essa fronteira cria um mecanismo de falha claro. Se a única entrega ativa da Cloudnet para a Niss falhar, ou se uma sessão de roteamento for retirada sem uma alternativa funcional, todos os endereços da Cloudnet roteados globalmente podem se tornar inalcançáveis, mesmo enquanto a fibra do cliente e os switches locais permanecem energizados. Se a conexão com a Niss permanecer ativa, mas sua capacidade comprometida for esgotada, os usuários podem ver congestionamento em vez de uma interrupção total. Se um filtro de rota ou autorização estiver errado, uma família de endereços ou um comprimento de prefixo pode falhar enquanto outros continuam.

A recuperação depende de fatos que não são públicos: se a Cloudnet tem um segundo circuito; se ele termina em um dispositivo de borda diferente; se esse circuito segue um caminho separado; se o failover é automático; se o backup tem capacidade suficiente para o pico normal; se ambos IPv4 e IPv6 são transportados; e qual empresa é responsável pela primeira resposta. Um diagrama com duas linhas não provaria nada disso a menos que identificasse os pontos comuns físicos e contratuais.

A rede física começa onde o BGP para de explicar

O BGP pode mostrar que o AS150069 torna um bloco de endereços alcançável. Ele não pode mostrar o cabo das instalações do cliente até o primeiro dispositivo ativo. Entre esses pontos pode haver um terminal de rede óptica, fibra de descida, divisor, fibra de distribuição aérea ou subterrânea, um terminal de linha óptica, agregação Ethernet, backhaul alugado, painéis de conexão, fontes de alimentação e refrigeração. As evidências públicas não identificam quais desses a Cloudnet usa ou possui.

A autoridade de Categoria B da empresa permite serviço em toda a área de serviço licenciada de Tamil Nadu; ela não certifica um projeto de acesso específico. A Cloudnet poderia operar fibra até a casa, Ethernet empresarial, enlaces sem fio, serviço através de parceiros locais de cabo ou uma mistura. Nenhum mapa de cobertura, folha de planejamento, especificação de rede óptica, registro de torre ou parceria de cabo local foi encontrado. A presença de dois endereços IP responsivos na varredura recente do IPinfo mostra que os endpoints responderam às medições, não como a última milha foi construída.

Essa fronteira de propriedade desconhecida muda quem repara uma interrupção. Um cabo de descida do cliente cortado pode ser responsabilidade da Cloudnet ou de um operador local. Uma falha na fibra alimentadora pode exigir uma equipe de postes, um empreiteiro civil ou o proprietário da fibra alugada. Uma falha de agregação pode precisar de ópticas de substituição, um switch, uma placa OLT ou uma fonte de alimentação. Uma falha de backhaul pode estar com outra operadora. O cliente vê um serviço indisponível, enquanto o reparo atravessa várias organizações.

A energia cria sua própria cadeia. O equipamento do cliente precisa de eletricidade. Armários de rua, sites sem fio, terminais de linha óptica, switches de agregação e roteadores de borda precisam de eletricidade. Um escritório registrado ter energia não diz nada sobre um nó de distribuição remoto. Um UPS pode cobrir uma interrupção curta, mas tem autonomia finita e baterias que envelhecem. Um gerador ajuda apenas se estiver instalado, abastecido, mantido e conectado ao local afetado.

Nenhuma declaração pública da Cloudnet fornece autonomia de backup, cobertura de gerador, manutenção de baterias, alimentação dupla ou arquitetura de energia do local.

O inventário de hardware é importante para uma rede pequena porque a peça com falha pode ser barata, mas operacionalmente específica. Um módulo óptico de reposição pode restaurar um link rapidamente se for compatível e estiver à mão. Uma placa de linha, fonte de alimentação ou chassi de acesso com falha pode levar mais tempo se precisar ser encomendada. Os backups de configuração precisam estar atualizados e utilizáveis em equipamentos de substituição. O registro público não contém dados de tempo médio para reparo, política de estoque, lista de fornecedores ou janela de manutenção.

A mão de obra de suporte é, portanto, parte da capacidade. Uma rede pode ter largura de banda não utilizada e ainda assim permanecer indisponível porque nenhum técnico pode alcançar um corte, nenhum engenheiro pode mudar uma rota ou nenhum contato autorizado pode escalar com um upstream. Os registros de registro e licença da Cloudnet publicam uma única cadeia de contato administrativo, mas esses registros não descrevem um centro de operações de rede com pessoal, cobertura de campo 24 horas, sistema de tickets ou escala de escalonamento. Seria errado transformar um número de contato em uma promessa de nível de serviço.

A questão da localização física deve permanecer em aberto. Kottivakkam é uma localização de escritório registrado. Coordenadas de registro sugerem outro ponto no norte de Tamil Nadu, e medições de terceiros associam endereços a Chennai, Nagari e outros rótulos de Tamil Nadu. Bancos de dados de geolocalização IP podem refletir registro de endereço, localizações inferidas de usuários ou viés de medição. Nada disso prova que a Cloudnet tem um rack em um data center nomeado ou possui equipamentos em qualquer local específico.

Cobrança, suporte e contratos podem interromper uma rede intacta

Nem toda falha de serviço começa com um cabo cortado. Um provedor de acesso precisa identificar clientes, autorizar sessões, emitir faturas, aceitar pagamentos, aplicar mudanças de plano e distinguir uma conta inadimplente de uma falha de rede. Dependendo do design, a autenticação pode depender de um banco de dados de assinantes, servidor RADIUS, gateway de banda larga, sistema de gerenciamento de rede óptica ou plataforma de revendedor. O registro público não divulga quais desses a Cloudnet usa. Ele estabelece que a administração de clientes é uma camada operacional separada do BGP.

Essa distinção é fácil de ver do lado de fora. O AS150069 pode permanecer globalmente visível enquanto uma conta não consegue se conectar. Um pagamento lançado no livro errado, uma credencial expirada, um servidor de autenticação com falha ou um sinalizador de suspensão incorreto pode se apresentar como uma interrupção no roteador do cliente. A equipe de campo pode encontrar níveis de luz saudáveis e um caminho upstream intacto, mas o serviço permanece indisponível até que o controle da conta seja corrigido. Um coletor de rotas não registrará nada disso.

A continuidade da cobrança também importa durante um incidente mais amplo. Os clientes precisam de um canal acessível para relatar falhas e determinar se um pagamento, dispositivo ou interrupção de área é responsável. A equipe precisa de registros de conta e rede atuais. Se a mesma falha de energia, servidor ou conectividade derrubar tanto o serviço de acesso quanto seus sistemas de suporte, o diagnóstico fica mais lento.

Os contatos regulatórios e de registro publicados da Cloudnet não revelam se ela tem uma plataforma de atendimento ao cliente separada, registros fora do local, roteamento de telefone de emergência ou um processo manual testado.

O contrato de atacado com o vizinho visível é outro possível ponto de controle. Uma fibra e um roteador podem estar tecnicamente íntegros enquanto uma disputa de provedor, pedido expirado, fatura não paga, limite de capacidade ou autorização de rota vencida interrompe o serviço. Não há evidência de que qualquer disputa desse tipo tenha ocorrido entre a Cloudnet e a Niss. O ponto é estrutural: onde a alcançabilidade depende de outro operador, a continuidade comercial pertence à avaliação de resiliência junto com óptica e energia.

A falha do contrato com o provedor se torna mais consequente quando não há alternativa comprovada. Mudar de upstream requer mais do que pedir uma linha. O novo provedor precisa alcançar um ponto de entrega, aceitar as rotas da Cloudnet, aplicar filtros, transportar IPv4 e IPv6, suportar autorizações de rota válidas e fornecer capacidade suficiente. O tráfego do cliente pode precisar de novas rotas padrão, caminhos DNS ou política de endereçamento. Se a migração for apressada após o fim de um serviço existente, a rede pode ficar offline mesmo que a Cloudnet ainda controle seu ASN e prefixos.

Mover clientes de acesso individuais levanta um problema de migração diferente. Se a Cloudnet deixasse de atender uma área ou transferisse assinantes para outro operador, a continuidade dependeria da propriedade da fibra de descida e do equipamento do cliente, da portabilidade dos registros de conta, prazos de aviso, reembolsos e da capacidade do provedor substituto de provisionar o serviço. O BGP público pode não mostrar mudança se os endereços e a origem permanecerem os mesmos, ou uma grande mudança se os clientes forem renumerados. Nenhum resultado por si só explica quem assumiu a obrigação de varejo.

Para um serviço hospedado genuíno, a migração seria ainda mais difícil: os clientes precisariam de exportação de dados, imagens de máquinas, controle de DNS e tempo para reconstruir. Essa é uma razão pela qual a hipótese de nuvem não suportada não pode ser tratada casualmente. Ela implica obrigações de custódia e saída de dados que estão ausentes das evidências.

Para a rede de acesso que é realmente visível, as perguntas imediatas são mais simples, mas ainda sem resposta: quem é o proprietário do relacionamento com o assinante, quem pode restaurar a autenticação, quem escala com a Niss e como um cliente é movido se esse relacionamento terminar.

Capacidade instalada não é capacidade de varejo

Não há uma lista de preços ou tabela de velocidades pública da Cloudnet para comparar com a rede. Mesmo se existisse, a velocidade de acesso anunciada ainda seria apenas a borda externa da questão da capacidade. Um plano de assinante de 100 Mbps não reserva 100 Mbps em todos os switches de agregação, backhaul e links de trânsito a todo momento. Os provedores agrupam capacidade assumindo que os clientes não exigirão todos a sua taxa máxima simultaneamente.

As grandezas operacionais relevantes estão ausentes. A Cloudnet não publica o número de assinaturas ativas, mistura de velocidades, trânsito comprometido, capacidade de peering, design de backhaul, utilização de portas, vazão em hora de pico, taxa de sobressubscrição ou registro de congestionamento. O pool de 512 endereços IPv4 não preenche essas lacunas. O NAT de classe de operadora pode permitir que muito mais de 512 dispositivos de clientes compartilhem o pool; serviços empresariais estáticos podem consumir vários endereços por conta; e o IPv6 muda o cálculo de endereçamento sem adicionar um único bit de capacidade de trânsito por si só.

O Cloudflare Radar exibiu uma população estimada para o AS150069 na casa das centenas, com a estimativa exibida mudando entre capturas e subpáginas. Essas estimativas usam sinais de tráfego e medição, em vez do sistema de cobrança do provedor. Elas indicam uma pequena população de usuários observável e reforçam a interpretação de ISP de consumo, mas não devem ser citadas como um livro-razão de assinantes. Uma assinatura pode atender uma residência ou empresa com muitas pessoas, enquanto alguns usuários podem não aparecer nas medições subjacentes.

A mesma cautela se aplica ao desempenho medido. A página de qualidade de internet do Cloudflare para o AS150069 agrega testes de velocidade e observações de rede disponíveis. Uma medição feita a partir de um endereço responsivo pode mostrar que um caminho funcionou em um determinado momento e local. Ela não pode certificar a velocidade do plano para cada assinante, quantificar a frequência de interrupções em toda a pegada de acesso ou revelar se a linha testada é representativa. Amostras pequenas são particularmente vulneráveis a mudanças de composição.

Os regulamentos de qualidade de banda larga de 2024 da TRAI estabelecem parâmetros e deveres de relatório para provedores de acesso e banda larga, incluindo provisionamento de serviço, desempenho de rede, reparo de falhas e tratamento de reclamações. O relatório de desempenho trimestral de dezembro de 2024 explica que seu resumo de desempenho de banda larga publicado cobriu provedores com mais de 10.000 assinantes. A Cloudnet não é identificada no resumo público como um desses grandes provedores.

Essa omissão não estabelece seu tamanho nem a isenta de obrigações aplicáveis; significa que o resumo nacional não pode ser usado como evidência de desempenho específica da Cloudnet.

Capacidade utilizável é o que resta após contenção, falha e política. Se um caminho de backup transporta apenas uma fração do tráfego normal, a redundância nominal ainda pode produzir congestionamento severo. Se as rotas específicas IPv4 forem retiradas, mas o agregado permanecer, a alcançabilidade pode continuar com engenharia de tráfego alterada. Se o IPv6 falhar enquanto o IPv4 permanece ativo, os usuários podem experimentar atrasos e falhas específicas de aplicativos, em vez de desconexão total.

Uma declaração de capacidade confiável precisaria de medições de hora de pico para ambas as famílias de endereços, não o tamanho dos prefixos alocados.

Um serviço de nuvem exigiria um conjunto de evidências diferente

Um provedor de acesso e um provedor de nuvem podem compartilhar roteadores, endereços e equipe, mas vendem promessas diferentes. O serviço de acesso transporta o tráfego do cliente para outros sistemas. A computação hospedada mantém a aplicação, dados ou servidor do cliente em execução na infraestrutura própria ou alugada do provedor. A segunda promessa introduz perguntas que o registro do AS150069 não pode responder.

A primeira é o ativo. Uma oferta confiável de servidor virtual deve identificar uma plataforma de computação ou, pelo menos, divulgar características de CPU, memória, armazenamento, rede e tipo de locação. Bare metal deve identificar classes de servidor e termos de provisionamento. Colocation deve identificar instalação, energia do rack e arranjos de mãos remotas. Hospedagem gerenciada deve definir quais tarefas operacionais o provedor executa. Nenhum material específico da empresa encontrado aqui descreve qualquer um desses produtos.

A segunda é a localização. “Hospedado na Índia” ou “hospedado em Chennai” precisaria de evidência da instalação onde os dados e a computação residem. Um ASN registrado na Índia não localiza um servidor. O tráfego pode ser roteado através de uma rede indiana para equipamentos em outra instalação ou jurisdição; inversamente, a Cloudnet poderia usar infraestrutura indiana de terceiros que não aparece em seu próprio espaço de endereçamento. País de registro e residência de dados são alegações separadas.

A terceira é o controle. Se a Cloudnet revendesse máquinas virtuais de outro provedor, a Cloudnet poderia controlar a cobrança e o suporte enquanto o provedor subjacente controlaria racks, hypervisors, energia e peças. Se a Cloudnet alugasse colocation, poderia possuir servidores, mas não os sistemas prediais. Se operasse sua própria sala, ainda poderia depender de proprietários e operadoras. Os clientes precisam saber quem pode restaurar a energia, substituir um disco, recuperar um backup e aprovar acesso de emergência. Nenhum documento público desenha essa fronteira.

A quarta é a redundância. Um serviço de nuvem pode replicar dados entre unidades, hosts, racks, salas, prédios ou regiões, cada um protegendo contra uma falha diferente. Duas cópias em um host não sobrevivem à falha do host. Dois hosts em um rack podem compartilhar uma unidade de distribuição de energia. Dois racks em um prédio podem compartilhar energia da concessionária, refrigeração e fibra upstream. Dois prédios ainda podem depender de um duto metropolitano ou plano de controle. Sem uma arquitetura divulgada e um caminho de restauração testado, a palavra “nuvem” não diz nada sobre o domínio de falha.

A quinta é a saída. Um cliente se recuperando de uma falha do provedor precisa de uma imagem exportável, dump de banco de dados, cópia de objeto, controle de DNS e tempo e largura de banda suficientes para mover. O término do contrato, disputa de cobrança ou falha da empresa pode ser tão disruptivo quanto uma falha de hardware se credenciais ou dados estiverem bloqueados em uma conta. Nenhum termo da Cloudnet foi encontrado descrevendo devolução de dados, exclusão, assistência à migração, retenção de backup ou suspensão de conta.

Estas não são alegações de que a Cloudnet carece das capacidades. São as perguntas mínimas que a evidência pública precisaria responder antes de atribuir essas capacidades. Uma cotação privada, contrato ou cronograma técnico poderia alterar a conclusão para um cliente específico. Até que tal evidência apareça, o AS150069 deve ser lido como evidência de operação de rede, não um produto de nuvem.

RPKI é uma higiene de roteamento útil, não resiliência por si só

A Cloudnet deu um passo concreto de segurança de roteamento. A validação do RIPEstat para o agregado IPv4 encontrou uma autorização de origem de rota válida cobrindo o AS150069 e permitindo anúncios até/24. As rotas componentes são, portanto, válidas sob a mesma autorização. A validação para o/48IPv6 também foi válida.

O RPKI ajuda outras redes a rejeitar um anúncio de origem que conflite com a autorização assinada. Ele reduz uma classe de erro ou sequestro de roteamento. Ele não verifica cada AS no caminho, criptografa o tráfego, impede um corte de fibra, fornece um segundo upstream, previne congestionamento ou mantém um roteador energizado. Uma rota válida pode levar a um serviço indisponível se a rede de origem não tiver um caminho funcional até o cliente.

A combinação atual é, no entanto, significativa: recursos registrados, origens IPv4 e IPv6 ativas, objetos de rota e autorizações de origem válidas. Isso mostra mais maturidade operacional do que um nome de empresa dormente. Também aguça a questão da resiliência porque a topologia visível permanece estreita. Alcançabilidade corretamente autorizada através de um vizinho observado ainda é um vizinho observado.

Os anúncios IPv4 mais específicos adicionam outra peculiaridade operacional. Durante o período em que os/24s tiveram baixa visibilidade, o agregado/23permaneceu amplamente visível. Anunciar tanto o agregado quanto os específicos pode preservar uma rota de cobertura se um específico desaparecer. Também pode ser usado para política ou mitigação. Coletores públicos não podem revelar o design pretendido, e o agregado não cria um segundo caminho físico. Redundância de roteamento e redundância de circuito não devem ser confundidas.

O IPv6 também merece uma conclusão limitada. O/48foi anunciado globalmente por anos e seu objeto de rota foi atualizado recentemente. Isso suporta roteamento IPv6 ativo na borda da rede. Não prova que cada cliente de varejo recebe um prefixo IPv6, que o equipamento do cliente o suporta ou que a equipe de suporte soluciona problemas em ambos os protocolos igualmente. Uma divulgação específica do provedor ou medição do lado do cliente seria necessária para estabelecer a profundidade da implantação.

As pessoas afetadas são provavelmente clientes de acesso, não cargas de trabalho hospedadas

O ritmo diário do IPinfo, a licença de ISP e a ausência de um catálogo de hospedagem apontam para uma rede de acesso. As estimativas de usuários observados do Cloudflare e os endereços responsivos na área de Chennai apoiam essa direção. Eles não revelam nomes, localizações exatas ou tipos de clientes. A população afetada provável é, portanto, condicional: residências, pequenas empresas ou usuários institucionais que recebem conectividade através do AS150069 ou através do serviço de acesso da Cloudnet.

Para uma residência, uma interrupção interrompe mensagens, streaming, trabalho remoto, educação, pagamentos e dispositivos conectados. Para uma pequena empresa, a mesma falha pode parar aplicações em nuvem, autorização de cartão, contato com fornecedores e comunicações com clientes. Uma empresa que usa um endereço estático da Cloudnet também pode perder a alcançabilidade de entrada para uma câmera, ponto final de VPN ou serviço auto-hospedado. Esses são mecanismos, não alegações de que qualquer organização nomeada compra o serviço da Cloudnet.

A dependência se estende além do titular da conta. Um operador ou revendedor local pode colocar clientes atrás do espaço roteado da Cloudnet. Nenhum AS downstream era visível, mas arranjos de varejo downstream não exigem um ASN separado. Se a Cloudnet fornece capacidade para outro negócio de acesso, uma falha na fronteira Cloudnet-Niss poderia afetar usuários que não reconhecem o nome de nenhuma das empresas. O roteamento público não pode contar esses arranjos.

Falhas diferentes produzem sintomas diferentes. Um drop cortado afeta uma única instalação. Uma falha de divisor ou porta de acesso afeta um cluster. Uma falha de agregação ou backhaul afeta uma área maior. A perda da entrega da Niss pode afetar toda a pegada roteada. Falha de DNS ou autenticação pode deixar os links ativos enquanto as sessões falham. Erros de cobrança ou sistema de conta podem desconectar um indivíduo sem nenhuma falha de rede. O registro público não identifica quais sistemas a Cloudnet opera por conta própria.

A recuperação deve ser medida a partir da borda do cliente. Restaurar um anúncio BGP não é suficiente se a fibra alimentadora permanecer cortada. Reparar a fibra não é suficiente se a autenticação estiver fora do ar. Energizar um switch não é suficiente se a sessão upstream ainda estiver indisponível. Um relato de incidente sólido identificaria a camada com falha, o operador responsável, os tempos de início e restauração, a área afetada, a solução alternativa e se a capacidade foi totalmente restaurada.

A ausência de uma página de incidentes pública ou histórico de status de serviço impede um julgamento de desempenho. O silêncio não prova confiabilidade perfeita, e relatos de usuários dispersos não estabeleceriam uma taxa em toda a rede sem verificação. A evidência atual apoia o mapeamento da cadeia de falhas, não a pontuação do uptime histórico da Cloudnet.

O que estabeleceria uma imagem operacional mais forte

O primeiro item faltante é uma descrição de serviço atual voltada para o cliente. Para serviço de acesso, deveria nomear cobertura, tecnologia de acesso, velocidades de plano, regras de contenção ou uso justo, termos de instalação, contato para falhas e metas de serviço. Para qualquer serviço hospedado, deveria especificar computação, armazenamento, rede, backup e recursos de migração. Um logotipo e uma promessa genérica de serviço rápido não seriam suficientes.

O segundo é um mapa de rede físico e contratual em um nível apropriado de abstração. A Cloudnet não precisa publicar rotas sensíveis a nível de rua. Poderia divulgar o número de pontos de presença ativos, as cidades ou zonas de serviço que cobrem, se o backhaul é próprio ou alugado e se os circuitos upstream terminam em locais separados e seguem caminhos diversos. A chave é identificar domínios de falha comuns sem expor segredos operacionais.

O terceiro é evidência de capacidade. Medidas úteis incluem tráfego total e em hora de pico, utilização de portas, trânsito comprometido e de burst, capacidade de failover, saturação de nós de acesso e adoção de clientes IPv4/IPv6. Uma captura deve ter uma data. Capacidade de design, interfaces instaladas, capacidade iluminada e vazão disponível para o cliente devem ser relatadas separadamente.

O quarto é evidência de recuperação. A Cloudnet poderia declarar a autonomia de energia de backup por classe de local, política de hardware de reposição, propriedade do escalonamento, janelas de manutenção e desempenho recente de restauração. Uma alegação de resiliência se torna crível quando uma falha foi testada: retirada de rota, perda de upstream, interrupção de energia, substituição de hardware e restauração de configuração. O resultado deve mostrar se o serviço realmente mudou e quanta capacidade permaneceu.

O quinto é a corroboração independente da topologia. Um segundo vizinho visível fortaleceria o caso para diversidade de roteamento, mas ainda exigiria evidência de caminho físico. Um circuito de backup para o mesmo AS pode ser valioso se entrar em uma instalação diferente e evitar dutos comuns. Por outro lado, dois nomes de provedores podem compartilhar a mesma operadora de última milha. Contratos, locais de entrega e pesquisas de rota resolvem o que o BGP sozinho não pode.

O sexto é prova para qualquer alegação de nuvem. Um nome de instalação ou local independentemente verificável, termos do cliente, especificações de infraestrutura, declaração de localização de dados, arquitetura de backup, matriz de responsabilidade de segurança e procedimento de saída moveriam a discussão da inferência para a análise de produto. Um único domínio hospedado ou um servidor respondendo do/23não provaria uma plataforma de nuvem comercial.

Até que esses itens existam, a evidência mais forte da Cloudnet continua sendo sua identidade de ISP regulamentada e roteamento ativo. As incógnitas não são lacunas decorativas. São exatamente os lugares onde o serviço pode falhar: linha de acesso, energia de agregação, backhaul, entrega da Niss, trânsito subsequente, escalonamento de suporte e restauração do cliente.

Uma pequena rede ativa, com uma história mais restrita do que seu nome

A CLOUDNET INTERNET SERVICE PVT LTD não é uma casca corporativa vazia. Ela tem uma autorização de serviço de internet Categoria B para Tamil Nadu, uma identidade consistente de Chennai em registros públicos, um sistema autônomo ativo, uma alocação de 512 endereços IPv4, um/48IPv6 anunciado e autorizações de origem de rota válidas. Suas rotas estão visíveis desde 2022, e seus dados de registro foram mantidos próximos à data de observação.

A mesma evidência estabelece um limite firme. Um vizinho de roteamento imediato era visível. Nenhum material público estabeleceu diversidade upstream ou física, uma pegada de acesso mapeada, largura de banda instalada, autonomia de energia de backup, desempenho de reparo em campo ou uma operação de suporte com pessoal. Mais importante, nada localizou um serviço comercial de nuvem, VPS, bare-metal, colocation, armazenamento ou hospedagem gerenciada.

Isso não é um resultado decepcionante. É um resultado mais útil. O nome não obscurece mais a superfície operacional que pode realmente ser observada. A Cloudnet parece transportar tráfego de acesso em Tamil Nadu através do AS150069 e da Niss Internet Services. Sua resiliência será decidida por infraestrutura comum: cabos, eletrônicos energizados, backhaul, configuração de rota, peças de reposição e pessoas que podem restaurá-los.

O grau de evidência de rede é Fraco para uma avaliação completa de infraestrutura, apesar de fortes evidências de que o ASN está ativo. O roteamento é visível; o sistema físico e comercial por trás dele não é. Um grau mais forte requer prova de onde os clientes se conectam, como o tráfego sai, o que faz failover, como a capacidade se comporta sob estresse e quem repara cada camada. Qualquer futura alegação de serviço de nuvem deve começar um passo antes, provando que há um serviço hospedado a ser avaliado.