Summary

  • AFRINIC records AS37599 as an active autonomous-system object whose registrant is Teraco Data Environments (PTY) LTD. That is authoritative number-resource identity, not proof of a currently visible route, live exchange session or healthy customer service.
  • PeeringDB lists one network record and six declared exchange connections for the ASN, while NAPAfrica lists Teraco Data Environments at JB1, CT1 and DB1. The entries clarify public interconnection context but do not prove traffic, usable capacity, physical diversity or a customer's path.

Start with the object that the registry actually controls

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, is the identifier used when networks exchange reachability information through the Border Gateway Protocol, usually shortened to BGP.

The AFRINIC RDAP object covers exactly autonomous-system number 37599. It uses the handle AS37599, carries the object name ORG-TDEL1-AFRINIC, and identifies Teraco Data Environments (PTY) LTD as the registrant. The administrative status is active. The record shows a registration event on 17 May 2013 and a last-changed event on 5 August 2026.

Those fields answer a narrow but important question: which organisation does the regional internet registry currently associate with this number resource? A unique object, a traceable registrant and maintained contact boundaries make routing and abuse coordination less ambiguous. They help an engineer avoid treating a similar company name, a data-centre product or an exchange brand as the routing identity itself.

The word active belongs to the registry object. It is not a green status light for routers, exchange ports, data halls or customer applications. RDAP does not test whether AS37599 is announcing a prefix at this moment, whether another network accepts that route, or whether a service can be reached. The last-changed date records maintenance of the administrative object; it does not summarise every operational change to equipment, policy or dependencies.

This boundary does not diminish the registry. A ledger is useful precisely because it keeps the identity stable and reviewable. It becomes misleading only when readers ask it to certify a running system that it does not observe.

PeeringDB adds a declared network profile

PeeringDB's network response contains one row for ASN 37599. The row names Teraco Data Environments, also uses the label NAPAfrica, points to Teraco's official website, classifies the entry as Network Services and declares an open general peering policy. It also names the IRR set AS-TERACO.

The same row reports 500 IPv4 prefixes and 100 IPv6 prefixes. These are participant-maintained fields in a public directory. They are not a route-collector result. The numbers do not tell a reader which prefixes are currently originated, where they are visible, whether route policy accepts them or how a specific service reaches a customer. A directory count and an observed route set may differ in purpose, scope and update time without either becoming a universal verdict on the network.

For an operator, the record is still a useful checklist. It provides an ASN, an expected name, a policy description and a published routing-set identifier that can be compared with current design information. A mismatch should trigger a bounded investigation. A match should not close that investigation before the live routing layer is checked.

Six connection rows are six declarations, not six proven paths

PeeringDB's separate exchange-connection response contains six rows for AS37599. The names cover NAPAfrica IX entries in Johannesburg, Cape Town and Durban, including two separate Durban rows, plus MAPS entries in Johannesburg and Cape Town. Every row carries an operational directory flag and a route-server-peer flag.

Two of the rows declare 100,000 Mbps and four declare 10,000 Mbps. The response also supplies exchange addresses. These details can help a network team ask exact questions: Is the ASN expected at this exchange? Does the listed address still belong to the intended session? Is the route-server relationship part of the present design? Which row should be relevant to a particular service or incident?

They cannot answer those questions on their own. Operational is a field maintained in the directory, not continuous session telemetry. A listed speed does not show present traffic, free headroom, contracted capacity or performance during a failure. An address at an exchange does not reveal the complete customer path.

The row count is also a poor shortcut for resilience. Six logical entries do not prove six independent physical routes. They do not establish separation of fibre, power, buildings, upstream networks, control systems or operational teams. Two rows can share a risk; one well-designed path can include protections not visible in the directory. Physical diversity requires evidence about the actual dependencies and the failure being considered.

NAPAfrica confirms participant entries, not live sessions

NAPAfrica's own participant page lists Teraco Data Environments with ASN 37599 in rows for JB1, CT1 and DB1. That independent directory view supports a bounded statement: the exchange publishes Teraco Data Environments and this ASN at those three location codes.

It does not prove that every associated BGP session is currently established or that a named customer's packets cross any one of the sites. Nor does the shared Teraco and NAPAfrica context mean AS37599 represents every route server, exchange component or participant service. An exchange directory describes participation and coordination points; it does not collapse all technical objects into one ASN.

This distinction is particularly important during an incident. An entry can remain on a participant page while a session is being changed or a service is impaired. Conversely, the absence of live measurements from the public page is not evidence that a session is down. The page gives an identity and a declared place to investigate, not the outcome of the investigation.

Teraco's website describes the service setting

Teraco presents itself as a Digital Realty company and describes colocation, interconnection and cloud-exchange services. Its site places the data-centre context in Johannesburg, Cape Town and Durban. The domain aligns with the website field in PeeringDB and with Teraco contact domains in the AFRINIC object, creating a narrow bridge between the registry, directory and operator identity.

The service presentation does not prove that AS37599 carries every Teraco product. A data-centre operator can use multiple network resources, platforms, partners and delivery paths. A colocation page does not identify a tenant's prefix, a cloud connection's route or the physical dependencies behind a service.

First-party descriptions are useful for understanding what the company says it offers. They are not independent measurements of uptime, security effectiveness, capacity or continuity. Those outcomes need a defined service, a date, a test method and a result.

What operators, customers and incident teams can verify next

A network operator can begin with identity. Confirm that AS37599 is still the intended routing domain, that the expected policy and routing set remain current, and that the six public connection entries correspond to the design under review. Then move to running evidence: BGP session state, accepted and advertised routes, route-collector observations from named vantage points, and interface measurements for a defined period.

A customer can ask which ASN and delivery path serve the contracted product. If the service depends on a particular exchange, cloud connection or facility, the provider should be able to define the dependency without exposing another customer's sensitive configuration. The customer can also ask which elements share fibre, power, building access, upstream networks or management systems, and what dated test supports a continuity claim.

An incident responder should preserve the layers in the timeline. The AFRINIC record establishes the public resource identity. PeeringDB and NAPAfrica show declared coordination points. Current telemetry shows whether sessions and routes are operating. End-to-end tests show whether DNS, access, applications and external dependencies deliver the affected service.

The order prevents premature attribution. A visible route does not prove an application works. An established session does not prove adequate capacity. Traffic on one interface does not identify every customer path. A failed service test does not make the registry record inaccurate. Each observation should retain its timestamp, vantage point and scope.

What to watch

  • changes to the AS37599 registrant, administrative status, contacts or event history in AFRINIC;
  • changes to the PeeringDB network name, policy, prefix-count fields or IRR set;
  • additions, removals or material field changes among the six declared exchange connections;
  • changes to the exact JB1, CT1 and DB1 participant rows in NAPAfrica;
  • changes to Teraco's domain or public description of colocation and interconnection services;
  • authoritative, time-stamped routing, session, interface or service evidence that answers a current operational question.

Every change should remain attached to its evidence layer. A registry update, participant declaration, route observation and service test can all be accurate while describing different moments and objects. The defensible conclusion from the public record is therefore limited but useful: AFRINIC associates Teraco Data Environments (PTY) LTD with AS37599, and PeeringDB and NAPAfrica publish a declared interconnection surface. Current routing, traffic, physical diversity and customer outcomes are not proved by those records alone.

Sources