CLOUDNET INTERNET SERVICE PVT LTD is a visible Tamil Nadu ISP

Summary

India's Department of Telecommunications listed Cloudnet Internet Service Private Limited as holding a Category B internet-service authorisation for Tamil Nadu, effective 10 April 2023. Corporate-data pages connect the same address and contact details to a Chennai company incorporated in 2021. This establishes a regulated ISP identity, not a cloud-computing product portfolio.
AS150069 was active on 10 July 2026, originating 103.21.6.0/23, both component /24 routes and 2001:df1:66c0::/48. The IPv4 aggregate had been visible since October 2022 and the IPv6 route since November 2022. Current route authorisation was valid under RPKI, and registry records had been maintained recently.
Public route collectors showed only one immediate neighbour for AS150069: Niss Internet Services Private Limited's AS132774. That is evidence of one visible external routing path, not proof that Cloudnet has no private interconnection or backup circuit. It is also not evidence of physical route diversity, automatic failover or spare capacity.
IPinfo characterises AS150069 as a consumer ISP with a pronounced day-and-night traffic rhythm and reports only one hosted domain in the address space. Those are useful signals, not audited customer or product figures. No public Cloudnet service catalogue, data-centre location, rack inventory, virtual-machine offer, bare-metal offer, storage service, uptime commitment, backup policy or migration procedure was found.
The responsible downgrade is therefore from a presumed cloud-service operator to a small, currently routed Tamil Nadu ISP whose exact retail footprint and physical network remain undisclosed. Its resilience depends on local access plant, powered aggregation equipment, the handoff to Niss, Niss's onward connectivity and support labour. Evidence of actual hosted workloads would be required before discussing Cloudnet as a cloud provider.

The cloud hypothesis fails at the first product question

The word "Cloudnet" can do too much work if it is allowed to. It combines two fashionable pieces of network vocabulary, and the company controls internet number resources. Neither fact shows that a customer can buy a virtual machine, a managed database, a storage bucket, a bare-metal server or even a conventional web-hosting account. The distinction matters because a cloud service has failure and recovery obligations that an access provider may never have undertaken.

The strongest company-specific public document is not a cloud catalogue. It is the Department of Telecommunications list of internet-service authorisations as of 31 January 2025. The entry identifies Cloudnet Internet Service Private Limited, licence number DS-11/401/2022-DS-III, Category B, service area Tamil Nadu, with an effective date of 10 April 2023. The authorised contact, registered-office address and phone number line up with the company's corporate and internet-registry records.

The Department's internet-service page explains what Category B means. It is authority to provide internet service in one licensed service area, defined as a telecom circle or metro area. The Unified Licence compendium describes internet access, IPTV and specified forms of internet telephony within the scope of the authorisation. The licence is material evidence that Cloudnet can operate as an ISP in Tamil Nadu. It does not certify that the company has built statewide coverage, and it does not turn an access authorisation into evidence of hosted compute.

The network record points in the same direction. IPinfo's AS150069 overview classifies the network as a consumer ISP and finds a pronounced daily activity rhythm of the kind associated with people using a connection during waking hours. It reports one hosted domain, compared with 512 IPv4 addresses. Hosted-domain counts have measurement limits: a domain can sit behind a content-delivery network, one address can host many names, a private service may not be discoverable, and access customers can run servers. Even with those caveats, one observed domain is not affirmative evidence of a hosting estate.

Cloudnet's public footprint gives no prices or specifications for compute, storage, backup, colocation or managed infrastructure. No data-centre address is named. No server vendor, rack count, power design, certification, availability zone, customer portal, service-level agreement, data-processing addendum, incident history, restore objective or export format is described. A company may sell privately without documenting every service on the open web, but the burden of proof does not reverse. In the absence of a product and an operating surface, the cloud claim must be put down rather than embellished.

That leaves a different and more grounded story. Cloudnet has a live autonomous system, a Tamil Nadu ISP authorisation, a small IPv4 allocation, an IPv6 allocation and a visible upstream dependency. These are the bones of an access network. The physical plant behind them is largely unexposed, which makes resilience harder to assess but does not make the network imaginary.

A Chennai company and a Tamil Nadu authorisation

Corporate aggregators identify Cloudnet Internet Service Private Limited by Corporate Identification Number U64120TN2021PTC142654. Tofler's company page dates incorporation to 8 April 2021, gives authorised share capital of Rs 1 million and paid-up capital of Rs 100,000, and names Logasundari and Gopikrishnan as directors. ZaubaCorp's record supplies the same CIN, Chennai registration and Kottivakkam address, although some date fields in its rendered summaries are inconsistent and should not be treated as a substitute for a current filing.

The address is unusually useful for identity resolution. The licence list places the company on the third floor of plot 11/236A, Vivekanandar Third Street, Kottivakkam, Chennai. APNIC's AS150069 registration uses the abbreviated legal name, CLOUDNET INTERNET SERVICE PVT LTD, and its administrative role repeats the same address and phone number. The IPv4 allocation record and IPv6 allocation record carry the same network name, CNISPL, and the same contact chain. These are not merely similar businesses sharing a generic name; the records converge on one company.

That convergence also keeps several namesakes out of the picture. A separate Cloudnet Broadband Services Private Limited appears in older Haryana licensing material, and Cloudnet Communications Private Limited appears in subscriber tables. Other businesses elsewhere use Cloud Net or Cloudnet as a trading style. They should not be used to fill gaps in this company's service catalogue, customer count or history. The identity anchor here is the Tamil Nadu licence, CIN, Kottivakkam address and AS150069.

The 2025 DoT list is evidence of an authorisation at that reporting date. It is not a daily operating certificate for July 2026. On the other hand, the live routes and recently maintained internet-registry objects provide much fresher technical evidence. The company therefore should not be described as merely registered or historically licensed. Its autonomous system was carrying a globally visible announcement at the observation time.

The address still does not answer where network equipment sits. A registered office can be an administrative office, a point of presence, both, or neither. The IPv4 record includes coordinates 13.427804, 80.14154212, but registry geolocation is operator-supplied metadata, not a survey of a router room. IPinfo places several observed addresses or routers in and around Chennai and Nagari, while its recent probes reached responding addresses from Chennai-area vantage points. Such geolocation is probabilistic. It cannot identify an optical line terminal, prove ownership of a fibre route or establish that a customer is served at a particular street.

The defensible geographic statement is consequently narrow. Cloudnet is authorised for the Tamil Nadu service area, registered in Chennai and operates address space that independent measurements associate with India and the Chennai region. Public evidence does not map its retail footprint inside Tamil Nadu, show that it serves all of Chennai, or disclose a point of presence beyond the registered address.

AS150069 provides current operating evidence

An autonomous system is a unit of routing policy, not a complete business. Still, AS150069 is the clearest evidence that Cloudnet operates something now. RIPEstat's AS overview reported the ASN as announced on 10 July 2026. Its announced-prefix response listed the IPv4 aggregate 103.21.6.0/23, the two more-specific routes 103.21.6.0/24 and 103.21.7.0/24, and IPv6 prefix 2001:df1:66c0::/48.

The IPv4 aggregate contains 512 addresses. Current routing status showed AS150069 as the sole visible origin for the /23, seen by 326 of 327 reporting IPv4 peers. It also showed both /24s beneath the aggregate. Separate status responses for 103.21.6.0/24 and 103.21.7.0/24 recorded the same origin and visibility. This was not a trace visible to only one observer.

The chronology is substantial. Routing history for the /23 begins Cloudnet's aggregate announcement in October 2022 and continues it through the research date. The two /24s first appeared in December 2022. Their visibility fell sharply for a period beginning in March 2025 while the covering /23 remained widely visible, then returned to broad visibility in May 2026. That is a change in route granularity and propagation, not evidence that customer service stopped. Traffic addressed to the two blocks could still follow the covering aggregate when a more-specific route was not visible.

IPv6 is not just a registry reservation. Routing status for 2001:df1:66c0::/48 showed AS150069 originating the prefix to all 321 reporting IPv6 peers on 10 July. The route was first seen in November 2022. APNIC's route object was modified on 8 July 2026, two days before the observation, and the associated contact record had also been updated in June. Those dates show continued resource administration. They do not tell us how much customer traffic uses IPv6 or how many users receive it.

The distinction between installed and usable capacity is essential. A /23 is an address pool, not a bandwidth purchase. Five hundred and twelve IPv4 addresses do not mean 512 customers, servers, ports or megabits. A provider can use addresses for router interfaces, carrier-grade NAT pools, business circuits, infrastructure or spare inventory. One household can use multiple public addresses; many households can share one address. The almost incomprehensibly larger count of numerical addresses inside an IPv6 /48 is even less useful as a capacity measure.

Nor do three simultaneous IPv4 announcements triple the network. The /23 and its two component /24s cover the same address space. More-specific announcements can support routing policy, traffic engineering or operational transition, but the visible routing data does not disclose which purpose applies. Counting the aggregate and components as 1,024 unique IPv4 addresses would double-count the same 512 addresses.

The current routes support a real, active network. They do not show subscriber access technology, port count, aggregate transit, peak utilisation, contention, backhaul, cache capacity or service speed. Those quantities determine whether a sold connection is usable at the evening peak. None can be calculated from the ASN.

One immediate neighbour is the visible external boundary

RIPEstat's AS-neighbour view found one immediate neighbour on 10 July 2026: AS132774. APNIC identifies that ASN as Niss Internet Services Private Limited, a Tamil Nadu network registered in Tirunelveli. CIDR Report's AS150069 view independently shows the same adjacency and no downstream ASN.

Route collectors see topology, not contracts. An AS directly preceding Cloudnet in observed paths is consistent with Niss supplying transit, managed routing or another form of upstream reachability. It does not reveal price, committed bandwidth, burst terms, physical handoff, fibre supplier, notice period, restoration obligation or whether Cloudnet buys the service directly. The commercial label "upstream" is a sensible inference here, but the public result is strictly one visible external BGP neighbour.

The distinction becomes important when discussing redundancy. One visible neighbour is evidence against claiming publicly demonstrated upstream diversity. It is not proof that Cloudnet has only one cable. Cloudnet could have two physically separate circuits into different Niss routers while presenting the same ASN path. It could have a backup session that was idle at the observation time. It could receive a default route over a connection not visible to collectors. Conversely, several BGP sessions to one provider could converge on a single duct, building, router or power domain. Session count and physical diversity are different things.

Niss itself has a broader topology. Its PeeringDB entry lists NIXI Chennai peering and facilities in Chennai and Tirunelveli, while bgp.tools lists several upstreams for AS132774. These are self-reported and observed facts about Niss, not inherited properties of Cloudnet. A Cloudnet packet may benefit from Niss's onward options after reaching AS132774, but Niss having multiple upstreams does not prove that Cloudnet has two independent ways to reach Niss.

The live RIPEstat looking-glass view of the /23 repeatedly placed AS132774 immediately before AS150069 in collected paths. Many paths then passed through Bharti Airtel's AS9498 beyond Niss. That indicates the visible chain at that moment: Cloudnet, Niss, and then larger transit networks. It does not mean Cloudnet holds a direct Airtel contract, and it does not establish where the physical handoff occurs.

This boundary creates a clear failure mechanism. If Cloudnet's only active handoff to Niss fails, or if a routing session is withdrawn without a working alternative, all globally routed Cloudnet addresses may become unreachable even while customer fibre and local switches remain powered. If the Niss connection stays up but its committed capacity is exhausted, users may see congestion rather than a clean outage. If a route filter or authorisation is wrong, one address family or one prefix length may fail while others continue.

Recovery depends on facts that are not public: whether Cloudnet has a second circuit; whether it terminates on a different edge device; whether that circuit follows a separate path; whether failover is automatic; whether the backup has enough capacity for the normal peak; whether both IPv4 and IPv6 are carried; and which company owns the first response. A diagram with two lines would prove none of these unless it identified the physical and contractual common points.

The physical network begins where BGP stops explaining

BGP can show that AS150069 makes an address block reachable. It cannot show the cable from a customer's premises to the first active device. Between those points may sit an optical network terminal, drop fibre, splitter, aerial or underground distribution fibre, an optical line terminal, Ethernet aggregation, leased backhaul, patch panels, power supplies and cooling. The public evidence does not identify which of these Cloudnet uses or owns.

The company's Category B authority permits service across the Tamil Nadu licensed service area; it does not certify a particular access design. Cloudnet could operate fibre-to-the-home, business Ethernet, wireless links, service through local cable partners or a mixture. No public coverage map, plan sheet, optical-network specification, tower record or local-cable partnership was found. The presence of two responsive IP addresses in IPinfo's recent scan shows that endpoints answered measurements, not how the last mile was built.

This unknown ownership boundary changes who repairs an outage. A cut customer drop may be Cloudnet's responsibility or that of a local operator. A feeder-fibre failure may require a pole crew, civil contractor or leased-fibre owner. An aggregation fault may need replacement optics, a switch, an OLT card or a power supply. A backhaul fault may sit with another carrier. The customer sees one unavailable service, while the repair crosses several organisations.

Power creates its own chain. Customer equipment needs electricity. Street cabinets, wireless sites, optical line terminals, aggregation switches and edge routers need electricity. A registered office having power says nothing about a remote distribution node. A UPS can bridge a short interruption but has finite runtime and batteries that age. A generator helps only if it is installed, fuelled, maintained and connected to the affected site. No public Cloudnet statement gives backup runtime, generator coverage, battery maintenance, dual feeds or site power architecture.

Hardware inventory matters for a small network because the failed part may be cheap but operationally specific. A spare optical module can restore a link quickly if it is compatible and on hand. A failed line card, power supply or access chassis can take longer if it must be ordered. Configuration backups need to be current and usable on replacement equipment. The public record contains no mean-time-to-repair data, stock policy, vendor list or maintenance window.

Support labour is therefore part of capacity. A network can have unused bandwidth and still remain unavailable because no technician can reach a cut, no engineer can change a route or no authorised contact can escalate with an upstream. Cloudnet's registry and licence records publish a single administrative contact chain, but those records do not describe a staffed network operations centre, 24-hour field coverage, ticketing system or escalation rota. It would be wrong to turn a contact number into a service-level promise.

The physical location question must remain open. Kottivakkam is a registered-office location. Registry coordinates suggest another point in northern Tamil Nadu, and third-party measurements associate addresses with Chennai, Nagari and other Tamil Nadu labels. IP geolocation databases can reflect address registration, inferred user locations or measurement bias. None proves that Cloudnet has a rack at a named data centre or owns equipment at any particular site.

Billing, support and contracts can interrupt an intact network

Not every service failure begins with a cut cable. An access provider has to identify customers, authorise sessions, issue bills, accept payments, apply plan changes and distinguish a delinquent account from a network fault. Depending on the design, authentication may rely on a subscriber database, RADIUS server, broadband network gateway, optical-network management system or a reseller's platform. The public record does not disclose which of these Cloudnet uses. It does establish that customer administration is a separate operating layer from BGP.

That distinction is easy to see from the outside. AS150069 can remain globally visible while one account is unable to connect. A payment posted to the wrong ledger, an expired credential, a failed authentication server or an incorrect suspension flag can present as an outage at the customer's router. Field staff may find healthy light levels and an intact upstream path, yet the service remains unavailable until account control is corrected. A route collector will record none of it.

Billing continuity also matters during a wider incident. Customers need a reachable channel to report faults and determine whether a payment, device or area outage is responsible. Staff need current account and network records. If the same power, server or connectivity failure takes out both the access service and its support systems, diagnosis slows. Cloudnet's published regulatory and registry contacts do not reveal whether it has a separate customer-care platform, off-site records, emergency phone routing or a tested manual process.

The wholesale contract with the visible neighbour is another possible control point. A fibre and router can be technically sound while a provider dispute, expired order, unpaid invoice, capacity cap or lapsed route authorisation interrupts service. There is no evidence that any such dispute has occurred between Cloudnet and Niss. The point is structural: where reachability depends on another operator, commercial continuity belongs in the resilience assessment alongside optics and power.

Provider-contract failure becomes more consequential when there is no proven alternative. Changing upstreams requires more than ordering a line. The new provider must reach a handoff, accept Cloudnet's routes, apply filters, carry IPv4 and IPv6, support valid route authorisations and provide enough capacity. Customer traffic may need new defaults, DNS paths or address policy. If the migration is rushed after an existing service ends, the network can be offline even though Cloudnet still controls its ASN and prefixes.

Moving individual access customers raises a different migration problem. If Cloudnet ceased serving an area or handed subscribers to another operator, continuity would depend on the ownership of drop fibre and customer equipment, the portability of account records, notice periods, refunds and the replacement provider's ability to provision service. Public BGP may show no change if the addresses and origin stay the same, or a large change if customers are renumbered. Neither outcome alone explains who assumed the retail obligation.

For a genuine hosted service, migration would be harder again: customers would need data export, machine images, DNS control and time to rebuild. That is one reason the unsupported cloud hypothesis cannot be treated casually. It implies obligations for data custody and exit that are absent from the evidence. For the access network that is actually visible, the immediate questions are simpler but still unanswered: who owns the subscriber relationship, who can restore authentication, who escalates with Niss, and how a customer is moved if that relationship ends.

Installed capacity is not retail capacity

There is no public Cloudnet price list or speed table to compare against the network. Even if one existed, advertised access speed would still be only the outer edge of the capacity question. A 100 Mbps subscriber plan does not reserve 100 Mbps through every aggregation switch, backhaul and transit link at all hours. Providers pool capacity on the assumption that customers will not all demand their maximum rate simultaneously.

The relevant operational quantities are absent. Cloudnet does not publish the number of active subscriptions, mix of speeds, committed transit, peering capacity, backhaul design, port utilisation, busy-hour throughput, oversubscription ratio or congestion record. The 512-address IPv4 pool does not fill those gaps. Carrier-grade NAT can let far more than 512 customer devices share the pool; static business services can consume several addresses per account; and IPv6 changes the addressing calculation without adding a bit of transit capacity by itself.

Cloudflare Radar has displayed an estimated population for AS150069 in the hundreds, with the displayed estimate changing across snapshots and subpages. Such estimates use traffic and measurement signals rather than the provider's billing system. They indicate a small observable user population and reinforce the consumer-ISP interpretation, but they should not be quoted as a subscriber ledger. One subscription may serve a household or business with many people, while some users may not appear in the underlying measurements.

The same caution applies to measured performance. Cloudflare's internet-quality page for AS150069 aggregates available speed-test and network observations. A measurement taken from a responding address can show that a path worked at a time and place. It cannot certify a plan speed for every subscriber, quantify outage frequency across the access footprint or reveal whether the tested line is representative. Small samples are particularly vulnerable to composition changes.

TRAI's 2024 broadband quality regulations establish benchmarks and reporting duties for access and broadband providers, including service provisioning, network performance, fault repair and complaint handling. The December 2024 quarterly performance report explains that its published broadband performance summary covered providers with more than 10,000 subscribers. Cloudnet is not identified in the public summary as one of those large providers. That omission does not establish its size or exempt it from applicable obligations; it means the national summary cannot be used as Cloudnet-specific performance evidence.

Usable capacity is what remains after contention, failure and policy. If a backup path carries only a fraction of normal traffic, nominal redundancy may still produce severe congestion. If IPv4 specifics are withdrawn but the aggregate remains, reachability can continue with changed traffic engineering. If IPv6 fails while IPv4 stays up, users may experience delays and application-specific faults rather than total disconnection. A credible capacity statement would need busy-hour measurements for both address families, not the size of the allocated prefixes.

A cloud service would require a different evidence set

An access provider and a cloud provider can share routers, addresses and staff, but they sell different promises. Access service carries a customer's traffic to other systems. Hosted compute keeps a customer's application, data or server running on the provider's own or leased infrastructure. The second promise introduces questions that the AS150069 record cannot answer.

The first is the asset. A credible virtual-server offer should identify a compute platform or at least disclose CPU, memory, storage, network and tenancy characteristics. Bare metal should identify server classes and provisioning terms. Colocation should identify facility, rack power and remote-hands arrangements. Managed hosting should define which operating tasks the provider performs. No company-specific material found here describes any of those products.

The second is location. "Hosted in India" or "hosted in Chennai" would need evidence of the facility where data and compute reside. An ASN registered in India does not locate a server. Traffic may be routed through an Indian network to equipment in another facility or jurisdiction; conversely, Cloudnet could use third-party Indian infrastructure that does not appear in its own address space. Registry country and data residency are separate claims.

The third is control. If Cloudnet resold another provider's virtual machines, Cloudnet might control billing and support while the underlying provider controlled racks, hypervisors, power and parts. If Cloudnet leased colocation, it might own servers but not the building systems. If it operated its own room, it might still depend on landlords and carriers. Customers need to know who can restore power, replace a disk, recover a backup and approve emergency access. No public document draws that boundary.

The fourth is redundancy. A cloud service can replicate data across drives, hosts, racks, rooms, buildings or regions, each protecting against a different failure. Two copies on one host do not survive host failure. Two hosts in one rack may share a power distribution unit. Two racks in one building may share utility power, cooling and upstream fibre. Two buildings can still depend on one metro duct or control plane. Without a disclosed architecture and tested restore path, the word "cloud" says nothing about the failure domain.

The fifth is exit. A customer recovering from provider failure needs an exportable image, database dump, object copy, DNS control and enough time and bandwidth to move. Contract termination, billing dispute or company failure can be as disruptive as a hardware fault if credentials or data are locked to one account. No Cloudnet terms were found describing data return, deletion, migration assistance, backup retention or account suspension.

These are not allegations that Cloudnet lacks the capabilities. They are the minimum questions that public evidence would need to answer before assigning those capabilities. A private quotation, contract or technical schedule could change the conclusion for a particular customer. Until such evidence appears, AS150069 should be read as network-operation evidence, not a cloud product.

RPKI is useful routing hygiene, not resilience by itself

Cloudnet has taken a concrete routing-security step. RIPEstat validation for the IPv4 aggregate found a valid route-origin authorisation covering AS150069 and permitting announcements down to /24. The component routes are therefore valid under the same authorisation. Validation for the IPv6 /48 was also valid.

RPKI helps other networks reject an origin announcement that conflicts with the signed authorisation. It reduces one class of routing mistake or hijack. It does not verify every AS in the path, encrypt traffic, stop a fibre cut, provide a second upstream, prevent congestion or keep a router powered. A valid route can lead to an unavailable service if the originating network has no working path to the customer.

The current combination is nevertheless meaningful: registered resources, active IPv4 and IPv6 origins, route objects and valid origin authorisations. It shows more operational maturity than a dormant company name. It also sharpens the resilience question because the visible topology remains narrow. Correctly authorised reachability through one observed neighbour is still one observed neighbour.

The more-specific IPv4 announcements add another operational wrinkle. During the period when the /24s had low visibility, the /23 aggregate remained broadly visible. Advertising both aggregate and specifics can preserve a covering route if a specific disappears. It may also be used for policy or mitigation. Public collectors cannot reveal the intended design, and the aggregate does not create a second physical path. Routing redundancy and circuit redundancy should not be conflated.

IPv6 also deserves a bounded conclusion. The /48 has been globally announced for years and its route object was updated recently. That supports live IPv6 routing at the network edge. It does not prove that every retail customer receives an IPv6 prefix, that customer equipment supports it, or that support staff troubleshoot both protocols equally. A provider-specific disclosure or customer-side measurement would be needed to establish deployment depth.

The people affected are probably access customers, not hosted workloads

IPinfo's daily rhythm, the ISP licence and the absence of a hosting catalogue point toward an access network. Cloudflare's observed-user estimates and responsive Chennai-area addresses support that direction. They do not reveal names, exact locations or customer types. The probable affected population is therefore conditional: households, small businesses or institutional users that receive connectivity through AS150069 or through Cloudnet's access service.

For a household, an outage interrupts messaging, streaming, remote work, education, payments and connected devices. For a small business, the same failure can stop cloud applications, card authorisation, supplier contact and customer communications. A business using a Cloudnet static address may also lose inbound reachability to a camera, VPN endpoint or self-hosted service. These are mechanisms, not claims that any named organisation buys Cloudnet service.

The dependency extends beyond the account holder. A local operator or reseller may place customers behind Cloudnet's routed space. No downstream ASN was visible, but downstream retail arrangements do not require a separate ASN. If Cloudnet supplies capacity to another access business, a fault at the Cloudnet-Niss boundary could affect users who do not recognise either company name. Public routing cannot count those arrangements.

Different faults produce different symptoms. A severed drop affects one premise. A splitter or access-port fault affects a cluster. An aggregation or backhaul fault affects a larger area. Loss of the Niss handoff can affect the entire routed footprint. DNS or authentication failure can leave links up while sessions fail. Billing or account-system errors can disconnect an individual without any network fault. The public record does not identify which systems Cloudnet operates itself.

Recovery should be measured from the customer edge. Restoring a BGP announcement is not enough if the feeder fibre remains cut. Repairing fibre is not enough if authentication is down. Powering a switch is not enough if the upstream session is still unavailable. A sound incident account would identify the failed layer, responsible operator, start and restoration times, affected area, workaround and whether capacity was fully restored.

The absence of a public incident page or service-status history prevents a performance judgement. Silence does not prove perfect reliability, and scattered user reports would not establish a network-wide rate without verification. The current evidence supports mapping the failure chain, not scoring Cloudnet's historical uptime.

What would establish a stronger operating picture

The first missing item is a current customer-facing service description. For access service, it should name coverage, access technology, plan speeds, contention or fair-use rules, installation terms, fault contact and service targets. For any hosted service, it should specify compute, storage, network, backup and migration features. A logo and a generic promise of fast service would not be enough.

The second is a physical and contractual network map at an appropriate level of abstraction. Cloudnet need not publish sensitive street-level routes. It could disclose the number of active points of presence, the cities or service zones they cover, whether backhaul is owned or leased, and whether upstream circuits terminate at separate sites and follow diverse paths. The key is to identify common failure domains without exposing operational secrets.

The third is capacity evidence. Useful measures include total and busy-hour traffic, port utilisation, committed and burst transit, failover capacity, access-node saturation and IPv4/IPv6 customer adoption. A snapshot should carry a date. Design capacity, installed interfaces, lit capacity and customer-available throughput should be reported separately.

The fourth is recovery evidence. Cloudnet could state backup-power runtime by site class, spare-hardware policy, escalation ownership, maintenance windows and recent restoration performance. A resilience claim becomes credible when a failure has been tested: route withdrawal, upstream loss, power interruption, hardware replacement and configuration restore. The result should show whether service actually moved and how much capacity remained.

The fifth is independent topology corroboration. A second visible neighbour would strengthen the case for routing diversity but would still require physical-path evidence. A backup circuit to the same AS can be valuable if it enters a different facility and avoids common ducts. Conversely, two provider names can share the same last-mile carrier. Contracts, handoff locations and route surveys settle what BGP alone cannot.

The sixth is proof for any cloud claim. A facility name or independently verifiable site, customer terms, infrastructure specifications, data-location statement, backup architecture, security responsibility matrix and exit procedure would move the discussion from inference to product analysis. A single hosted domain or a server responding from the /23 would not prove a commercial cloud platform.

Until those items exist, Cloudnet's strongest evidence remains its regulated ISP identity and live routing. The unknowns are not decorative gaps. They are the exact places where service can fail: access line, aggregation power, backhaul, Niss handoff, onward transit, support escalation and customer restoration.

A live small network, with a narrower story than its name

CLOUDNET INTERNET SERVICE PVT LTD is not a blank corporate shell. It has a Tamil Nadu Category B internet-service authorisation, a consistent Chennai identity across public records, an active autonomous system, a 512-address IPv4 allocation, an announced IPv6 /48 and valid route-origin authorisations. Its routes have been visible since 2022, and its registry data was maintained close to the observation date.

The same evidence sets a firm boundary. One immediate routing neighbour was visible. No public material established upstream or physical diversity, a mapped access footprint, installed bandwidth, backup-power runtime, field-repair performance or a staffed support operation. Most importantly, nothing located established a commercial cloud, VPS, bare-metal, colocation, storage or managed-hosting service.

That is not a disappointing result. It is a more useful one. The name no longer obscures the operating surface that can actually be observed. Cloudnet appears to carry access traffic in Tamil Nadu through AS150069 and Niss Internet Services. Its resilience will be decided by ordinary infrastructure: cables, powered electronics, backhaul, route configuration, spare parts and people who can restore them.

The network evidence grade is Weak for a full infrastructure assessment, despite strong evidence that the ASN is active. Routing is visible; the physical and commercial system behind it is not. A stronger grade requires proof of where customers connect, how traffic leaves, what fails over, how capacity behaves under stress and who repairs each layer. Any future cloud-service claim must begin one step earlier, by proving that there is a hosted service to assess.