https://www.peeringdb.com/

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

Networking-Overview