Deep Dive: PeeringDB als Backbone der Interconnection-Automatisierung
PeeringDB ist die autoritative, community-getriebene Datenbank zur Verknüpfung von ASNs mit physischen und logischen Interconnection-Informationen. Sie liefert das strukturierte Fundament, um BGP-Peering-Beziehungen reproduzierbar, auditierbar und automatisiert zu etablieren.
Datenmodell und Objekte
PeeringDB nutzt ein relationales Schema, dessen Kernobjekte direkt auf BGP- und Interconnection-Workflows abzielen:
- Network (net)
- Schlüssel: asn, name, website, irr_as_set, policy_general (Open/Selective/Restrictive), policy_url
- Metadaten: info_prefixes4/6, info_unicast, info_ipv6, info_never_via_route_servers
- Facility (fac)
- Geodaten: address, city, country, latitude/longitude
- Betreiber- und Standort-Metadaten; Grundlage für Colocation-Zuordnung
- Internet Exchange (ix)
- Eigenschaften: name, city, country, website, proto_ipv6, proto_unicast, proto_route_server
- IX-LAN (ixlan)
- Layer-2 Broadcast-Domain eines IX; Basis für Peering-LANs
- IX-LAN Prefix (ixpfx)
- IPv4-/IPv6-Subnetze der Peering-LANs zur Adressvalidierung
- Network–IX Link (netixlan)
- Kritisch für Automatisierung: Zuordnung net ↔ ix inkl. ipaddr4/ipaddr6, speed, operational status
- Network–Facility Link (netfac)
- Abbildung net ↔ fac zur physischen Präsenz
- Point of Contact (poc)
- Rollenbasierte Kontaktpunkte (NOC, Peering, Abuse) für Automations-Fallbacks
Beziehungen:
- Ein net kann mehrere netixlan- und netfac-Einträge haben (Mehrfachpräsenz, diverse Ports/Standorte).
- Ein ix besitzt ≥1 ixlan und zugehörige ixpfx-Einträge (IPv4/IPv6 Peering-LANs).
API-First und Caching-Strategien
- REST-API: https://www.peeringdb.com/api
- Rückgabeformat: JSON mit data-Array
- Filter: Django-Style Query-Parameter (z. B. asn=, name__contains=, ix_id=, updated__gt=ISO8601)
- Konsum: Pull-basiert; kein Realtime-SLA
Best Practices:
- Lokaler Cache/Mirror
- django-peeringdb (Python) als referenzierter Client mit inkrementeller Synchronisation
- Periodischer Pull (z. B. alle 5–15 Minuten), Nutzung von updated__gt zur Reduktion der Payload
- ETag/If-Modified-Since verarbeiten, wenn bereitgestellt
- Robustheit
- Toleranz für unvollständige Felder (fehlendes irr_as_set, nur IPv4/IPv6)
- Staleness-Metrik: updated-Feld überwachen und veraltete Datensätze kennzeichnen
Beispiel-Queries (cURL + jq)
Lookup eines Netzwerks (net) nach ASN:
curl -s "https://www.peeringdb.com/api/net?asn=15169" \
| jq '.data[0] | {asn, name, irr_as_set, policy_general, info_prefixes4, info_prefixes6}'IX identifizieren und Mitglieder (netixlan) abrufen:
IX_ID=$(curl -s "https://www.peeringdb.com/api/ix?name__contains=DE-CIX%20Frankfurt" | jq '.data[0].id')
curl -s "https://www.peeringdb.com/api/netixlan?ix_id=${IX_ID}" \
| jq '.data[] | {asn, ipaddr4, ipaddr6, speed}'Open-Policy-Peers am selben IX finden:
ASNS=$(curl -s "https://www.peeringdb.com/api/netixlan?ix_id=${IX_ID}" | jq -r '.data[].asn' | sort -u | paste -sd, -)
curl -s "https://www.peeringdb.com/api/net?asn__in=${ASNS}&policy_general=Open" \
| jq '.data[] | {asn, name, irr_as_set}'Peering-LAN-Präfixe (ixpfx) validieren:
IXLAN_ID=$(curl -s "https://www.peeringdb.com/api/ixlan?ix_id=${IX_ID}" | jq '.data[0].id')
curl -s "https://www.peeringdb.com/api/ixpfx?ixlan_id=${IXLAN_ID}" \
| jq '.data[] | {protocol, prefix}'Inkrementelles Update seit Timestamp:
SINCE="2025-01-01T00:00:00"
curl -s "https://www.peeringdb.com/api/net?updated__gt=${SINCE}" | jq '.data | length'Pipeline-Use-Cases
- Auto-Discovery
- Schnittmenge gemeinsamer IX-Präsenzen via netixlan bestimmen
- policy_general=Open filtern; optional info_never_via_route_servers beachten
- Kontaktpunkte via poc abrufen, falls bilaterales Peering koordiniert werden soll
- Configuration Generation
- Nachbarn: ipaddr4/ipaddr6 aus netixlan; Remote-AS aus net.asn
- Max-Prefix: aus info_prefixes4/6 mit Headroom ableiten (z. B. ceil(prefixes × 1.2))
- RS-Entscheidung: ix.proto_route_server und lokale Policy berücksichtigen
- Template-basierte Ausgabe (IOS-XR, Junos, SR OS) über Jinja/Ansible oder Peering Manager
- Inventory-Korrelation
- netfac ↔ eigenes DC/PoP-Inventar matchen (physische Präsenz und Patch-Planung)
- ixpfx prüfen, ob die Interface-IP im korrekten Peering-LAN liegt
Ingress Filtering und Routing-Sicherheit
- IRR-gestützte Filter
- irr_as_set aus net verwenden, AS-SET expandieren, präzise Prefix-Listen generieren
- Route-Maps/Policies mit as-path constraints und max-prefix anwenden
- RPKI-Validierung ergänzen
- IRR-Informationen mit ROA-Status korrelieren (Prefer-Valid, Reject-Invalid)
- Route-Server-Policies
- Bei RS-Peering communities und Large Communities gemäß IX-Dokumentation berücksichtigen
Authentifizierung und Validierung
- OAuth2 via PeeringDB
- IX- und Betreiberportale nutzen PeeringDB als IdP, um Nutzer mit Organisationen/ASNs zu verknüpfen
- Rechteverwaltung: Nur verifizierte Org-Mitglieder dürfen Objekte ihres ASNs pflegen
- Datenintegrität
- Onboarding-Validierung gegen RIR-Daten (RIPE/ARIN/etc.) zur ASN-Inhaberschaft
- Verifizierte Facilities/Orgs zur Reduktion von Falschzuordnungen
Betriebsaspekte
- Aktualität überwachen
- Alerts bei stark veralteten net-/netixlan-Einträgen
- Periodische Revalidierung von irr_as_set und Kontaktpunkten (poc)
- Fehlertoleranz
- Mehrere Ports am selben IX korrekt deduplizieren/aggregieren
- IPv4-/IPv6-Asymmetrien behandeln (nur v6 oder nur v4 vorhanden)
- Compliance
- Dokumentation der aus PeeringDB abgeleiteten Konfigurationsstände (Audits, Change-Tracking)
Fallstricke und bewährte Praktiken
- Nicht jedes „Open“ impliziert sofortige Session: Kapazität, NOC-Fenster und RS-Policies prüfen.
- Fehlendes oder inkonsistentes irr_as_set ist häufig: Fallback auf manuelle Bestätigung oder Org-weit gültige AS-SETs.
- Namen und Orgs können variieren: Matching über IDs (net.id, ix.id) statt freie Textfelder.
- Address-Checks gegen ixpfx erzwingen, um Fehlkonfigurationen im Peering-LAN früh zu erkennen.
- Max-Prefix konservativ dimensionieren; automatische Erhöhungen nur mit Change-Kontrolle.
Tags:peeringdbixpbgpautomationnetopsinterconnectionapiirrrpkioauthnetworking