Summary

  • An AfNOG mailing-list post at 10:48 UTC on 20 July supplied a one-line check that made duplicate entries in as-TelOneZW visible.
  • A fresh query to AFRINIC reproduced 24 members: lines but only 21 distinct ASNs: AS37183 appears three times and AS37123 twice.
  • Under RPSL set semantics, the repeated lines add no new distinct member. They are evidence of record-level redundancy, not evidence of an outage, route leak or rejected route.
  • AFRINIC says upstream and transit providers query Internet Routing Registries for filter updates, so even harmless redundancy is worth treating as a data-maintenance signal.

The routing-policy set did not gain three networks. It gained three lines.

That distinction is the useful finding in a short message posted to the African Network Operators Group list on Monday. S. Moonesamy ran a compact command against AFRINIC’s WHOIS service, sorted the membership of as-TelOneZW, and put repeated values at the top. AS37183 appeared three times; AS37123 appeared twice.

The message did not diagnose the cause. It explicitly allowed that there was probably a plausible explanation. A fresh BTW check after the post reproduced the current record: 24 member declarations, 21 unique AS numbers. The entity describes itself as “TelOne ASNs”, names AS8668-MAINTAINER as its maintainer and records AFRINIC as its source.

This is not an outage report. It is a narrow, reproducible case of policy data carrying more text than meaning.

Repetition changes the record, not the membership

RFC 2622 defines an as-set as a set whose members attribute lists AS numbers or other AS-set names. On that semantic level, repeating AS37183 does not create three autonomous systems, and repeating AS37123 does not create two. The distinct membership remains 21.

That makes the immediate technical claim modest. No evidence in the AfNOG post or the live record shows that a route was dropped, a prefix was mis-originated, traffic changed path or a generated filter broke. A standards-aware expansion should not acquire a new distinct ASN from a duplicate declaration.

It would still be careless to say every consumer behaves identically. Some tools may normalise a set before generating configuration; others may preserve raw rows in intermediate files, diffs, audits or dashboards. The public evidence establishes redundant input, not the behaviour of every downstream parser.

The two repeated ASNs are also not interchangeable. AFRINIC’s live registration data identifies AS37183 with Utande Internet Services (Pvt) Ltd and AS37123 with Telecontract Pvt Ltd, both in Zimbabwe. Their presence in a TelOne-labelled set does not, by itself, prove ownership, a subsidiary relationship or even the current commercial reason for inclusion. An AS-set expresses routing-policy membership; it is not a corporate family tree.

Why a harmless duplicate still matters

Internet Routing Registry records sit between a network’s declared policy and systems that may turn that declaration into controls. RFC 2622 was designed so operators could describe policy at the AS level in a form detailed enough to contribute to router configuration. AFRINIC’s own guide says upstream and transit providers query routing registries to update route filters and improve the stability and consistency of BGP information.

The duplicate does not prove those filters are wrong. It shows that the data feeding such workflows can drift without changing the mathematical result.

That is precisely why small anomalies are useful. A duplicate is easy to dismiss because it is often idempotent: one member or three copies still denotes the same member. But an unexplained duplicate can indicate that an update process appends instead of reconciling, that two administrative paths touched the same entity, or that no linting step checks the final record. Those are hypotheses, not findings in this case. The list post provides neither change history nor root cause.

The governance question is therefore not “did this duplicate take the Internet down?” It is “what other errors would the same maintenance path fail to catch?” A repeated valid ASN is forgiving. A stale customer ASN, a missing member or an unintended nested set would not necessarily be.

The right response is verification, not alarm

The first repair step should preserve uncertainty. The maintainer can confirm whether all 21 distinct members still belong in the intended routing-policy scope, identify how the three redundant lines entered the entity, and then publish a clean update if appropriate. Simply deleting duplicates without checking the intended set would make the text neater but would not validate the policy.

The second step is to test both representation and expansion. A useful control would compare raw member-line count with unique direct members, expand nested sets where applicable, record changes over time and alert separately on duplicates, missing entities, unexpected additions and expansion failures. RIPE’s database documentation illustrates why recursive member queries deserve their own checks: the final set can be assembled through more than the lines visible in one entity.

Finally, operators consuming IRR data should keep provenance in generated artefacts. A filter build should be traceable to a registry source, query time, expansion method and review state. That does not make the registry infallible; it makes a bad input diagnosable.

The AfNOG message is valuable because it does not need a dramatic incident to justify attention. Three redundant lines left the set with the same 21 distinct members. They also created a cheap test of whether routing-policy maintenance is reconciled, reviewed and observable before a less forgiving error arrives.

Sources