Summary

  • The registry, cryptographic and routing layers of DATAMATIX's AS210973 tell three different stories, and each layer proves something different about operation.
  • 194.0.132.0/24 is the sharpest anomaly: cryptographically authorised, yet absent from the visible routing table at several monitors.
  • Independent signs of real commercial operation exist — a registered Vienna company, hosted domains, a pingable address — but no single source proves that the network operates as a functioning service business.

DATAMATIX Datensysteme GmbH has appeared in this publication's coverage before, and each previous examination stopped at a different layer of the public record. The registry chain from the RIPE NCC to the operating business was closed in one report (BTW, "Evidence chain closed"); the disagreement between commercial mirrors about that same network was dissected in another (BTW, "Route visibility divergence"). This report asks the question those pieces deliberately left open: does the current observable record — as of the research snapshots taken for this article — show a network that genuinely operates, or one that exists mainly as a registry entry?

The honest answer is that the record supports only precise, layer-by-layer statements, and this article makes them one at a time. A blanket verdict — "operating network" or "registry shell" — would flatten evidence that the public sources themselves keep separating.

Layer one: the registry record

The registry layer is the clearest. AS210973, as-name DATAMATIX-AS, is held by DATAMATIX Datensysteme GmbH, allocated by the RIPE NCC with status ALLOCATED on 30 July 2021, country AT, per the RIPEstat ASN overview (RIPEstat, AS210973) and its resource view (RIPEstat, resource view). The aut-num object observed through registry mirrors carries organisation ORG-DDG16-RIPE, was created on the same 2021-07-30 date and last modified on 5 June 2023, and its import/export policy names only AS8245 and AS24953 as neighbours (RIPE mirrors via whois.ipip.net).

A disclosure is owed here. The RIPE Database web query itself was not directly retrieved during this research session; the underlying registry facts were reconstructed from mirrors that reproduce the RIPE aut-num and organisation objects (RIPE Database web query, not directly retrieved). That is an access limitation, not evidence of absence: the mirror facts are mutually consistent, but a reader should know the canonical endpoint was observed indirectly. The organisation object places DATAMATIX Datensysteme GmbH at Märzstraße 1, 1150 Wien, as a local registry (LIR) with commercial register number FN240683x (RIPE mirrors via whois.ipip.net) — the same register number that appears in the Austrian company register extract (Austrian commercial register, FN240683x).

That last cross-match matters for the execution question. The register extract, the company's own impressum page (datamatix.at impressum) and the company website itself (datamatix.at) together show a real, registered, publicly documented Austrian business. Whatever else the network does, the entity holding AS210973 is not a phantom name in a database.

Layer two: cryptographic authorisation

The RPKI layer is coherent within itself. Two ROAs are issued for AS210973 in the RIPE RPKI repository: one covering 212.236.9.0/24 and 212.236.10.0/24 with maximum length /24, and one covering 149.62.35.0/24 (maxlen /24), 194.0.132.0/24 (maxlen /24) and the IPv6 prefix 2a10:fd00::/32 (maxlen /32), as shown by the independent rpki-client console (rpki-client console, AS210973). Hurricane Electric's ASN view reports four originated prefixes, four RPKI-originated-valid and zero invalid (bgp.he.net, AS210973).

Authorisation, however, proves intent to originate, not observed carriage. An ROA is a signed statement that AS210973 may announce these prefixes; it says nothing about whether the global routing table carries them. That gap is where layer three begins.

Layer three: the routing table

The routing layer is where the picture stops being uniform, and the per-prefix reading is the only defensible one.

The two 212.236.x /24s are the cleanest case. IRR Explorer shows both with BGP origin 210973, a matching RPKI ROA of 210973/24 and a matching RIPE route object — its verdict, quoted verbatim in the snapshot, is "Everything looks good" (IRR Explorer, AS210973). Qrator Radar lists both with ROA and route object "Valid" over its 20 May to 20 August 2026 observation window (Qrator Radar, AS210973 prefixes). Hurricane Electric's per-prefix page for 212.236.9.0/24 confirms the RPKI-valid status under a DATAMATIX ROA, and adds a telling contextual detail: the parent range 212.236.0.0/16 is announced by AS8245 Video-Broadcast GmbH, and IPinfo's data associates the range's domain with video-broadcast.at while the registry netname reads DATAMATIX-01 (bgp.he.net, 212.236.9.0/24; IPinfo, 212.236.9.0/24). Ownership of the /24 and carriage of the /16 thus travel on two different rails.

The sharpest anomaly is 194.0.132.0/24. IRR Explorer records that the prefix has both an RPKI ROA and route objects, yet is flagged "not seen in DFZ" — absent from the default-free zone the collector set observes (IRR Explorer, AS210973). Two other monitors agree with that absence from different directions: Qrator Radar's prefix list simply omits 194.0.132.0/24 (Qrator Radar, AS210973 prefixes), and CIDR Report's collector view counts only three IPv4 prefixes totalling 768 addresses (CIDR Report, AS210973). Meanwhile RIPEstat's RIS-based prefix table lists all four IPv4 /24s (RIPEstat, AS210973) and Hurricane Electric counts four originated prefixes with RPKI-valid status (bgp.he.net, AS210973). A prefix can be authorised, ROA-valid and counted by one measurement system while never appearing in another's routing feed; collector coverage and announcement thresholds are not the same thing as announcement. What can be said flatly is that the cryptographic authorisation for 194.0.132.0/24 exists (rpki-client console, AS210973) and that several independent monitors do not observe it carried.

The remaining two prefixes carry route-object conflicts. On 149.62.35.0/24 and 2a10:fd00::/32, IRR Explorer finds multiple route objects with different origins — 24953 and 210973 — flagged as "RPKI-invalid route objects found", meaning objects in the routing registry assert origins the cryptographic layer does not authorise (IRR Explorer, AS210973). This is the same registry-versus-routing split this publication documented prefix by prefix in prior reporting (BTW, "Route visibility divergence"), and the current snapshot shows it persisting.

The topological view is consistent across sources: three upstreams — AS8218 (Zayo Infrastructure France SA), AS8245 (Video-Broadcast GmbH) and AS24953 (NETPLANET GmbH) — and zero downstreams (IPinfo, AS210973; bgp.he.net, AS210973; CIDR Report, AS210973). RIPEstat adds that the network originates prefixes visible in RIS but is "not seen in RIS as transiting" (RIPEstat, AS210973). That combination — three suppliers, no customers visible in routing data, no transit carried for others — describes an edge network, not a provider. Two corroborating third-party routing views, the bgpthingy collector (bgpthingy, AS210973) and bgp.tools (bgp.tools, AS210973), were also captured for this report and align with the same topological reading.

One internal tension in the monitoring layer deserves its own sentence. Hurricane Electric simultaneously reports all originated prefixes as RPKI-valid and flags AS210973 as "announcing bogons" (bgp.he.net, AS210973). Those two statements are hard to hold together: a flag of this kind can be a tool-side classification artifact, for instance if a monitor attributes the 212.236.x /24s to a differently-originated aggregate, or it can reflect real announcements the ROAs do not cover. The snapshot does not resolve which; this report records the tension rather than choosing an interpretation.

Layer four: the service footprint

Execution, in the ordinary business sense, would show up as services. The footprint here is thin but not empty. IPinfo reports 1,024 IPv4 addresses across the listed netblocks, two hosted domain names on addresses inside 194.0.132.0/24, and one pingable address, 212.236.10.251, replying from Vienna (IPinfo, AS210973). The same source's per-prefix page shows a traceroute that reaches into the range and confirms the RPKI-valid status under DATAMATIX's ROA (IPinfo, 212.236.9.0/24). A responsive address and hosted domains are real signals — machines exist behind the ASN — but two domains and one pingable IP do not amount to evidence of a service business at scale, and the association of the 212.236.9.0/24 range with video-broadcast.at rather than datamatix.at keeps the attribution question open (IPinfo, 212.236.9.0/24).

What the record supports, and what it does not

Putting the four layers side by side:

  • Registry: fully resolved. The holder is a real, registered Vienna company; the chain from RIPE NCC to the operating business is closed (BTW, "Evidence chain closed").
  • Cryptographic: coherent. Two ROAs authorise all five prefixes under AS210973 (rpki-client console, AS210973).
  • Routing: partial and uneven. Two /24s are clean (IRR Explorer, AS210973); one is authorised but widely unobserved; two carry conflicting route-object origins.
  • Service: minimal but real. A registered business, a responsive address, two hosted domains (IPinfo, AS210973; datamatix.at).

On this evidence, DATAMATIX/AS210973 is not a pure registry shell — the network announces, is routed by three upstreams, holds valid cryptographic authorisations and answers on at least one address. Neither is it demonstrably a functioning service provider in the way its own web presence might suggest; the observable operational footprint is an edge network with a very small visible payload. The most precise statement the public record supports today is: a real registered Austrian company operates a small, partially visible edge network whose registry, cryptographic and routing layers disagree in specific, enumerable ways.

The open questions follow directly from the gaps: why 194.0.132.0/24 is ROA-valid yet unobserved in the DFZ by several monitors; what services actually run behind the responsive Vienna address and the two hosted domains; why the aut-num policy names only AS8245 and AS24953 while three upstreams appear in routing data (RIPE mirrors via whois.ipip.net; IPinfo, AS210973); and whether Hurricane Electric's bogon flag reflects monitor classification or genuine announcements (bgp.he.net, AS210973). Each is checkable on the next snapshot, and this report's method — triage by layer before any composite judgment — is designed so the next reading can be compared to this one claim by claim.

For the full directory record of this subject, see the BTW directory entry (https://btw.media/en/directory/datamatix).