Summary

  • RIPE RDAP identifies AS213868 as takecloud, links it to organisation handle ORG-TS695-RIPE, and names TAKECLOUD SAS as the registrant.
  • The captured RIPEstat view shows one announced IPv4 prefix, 45.130.47.0/24, no announced IPv6 prefix and one observed neighbour.
  • The same /24 is visible from AS213868 and has a valid RPKI route-origin authorisation for that exact origin and prefix length.
  • Takecloud's own site describes French data-centre hosting, VEEAM immutable backups, recovery planning, interconnection options and 99.99 per cent availability.
  • Those first-party statements do not independently prove site ownership, power design, carrier diversity, backup restoration, customer failover or measured availability.
  • The useful operating question is where the one visible public route meets the private chain of facilities, electricity, transit, servers, storage, recovery operations and customer support.

The company-to-ASN bridge is direct

The strongest public identity link begins with a unique number resource rather than a broad service label. RIPE's RDAP record for autonomous system 213868 uses the name takecloud. It identifies ORG-TS695-RIPE as the registrant organisation, and that organisation is named TAKECLOUD SAS. The record carries the same Villeneuve-d'Ascq location that appears in the company's current public identity. Registration and last-change timestamps place the ASN assignment in November 2024.

That chain matters because the name Takecloud could otherwise refer to a brand, a product or a commercial website without establishing control of a network resource. The RDAP record makes the relationship reproducible. A reader can move from the ASN to the organisation handle and from the organisation handle to the legal company name. The existing BTW directory object supplies the same company identity and passes its canonical public route checks.

The bridge is exact, but its scope is narrow. An ASN is an identifier for routing policy. It is not a list of servers, customers, data centres, backup repositories or contracts. The assignment says who is accountable for the resource. It does not establish which Takecloud services currently use it, how much traffic crosses it, or whether every customer-facing product depends on it.

The timing also deserves restraint. AS213868 is a relatively recent assignment compared with Takecloud's first-party statement that the company has operated for more than a decade. The ASN cannot stand in for the company's entire history. It captures a newer public network perimeter inside a longer commercial operation. Any claim that older services were always delivered through this ASN would require separate historical evidence.

This exact-but-bounded identity is the right starting point for infrastructure analysis. It provides an accountable operator and a testable resource while preventing the company name from becoming a shortcut to assumptions about physical ownership or operational performance.

One IPv4 prefix is currently visible

RIPEstat's AS overview marks AS213868 as announced. Its announced-prefix response contains one route: 45.130.47.0/24. The routing-status snapshot describes one IPv4 prefix covering 256 addresses, no IPv6 prefix, one observed neighbour and visibility from 330 of 330 sampled IPv4 RIS full-feed peers. The prefix overview independently reports the same /24 as announced from AS213868.

The observation is simple enough to state precisely. In the captured RIPE RIS view, AS213868 originates one globally visible IPv4 /24. That is materially stronger than a registry-only claim because it describes running routing state. It establishes that Takecloud's assigned ASN is not merely parked in the database at the observation time.

The figures remain bounded by the measurement system. RIPEstat notes that routes with very low visibility are excluded from the announced-prefix result. Its routing-status response also says the requested query time was adjusted to the latest data available. The 330-of-330 visibility number describes the sampled full-feed peers used by that service, not every router on the Internet.

One route does not reveal one service. A /24 can support customer systems, management services, public endpoints, transit functions or combinations of those uses. The accepted sources do not map addresses inside the prefix to individual products. They also do not show traffic volume, utilization, latency, congestion or customer geography.

The most defensible conclusion is therefore a perimeter statement: Takecloud has one clearly observed public IPv4 origin in the current snapshot. The route is a real operating surface and a useful monitoring object. It is not a proxy for the size, quality or resilience of the systems behind it.

The prefix and the route authorisation align

The route-origin authorisation adds a second current control layer. RIPEstat's RPKI validation response for AS213868 and 45.130.47.0/24 reports a valid result. The returned ROA names origin 213868, covers the exact /24 and sets maximum length 24. In the same snapshot, the BGP prefix overview reports AS213868 as the observed origin.

This alignment is operationally useful. The registry holder, the observed route origin and the authorisation metadata point to the same ASN. Networks performing route-origin validation can distinguish that exact announcement from a route with an unexpected origin or an unauthorised more-specific prefix.

A valid ROA is not an end-to-end security certificate. It validates the relationship between a prefix and an origin ASN. It does not authenticate every router in the path, inspect the traffic, verify the company behind an application, or prove that an upstream will remain available. It also does not prevent all route leaks, path manipulation or configuration errors.

The maximum-length value matters. A max length of 24 authorises the /24 but not a more-specific /25 or /26 under the same ROA. If a more-specific route appeared, it would need separate authorization or would be classified differently by validating networks. The current source set contains no such more-specific observation.

Alignment should be treated as a maintained condition rather than a permanent badge. The route can move to another origin, the ROA can change, or the prefix can disappear. Each change would create a new state that needs a dated comparison. For now, the record supports a narrow positive finding: the visible Takecloud route and the returned RPKI authorization agree at the origin layer.

The allocation record is not a service map

RIPE RDAP records 45.130.47.0/24 as an active allocated provider-aggregatable network. The network name is FR-TAKECLOUD-20190717, and the organisation link points to ORG-TS695-RIPE. That provides a clear resource-accountability bridge from the address block to TAKECLOUD SAS.

RIPE's inverse organisation search returns a wider resource set. It includes multiple IPv4 allocation records, an IPv6 allocation record and AS213868 under the same organisation handle. Those entries show that the company appears across more than one registry object. They do not show that every allocation is currently announced or used by the same platform.

The current routing snapshot illustrates that distinction. It reports one visible IPv4 /24 and no IPv6 origin for AS213868. An allocated IPv6 block can exist without appearing under that ASN at the sampled time. The allocation remains relevant for accountability, planning and future monitoring, but it is not current route evidence.

Address ownership also does not identify the workload behind an address. A registered range can contain company systems, customer systems, shared services, network appliances or unused capacity. Public RDAP does not expose those internal assignments. Reverse DNS, certificates and service banners could add clues, but none would by itself prove physical location or customer ownership.

Treating an allocation as a service map would distort both scale and dependency. The number of addresses does not translate into the number of servers, virtual machines, subscribers or applications. A /24 can be lightly used or densely shared. The useful fact is that Takecloud controls a clearly identifiable address resource that is currently routed through its ASN. Everything behind that boundary needs another evidence layer.

The public route is not the cloud architecture

Cloud and managed-hosting services depend on many components that BGP does not describe. The visible route identifies how an address block enters the global routing system. It does not show the switching fabric, virtualization layer, storage design, backup infrastructure, orchestration systems, support tools or customer identity controls behind that ingress.

The route can remain visible while an application fails. A server cluster may lose storage, a database may stop accepting writes, authentication may fail, or a customer configuration may break even though the /24 continues to originate normally. Conversely, a route can disappear while workloads remain healthy inside a facility but unreachable from external networks.

That separation is essential when interpreting availability. Public reachability is one dependency, not the whole service. A 99.99 per cent commitment could refer to a particular platform, connectivity component or contractual measurement method. Without the underlying service description and exclusions, it cannot be compared directly with BGP visibility.

The ASN also cannot reveal tenancy boundaries. Takecloud may use owned hardware, leased hardware, colocation, upstream cloud capacity or a combination. The accepted first-party pages describe managed infrastructure and hosting, but they do not provide a complete technical inventory that maps each service to a physical or contractual layer.

The routing perimeter is still valuable. It gives customers and external operators a stable point to monitor. Unexpected origin changes, route loss or authorization drift can be detected at that boundary. The discipline is to stop there until additional evidence connects the route to specific systems. A precise public perimeter is more useful than an invented architecture.

First-party pages define the promise, not the proof

Takecloud's website places the company in a practical service context. It describes hosting and backup, managed IT, cybersecurity, telecom and network services. The hosting page refers to a French data centre, names Lesquin, advertises 99.99 per cent availability, mentions immutable VEEAM backups and presents recovery planning with defined recovery-point and recovery-time objectives.

Those statements are relevant because they identify what customers may believe they are buying. They also reveal the dependency categories that deserve verification: facility location, power continuity, network access, server operations, storage, backup immutability, restore procedures and support escalation.

First-party claims remain claims. A company can accurately describe a service without publishing the engineering records needed to test every part of it. The accepted pages do not include a site ownership document, utility design, generator runtime, carrier list, cross-connect map, independent uptime measurement, backup restore log or customer failover record.

The phrase "our data centre" is especially ambiguous without a legal and operational boundary. It can mean owned property, leased space, a dedicated room, a managed footprint or a commercial service presented under the provider's name. The source set does not resolve which interpretation applies in Lesquin.

The correct use of the website is attribution and question formation. Takecloud says it offers these capabilities and commitments. The public network record shows one current route and matching authorization. The unproved space between them is not a reason to dismiss the service. It is the infrastructure surface that requires evidence before availability or resilience can be treated as measured fact.

A 99.99 per cent promise needs a failure definition

Availability percentages can appear precise while leaving the underlying event undefined. A 99.99 per cent figure implies roughly 52.6 minutes of annual unavailability if measured continuously across a calendar year. That arithmetic says nothing about what the company counts as unavailable, which service is covered, how maintenance is treated or whether credits rather than performance are the contractual remedy.

The accepted first-party page presents the figure as a guarantee. It does not provide the complete measurement contract in the captured source set. A guarantee may apply to facility power, network reachability, a hosting platform, a managed service or another component. Each produces a different operational meaning.

BGP uptime cannot verify application uptime. AS213868 may remain visible while a hosted workload is inaccessible. Likewise, a short route interruption visible to some networks may not breach a platform SLA if traffic moves through another path or if the metric excludes upstream events. Without definitions, the route and the percentage cannot be compared.

Maintenance and force-majeure clauses often determine how availability is calculated. So do the observation point, polling interval, minimum outage duration and customer reporting process. None of those details is present in the frozen evidence. The 99.99 per cent number should therefore be attributed to Takecloud rather than repeated as an independently verified performance record.

The useful test is a failure path. What happens when the visible /24 loses reachability, the facility loses utility power, storage becomes inconsistent, or the support team cannot restore a workload? Which clock starts, which evidence records the event, and what makes the service usable again? A percentage becomes operationally meaningful only when those questions have documented answers.

The Lesquin facility boundary remains unresolved

Takecloud's hosting page references a data centre in Lesquin and describes the platform as operated by its teams. That is the clearest public physical-location claim in the accepted source set. It is still insufficient to establish the ownership, operating agreement or complete technical role of the site.

A place name can describe several different dependencies. Takecloud could own the property, lease a private suite, rent racks in a third-party facility, use a managed hosting contract, or operate equipment while another company controls power, cooling and building security. Each arrangement assigns failure responsibility differently.

The site claim also does not establish that every service associated with AS213868 is located there. The visible /24 could terminate at the facility, at an upstream network, across multiple sites or through an architecture not disclosed publicly. BGP identifies the origin policy, not the physical termination point.

Independent facility evidence would need to bind the exact company and exact service to the location. Useful records could include a facility operator statement, property or lease evidence, cross-connect documentation, technical certifications with scope, utility arrangements, or customer service descriptions that identify the operating boundary.

Until that evidence exists, the defensible language is limited. Takecloud publicly says it provides hosting in a French data centre and names Lesquin. The company and its route are real and current. The physical control model, capacity and failure domains behind the location remain unverified. That boundary should be preserved because it determines who can actually repair a power, cooling, building or carrier fault.

Power is the first hidden dependency

Every hosted service ultimately depends on electricity. The public routing record can remain intact at distant collectors even while equipment at a site runs on batteries, transfers to generators or shuts down. A route origin is not a power-status sensor.

The accepted source set contains no utility-feed diagram, generator specification, fuel contract, battery runtime or tested transfer record for the referenced hosting environment. It also does not identify whether Takecloud or a facility partner controls those systems. Without that boundary, a resilience claim cannot assign responsibility for prevention or recovery.

Installed backup equipment is not the same as usable continuity. A generator may exist but fail to start, lack fuel, exceed its tested load or depend on cooling and switchgear that share the original failure. Batteries may bridge a short transfer but not a prolonged utility outage. Maintenance can remove redundancy even when normal diagrams show multiple components.

Power capacity also constrains growth. A rack can have physical space while lacking deliverable electrical capacity. A facility can announce expansion before utility service, switchgear, transformers and cooling are commissioned. Nothing in AS213868 or the /24 distinguishes designed, installed, energised, commissioned and customer-usable capacity.

The practical evidence would be dated and operational: utility topology, tested generator load, fuel autonomy, maintenance arrangements, transfer results and a clear owner for each component. Until then, the public record supports no claim about dual feeds, generator endurance or electrical independence. The power layer remains a necessary but unresolved part of Takecloud's service promise.

Network diversity cannot be inferred from one neighbour field

RIPEstat reports one observed neighbour for AS213868 in the captured routing-status view. That is a useful measurement, but it is not a complete topology map. The field reflects the routes visible to the service and the way neighbouring autonomous systems are inferred from collected BGP paths.

One observed neighbour does not prove one physical carrier. Multiple physical circuits can terminate in one upstream ASN. The reverse is also true: several AS-level paths can traverse a shared duct, building entrance, metro ring or power system. Logical and physical diversity are different properties.

The ASN's RIPE routing policy record names upstream relationships, but policy declarations and current observations do not necessarily describe every active or backup path. A configured relationship can be inactive, selective, customer-specific or invisible in the sampled route. A backup link may not appear until a failover event.

Takecloud's first-party reference to data-centre/cloud interconnection options describes a service capability. It does not identify which carriers serve the referenced environment, where paths separate, how failover is triggered, or whether customer traffic can move without changing the failure domain.

Proving network redundancy would require current circuit and path evidence. At minimum, the analysis would need distinct carrier contracts, separate physical entrances or routes, tested failover behavior, routing-policy confirmation and evidence that monitoring detects partial reachability. The one visible neighbour should therefore be reported as one observed relationship, not as proof of either fragility or resilience.

The absence of an IPv6 origin is a bounded fact

The inverse RIPE organisation lookup includes an IPv6 allocation object associated with TAKECLOUD SAS. The current RIPEstat routing snapshot for AS213868 reports no announced IPv6 prefix and zero IPv6 visibility. Both records can be true at the same time.

An allocation indicates that number space has been registered to the organisation. It does not require the space to be globally originated through this ASN at every time. The company may be preparing deployment, using another origin, assigning the resource privately, or not using it. None of those explanations is established by the accepted evidence.

The absence should not be converted into a service-quality judgment. Customers may receive IPv6 through another network, or particular products may remain IPv4-only by design. The current source set does not describe customer addressing, internal networking or product-level protocol support.

It is nevertheless a useful monitoring point. If an IPv6 route later appears under AS213868, the event would mark an observable expansion of the public routing perimeter. The prefix, origin, authorization and visibility could then be frozen and compared with the present state.

Separating allocation from announcement prevents two errors. It avoids calling the company dual-stack merely because an IPv6 object exists, and it avoids calling the allocation unused merely because this ASN does not originate it in the snapshot. The correct present-tense statement is narrower: no IPv6 prefix is visible from AS213868 in the captured RIPEstat view.

Backup claims require evidence of restoration

Takecloud's hosting page refers to automated VEEAM backups, immutable storage and recovery planning. Those are relevant controls, but their effectiveness depends on implementation and testing. A backup is not a recovery until usable data has been restored within the required time and integrity boundary.

Immutability can protect a copy from alteration during a defined retention period. It does not guarantee that the copy contains every required system, that credentials remain available, that encryption keys can be recovered, or that the restore target has enough compute, storage and network capacity.

Recovery-point and recovery-time objectives are also targets rather than outcomes. RPO defines the acceptable data-loss interval; RTO defines the intended restoration time. Meeting them requires synchronized application, database, identity, DNS, network and operational procedures. A storage copy alone may not restore a working service.

The accepted pages do not contain restore-test dates, success rates, sample scope, isolated recovery environments or incident results. They do not identify whether backup repositories share a facility, operator, account or administrative control with production. Those shared dependencies can matter during ransomware, credential compromise or a site outage.

The appropriate claim boundary is therefore clear. Takecloud says it provides immutable backups and recovery planning. The public evidence does not independently establish backup completeness, separation, restoration performance or customer recovery outcomes. A stronger assessment would require dated restore evidence and a dependency map showing how data, credentials, infrastructure and people come together during recovery.

Customer continuity depends on more than the server

Takecloud presents its services to small and medium-sized organisations, industrial customers and public-sector bodies. Those users can depend on hosted applications, files, communications, identity systems and support. An interruption can therefore affect business processes even when the underlying server hardware remains available.

The customer path begins before the hosting platform. Local access circuits, DNS, identity providers, endpoint configuration and customer credentials can all determine whether a service is usable. It continues after the platform through application dependencies, third-party APIs, payment systems and user support.

AS213868 exposes only one segment of that chain. Its route can be monitored from outside, but it does not reveal whether a customer uses the /24, reaches a service through another network, or depends on a separate cloud provider. The accepted sources contain no customer-to-prefix mapping.

This is why capacity and resilience must be expressed at the service boundary. Available rack power does not help if an upstream authentication service fails. A healthy route does not help if backup credentials are inaccessible. A restored virtual machine may still be unusable if DNS, certificates or database state are stale.

Evidence of customer continuity would include dependency inventories, tested failover procedures, recovery priorities, communication plans and measured restoration outcomes. Public testimonials or service labels would not replace those records. The current source set supports a company-level operating context and a public route, but not a claim that every customer dependency has been mapped or tested.

Ownership, operation and dependency are separate roles

Infrastructure discussions often collapse three questions into one: who owns an asset, who operates it, and who depends on it. Takecloud's public identity and AS213868 establish accountability for a network resource. They do not resolve every role in the hosting chain.

The company may own equipment while relying on a facility operator for power and cooling. It may operate customer systems while leasing connectivity from carriers. It may hold address space while another network supplies a physical path. Customers may depend on Takecloud even where parts of the service are provided under upstream contracts.

Each boundary affects incident response. The asset owner may authorize replacement, the operator may control access, and the dependent customer may define urgency. A service can remain delayed when those roles are unclear even if spare equipment exists.

Public marketing tends to present a unified service because customers buy one outcome. Engineering accountability still needs the underlying handoffs. Which party can enter the facility, switch a circuit, restore data, change a route-origin authorization, update DNS or communicate with customers?

The current record answers only part of that list. TAKECLOUD SAS is the exact company behind AS213868 and the /24 registry objects. The first-party site says its teams operate the service environment. Legal title to the building, power system, fibre paths, server estate and backup infrastructure is not established. The missing boundaries are not administrative trivia; they determine who can keep the service running and who can restore it after failure.

Failure can occur while the route looks healthy

A route collector sees whether a prefix is announced and through which origin. It does not see the health of a virtual machine, storage array, application, database, identity system or help desk. Many service failures therefore leave the BGP layer unchanged.

Storage failure is an obvious example. The /24 may remain visible while a degraded array causes high latency or data unavailability. A database can fail over incorrectly, leaving an application reachable but unable to commit transactions. A certificate or authentication outage can block users even when packets arrive normally.

Power and cooling faults can also unfold gradually. Equipment may run on backup power while external routes remain stable. Thermal limits can reduce available compute before systems shut down. If monitoring focuses only on reachability, the physical constraint may become visible only after customer impact.

The reverse pattern matters too. A route can disappear because of a configuration or upstream event while servers remain healthy. Recovery then depends on routing control, upstream coordination and DNS or address design rather than on restoring workloads.

A credible continuity design must therefore monitor several layers and correlate them. BGP, facility systems, servers, storage, applications and customer experience answer different questions. AS213868 offers one external signal. It should be combined with, not substituted for, evidence from the rest of the service chain.

Recovery is an operating sequence, not a product label

Recovery plans become useful when they specify ordered actions, responsible people, required access and success criteria. A general promise of continuity does not show how a service moves from failure to stable customer use.

For a routing failure, the sequence might include detecting origin loss, confirming configuration, contacting an upstream, validating RPKI state and testing reachability from independent networks. For a facility failure, it might include power transfer, physical access, workload relocation, storage recovery and customer communication.

Each step can introduce another dependency. Staff need credentials and secure communications. Replacement hardware needs supply and access. Restored workloads need DNS, certificates and network policy. Backup data needs keys and compatible infrastructure. A plan that omits those dependencies can fail despite having the right headline controls.

The accepted evidence does not describe Takecloud's recovery sequence. The website says recovery planning is available and cites RPO/RTO concepts. It does not publish a runbook, test result or incident chronology. The absence of public detail is understandable for security and commercial reasons, but it prevents independent confirmation.

The right public conclusion is not that recovery is weak. It is that recovery performance is unverified. Customers evaluating the service can ask for scoped evidence under appropriate confidentiality: test frequency, sampled workloads, achieved restoration times, independence of copies, escalation ownership and lessons from failed exercises.

Registry accuracy supports operational continuity

RIPE's records perform a coordination function. Unique AS numbers and address ranges allow operators to identify resources, contact responsible parties and compare intended authorization with observed routing. That ledger role is valuable precisely because it is separate from commercial claims.

AS213868 currently shows a coherent public control surface. The ASN, organisation, /24 origin and RPKI authorization align. That coherence reduces one class of ambiguity. An external observer can identify the holder and the expected origin without inferring it from a brand name.

Registry accuracy still requires maintenance. Addresses, contacts, routing policies and authorizations can become stale as operations change. A correct record at assignment time is not guaranteed to remain correct. The public snapshot should be treated as a dated baseline.

Running-code primacy provides the corresponding operational test. When the question is what route exists now, the current BGP observation matters more than a static intention. When the question is who is accountable for the resource, the registry matters. When the question is which origin is authorised, RPKI matters.

Combining the three layers creates a reality-based view without turning any one system into a sovereign description of the network. The ledger records responsibility, the route shows observed operation, and authorization metadata expresses origin policy. None reveals the complete physical or service architecture.

What a route change would mean

AS213868 is a useful monitoring object because its current state is small and specific. A new prefix, an IPv6 announcement, a different origin, a visibility change or a new observed neighbour would be easy to identify against the frozen baseline.

A change would not explain itself. A second prefix could represent growth, migration, customer use or route engineering. An IPv6 origin could mark product deployment or internal infrastructure. A different origin could be planned, accidental or temporary. Evidence of the change comes before interpretation.

Authorization should be checked at the same time. If the BGP origin changes while the ROA remains fixed, networks that validate routes may treat the new state differently. If the ROA changes first, it may signal preparation for an origin transition. Timing can narrow the operational sequence without establishing motive.

First-party disclosures can add context if they identify a migration, new site or service. Those statements should still be compared with running observations. Announced, installed, energised, commissioned and customer-usable states are distinct. A press release or web-page update cannot move an infrastructure asset through those stages by itself.

The baseline therefore supports disciplined updates. Each later record should capture the exact prefix, origin, authorization, observation time and accountable entity. That sequence can show change without converting it into an unsupported story about capacity, customers or resilience.

Evidence that would strengthen the physical picture

The largest evidence gap lies between the public route and the physical service platform. Several records could narrow it without requiring disclosure of sensitive customer data or security details.

A facility statement could identify the operator, location boundary and Takecloud's control scope. It could distinguish owned property from colocation or managed space. Power evidence could describe feed topology, backup runtime, maintenance responsibility and recent load testing without publishing exploitable diagrams.

Carrier and interconnection evidence could name independent providers and confirm physical path separation at a useful level. A logical BGP relationship alone would not be enough; the evidence should address shared ducts, building entrances, meet-me rooms and power domains.

Backup evidence could report the date, scope and outcome of restoration tests. It could distinguish immutable retention from recoverability, identify whether copies are separated from production control, and show achieved RPO/RTO results for representative workloads.

Availability evidence could define the measured service, observation point, exclusions and reporting period. A customer-facing figure becomes more meaningful when the failure definition and calculation are explicit. Incident and recovery summaries could further show how the design behaves under stress.

None of these records is required to establish that Takecloud exists or that AS213868 is routing one /24. They are required to support stronger claims about physical control, capacity, independence and resilience. Until they appear, the public network perimeter should remain the measured fact and the deeper service chain should remain an open verification surface.

A compact route can carry a large dependency question

The public facts around AS213868 are not dramatic. One company is directly tied to one ASN. One IPv4 /24 is visible. The origin and route authorization agree. No IPv6 origin is visible in the captured view. That clarity is valuable because it removes ambiguity at the network-resource layer.

The unresolved questions begin immediately behind that perimeter. Takecloud describes French hosting, managed infrastructure, backup, recovery planning and availability. Delivering those outcomes requires facilities, electricity, carriers, hardware, storage, software, credentials, staff and customer coordination. The accepted sources do not map those dependencies or prove their independence.

That gap should not be filled with suspicion or promotion. A narrow route is neither evidence of weakness nor proof of resilience. A company website is neither a fabrication nor an independent operational audit. Each source answers a limited question.

The practical standard is to follow the failure path. If the /24 disappears, who restores routing? If the facility loses power, how long can systems remain usable? If storage is compromised, which copy can be restored and within what time? If a carrier fails, is the alternative physically independent? If the service remains reachable but an application fails, who owns the recovery sequence?

AS213868 gives those questions an exact company and a reproducible public boundary. The next level of confidence depends on evidence from the private physical and operational chain. Until then, Takecloud's public route can be described with precision, while its uptime, capacity and recovery claims remain attributable promises awaiting deeper verification.

Capacity needs a stage as well as a number

Capacity claims are meaningful only when the relevant stage is named. A provider can design a hosting platform, order equipment, install racks, energise systems, commission services and release capacity to customers at different times. Those stages are not interchangeable, and the public routing record does not identify any of them.

The one routed /24 is especially easy to misuse as a scale signal. It contains 256 IPv4 addresses, but address count does not equal server count, virtual-machine count, storage volume, customer count or usable network throughput. Address sharing, private addressing, virtualization and load balancing can produce very different service scales behind the same public prefix.

First-party references to flexible infrastructure and interconnection options also do not specify installed or sold capacity. A platform can support a capability in principle while current customer capacity is constrained by power, hardware inventory, software licences, storage performance or support staffing. An available product page does not establish that every requested configuration can be delivered immediately.

Physical evidence should therefore separate designed, installed, powered, commissioned, sold and usable capacity. A rack that is installed but not powered is not usable. A server that is powered but not connected to storage or transit is not a complete service. Capacity reserved under contract may be unavailable to a new customer even when the equipment is running.

None of those distinctions weakens the verified network finding. AS213868 and 45.130.47.0/24 remain a current, attributable public route. They simply cannot answer the separate question of how much hosting service Takecloud can deliver under normal conditions or after a component failure. Any future capacity statement should identify its unit, stage, date, location and controlling dependency before it is compared with demand.

Sources