Zusammenfassung

  • AS17494 ist in der globalen Routing-Tabelle aktiv und groß, aber die an das Netz geknüpften Identitätsdaten widersprechen einander: Die APNIC-Registrierung benennt BTTB, PeeringDB und das IRR as-set benennen BTCL, und Verzeichnisse tragen eine Beschreibungszeile als Entity-Namen.
  • Selbst gemeldete Kapazitätsfelder — 500.000 IPv4- und 50.000 IPv6-Präfixe in PeeringDB — liegen mehrere Größenordnungen über den etwa 30-49 tatsächlich ursemittierten Präfixen, die Routing-Tracker beobachten.
  • Peer- und Adjazenz-Zählungen streuen je nach Methode zwischen 50 und 643; die Summe der ursemittierten Adressen reicht von 31.744 bis 75.520.
  • Das IRR as-set erklärt über 1.000 Mitglieds-ASNs, während beobachtete Downstreams bei 56-63 liegen; die Liste enthält Duplikate und fehlerhafte Einträge.
  • Das Ergebnis ist ein wirtschaftliches Datenqualitätsproblem: Peering-Entscheidungen, Missbrauchsbearbeitung und Beschaffungsprüfung zahlen mit Friction, wenn Registrierungs- und Betriebsdaten divergieren.

Ein Netz mit zwei Ledgern

Jedes autonome System existiert auf zwei Ledgern gleichzeitig. Das erste ist das Registrierungslager: die APNIC-Objekte, die eine autonome Systemnummer einer Organisation, einer Region und einer Verantwortungskette zuordnen; das IRR as-set, das erwartete Kunden deklariert; und die Verzeichnisse, die aus diesen Feldern und aus selbst gemeldeten Angaben Profile bauen. Das zweite ist das Betriebslager: die Präfixe, die in der globalen Routing-Tabelle tatsächlich erscheinen, die Peers, an denen Routenaustausch beobachtet wird, und die Sessions, die an Internet-Knoten über Monate laufen.

Bei einem gesunden Netz liegen beide Lager grob deckungsgleich. Bei AS17494 liegen sie weit auseinander — und die Richtung der Abweichung ist asymmetrisch: Der Betrieb ist nachweisbar real und intensiv; das Registrierungs- und Identitätslager ist veraltet, kontaminiert oder frei-textuell.

Der Fall ist deshalb lehrreich, weil er zeigt, wie ein einzelner Freitext-String zu einer Entity-Identität werden kann. Die APNIC-Registrierung für AS17494 trägt zwei Beschreibungszeilen: „Telecom Operator & Internet Service Provider as well" und „Bangladesh Telegraph & Telephone Board(BTTB)" [https://records.ping.pe/whois/AS17494]. Aggregatoren und Verzeichnisse haben die erste Zeile über ihre Anzeigefelder als Netznamen übernommen; das BTW-Verzeichnis führt den Eintrag unter genau dieser Zeichenfolge [https://btw.media/en/directory/telecom-operator-internet-service-provider-as-well]. Damit ist kein Firmenname beschrieben, sondern ein frei formulierter Hinweis — „auch Telekommunikationsbetreiber und Internetanbieter" —, der als Objektname missverstanden wurde.

Was die Registrierung sagt

Die APNIC-Registrierungsobjekte zeichnen ein kohärentes, wenn auch veraltetes Bild. Das aut-num trägt den as-namen BTTB-AS-AP, ist der Organisation ORG-BTTB1-AP zugeordnet — „Bangladesh Telegraph & Telephone Board", LIR-Typ, Adresse Telejogajog Bhaban, 37/E, Eskaton Garden in Dhaka —, wurde zuletzt am 18. Januar 2021 geändert, und die Organisation am 5. September 2023. Wartung läuft über APNIC-HM und MAINT-BD-BTTB, das IRT-Objekt ist IRT-BTTB-BD [https://records.ping.pe/whois/AS17494]. Die Zuteilung der Nummer erfolgte am 7. Dezember 2000, Status „Allocated", Land BD [https://ipinfo.io/AS17494], [https://bgpview.io/asn/17494]. Die Import-/Export-Richtlinienzeilen des aut-num verweisen auf AS3491, AS7374, AS5400, AS702 und AS6762 mit announce/accept ANY — historischer Registrierungstext, kein Beweis aktueller Transitverträge.

Parallel dazu benennen mehrere Quellen eine andere Institution. Der PeeringDB-Eintrag 13897 listet die Organisation als „Bangladesh Telecommunications Company Limited(BTCL)" [https://www.peeringdb.com/asn/17494]. Das IRR as-set AS17494:AS-CUSTOMERS ist in APNIC registriert und beschrieben als „BTCL's AS-SET for its Customers" [https://bgp.he.net/irr/as-set/AS17494:AS-CUSTOMERS]. Website-Zuschreibungen über mehrere Aggregatoren hinweg zeigen auf btcl.gov.bd bzw. btcl.gov.bd/en, und PeeringDB verzeichnet die Peering-Policy unter btcl.com.bd [https://ipinfo.io/AS17494], [https://bgpview.io/asn/17494], [https://www.peeringdb.com/asn/17494], [https://worldip.io/asn/17494]. Das IRT-Objekt trägt die Postadresse „Data and Internet Service, Bangladesh Telecommunications Company Ltd, Moghbazar Telephone Bhaban, Dhaka" [https://records.ping.pe/whois/AS17494].

Wichtig ist die Grenze dessen, was diese Quellen belegen: Keine Quelle im zugrundeliegenden Paket datiert oder dokumentiert eine formale BTTB-zu-BTCL-Nachfolge. Die beiden Namen treten auf denselben Registern desselben ASN auf; dass BTTB im Registrierungsnamen und BTCL in Interconnection- und Website-Zuschreibungen erscheint, ist beobachtbar und wird hier als Beobachtung berichtet — nicht als Unternehmensgeschichte. Für die Praxis des Gegenparteien-Checks ändert das nichts am Befund: Drei verschiedene Identitäten werden für dieselbe Nummer behauptet, und die Verzeichnisebene hat die am wenigsten informative davon als Namen übernommen.

Was der Betrieb zeigt

Das Betriebslager ist dagegen eindeutig und reichhaltig. Ein Snapshot des Hurricane-Electric-BGP-Toolkits zeigt 49 ursemittierte Präfixe (36 IPv4, 13 IPv6), 729 angekündigte Präfixe einschließlich More-Specifics, 75.520 ursemittierte IPv4-Adressen, 4.680 beobachtete IPv4- und 1.619 IPv6-AS-Pfade und 388 beobachtete BGP-Peers [https://bgp.he.net/AS17494]. Auf demselben Snapshot waren 37 der ursemittierten Präfixe RPKI-valide und 12 RPKI-invalid; die Seite flaggt auch, dass AS17494 „bogons" ankündigt. Ein per-Präfix-Spiegel listet 38 angekündigte Präfixe, davon zwei als invalid, darunter 103.110.215.0/24 und 2407:5000:b::/48; die Aggregate umfassen 114.130.128.0/18, 123.49.0.0/18, 180.211.128.0/17, 203.112.192.0/19 und 209.58.24.0/24 — letzteres ein ARIN-Bereichs-Block, ursemittiert von einem APNIC-ASN, dessen RPKI-Abgleich in diesem Lauf nicht durchgeführt wurde [https://records.ping.pe/AS17494].

Die Kontinuität ist bemerkenswert: Das Monitoring-Fenster von Qrator Radar vom 18. Juni bis 18. September 2026 zeigt rund 35 aktive Präfixe mit etwa 81.600 IPs, Propagation bei 521-580 Beobachtern (nahezu 100 Prozent) und durchweg RPKI-Valide- sowie Route-Object-Valide-Markierungen — Beleg für ununterbrochene Ursemittierung über drei Monate [https://radar.qrator.net/as/17494]. Das ist kein veraltetes oder totes Netz; es ist ein Netz mit täglichem operativem Leben.

Die Exchange-Präsenz ist konsistent dokumentiert: AMS-IX Amsterdam (80.249.211.151), DE-CIX Mumbai (103.27.171.154), Equinix Singapore (27.111.228.145) und LINX LON1 (195.66.226.78), mit über drei Tracker und PeeringDB hinweg identischen Interface-Adressen, jeweils inklusive IPv6-Endpunkten [https://bgp.he.net/AS17494], [https://www.peeringdb.com/asn/17494], [https://worldip.io/asn/17494]. Die selbst gemeldeten Interconnection-Einrichtungen — Arelion St. Petersburg, Bharti Airtel Mumbai, TATA Communications Chennai und Mumbai — ergänzen dieses Bild, sind aber Selbstauskunft [https://www.peeringdb.com/asn/17494], [https://worldip.io/asn/17494], [https://bgpview.io/asn/17494].

Die Adjazenzdaten zeigen, wer am Randaustausch beteiligt ist. Im IPv4-Report von potaroo sind 62 Adjazenzen sichtbar: sechs als Upstream klassifizierte Systeme (AS6461 Zayo Bandwidth, AS9498 Bharti Airtel, AS3491 PCCW Global, AS6453 TATA Communications America, AS6762 Telecom Italia Sparkle, AS2914 NTT) und 56 Downstreams — darunter University of Dhaka, GrameenPhone AS24389, Robi/Axiata AS24432, BdREN AS63961, Bangladesh Computer Council AS63932, BTCL-ISP AS45588, AmberIT, Radiant, DESCO, Special Security Force SSF, Power Net und Cloudflare AS14789 [https://bgp.potaroo.net/cgi-bin/as-report?as=AS17494&v=4&view=2.0]. Der IPv6-Report listet 14 Adjazenzen: vier Upstreams (AS6453 TATA, AS1299 Arelion, AS2914 NTT, AS9498 Bharti) und zehn Downstreams [https://www.cidr-report.org/cgi-bin/as-report?as=AS17494&v=6&view=2.0]. Beide Reports warnen ausdrücklich, dass Upstream-/Downstream-Labels relative Topologie beschreiben, keine nachgewiesene Provider-/Kunden-/Peer-Geschäftsbeziehung. Die Peers-Seite von ping.pe zeigt 68 Upstreams, 116 Peers und 63 Downstreams, mit Bharti Airtel, NTT America, Tata Communications America, Telecom Italia Sparkle und Hurricane Electric unter den Upstreams sowie Gmax, Cybergate, BdREN, Radiant, Bijoy Online und bdHUB unter den Downstreams [https://records.ping.pe/peers/AS17494].

IPinfo meldet zudem 1.161 gehostete Domains auf 44 IP-Adressen des Netzes und repräsentative angekündigte Netblocks [https://ipinfo.io/AS17494]. Das Gesamtbild ist das eines nationalen Träger-Netzes mit internationaler Transit- und IXP-Anbindung — gerade das Gegenteil eines Ghost-Eintrags.

Die Drift, in Zahlen

Jetzt die Diskrepanzen im Einzelnen, jede ihrer Methode zugeordnet. Die selbst gemeldeten Felder von PeeringDB nennen 500.000 IPv4-Präfixe und 50.000 IPv6-Präfixe, Traffic „500-1000Gbps", „Heavy Inbound", „Asia Pacific", Policy „Open", Präferenz „Never via route servers"; der Datensatz wurde zuletzt am 26. Januar 2023 aktualisiert, das „Public Peering Info" am 24. April 2026 [https://www.peeringdb.com/asn/17494]. Dagegen stehen die beobachteten rund 30-49 ursemittierten Präfixe [https://bgp.he.net/AS17494], [https://bgpview.io/asn/17494], [https://records.ping.pe/AS17494]. Das ist ein Faktor von etwa vier Größenordnungen — keine Rundungsdifferenz, sondern ein Feld, das nie mit gearchivierter Realität abgeglichen wurde. Dasselbe Profil wird von WorldIP und BGPView reproduziert [https://worldip.io/asn/17494], [https://bgpview.io/asn/17494].

Die Peer-Zählungen streuen methodenabhängig: 388 beobachtete BGP-Peers (bgp.he.net), 68/116/63 Upstreams/Peers/Downstreams (ping.pe), 50 Peers/6 Upstreams/50 Downstreams (IPinfo), 94 Peers (BGPView), 62 IPv4-Adjazenzen (potaroo), 14 IPv6-Adjazenzen (cidr-report) [https://bgp.he.net/AS17494], [https://records.ping.pe/peers/AS17494], [https://ipinfo.io/AS17494], [https://bgpview.io/asn/17494], [https://bgp.potaroo.net/cgi-bin/as-report?as=AS17494&v=4&view=2.0], [https://www.cidr-report.org/cgi-bin/as-report?as=AS17494&v=6&view=2.0]. Keine dieser Zahlen ist „falsch"; jede misst etwas anderes — beobachtete Sessions, klassifizierte Adjazenzen, Verzeichniseinträge. Aber für einen Prüfer sind sie schwer auseinanderzuhalten, und die Spannweite von 50 bis 643 (an anderer Stelle abgeleitete Verbindungen) ist breit genug, dass strategische Peering-Bewertungen diametral unterschiedliche Schlüsse ziehen könnten.

Die Summe der ursemittierten Adressen spannt von 31.744 (WorldIP) über 75.264 (IPinfo, BGPView) bis 75.520 (bgp.he.net) [https://worldip.io/asn/17494], [https://ipinfo.io/AS17494], [https://bgpview.io/asn/17494], [https://bgp.he.net/AS17494]. Die IPv6-Sichtbarkeit streut zwischen 13 und 2 ursemittierten Präfixen; die RPKI-Invalid-Zählungen zwischen 12 und 2 [https://bgp.he.net/AS17494], [https://records.ping.pe/AS17494], [https://bgpview.io/asn/17494]. Selbst bgp.he.net weicht in zwei eigenen Crawls ab: sein IPv4-Spiegel zeigte 742 gesamt / 729 v4, die Hauptseite 729 / 716 — ein Beleg, dass selbst dieselbe Datenquelle zwischen Crawls driftet [https://bgp.he.net/AS17494].

Das as-set als Datenqualitätsdokument

Das auffälligste Registrierungsartefakt ist das as-set AS17494:AS-CUSTOMERS. Es deklariert nach der Einschätzung des Pakets über 1.000 Mitglieds-ASNs, während die beobachteten Downstream-Adjazenzen bei 56 (potaroo IPv4) bis 63 (ping.pe) liegen [https://bgp.he.net/irr/as-set/AS17494:AS-CUSTOMERS], [https://records.ping.pe/peers/AS17494], [https://bgp.potaroo.net/cgi-bin/as-report?as=AS17494&v=4&view=2.0]. Die Liste enthält Duplikate, Fälle inkonsistenter Schreibweise („as136004", „As133954", „As138497") und offensichtlich fehlerhafte IDs wie „AS1347121" und „AS386001"; AS17494 selbst steht unter den Mitgliedern [https://bgp.he.net/irr/as-set/AS17494:AS-CUSTOMERS].

Wirtschaftlich liest sich das so: ein as-set ist für Filterautomatik, Route-Objekt-Erzeugung und Sicherheitsprüfungen der wichtigste deklarierte Vertrag über „wessen Kunden ist wer". Wenn er um Größenordnungen überbelegt, Großbuchstaben inkonsistent und fehlerhafte IDs enthält, zahlt jeder Teilnehmer downstream mit Komplexität: Filter, die entweder zu permissiv oder zu restriktiv ausfallen, Prüfer, die manuell prüfen müssen, und Routenserver-Operatoren, die mit einem verrauschten membership-Set arbeiten. PeeringDB meldet für denselben Datensatz IRR-Status „Verified" und RIR-Status „ok" — Zuletzt-Prüfung 26. Juni 2024 [https://www.peeringdb.com/asn/17494]. Ein „Verified"-Label für ein Set dieser Qualität ist selbst Teil des Datenqualitätsproblems.

Die Kontakt-Validierungs-Schicht zeigt dasselbe Muster. Ein whois-Spiegel markierte am 31. März 2026 das im IRT-Objekt registrierte Abuse-Postfach (eine gov.bd-Domain-Adresse) als ungültig, während eine persönliche gmail.com-Adresse validiert wurde; ein zweiter Spiegel vom 28. Januar 2025 zeigt diese Bemerkung nicht [https://records.ping.pe/whois/AS17494], [https://bgpview.io/asn/17494]. Der authoritative whois.apnic.net-Dienst wurde in diesem Lauf nicht direkt abgefragt; alle Registrierungstexte sind über Spiegel gelesen worden, die verzögern oder desynchronisieren können. Für Missbrauchsbearbeitung ist das konkret: Das registrierte Missbrauchs-Postfach eines Netzes mit fünfstelligen betroffenen IPs und mehr als tausend Domains kann je nach Tagesdatum als ungültig erscheinen.

Das Verzeichnis als Verstärker

Das BTW-Verzeichnis führt den Eintrag unter der Beschreibungszeichenfolge, mit zwei Leistungen („Managed network" und „Internet service provider", jeweils „Not yet assessed - 1 record"), 5.006 verwandten Netzen, einem ASN, einem unterstützenden öffentlichen Verweis und den Markierungen „Last updated: 2026-05-14" und „Data as of 2026-07" [https://btw.media/en/directory/telecom-operator-internet-service-provider-as-well]. Die Kanten-Zählungen — Cloudflare-Upstream High Confidence 21 Einträge, Downstream High 20 / Medium 12, Stand Juni 2026; Route-Origin 203.112.192.0/24 Medium, 448 Einträge, Stand August 2026 — passen zu keiner der operativen Taxonomien; die Kanten mischen Netz- und Nicht-Netz-Knoten.

Damit steht das Verzeichnis nicht außerhalb des Problems, sondern als sein Publikationsvektor: Eine Freitextzeile aus dem APNIC-Objekt ist über Aggregator-Anzeigefelder in eine Entity-Identität propagiert, ohne dass eine Prüf- oder Normalisierungsschicht dazwischen griff. Die Lehre reicht über diesen Fall hinaus: Für jedes Netz, dessen Namen aus einer descr-Zeile stammt, ist die öffentliche Identität genau so zuverlässig wie die schwächste Zeichenfolge in der Pipeline.

Was hier nicht behauptet wird

Die Grenzen dieses Berichts sind scharf. Keine Unternehmensbilanzen, keine Transaktionsunterlagen und keine Regulierungsentscheidungen lagen vor; zur BTTB-BTCL-Institutionengeschichte kann auf Basis der gepackten Quellen nichts Substanzielles gesagt werden. Die meisten Tracker-Snapshot-Daten sind undatiert; nur Qrator liefert ein Fenster (18. Juni bis 18. September 2026), und das BTW-Verzeichnis markiert Mai/Juli 2026. Ob die vollständige Kantenliste und alle Confidence-Werte des Verzeichnisses sichtbar waren, ist unklar. Die Ursemittierung von 209.58.24.0/24 wurde nicht gegen RPKI-ROA-Besitz geprüft.

Und die PeeringDB-Felder für Route-Server-URL und Looking-Glass-URL erscheinen ohne erfasste Werte — ob leer oder nicht gerendert, ist nicht unterscheidbar.