Summary

  • AFRINIC records AS328032 as an active autonomous-system object registered to Routed Hosting (PTY) LTD, while PeeringDB and NAPAfrica list declared public interconnection for the ASN. These records establish identity and exchange context; they are not tests of a cloud workload or a disaster-recovery plan.
  • Routed publicly describes backup and recovery services using Johannesburg and Cape Town availability zones. A customer evaluating continuity still needs dated evidence for replication, recovery objectives, dependency separation, test results, failover capacity and failback.

Start with the object each record actually describes

Public infrastructure records become most useful when each one is asked a precise question.

The BTW directory entry for Routed Hosting identifies the company object. It gives a stable way to distinguish the provider from a product, a routing number or a similarly named organization. That sounds elementary, but it prevents a common failure at the beginning of technical due diligence: treating a resource label as if it were the company itself, or attaching evidence to the wrong directory entry.

The AFRINIC RDAP record for AS328032 describes a number resource. An autonomous system is a network or group of networks that presents a common routing policy to the wider internet. Its autonomous system number, or ASN, gives other networks a unique identifier to use when exchanging route information through the Border Gateway Protocol, usually shortened to BGP.

AFRINIC's record identifies the object as AS328032, marks the registry object active and names Routed Hosting (PTY) LTD as its registrant. It records a registration event in June 2016 and a last-changed event in January 2023. Those fields answer a valuable identity question: which organization does the registry associate with this routing number?

They do not answer a service-health question. An active RDAP object is not a green light on every router, storage array or replication job. It does not say that every prefix is visible from every observation point. It does not report packet loss, spare capacity, backup age or recovery-test results. The registry is doing its job when it provides an accurate, unique and traceable record. It should not be treated as a monitoring system for equipment or applications it does not operate.

Exchange listings add context, not a customer path

Interconnection directories provide a second layer. PeeringDB's network record associates Routed Hosting with AS328032 and the AS-ROUTEDHOSTING routing set. It describes an open general peering policy and support for IPv4 and IPv6. PeeringDB's separate public exchange-connection records place the ASN at CINX, JINX and NAPAfrica locations in Cape Town and Johannesburg.

NAPAfrica's participant directory supplies an exchange-operator view. It lists Routed Hosting and AS328032 at its Johannesburg and Cape Town exchanges, with route-server participation and both internet protocol families. An internet exchange is a shared interconnection environment where participating networks can exchange traffic. A route server helps participants exchange routing information without requiring a separate bilateral BGP session with every other participant.

These listings make the public interconnection surface more legible. They tell an engineer where an exchange relationship is declared and which ASN should be used in a routing conversation. They can help a buyer ask better questions about local traffic exchange, upstream design and route policy.

They still do not reveal the path of a named workload. A PeeringDB entry marked operational is a directory status, not continuous packet measurement. A listed 10-gigabit port value describes a declared exchange connection; it does not reveal the traffic load at the moment a customer needs to fail over. Two addresses at two exchange locations do not prove that all underlying fibre, power, building access, management systems and upstream providers are independent. Logical diversity and physical diversity are related questions, but they are not the same question.

This distinction matters during an incident. A customer may see AS328032 in a route and correctly identify Routed Hosting as the network in the path. That observation alone cannot determine whether an application problem began at the customer's premises, inside a cloud platform, at a name-service dependency, on an upstream route, or in the application itself. The ASN narrows the coordination boundary. It does not diagnose every layer inside it.

Product descriptions explain intent

The Routed website describes enterprise private-cloud services, backup from customer environments to its cloud, and disaster recovery between customer premises and Routed availability zones or between those zones. In a separate explanation of its disaster-recovery service, the company describes ground-to-cloud and cloud-to-cloud topologies involving Johannesburg and Cape Town.

Routed says its service uses VMware Cloud Director Availability and Veeam Cloud Connect Replication. It describes capabilities including replication, recovery plans, reports, test failovers and failback. Failover is the controlled move to a recovery environment when the primary service cannot carry the workload. Failback is the move back after the primary environment is ready again.

A VMware cloud-provider article from 2022 also described Routed's use of Cloud Director, Veeam integration and Cloud Director Availability for backup and disaster recovery as a service. The partner article helps establish the history of the published architecture. Its date matters. It should not be treated as proof of the provider's current software version, present certification or the outcome of a current customer's recovery exercise.

These sources explain service intent and available mechanisms. They are a sensible starting point for a purchasing conversation. They cannot substitute for the customer's own scope and operating evidence. A recovery service can be available while a workload remains outside the replication policy. A replica can exist while authentication, DNS, encryption keys or a database dependency remains unavailable. A test can succeed for one application and say nothing about another.

Recovery is a workload claim

The strongest continuity evidence is attached to a defined workload, a defined failure and a defined time.

Two measures usually frame the discussion. The recovery point objective, or RPO, is the maximum acceptable amount of data loss measured in time. If the RPO is fifteen minutes, the design and operation should make it possible to recover to a state no more than fifteen minutes behind the failure point under the agreed conditions. The recovery time objective, or RTO, is the target time for restoring the service after disruption.

Neither target is established by an ASN. Neither is established by an exchange membership. Even a product page that names replication technology cannot show that a particular customer's current configuration meets either objective.

A buyer should ask for a compact evidence chain:

  1. Protected inventory. Which virtual machines, databases, object stores, identity services, DNS zones, keys and network policies are inside the recovery scope? What is explicitly outside it?
  2. Replication state. When did each protected component last replicate successfully? Which alarms detect lag, failure or a replica that cannot be started?
  3. Recovery objectives. What RPO and RTO apply to this workload, under which failure scenarios, and where are those objectives written into the service agreement?
  4. Dependency separation. Which facilities, power systems, fibre routes, upstream networks, management planes and personnel are shared between the primary and recovery environments?
  5. Recovery capacity. How much compute, storage, network and licence capacity is reserved or obtainable after a fault? Does the recovery design still work when multiple customers invoke it at once?
  6. Test evidence. When was the last end-to-end recovery exercise? Did users reach the application, did data reconcile, did identity and keys work, and how long did each stage take?
  7. Failback evidence. How will changes made during recovery be returned to the primary environment without losing data or creating a second outage?

This evidence need not disclose another customer's confidential information. It can be delivered as a scoped test report, a control summary, an architecture diagram with sensitive details removed, and a contract that names responsibility at each handoff. The key is that it comes from the running service and the customer's configuration, not from a label borrowed from another layer.

A hypothetical failure shows the boundary

Consider a hypothetical retailer whose ordering system runs in a private cloud and is replicated to a second site. This is an example, not a statement about a known Routed customer.

If the primary site becomes unavailable, AS328032 may help an outside network identify which routing domain is involved. Exchange listings may help engineers understand where public interconnection is declared. Those facts could speed coordination if reachability is part of the problem.

The application will recover only if the rest of the chain also works. The replica must be recent and consistent. The recovery site must have capacity. Identity services and encryption keys must be available. DNS or traffic-management changes must direct users to the recovered application. Staff must know who can authorize the move. The database must accept writes without creating two competing versions of the truth. The service must later fail back safely.

If the application returns in forty minutes against a one-hour RTO, that is operating evidence for that test and scope. It is not a permanent conclusion about every future event. If the test fails because a key was missing, the result does not make the ASN inaccurate. It reveals a gap at a different layer.

Read public status words carefully

Infrastructure pages often use the same reassuring vocabulary for different objects. The word active can describe a registry record. Operational can describe a declared exchange connection. Available can describe a product. Resilient can describe a design intention. Recovered should describe an observed outcome for a defined service.

Collapsing these words into one claim makes due diligence shorter but weaker. Keeping them separate produces a more useful account:

  • AFRINIC records the number-resource identity.
  • PeeringDB and NAPAfrica provide declared interconnection context.
  • Routed and VMware describe service architecture and mechanisms.
  • A dated workload test establishes what recovered, under which conditions and within what time.

No layer needs to be dismissed for the distinction to hold. Accurate registry and exchange records are part of operational continuity because they help networks coordinate and reduce identity errors. Product documentation is part of continuity because it sets expectations and explains responsibility. Running-code evidence is decisive because it shows whether those expectations worked for the service being judged.

Questions for a buyer

A useful procurement conversation can begin with the public record and then move deliberately inward.

Ask whether AS328032 is the ASN expected to originate or carry the relevant public service traffic, and whether any other network identity is involved. Ask which exchanges or upstreams matter to the contracted service, without assuming that every public listing is in the customer path. Ask which site receives the recovery copy and which dependencies remain shared with the primary environment.

Then ask for the latest recovery exercise, including the failure injected, the starting state, the measured RPO and RTO, the user validation, the data reconciliation and the failback result. Confirm who owns each action: the provider, a reseller, the customer or a software partner. A capability that exists but has no owner during an incident is not yet an operational plan.

The answers may vary by service tier and contract. Public pages cannot resolve those differences. That is not a defect in the pages; it is a reason to keep the public evidence in its proper role.

What to watch

Several signals could change the assessment:

  • AFRINIC RDAP changes to the AS328032 registrant, status or event history.
  • PeeringDB or exchange-operator changes to the ASN's declared locations, protocol support or route-server participation.
  • Routed updates to its availability-zone, backup, recovery or platform descriptions.
  • Dated customer or independent recovery exercises that disclose a clear scope and measured result.
  • Changes to contracts that clarify recovery objectives, capacity, dependencies and responsibility for failover and failback.

These signals should be recorded with dates. Routing and service configurations change. A useful continuity account distinguishes a durable identity from a current observation and an intended design from a tested result.

Sources

AS328032 is valuable because it gives Routed Hosting's routing domain a unique public identity and a coordination point. The exchange records add declared interconnection context. Routed's pages describe a recovery service and the mechanisms it intends to use. A decision about whether a workload will recover still depends on dated evidence from that workload, its dependencies and a completed exercise. If that evidence is not public, the correct conclusion is that the public record has reached its limit—not that recovery has failed and not that it has been proved.

A monitoring plan that preserves the layers

A professional monitoring plan should keep four clocks instead of merging them into one status.

The first clock follows identity: changes to the AFRINIC object, registrant and maintenance history. The second follows declared interconnection: additions, removals or material updates in PeeringDB and exchange-operator directories. The third follows the service design: product, platform, availability-zone and responsibility changes published by Routed or its technology partners. The fourth follows operating proof: the most recent recovery exercise for the workload being protected.

Each clock should have a trigger. An unexpected registry change calls for identity reconciliation. A removed exchange entry calls for a routing and service-path review, not an automatic outage declaration. A platform change calls for compatibility and recovery-runbook review. An overdue or failed exercise calls for remediation at the workload layer.

The monitoring record should preserve the observation date and the claim type. That makes it possible to distinguish a directory update from a route observation and a provider announcement from a tested recovery result. It also prevents an old partner article from silently becoming evidence of a present configuration.

For procurement teams, the practical trigger is the distance between promise and proof. If the contract names a one-hour RTO but the latest end-to-end exercise is missing, partial or older than the agreed interval, the next action is a scoped test. If the exercise succeeded but the workload or dependency inventory has since changed, the result should not be extended to the new scope without review.

For network teams, an ASN or exchange change should update the escalation map and expected routing observations. For application owners, it should prompt a check that public reachability, DNS and certificate dependencies are represented in the recovery plan. Neither team should assume the other layer has been tested.

The control decision is who owns the recovery claim

Continuity failures often begin as ownership failures. A cloud provider may operate the platform, a reseller may own the commercial relationship, a customer may control application replication, and a separate team may control DNS, identity or encryption keys. Every party can accurately describe its own component while the end-to-end service remains unproved.

Leadership should therefore assign one owner to the complete recovery claim and require that owner to assemble evidence across organizational boundaries. That person needs authority to schedule a test, disclose gaps, reserve capacity and stop a migration when dependencies are not recoverable. Without that authority, a recovery plan can become a collection of compatible-looking documents with no one responsible for the outcome.

The incentives also need attention. Sales material rewards broad claims. Registry and exchange pages reward accurate, reusable records. Operations rewards stable systems and controlled change. A useful governance design does not ask one artifact to satisfy all three incentives. It lets public records establish identity, contracts define responsibility and tests establish performance.

Some choices become costly to reverse. A workload may accumulate proprietary dependencies, an identity system may remain only in the primary site, or a recovery design may depend on capacity that is not reserved. Those risks should be identified before migration, when the customer can still change architecture or contract terms. Waiting until the first incident turns a design choice into an emergency constraint.

The decisive question is therefore not whether AS328032 is real or whether Routed offers disaster recovery. Public evidence supports both bounded statements. The leadership question is whether the exact workload, under an agreed failure scenario, has a named owner and a recent result that demonstrates recovery and safe return. That is the point where records, contracts and running systems become one accountable continuity decision.