Summary

  • AS210860 has been invisible in the global routing table since 26 March 2026: Hurricane Electric's data reports zero announced prefixes and a single historic origin, 193.21.248.0/21 (EDEKA DIGITAL GmbH), with one observed peer, AS9211 (https://bgp.he.net/AS210860).
  • RIPEstat, checked on 14 September 2026, shows no RIS-visible originations and no transit, and renders the registration status as RESERVED with no holder named (https://stat.ripe.net/resource/AS210860).
  • Mirror copies of the RIPE Database show the aut-num object created on 24 August 2021 and last modified on 27 October 2021, naming the organisation ORG-EDG14-RIPE and the role handle DA9499-RIPE (https://apps.db.ripe.net/db-web-ui/query?searchtext=AS210860).
  • A PeeringDB-derived record still self-declares 10 IPv4 prefixes, 1 IPv6 prefix and an open peering policy — a market surface that no observed routing behaviour supports (https://hostdir.net/networks/as210860-edeka-digital).
  • RIPEstat's announced-prefixes endpoint is a public, reproducible and cost-free verification method (https://stat.ripe.net/docs/data-api/api-endpoints/announced-prefixes); the contradiction persists because nobody has run the check into the record, not because the answer is unavailable.

The subject of this briefing is small in traffic terms but instructive in evidentiary terms. AS210860 is registered in the RIPE service region as an autonomous system with the as-name "edeka_digital", the organisation ORG-EDG14-RIPE, and the administrative and technical contact DFINFRA (nic-hdl DA9499-RIPE), created on 10 June 2021 (https://apps.db.ripe.net/db-web-ui/query?searchtext=AS210860). DFINFRA itself is a role object, not a company: it exists in the registry as a contact handle serving AS210860, and the authoritative RIPE endpoint returned only an interface shell when queried, so all registry facts here are mirror-based (https://whois.ipip.net/AS210860). BTW's directory entry for the object tracks this registration rather than an operating company (https://btw.media/en/directory/dfinfra).

The routing silence is not in dispute. Third-party routing data shows no announced prefixes since 26 March 2026 and a single historic origin for 193.21.248.0/21 under EDEKA DIGITAL GmbH, with AS9211 as the only observed peer (https://bgp.he.net/AS210860). RIPEstat's own view, taken on 14 September 2026, agrees on the substance — no RIS-visible originations, no transit — and adds a wrinkle: it renders the registration status as RESERVED with no holder, where the mirrors show an ASSIGNED aut-num (https://stat.ripe.net/resource/AS210860). That status discrepancy between the RIPEstat rendering and mirror-held registry objects is unadjudicated in any public source retained for this briefing.

The mirror layer is itself inconsistent. Third-party RIPE mirrors show the aut-num created on 24 August 2021 and last modified on 27 October 2021, with import and export policies naming AS9211 and AS13237 (https://whois.ipip.net/AS210860). But the organisation object ORG-EDG14-RIPE is rendered differently by different mirrors: one renders it as EDEKA Verwaltungs- und Beteiligungs GmbH in Hamburg, HRB 90516, with a last-modified date of 13 May 2026 (https://whois.ipip.net/AS210860), while another renders EDEKA DIGITAL GmbH with a last-modified date of 27 October 2021 (https://ip.cc/topic/asn/AS210860/). Whether the 13 May 2026 modification had any operational meaning — a corporate restructuring, a registry correction, or a mirror artefact — cannot be determined from public sources retained here.

Derived catalogues compound the confusion. IPinfo labels AS210860 "Inactive" with zero prefixes (https://ipinfo.io/AS210860); checkip.com labels it "Active" while showing empty prefix fields (https://checkip.com/asn/AS210860/). Both labels are derived, not observed: each catalogue applied its own rule to the same underlying null routing state and produced opposite verdicts.

Against this, the PeeringDB-derived record distributed via HostDir still self-declares 10 IPv4 prefixes, 1 IPv6 prefix and an open peering policy (https://hostdir.net/networks/as210860-edeka-digital). The canonical PeeringDB record was not retrieved for this briefing and carries no visible timestamp in the retained evidence (https://peeringdb.com/net/?asn=210860). A self-declared market surface of ten IPv prefixes against a routing table that has carried nothing for six months is not a data problem. It is a verification-discipline problem.

The mechanism that could resolve it is public and free. RIPE NCC's RIPEstat Data API exposes an announced-prefixes endpoint that returns, deterministically and reproducibly, the set of prefixes a given origin announces (https://stat.ripe.net/docs/data-api/api-endpoints/announced-prefixes). Any counterparty — a prospective peer, a transit customer, a registry data steward — can run this check at zero incremental cost and see the same null result documented here. That the contradiction persists into late September 2026 therefore reflects a choice not to reconcile, not an inability to know.

BTW's own prior coverage frames the timeline. A routing-evidence check earlier in September 2026 established the zero-prefix baseline and the registry-modification dates (https://btw.media/en/dfinfra-as210860-routing-evidence-sep2026), and a state-difference check on 29 September 2026 found no observable change in routing, registry objects or peering self-declaration since the 26–27 September coverage (https://btw.media/en/dfinfra-as210860-state-difference-september-2026). The next conditions that would constitute real change remain the same three: persistent re-announcement, a PeeringDB edit, or a newer registry timestamp.

One further venue matters for the general case. RIPE's community policy proposal area for 2026-01 is publicly accessible (https://www.ripe.net/community/policies/proposals/2026-01/), indicating an active registry-governance venue where resource-handling rules for dormant or unannounced registrations could be contested. The retained snapshot documents the proposal page's existence and does not establish any pending proposal specific to AS210860; the relevance is structural, not case-specific.

The uncertainties are material. Primary RIPE Database object state could not be read at origin, so all registry facts here are mirror-based. The RIPEstat RESERVED status versus mirror ASSIGNED status is unadjudicated. The canonical PeeringDB record's current state is unverified. And the meaning of the 13 May 2026 organisation-object modification is unknown. What is established, on multiple independent routing observations, is the null state itself — and the fact that a free, public, reproducible method exists to keep it reconciled.