Cogent South Africa, AS174 and the Evidence Gap Between a Subsidiary and a Global Network

Summary

A current corporate filing confirms Cogent South Africa (Pty) Ltd as a South African subsidiary, while ARIN, PeeringDB and route observers describe AS174 at a wider Cogent group or network level. None of the reviewed sources proves that the South African subsidiary owns or operates every AS174 resource.
Public routing evidence can show that prefixes were observed behind AS174 at a stated time, but it cannot by itself prove customer reachability, path diversity, repair performance or a service-level result. Those outcomes need endpoint-specific records and tests.

The distinction sounds technical, but it answers an ordinary business question: when a company, regulator, customer or journalist sees a network name in a directory, what has actually been verified?

In this case, one layer is clear. Cogent Communications Holdings' subsidiary exhibit, effective February 1, 2026, lists COGENT SOUTH AFRICA (PTY) LTD in South Africa. That is strong primary evidence that the exact legal entity exists within the corporate group at the stated date. It does not assign all Cogent routing resources to that subsidiary.

A second layer is the public Internet's numbering and interconnection record. ARIN's RDAP service returns autonomous system number 174 under the name COGENT-174 and identifies Cogent Communications, LLC as registrant. PeeringDB presents AS174 under Cogent Communications, Inc. Other public observers display AS174 routes and relationships. Those records make a live network identity visible, but they use their own labels and scopes. They are not a legal ownership chain from every route back to the South African subsidiary.

A third layer is historical directory provenance. The BTW directory entry was imported from an AFRINIC member-directory source. The old source address now returns 404, and an exact match for the legal name was not found in the current public AFRINIC list checked for this article. The honest conclusion is narrow: the earlier directory material explains where the BTW record came from. It is not current proof that Cogent South Africa is an AFRINIC member.

The value of these records comes from combining them without collapsing them. The company filing answers, “Does this subsidiary exist in this corporate group?” The registry answers, “How is this routing number recorded?” Route collectors answer, “What did selected observers see at this time?” Operator documents answer, “What controls and processes does the network operator say are available?” A customer continuity review asks a further question: “Did the exact service work through the failure that mattered?”

Directory entry: Cogent South Africa (Pty) Ltd

Three records that look similar from a distance

Imagine a South African business reviewing its Internet supplier chain. The finance team sees a subsidiary name in a company directory. The network team sees AS174 in a routing path. The procurement team sees Cogent product information. A manager could understandably place all three under one mental label: Cogent.

That shortcut is useful for finding documents, but dangerous for assigning responsibility. A corporate group can contain many legal entities. A routing registry can name a particular registrant. A network brand can span more than one company, market or contract. An interconnection directory can be maintained by participants for an operational purpose. A route collector can record an announcement without knowing which subsidiary approved a change or which customer bought the service beneath it.

The SEC subsidiary exhibit is the cleanest exact-entity source in this packet. It identifies Cogent South Africa (Pty) Ltd and places it in South Africa. The record is current as of its stated effective date. It does not mention AS174 beside the subsidiary name. It does not list which IP addresses, routers, customers or contracts the subsidiary controls. Those omissions matter because a writer should not fill them with assumption.

ARIN's RDAP record answers a different question. RDAP, or Registration Data Access Protocol, is a standard way to retrieve machine-readable registration data for Internet number resources. The record says that AS174 is active, calls it COGENT-174 and names Cogent Communications, LLC as registrant. That gives the public an accountable registration point. It does not make RDAP a live map of the network or a final legal ruling about every asset that uses the number.

PeeringDB provides another operational view. Its AS174 page names Cogent Communications, Inc. and exposes information intended to help networks understand interconnection. The page also lists facilities, including a Johannesburg location in South Africa, at the time captured for this article. That can be useful evidence that the AS-level network presents a South African interconnection surface. It still does not prove that Cogent South Africa (Pty) Ltd owns that facility, operates every device there or is the contracting party for a particular connection.

PeeringDB is an operator-facing directory, not a land register, asset inventory or audited service report.

The records are not contradictory merely because their organisation labels differ. They were built for different jobs. The correct response is to preserve those labels and describe the relationship only as far as the sources support it.

What the old AFRINIC trail can and cannot establish

The historical AFRINIC trail deserves special care because a directory often looks more authoritative than it is. A regional Internet registry performs important administrative functions around Internet number resources in its service region. Its records can help users find an organisation, contact or allocation history. But a directory entry is still a record with a purpose, date, maintenance process and error boundary.

The BTW company row records an AFRINIC member-directory provenance. In plain language, that means an earlier public AFRINIC source was used to create or support the directory entry. The source is valuable because it explains the entry's lineage. It lets an editor ask what the record originally meant and whether the source still exists.

The old URL now returns 404. A 404 does not prove that the company disappeared, stopped operating or lost any right. Websites move. Page structures change. Lists are replaced. Equally, the old record should not be treated as current merely because it once existed. The current AFRINIC list checked for this article did not yield the exact legal name. That does not prove non-membership; it means the reviewed public material does not presently prove membership.

This is a small but important reporting discipline. “An imported directory record has AFRINIC provenance” is supported. “Cogent South Africa is currently an AFRINIC member” is not supported by the checked current list. “The subsidiary owns AS174 because both appear within an African network context” would be a larger and unsupported leap.

The ledger should therefore be treated as a traceable starting point, not as sovereign truth. A good ledger records names, identifiers, dates and changes accurately. It does not replace the running network, corporate law, contracts or incident evidence. When the public source behind an entry drifts, the useful action is to preserve provenance, state the gap and look for a current primary record. The SEC filing supplies current entity confirmation here, but it does not retroactively turn the historic AFRINIC row into a current membership certificate.

A plain-language guide to AS174 and BGP

An autonomous system number, or ASN, is a public identifier used by a network that exchanges routing information with other networks. AS174 is one such number. It is not an IP address, a server, a company registration number or a guarantee of performance. It labels a routing domain in the part of the Internet where networks tell one another which destinations they can reach.

BGP, the Border Gateway Protocol, carries those announcements between networks. A simplified announcement says, “Traffic for this block of IP addresses can reach it through my autonomous system.” Other networks combine those announcements with policy and select paths. The result is the changing web of routes that lets a user in one network reach a service in another.

Public routing observers collect some of these announcements. RIPEstat's announced-prefixes endpoint returned thousands of prefix records associated with AS174 in the captured window ending August 6, 2026. The exact result is a dated observation from that service, not a permanent inventory. The same address block can appear differently across methods and times, and a collector sees only what reaches its observation points.

Several limits follow.

First, a visible route does not prove that every user can reach the destination. A route may be visible at one observer while a customer suffers a local access failure, congestion, filtering problem, domain-name problem, application outage or power interruption.

Second, an observed origin does not settle corporate ownership. A route can show AS174 at the end of a path, but the collector does not inspect the corporate approvals, subsidiary responsibilities or commercial contract behind it.

Third, a large count is not a quality score. A network can originate or carry many routes and still have a problem on one customer path. A smaller network can provide a strong service where design and operations are appropriate. Numbers need definitions, timestamps and comparison methods before they can support a trend.

Fourth, a public AS-level view does not reveal every physical dependency. Two logical routes can share one fibre trench, building entrance, power supply or upstream facility. BGP can change a path after a failure, but it cannot make shared physical risk disappear.

These limits do not make route data weak. They make it precise. It is strong evidence for the question it actually answers: what selected collectors observed about inter-network routing at a specified time.

Independent observers and the danger of rankings

The public record uses several AS-level observers because no single service has a complete view. CAIDA's AS Rank page, Cloudflare Radar and Hurricane Electric's BGP Toolkit each present information about AS174. Their methods, update schedules and definitions differ.

CAIDA's captured page associates AS174 with Cogent Communications, LLC and presents topology estimates derived from observed paths. It showed AS174 as a highly connected transit network in its dataset. The word “observed” is essential. A customer-cone estimate or neighbour count is a model based on routing evidence, not a complete list of contracts, companies, cables or end users.

Cloudflare Radar's routing view is another observer. Its public page can help readers compare route visibility, prefixes and route-origin security information. Like every observer, its view is bounded by its own data sources, dates and methods. The bgp.tools address led to a login page rather than substantive AS174 content and supports no factual claim here. An unavailable or redirected page says nothing about the network.

Hurricane Electric's BGP Toolkit offers a further public view of AS174, including routing, peer and registry surfaces. Its data can corroborate that AS174 is actively visible. It does not convert every displayed relationship into a verified commercial agreement or assign it to Cogent South Africa.

Using several observers improves confidence when they agree on a narrow fact, such as the existence of a visible AS-level routing identity. It does not make their combined view omniscient. They may draw on overlapping route collectors. They may define peers, customers or prefixes differently. A ranked position can change with data and method. Reporting should therefore attribute each number to its source and date, rather than blending figures into a universal score.

For a non-specialist reader, the practical rule is simple: observer data is like several windows onto a busy railway junction. Seeing trains through several windows confirms activity. It does not show every track, ownership document, maintenance plan or passenger experience.

RPKI and route-origin evidence without false certainty

Some public routing pages also discuss RPKI, the Resource Public Key Infrastructure. RPKI helps network operators check whether an autonomous system is authorised to originate a particular IP prefix. The signed object commonly used for that purpose is a Route Origin Authorisation, or ROA.

A ROA can say that a named ASN is allowed to originate a particular prefix, sometimes down to a stated maximum prefix length. A validating network can compare a BGP announcement with that information. If the origin matches the authorisation and the prefix length is allowed, the route can be classified as valid for origin validation. If it conflicts, it can be invalid. If no covering authorisation exists, it can be not found.

That is a useful security control, but its scope is often misunderstood. Origin validation checks the relationship between a prefix and the ASN originating it. It does not verify every autonomous system in the path. It does not show that the route is free from congestion. It does not confirm that physical fibre is intact, that a router is correctly configured or that an application responds. It does not establish which subsidiary owns the equipment or the address block.

For AS174, public observers expose RPKI-related information at an AS-level scope. Any percentage or count can change with announcements, authorisations and the observer's method. This article therefore avoids turning a snapshot into a permanent assessment. A customer or operator reviewing a critical service should examine the exact prefixes in scope, the current ROAs, the maximum lengths, the intended origins and the filtering behaviour of relevant networks.

The operational continuity question is not “Does the AS have RPKI?” It is “Are the authorisations for our routes current, precise and safely maintained, and what happens during a planned or emergency change?” That requires owners, change records, monitoring and rollback steps.

What Cogent's own documents add

Cogent's network page and customer guide add an issuer perspective. The public network page describes Cogent's facilities-based optical and IP network and makes statements about markets, customer connections and design. Those descriptions show how the operator presents its network. They should be attributed to Cogent, not treated as independent measurements of every service.

The customer guide is more useful for understanding operational control surfaces. It discusses how customers interact with support, monitoring and routing functions. It includes BGP-related material and regional community handling that covers Africa. A BGP community is a label attached to a route so that networks can apply agreed policies, such as controlling how or where an announcement is propagated. Published controls can help customers and engineers plan changes.

The existence of a guide does not prove that a control was used correctly in a specific incident. It shows that an operating interface and documented process exist. The difference resembles an emergency manual in a building: the manual matters, but continuity depends on whether it is current, whether people know their roles, whether the equipment works and whether exercises reveal hidden dependencies.

Operator statements about footprint or performance also need a boundary. They can inform a buyer about available services and questions worth asking. They cannot establish the actual topology of a purchased path, the independence of two access circuits or the business impact of an outage. Only the service design, order records, as-built evidence, measurements and tests can do that.

Why the subsidiary boundary matters during an incident

Corporate precision may sound like paperwork until something fails. During an incident, teams need to know which company signed the contract, which network operations centre can change routing, which registry contact can update number-resource records, which local entity can coordinate access, and which executive owns the recovery decision.

If every Cogent-related label is treated as interchangeable, escalation can go to the wrong place. A customer may ask a local subsidiary to perform a change controlled by a group network team. A registry contact may have authority over a number record but not over a physical circuit. A facility contact may restore power while a route policy remains wrong. A legal entity may appear in a current filing but not be the party named in the customer's service order.

The solution is not to insist that one organisation own every step. Large networks necessarily distribute responsibility. The solution is to record the chain.

A useful responsibility map has at least five rows:

Contracting identity. Which exact legal entity supplies or resells the service, and what does the contract require?
Number-resource identity. Which registry record covers the ASN and relevant prefixes, and who may update it?
Routing authority. Which team may originate, filter, prepend, withdraw or redirect the routes?
Physical and facility responsibility. Who controls each access path, building entrance, optical segment, power source and repair relationship?
Customer operations. Who monitors the service, declares impact, authorises failover and validates recovery from the user's side?

Cogent South Africa's appearance in a current group subsidiary list helps with the first part of corporate discovery. AS174 records help with number-resource and routing discovery at the group-network layer. Neither source fills all five rows.

A practical evidence stack for buyers and operators

The strongest continuity assessment builds from several layers, each with a narrow purpose.

Layer 1: legal and directory identity

Collect the service order, invoice entity, company registration details, relevant licences and current corporate records. Compare them with the directory entry. Record name differences instead of silently normalising them. If an old source disappears, preserve its date and provenance while seeking a current primary record.

For this case, the current corporate exhibit supports the exact South African subsidiary. The old AFRINIC trail supports historical directory provenance only. The two records should sit next to each other, not substitute for one another.

Layer 2: number-resource registration

Record the ASN, relevant IP prefixes, registry status and operational contacts. Check RDAP rather than relying on a copied screenshot. Ask which organisation has authority to update the record and how emergency contact changes are approved.

AS174's ARIN record supplies a current registration view. It is a ledger entry, not a live health monitor.

Layer 3: observed routing

Use more than one route observer. Record query time, data source and the exact prefix or ASN. Compare outside observations with the customer's own BGP session, probes and application telemetry. A route seen publicly but not usable by the customer is still a customer problem. A route absent from one collector but working elsewhere may be a visibility or policy difference rather than an outage.

Layer 4: route-origin authorisation and policy

Check the current ROAs and route-filtering records for the exact prefixes. Validate maximum lengths before a more-specific announcement is needed. Review BGP community meanings and change processes. Test planned changes through a safe, authorised procedure.

Layer 5: physical and service design

Obtain as-built path evidence for critical circuits. Ask whether links use separate entrances, ducts, optical systems, routers, sites, power and upstream dependencies. Define where the service-level measurement begins and ends. A global AS number cannot answer these local questions.

Layer 6: operations and recovery

Document maintenance notice, escalation, ticket, restoration and post-incident processes. Identify the people who can act at each layer. Run exercises. Preserve time-stamped evidence so that later analysis can distinguish a routing change from a physical break, a customer configuration error or an application failure.

Each layer prevents another from carrying too much meaning. A legal filing does not have to prove routing. A route collector does not have to prove ownership. A service test does not have to rewrite a registry. Together they create an accountable picture.

Twelve questions for a non-specialist decision maker

A buyer does not need to become a BGP engineer to ask good questions. The following checklist turns the evidence into an understandable review.

Who is the supplier? Write the exact legal name from the contract and compare it with the directory and corporate records.
What does AS174 identify? Confirm that it is a routing identifier associated with the wider Cogent network, not a certificate that every service belongs to the South African subsidiary.
Which prefixes matter to us? List the customer's and provider's address blocks that the service actually depends on.
Where is the service measured? Define the endpoints, application checks and time source used to determine availability.
What is genuinely diverse? Request evidence for separate entrances, fibre paths, equipment, power and upstream dependencies.
What happens if BGP fails? Understand session timers, route policies, backup paths and the expected effect on active connections.
Are route origins authorised? Check current ROAs and the procedure for emergency or planned changes.
Who can make a routing change? Record named roles, approval boundaries and out-of-hours contacts.
How are incidents escalated? Test the support path and know whether local, group-network, facility or third-party teams must act.
What does the SLA exclude? Read the measurement method, maintenance exclusions, remedies and reporting deadlines.
How will recovery be proven? Require customer-side and provider-side evidence, not only a ticket marked resolved.
When is the next revalidation? Assign dates for checking contracts, contacts, routes, ROAs, diagrams and exercises again.

These questions also reveal why one directory record cannot carry the whole decision. A record can identify a party. It cannot design a customer's resilience or run the recovery exercise.

A 30-day continuity validation plan

Organisations that depend on a Cogent-related service can turn the checklist into a short programme without disrupting production.

Days 1-5: establish identity and scope

Collect the contract, service IDs, circuit endpoints, legal entity names, ASNs and prefixes. Mark every source with a date. Confirm which information comes from Cogent South Africa, which comes from another Cogent group entity, and which comes from a public registry or observer. List unresolved label differences as questions rather than guessing.

Days 6-10: build the dependency map

Diagram the service from the customer location through access links, facilities, provider handoffs, routing sessions, DNS and applications. Mark shared conduits, buildings, power and equipment where known. Ask suppliers to confirm or correct the diagram without demanding disclosure of unrelated network details.

Days 11-15: establish a measured baseline

Capture the intended BGP announcements, external route observations, ROA state, customer probes, latency and loss measurements, and application availability. Use the same method at repeated times. The purpose is not to score the whole AS174 network; it is to recognise a meaningful change for the exact service.

Days 16-20: review change and recovery controls

Walk through who can change a route, update a ROA, open a facility ticket, switch a customer path or declare an incident. Review BGP community documentation and maintenance procedures relevant to the service. Confirm that the contact details used outside office hours are current.

Days 21-25: exercise safe failure cases

With written approval, test a limited failover or use a tabletop exercise where production testing is unsafe. Include a route withdrawal, access-circuit loss, device failure, contact failure and misleading observer signal. Record expected and actual decisions. Never perform an Internet routing experiment without the responsible operators' authorisation.

Days 26-30: close gaps and set ownership

Assign each finding to an owner, deadline and evidence requirement. Update the identity map, technical diagram, monitoring rules and escalation plan. Record accepted residual risks. Schedule the next exercise and set a trigger for early review when a contract, company name, ASN contact, ROA, path or facility changes.

At the end of the month, the organisation should have more than a confidence statement. It should have a reproducible evidence set showing what was checked, what remains uncertain and who must act.

What the editorial image does not show

The image accompanying this article is a synthetic editorial reconstruction. It shows a fictional analyst comparing separate kinds of evidence beside an unbranded fibre cord. It does not depict Cogent or AFRINIC staff, an office, a network facility, a customer, a route map or a live AS174 screen.

That boundary mirrors the article. A realistic scene can help a reader understand the act of verification, but it cannot become visual proof. The papers in the image do not establish current AFRINIC membership. The fibre cord does not show an actual Cogent path. The person does not represent a real employee. The image makes the evidence layers visible without inventing access to proprietary operations.

What to watch next

Three kinds of change would justify updating this analysis.

The first is an exact current public record from AFRINIC for Cogent South Africa (Pty) Ltd. Such a record could close or clarify the directory-provenance gap. Its wording, date and scope would still need to be reported precisely.

The second is a material change in corporate identity. A future subsidiary exhibit, restructuring document or contract could change the relationship between the South African entity and other Cogent companies. The current February 2026 filing is evidence for its stated date, not a permanent guarantee.

The third is a change in the operating layer: AS174 registration, route observations, RPKI status, interconnection data or published customer controls. Any change should be checked with the same source and method before it is described as a trend. Customer impact should be measured separately.

The most useful monitoring record is a timeline. Place corporate filings, directory updates, RDAP changes, route observations, ROA changes, maintenance notices, customer measurements and incidents beside one another. The timeline helps investigators see whether several layers changed together or whether one record merely drifted while the service remained stable.

Conclusion

Public evidence supports a careful conclusion. Cogent South Africa (Pty) Ltd appears as a South African subsidiary in Cogent Communications Holdings' current subsidiary exhibit. The BTW directory row has historical AFRINIC member-directory provenance, but the old source now returns 404 and the exact legal name was not found in the current public list checked for this article. ARIN, PeeringDB and independent routing observers describe AS174 at the wider Cogent network level.

Those facts belong together, but they are not interchangeable. The corporate filing proves an entity relationship at a stated date. The registry supplies an accountable number-resource record. The observers show portions of the running route system. Cogent's own documents describe network and customer controls. None proves that the South African subsidiary owns every AS174 resource, that a route is reachable from everywhere, or that a customer's service will survive a failure.

For a non-specialist, the practical lesson is straightforward: ask each record only the question it was designed to answer. Keep names attached to their sources. Keep route figures attached to methods and times. Keep security authorisation separate from physical continuity. Then test the exact service, preserve the evidence and assign every operational dependency to an owner.

That approach respects the value of registries without turning them into sovereign truth. It gives running network evidence priority where operational reality is at issue, while acknowledging that public observers remain partial. Most importantly, it converts an ambiguous brand-and-ASN story into an accountable continuity review that a buyer, operator or manager can actually use.