Engineering-Methode
Wie TelcoAIO Netzwerkdaten berechnet, abfragt und prüft
TelcoAIO kombiniert deterministische Browserberechnungen mit Abfragen öffentlicher Netzwerkdienste. Beide Wege unterscheiden sich bei Datenschutz, Aktualität und Fehlern. Diese Seite dokumentiert die Unterschiede, damit Ergebnisse vor der Verwendung in Tickets, Wartungsplänen oder Live-Netzentscheidungen eingeordnet werden können.
Beschrieben wird die aktuelle Implementierung, keine allgemeine Netzwerkschulung oder unabhängige Zertifizierung. Bei Änderungen werden Text, Code, benannte Upstreams, Tests und sichtbare Fehlerzustände miteinander abgeglichen.
1. Lokale Berechnungen bleiben im Browser
Subnetz, VLSM, Wildcard-Maske, IP-Format, IPv6-Konvertierung, MTU, Bandbreite, SLA, Route-Filter, Konfigurationsvergleich und Highlighting laufen im Site-JavaScript. Eingaben müssen nicht an einen TelcoAIO-Server gesendet werden; Kopieren und Datei-Export entstehen ebenfalls lokal.
Gleiche Eingabe und Codeversion liefern reproduzierbare Ergebnisse, aber lokal bedeutet nicht autoritativ. Ein MTU-Modell berechnet gewählte Header, entdeckt jedoch keine ausgelassene Kapselung und bestätigt nicht das tatsächliche Forwarding eines Geräts.
2. Lookup-Werkzeuge hängen von benannten Upstreams ab
DNS nutzt Google Public DNS und Cloudflare DNS over HTTPS. IP-, ASN-, BGP-, RPKI-, IRR- und Routing-Kontext kommt von RIPEstat und der RIPE Database. TelcoAIO formatiert Antworten, besitzt aber nicht die zugrunde liegenden Registry-, Routing- oder Resolverdaten.
Aktualität gilt nur für Dienst, Cache und Beobachtungspunkt zum Anfragezeitpunkt. Begrenzte Timeouts und wenige Wiederholungen behandeln vorübergehende Fehler; ein unerreichbarer Upstream wird nicht in ein positives Ergebnis umgedeutet.
3. Aktualität folgt dem Datenpfad
Reine Rechner haben keinen Live-Zeitstempel, da sie Eingaben und den ausgelieferten Algorithmus verarbeiten. Lookups fragen beim Start ab, doch Upstreams können cachen oder aggregieren. HTTP-Erfolg beweist daher keine globale Echtzeitsicht.
Der Seekabel-Tracker prüft konfigurierte Quellen per Worker, protokolliert Laufzeit und Quellfehler und kennzeichnet Evidenzstufen. Veraltete oder degradierte Zustände bleiben sichtbar, damit Stille bei einem Ausfall nicht als Beweis für einen störungsfreien Betrieb gilt.
4. Berechnung, Parser und Darstellung werden geprüft
Automatisierte Tests decken Adressgrenzen, ungültige Präfixe, Wildcard-Zählung, Community- und Route-Filter-Regeln, Escaping externer Texte, Kabel-Evidenz, Locale-Abdeckung und gemeinsames Laden ab. Worker-Parsing, Speicher und APIs werden getrennt getestet.
Der Release-Review baut die statische Site und prüft HTML, Sprachalternativen, strukturierte Daten und Werbebedingungen. Das reduziert bekannte Regressionen, beweist aber nicht jede Herstellersyntax, Topologie oder zukünftige Upstream-Antwort.
5. Ergebnisse haben betriebliche Grenzen
DNS zeigt die Sicht des gewählten rekursiven Resolvers. RIPE-Routingdaten sind wertvolle öffentliche Beobachtungen, ersetzen aber nicht eigene RIBs, Telemetrie, Verträge oder Change-Datensätze. RPKI-valid beschreibt die Origin-Autorisierung, nicht den gesamten AS Path.
Generierte Konfigurationen müssen gegen Plattformversion und lokale Richtlinie geprüft werden. Vor Produktion sind Herstellerdokumentation, wenn möglich eine unabhängige Gegenrechnung und das eigene Monitoring oder führende System heranzuziehen.
6. Fehler und automatische Ereignisse bleiben erkennbar
Ungültige Eingabe, Timeout, fehlende Daten, Teilquellfehler, veraltete Sammlung und nicht unterstützte Kombinationen sind getrennte Zustände. Fehlerberichte sollten Tool sowie Ist- und Sollverhalten nennen; sensible Werte können durch ein minimales Beispiel ersetzt werden.
Kabelereignisse und Zusammenfassungen können aus Feeds und Messsignalen automatisch entstehen. Bei schwacher Evidenz bleiben sie Advisories mit Quellen und Zeitangaben und sind nicht automatisch werbefähige Artikel. Menschliche Kuratierung liegt in Quellkonfiguration, Schwellen, Korrekturen und dokumentierten Review-Grenzen.
Primäre Dienste und Implementierungsreferenzen
Diese Links benennen verwendete Systeme und die öffentliche Implementierung; sie garantieren kein einzelnes Ergebnis.
- RIPEstat Data API — öffentliche Routing-, Adressraum- und RPKI-Daten für IP/ASN
- RIPE Database REST API — Schnittstelle für Registry- und IRR-Abfragen
- Google Public DNS JSON API — eine öffentliche rekursive DNS-Sicht
- Cloudflare DNS over HTTPS — eine zweite öffentliche DNS-Schnittstelle
- Öffentliches TelcoAIO-Repository — Toolcode, Daten, Tests und Änderungshistorie
Pflege und Korrekturen
Ray pflegt TelcoAIO als persönliches Projekt. Korrekturen sollten Tool, Datenquelle oder Berechnungszweig sowie Ist- und Sollverhalten nennen. Dafür dienen die lokalisierte Kontaktseite oder das öffentliche Repository; Zugangsdaten und private Netzdaten gehören nicht in Berichte.
Das Review-Datum bezeichnet den letzten Abgleich dieser Erklärung mit dem Repository. Es ist kein externes Audit, Qualifikationsnachweis, Verfügbarkeitsversprechen oder Garantie.