Kapitel anzeigen
Wegweiser
BGP verbindet autonome Systeme, entscheidet aber nicht, welche Route geschäftlich oder technisch sinnvoll ist. BGP transportiert Policy. Eine etablierte Session ist deshalb erst der Anfang; sicher wird sie durch eindeutige Import- und Exportregeln, gepflegte Registry-Daten und unabhängiges Monitoring.
Dieser Leitfaden führt vom Routing-Grundwissen bis zum kontrollierten Produktionsbetrieb. Er richtet sich an Betreiber eines eigenen ASN, an technische Entscheider und an Teams, die Routing-Risiken beherrschbar machen möchten.
Empfohlene Reihenfolge
- Routing, CIDR und BGP-Pfadauswahl verstehen.
- Adressplan und Beziehungen zu Providern, Kunden und Peers dokumentieren.
- IRR-, ROA- und ASPA-Daten passend zur realen Policy veröffentlichen.
- Import und Export im Labor mit einem abschliessenden Deny testen.
- Aktivierung, Beobachtung und Rollback als einen gemeinsamen Change planen.
Wichtig: Beispiele erklären Konzepte und sind keine fertige Routerkonfiguration. Syntax, Standardverhalten und Sicherheitsfunktionen unterscheiden sich je nach Plattform und Version.
Routing-Grundlagen
Control Plane und Data Plane
Die Control Plane lernt und bewertet Routen. BGP, OSPF, IS-IS und statische Konfiguration füllen dabei die Routing Information Base (RIB). Die Data Plane leitet Pakete anhand der installierten Forwarding Information Base (FIB) weiter. Eine Route kann in BGP sichtbar sein, ohne wegen Policy, Next-Hop-Auflösung oder einer besseren Route in der FIB zu landen.
CIDR und Longest Prefix Match
Ein Präfix beschreibt einen zusammenhängenden Adressbereich. /24 bei IPv4 und /48 bei IPv6 geben die Anzahl der festen Netzbits an. Beim Weiterleiten gewinnt immer die spezifischste passende Route:
203.0.113.0/24gilt für den gesamten Block;203.0.113.128/25ist spezifischer;- ein Paket an
203.0.113.200folgt deshalb der/25, sofern diese installiert ist.
More-Specifics eignen sich für Traffic Engineering, erhöhen aber die globale Routentabelle und vergrössern die Fehlerfläche. Aggregation sollte der Normalfall bleiben.
Autonome Systeme
Ein autonomes System (AS) ist ein Netzwerk unter einer gemeinsamen externen Routing Policy. Die ASN identifiziert dieses System im AS-Pfad. Öffentliche ASNs werden durch die Regional Internet Registries vergeben; private ASNs sind für abgeschlossene Labore und interne Übergänge vorgesehen und dürfen nicht unkontrolliert in die globale Tabelle gelangen.
| Begriff | Bedeutung |
|---|---|
| eBGP | Routenaustausch zwischen unterschiedlichen autonomen Systemen |
| iBGP | Verteilung externer Routen innerhalb desselben AS |
| Origin | Das AS am Ende des AS_PATH, das ein Präfix in BGP einführt |
| Upstream | Provider, der Konnektivität zu weiteren Netzen bereitstellt |
| Peer | Gleichrangiger Austausch eigener und kundenbezogener Routen |
Die Protokollgrundlage beschreibt RFC 4271.
BGP-Sitzung und Pfadauswahl
Von Idle zu Established
Eine BGP-Sitzung läuft über TCP Port 179. OPEN-Nachrichten handeln ASN, Hold Time und Fähigkeiten wie Multiprotocol BGP aus. KEEPALIVE hält die Session aktiv; UPDATE kündigt Routen an oder zieht sie zurück. Der Zustand Established bestätigt nur den Protokollaustausch — nicht, dass Policy und Erreichbarkeit korrekt sind.
Vor der Aktivierung müssen mindestens folgende Werte auf beiden Seiten übereinstimmen:
- lokale und entfernte ASN;
- Quell- und Nachbaradresse;
- IPv4-/IPv6-Adressfamilien;
- Multihop- und TTL-Anforderungen;
- Authentisierung, sofern vereinbart;
- erwartete Präfixe, Communities und Prefix-Limits.
Wichtige Pfadattribute
| Attribut | Operative Bedeutung |
|---|---|
LOCAL_PREF |
Bevorzugt innerhalb des eigenen AS den Ausgang; höher ist üblicherweise besser |
AS_PATH |
Dient Loop-Erkennung und Policy; ein kürzerer Pfad ist nur ein Teil der Auswahl |
NEXT_HOP |
Muss über die Routingtabelle erreichbar sein, sonst ist der Pfad unbrauchbar |
MED |
Hinweis an ein Nachbar-AS für mehrere Übergänge; nur begrenzt vergleichbar |
| Communities | Markierungen für dokumentierte Policy-Aktionen |
| Large Communities | 32-Bit-feste Form global:funktion:parameter, robust für moderne ASNs |
Die genaue Best-Path-Reihenfolge ist herstellerabhängig. Prüfe daher nicht nur die empfangene Route, sondern auch den ausgewählten Pfad und die tatsächlich an jeden Nachbarn exportierten Routen.
Praxisregel:
LOCAL_PREFsteuert den bevorzugten Ausgang zuverlässig im eigenen AS. AS-Path-Prepending und MED beeinflussen eingehenden Verkehr nur indirekt und ohne Erfolgsgarantie.
Adressplanung und Ankündigungen
Ein sauberer Plan trennt Zuweisung, interne Nutzung und globale Ankündigung. Nicht jedes intern vergebene Subnetz muss separat im Internet sichtbar sein.
Default-Free Zone (DFZ)
Die Default-Free Zone ist der Teil des Internets, in dem Router die globale BGP-Tabelle statt nur einer Default-Route führen. bgp.cat meldet ein Präfix als DFZ-sichtbar, wenn ein aktueller direkter Origin-Pfad und zusätzlich eine unabhängige Weiterverbreitung beobachtet werden. Für Präfixe ohne direkten Feed genügt alternativ ein Konsens von mindestens 80 Prozent der frischen, etablierten Full-Table-Feeds. Einzelne Transit-Restpfade reichen ausdrücklich nicht aus.
Die Anzeige verwendet ausschließlich Session- und Routenzustände der bgp.cat-Collector, die höchstens fünf Minuten alt sind. Sie wird bei BGP-Updates sofort und zusätzlich alle 30 Sekunden neu berechnet. Registry-, IRR- und RPKI-Daten sagen dagegen nichts über die aktuelle globale Sichtbarkeit aus.
Wichtig: Eine Routerabfrage kann die beste abdeckende Route liefern und deshalb nur die Default-Route zeigen. Für eine lokale Prüfung muss das exakte Präfix in der BGP-RIB abgefragt werden.
Aggregation zuerst
- Kündige einen stabilen Aggregatpfad an.
- Verwende More-Specifics nur mit dokumentiertem Zweck.
- Hinterlege für jedes angekündigte Präfix einen kontrollierten Ursprung in der lokalen Routingtabelle, häufig als statische Discard-/Null-Route.
- Vermeide pauschale Redistribution von Connected-, IGP- oder fremden BGP-Routen.
- Pflege IPv4 und IPv6 als getrennte Policies; eine sichere IPv4-Konfiguration schützt IPv6 nicht automatisch.
Im globalen Internet werden IPv4-Präfixe länger als /24 und IPv6-Präfixe länger als /48 häufig gefiltert. Das ist eine operative Konvention, keine Garantie. Provider und Peers definieren ihre eigenen Grenzen.
PA und PI
Provider Aggregatable (PA) gehört zum Adressraum eines Providers und lässt sich durch diesen aggregieren. Bei einem Providerwechsel ist in der Regel eine Umnummerierung nötig. Provider Independent (PI) ist vom Transitprovider unabhängig, erfordert aber eigene Registry-, Routing- und Sicherheitsprozesse. Die konkrete Vergabepolitik bestimmt die zuständige RIR. Passende ASN-, IPv4- und IPv6-Angebote sowie limitierte Ressourcen findest du in den Netzwerkangeboten.
Direkt bestellen: 32-Bit-ASN + IPv6 /44 · 16-Bit-ASN + IPv6 /44 · IPv4-Angebote · IPv6-Angebote
Beziehungen und Routing Policy
BGP-Policy folgt der Beziehung, nicht bloss der Tatsache, dass eine Session existiert.
| Gelernte Route | An Kunden exportieren | An Peer exportieren | An Provider exportieren |
|---|---|---|---|
| Eigene Präfixe | ja | ja | ja |
| Von Kunden | ja | ja | ja |
| Von Peers | ja | nein | nein |
| Von Providern | ja | nein | nein |
Dieses vereinfachte, valley-free Modell verhindert viele Route Leaks: Eine von einem Provider oder Peer gelernte Route darf nicht einem anderen Provider oder Peer als eigene Transitroute angeboten werden.
Default Reject
Neue eBGP-Sessions sollten ohne explizite Policy keine nutzbaren Routen annehmen oder exportieren. RFC 8212 beschreibt dieses sichere Standardverhalten.
Eine belastbare Policy umfasst:
- exakte eigene Präfixlisten im Export;
- kundenbezogene Präfix- und AS-Pfad-Filter;
- RPKI Origin Validation;
- Filter für eigene, spezielle und unzulässige Präfixe und ASNs;
- realistische Prefix-Limits mit Warnschwelle;
- einen abschliessenden Deny;
- dokumentierte Communities statt undurchsichtiger Seiteneffekte.
RIPE Database, IRR und RPSL
Die RIPE Database enthält Ressourcen-, Kontakt- und Routing-Policy-Daten. Als Internet Routing Registry (IRR) stellt sie Informationen bereit, aus denen Betreiber Filter erzeugen können. Diese Objekte dokumentieren Absicht, sind aber kein Ersatz für Routerpolicy oder kryptografische Autorisierung.
Zentrale Objekte
| Objekt | Zweck |
|---|---|
mntner |
Legt fest, wer andere Objekte ändern darf |
person / role |
Kontakt für Personen oder dauerhafte Funktionen wie NOC und Abuse |
organisation |
Verknüpft Ressourcen und Kontakte mit einer Organisation |
aut-num |
Beschreibt ein AS und optional dessen RPSL-Policy |
route / route6 |
Ordnet ein IPv4-/IPv6-Präfix einem beabsichtigten Origin-AS zu |
as-set |
Gruppiert ASNs für Kundenkegel und Filtergenerierung |
domain |
Delegiert Reverse-DNS-Zonen |
Für langlebige Funktionen sind Rollenobjekte besser als persönliche Adressen. Maintainer-Rechte gehören nur zu vertrauenswürdigen Konten; NOC- und Abuse-Kontakte müssen erreichbar bleiben.
IRR ist nicht RPKI
Ein route- oder route6-Objekt hilft Providern bei der Filtererzeugung, ist aber keine kryptografische Aussage. Ein ROA autorisiert den Ursprung kryptografisch, beschreibt jedoch keine vollständige Routing Policy. In der Praxis werden beide Systeme parallel verwendet.
Hilfreiche Werkzeuge sind RIPE Database, IRRexplorer und bgpq4. Rekursive AS-SETs müssen klein, nachvollziehbar und aktuell bleiben.
RPKI, ROAs und Origin Validation
Die Resource Public Key Infrastructure (RPKI) bindet Internetnummernressourcen an Zertifikate. Ein Route Origin Authorisation (ROA) sagt aus, welche ASN ein Präfix bis zu welcher Präfixlänge ankündigen darf.
Die drei ROV-Zustände
| Zustand | Bedeutung | Typische Behandlung |
|---|---|---|
| Valid | Präfix, Origin-AS und Länge werden von einem ROA erlaubt | akzeptieren und normal bewerten |
| Invalid | Ein deckendes ROA existiert, erlaubt aber ASN oder Länge nicht | nach bereinigter Einführung verwerfen |
| Not Found | Kein deckendes ROA liefert eine Entscheidung | nicht wie Invalid behandeln |
maxLength ist eine zusätzliche Berechtigung, kein Komfortwert. Ein ROA für 203.0.113.0/24, Origin AS64512 und maxLength /24 erlaubt nur genau dieses Präfix. Ein unnötig grosses maxLength autorisiert zusätzliche More-Specifics und erweitert damit die Angriffsfläche.
Sichere Einführung
- Inventarisiere alle realen Präfix-/Origin-Kombinationen.
- Erstelle möglichst enge ROAs.
- Prüfe Veröffentlichung und Ablauf über ein unabhängiges Werkzeug.
- Beobachte Validierungszustände zunächst ohne Drop-Policy.
- Korrigiere legitime Invalids.
- Verwerfe Invalids kontrolliert und überwache Validator-Frische sowie RTR-Sessions.
RPKI validiert den Ursprung, nicht den vollständigen AS-Pfad. Grundlagen und Betriebsmodelle stehen in RFC 6480, RFC 6811 und bei der RIPE NCC RPKI-Dokumentation.
ASPA und Schutz vor Route Leaks
Ein ROA beantwortet: Darf AS X dieses Präfix originieren? Ein Autonomous System Provider Authorization (ASPA) beantwortet: Welche ASNs dürfen für dieses Kunden-AS als Transitprovider auftreten? Damit ergänzt ASPA die Origin Validation um kryptografisch prüfbare Informationen über Providerbeziehungen.
Stand Oktober 2026
Die RIPE NCC ermöglicht das Signieren von ASPA-Objekten im RPKI Dashboard. Das Objektprofil und die Verfahren zur AS_PATH-Verifikation sind jedoch weiterhin IETF-Internet-Drafts und noch keine finalen RFCs. Implementierungen und Betriebsrichtlinien entwickeln sich weiter; produktive Entscheidungen müssen sich deshalb an den jeweils aktuellen Spezifikationen orientieren.
Ein ASPA enthält:
- die Customer ASN (CAS), deren Inhaber signiert;
- die vollständige Menge autorisierter Provider ASNs (PAS);
- bei einem transitfreien AS den dafür vorgesehenen Providerwert
AS 0.
Was gehört in die Providerliste?
Aufgeführt werden alle echten Transitprovider — unabhängig davon, ob sie nur IPv4, nur IPv6 oder beides transportieren. Auch ein nicht transparenter Route Server oder eine komplexe Beziehung gehört hinein, wenn das Nachbar-AS tatsächlich eine Providerrolle übernimmt. Gewöhnliche Kunden, bilaterale Peers und transparente IXP Route Server sind keine Provider und werden nicht automatisch eingetragen.
Betriebsrisiko: Eine unvollständige ASPA kann legitime Pfade bei validierenden Netzen als Invalid erscheinen lassen. Providerwechsel, Backup-Transit und ASPA-Änderung müssen daher als gemeinsamer Change erfolgen.
Path Verification
Für jede AS-Nachbarschaft kann die ASPA-Datenlage sinngemäss Provider, Not Provider oder No Attestation ergeben. Daraus entstehen für Pfade die Zustände:
| Zustand | Aussage |
|---|---|
| Valid | Alle für die Prüfungsrichtung nötigen Beziehungen sind autorisiert |
| Invalid | Mindestens eine vorhandene ASPA widerspricht der behaupteten Providerbeziehung bzw. beweist eine unzulässige Pfadform |
| Unknown | Daten fehlen, aber es gibt keinen beweisbaren Widerspruch |
Invalid-Pfade können Route Leaks oder manipulierte AS-Pfade anzeigen. Unknown ist wegen unvollständiger weltweiter Einführung erwartbar und darf nicht pauschal wie Invalid verworfen werden. Die Prüfung unterscheidet ausserdem, ob ein Pfad von Kunde/Peer oder von einem Provider empfangen wurde; bei Providerpfaden wird eine valley-free Form aus Up- und Down-Ramp bewertet.
Autoritative Quellen sind das aktuelle ASPA-Objektprofil, die aktuelle ASPA-Verifikation und die ASPA-Dokumentation der RIPE NCC.
BGP Roles und OTC
RFC 9234 definiert BGP Roles und das transitive Only-To-Customer-Attribut (OTC). Rollen machen die erwartete Beziehung einer eBGP-Session explizit; OTC hilft, Verstösse gegen die Exportlogik zu verhindern oder zu erkennen. Strikte Rollenaushandlung darf auf bestehenden Sessions nur abgestimmt aktiviert werden, da widersprüchliche Rollen den Sessionaufbau verhindern können.
ASPA, Roles und OTC ersetzen keine Filter. Sie sind zusätzliche Schutzschichten neben exakter Exportpolicy, Prefix-Limits, IRR, ROAs und Monitoring.
Transit, Peering und Route Server
IP-Transit
Ein Transitprovider liefert Erreichbarkeit zu Netzen ausserhalb des eigenen Kundenkegels — als Default Route, Partial Routes oder Full Table. Die Wahl beeinflusst Speicherbedarf, Konvergenz und Traffic Engineering. Zwei Sessions zum selben Router sind keine echte Redundanz, wenn Leitung, Standort oder Backbone gemeinsam ausfallen können. Virtuelle Router, BGP-fähige Server und direkte IX-Anbindung sind unter Compute & Peering zusammengefasst.
Direkt bereitstellen: Securebit Virtual Server · RWIX Enterprise VPS
Bilaterales Peering
Peers tauschen typischerweise eigene und kundenbezogene Routen ohne Transit für Provider- oder Peerpfade. Vor der Session werden ASN, Adressen, Präfixzahlen, Policy, Communities und Kontakte abgestimmt. PeeringDB dient als öffentliches Verzeichnis, ersetzt aber keine direkte Betriebsabsprache.
IXP Route Server
Ein Route Server reduziert die Zahl bilateraler Sessions. Er leitet Routen zwischen Teilnehmern weiter, ohne normalerweise selbst im Forwardingpfad zu liegen. Prüfe insbesondere:
- ob das eigene ASN im AS_PATH korrekt behandelt wird;
- welche Communities Exporte steuern;
- ob RPKI-, IRR- und Prefix-Limits angewendet werden;
- ob direkte Sessions für wichtige Pfade sinnvoll sind;
- ob der Route Server transparent oder nicht transparent arbeitet — relevant auch für ASPA.
Sicherer Produktionsbetrieb
Vor der Aktivierung
- IPv4- und IPv6-Policy sind separat geprüft.
- Import und Export enden mit Deny.
- Export erlaubt nur freigegebene eigene oder explizit delegierte Präfixe.
- IRR-Objekte, ROAs und ASPA entsprechen dem beabsichtigten Betrieb.
- Prefix-Limits besitzen sinnvolle Warn- und Abschaltwerte.
- Out-of-Band-Zugang und Ansprechpartner funktionieren.
- Eine bekannte gute Konfiguration und konkrete Rollback-Schritte liegen bereit.
- Externes Monitoring ist bereits geöffnet.
- Eine zweite Person hat die Änderung geprüft, sofern möglich.
Session-Schutz
Je nach Plattform und Gegenstelle sind TCP-Authentisierung, GTSM/TTL-Schutz, ACLs für TCP/179 und BFD sinnvoll. BFD beschleunigt Fehlererkennung, kann bei aggressiven Timern aber selbst Instabilität erzeugen. Keine dieser Funktionen ersetzt Routenfilter.
Nach der Aktivierung
Prüfe Sessionzustand, empfangene und gesendete Routenzahlen, ausgewählte Pfade, RPKI-Zustände und die externe Sicht. Kontrolliere ausdrücklich die Adj-RIB-Out beziehungsweise die pro Nachbar angekündigten Routen; die lokale Routingtabelle allein beweist keinen korrekten Export.
Für allgemeine Best Practices siehe RFC 7454, den NLNOG BGP Filter Guide und die MANRS Actions.
Monitoring und Fehlersuche
Gutes Monitoring verbindet lokale Telemetrie mit unabhängigen Beobachtungspunkten.
| Symptom | Zuerst prüfen | Häufige Ursache |
|---|---|---|
| Session bleibt Idle/Active | TCP/179, Quelladresse, ASN, TTL, Authentisierung | Erreichbarkeit oder Parameter stimmen nicht |
| Established, aber keine Routen | Address Family, Importpolicy, Prefix-Limit | AFI/SAFI nicht aktiviert oder alles gefiltert |
| Route empfangen, nicht installiert | NEXT_HOP, RPKI, LOCAL_PREF, bessere Route | Next Hop unerreichbar oder Pfad nicht best |
| Eigenes Präfix extern unsichtbar | Adj-RIB-Out, IRR/ROA, Providerfilter | Export fehlt oder Autorisierung passt nicht |
| Nur einzelne Netze unerreichbar | More-Specifics, Rückweg, RPKI, MTU | asymmetrische Policy oder gefilterte Länge |
| Unerwarteter AS-Pfad | Leak, Route Server, Prepends, Aggregation | falscher Export oder unvollständige Sicht |
Nutze bgp.cat Looking Glass, Live Events, MRT-Downloads, RIPEstat, RIPE BGPlay und weitere externe Looking Glasses. Alarmiere mindestens auf Sessionwechsel, Präfixzahl, unerwarteten Origin, RPKI Invalid, ASPA Invalid, neue More-Specifics und Sichtbarkeitsverlust.
Bei einem Route Leak
- Stoppe den fehlerhaften Export an der Quelle; schalte notfalls die betroffene Address Family oder Session ab.
- Vermeide parallele, nicht zusammenhängende Änderungen.
- Bestätige Withdrawals über externe Collectors.
- Informiere betroffene Provider und Peers mit ASN, Präfixen, Startzeit und Massnahme.
- Sichere Logs, Konfigurationsdifferenz und Zeitstempel.
- Korrigiere Policy und gegebenenfalls IRR-, ROA- oder ASPA-Daten.
- Ergänze einen reproduzierbaren Labortest und dokumentiere Ursache sowie Prävention.
Reverse DNS und Betriebsdaten
Reverse DNS bildet IP-Adressen auf Namen ab. IPv4 nutzt in-addr.arpa, IPv6 die nibble-basierte Zone ip6.arpa. Delegationen müssen auf autoritative Nameserver zeigen; Forward- und Reverse-Einträge sollten zusammenpassen, wenn Anwendungen dies erwarten.
Halte ausserdem NOC-, Abuse- und Peeringkontakte aktuell. Veraltete Kontaktdaten verlängern Störungen. PeeringDB sollte reale Standorte, Policy, Präfixzahlen und Kontaktrollen abbilden; sensible persönliche Daten gehören nicht in öffentliche Rollen.
Labor und Bereitschaftscheck
Die erste BGP-Erfahrung gehört nicht ins öffentliche Internet. Ein geeignetes Labor nutzt private ASNs, Dokumentationspräfixe und einen getrennten Managementpfad. Mit BGP Labs, Containerlab oder FRRouting lässt sich eine reproduzierbare Topologie bauen.
Übe mindestens:
- dual-stack eBGP mit expliziter Import- und Exportpolicy;
- zwei Provider und Auswahl über LOCAL_PREF;
- Communities und kontrolliertes Prepending;
- Prefix-Limits und deren Wiederanlaufverhalten;
- einen absichtlich erzeugten Route Leak, der am Exportfilter scheitert;
- Sessionausfall, Graceful Shutdown und Rollback;
- Prüfung der tatsächlich gesendeten Routen pro Nachbar.
DN42 ist danach ein nützlicher privater Übungsverbund, muss aber strikt von der öffentlichen Routingtabelle getrennt bleiben.
Du bist für eine kontrollierte Aktivierung bereit, wenn du jede akzeptierte und exportierte Route erklären, einen Leak nachweislich blockieren, über Out-of-Band-Zugang zurückrollen und deine Ankündigungen von mehreren externen Netzen verifizieren kannst.
Referenzen und Weiterbildung
- RIPE NCC Academy — Routing, RPKI und Registry-Betrieb
- APNIC Academy — Routing Fundamentals, BGP und MANRS
- DE-CIX Academy — Peering und Interconnection
- Interconnection Academy — technische und wirtschaftliche Aspekte der Zusammenschaltung
- BGP for networks who peer — offenes BGP-Lehrbuch
- Team Cymru Bogon Reference — aktuelle Special-Purpose- und Bogon-Daten
Die Dokumentation beschreibt einen belastbaren Ausgangspunkt, keine universelle Policy. Vereinbarungen mit Nachbarn, aktuelle Standards und das Verhalten der eingesetzten Routersoftware bleiben massgeblich.
Guide Overview
BGP connects autonomous systems, but it does not determine which route makes business or technical sense. BGP carries policy. An established session is therefore only the beginning; secure operation requires explicit import and export rules, accurate registry data, and independent monitoring.
This guide takes you from routing fundamentals to controlled production operations. It is intended for operators of their own ASN, technical decision-makers, and teams seeking to manage routing risks effectively.
Recommended Sequence
- Understand routing, CIDR, and BGP path selection.
- Document the addressing plan and relationships with providers, customers, and peers.
- Publish IRR, ROA, and ASPA data that reflects the actual policy.
- Test import and export policies in a lab, including a final deny rule.
- Plan activation, monitoring, and rollback as a single change.
Important: The examples explain concepts and are not production-ready router configurations. Syntax, default behavior, and security features vary by platform and version.
Routing Fundamentals
Control Plane and Data Plane
The control plane learns and evaluates routes. BGP, OSPF, IS-IS, and static configuration populate the Routing Information Base (RIB). The data plane forwards packets according to the installed Forwarding Information Base (FIB). A route may be visible in BGP without being installed in the FIB because of policy, next-hop resolution, or the presence of a better route.
CIDR and Longest Prefix Match
A prefix describes a contiguous address range. /24 for IPv4 and /48 for IPv6 indicate the number of fixed network bits. The most specific matching route always wins during forwarding:
203.0.113.0/24covers the entire block;203.0.113.128/25is more specific;- a packet destined for
203.0.113.200therefore follows the/25, provided it is installed.
More-specific routes can support traffic engineering, but they increase the size of the global routing table and expand the potential impact of errors. Aggregation should remain the default.
Autonomous Systems
An autonomous system (AS) is a network operating under a common external routing policy. Its ASN identifies the system in the AS path. Public ASNs are assigned by the Regional Internet Registries; private ASNs are intended for isolated labs and internal handoffs and must not leak into the global routing table.
| Term | Meaning |
|---|---|
| eBGP | Route exchange between different autonomous systems |
| iBGP | Distribution of external routes within the same AS |
| Origin | The AS at the end of the AS_PATH that originates a prefix into BGP |
| Upstream | A provider that supplies connectivity to other networks |
| Peer | A network with which an operator exchanges its own and customer routes as an equal |
The protocol foundation is defined in RFC 4271.
BGP Session and Path Selection
From Idle to Established
A BGP session runs over TCP port 179. OPEN messages negotiate the ASN, Hold Time, and capabilities such as Multiprotocol BGP. KEEPALIVE messages keep the session active; UPDATE messages announce or withdraw routes. The Established state confirms only that the protocol exchange is operational—not that policy and reachability are correct.
Before activation, the following values must at minimum match on both sides:
- local and remote ASN;
- source and neighbor address;
- IPv4/IPv6 address families;
- multihop and TTL requirements;
- authentication, if agreed;
- expected prefixes, communities, and prefix limits.
Key Path Attributes
| Attribute | Operational Significance |
|---|---|
LOCAL_PREF |
Selects the preferred exit within the local AS; higher is usually better |
AS_PATH |
Supports loop detection and policy; a shorter path is only one selection factor |
NEXT_HOP |
Must be reachable through the routing table, or the path is unusable |
MED |
Signals a preference to a neighboring AS across multiple interconnections; comparability is limited |
| Communities | Tags that trigger documented policy actions |
| Large Communities | Fixed 32-bit form global:funktion:parameter, robust for modern ASNs |
The exact best-path decision sequence is vendor-specific. Therefore, verify not only the received route, but also the selected path and the routes actually exported to each neighbor.
Operational rule:
LOCAL_PREFreliably controls the preferred egress within your own AS. AS-path prepending and MED influence inbound traffic only indirectly and provide no guarantee of the desired result.
Address Planning and Announcements
A sound plan separates assignment, internal use, and global advertisement. Not every internally assigned subnet needs to be visible individually on the Internet.
Default-Free Zone (DFZ)
The Default-Free Zone is the part of the Internet where routers carry the global BGP table instead of relying only on a default route. bgp.cat marks a prefix as DFZ visible when it observes both a current direct-origin path and independent propagation. For prefixes without a direct feed, consensus from at least 80 percent of fresh, established full-table feeds is accepted instead. An isolated residual transit path is explicitly insufficient.
The indicator uses only bgp.cat collector session and route state no older than five minutes. It is recalculated immediately on BGP updates and every 30 seconds as a fallback. Registry, IRR, and RPKI data do not establish current global visibility.
Important: A router query may return the best covering route and therefore show only the default route. A local check must query the exact prefix in the BGP RIB.
Aggregate First
- Announce a stable aggregate route.
- Use more-specifics only for a documented purpose.
- Maintain a controlled origin for each announced prefix in the local routing table, commonly as a static discard/null route.
- Avoid blanket redistribution of connected, IGP, or third-party BGP routes.
- Maintain IPv4 and IPv6 as separate policies; a secure IPv4 configuration does not automatically protect IPv6.
In the global Internet, IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are commonly filtered. This is an operational convention, not a guarantee. Providers and peers define their own limits.
PA and PI
Provider Aggregatable (PA) space belongs to a provider’s address pool and can be aggregated by that provider. Changing providers generally requires renumbering. Provider Independent (PI) space is independent of the transit provider, but requires the holder to operate its own registry, routing, and security processes. The responsible RIR defines the applicable allocation policy. Suitable ASN, IPv4, and IPv6 services as well as limited resources are available under network solutions.
Order directly: 32-bit ASN + IPv6 /44 · 16-bit ASN + IPv6 /44 · IPv4 offers · IPv6 offers
Relationships and Routing Policy
BGP policy follows the relationship, not merely the existence of a session.
| Route Learned From | Export to Customers | Export to Peers | Export to Providers |
|---|---|---|---|
| Own prefixes | yes | yes | yes |
| Customers | yes | yes | yes |
| Peers | yes | no | no |
| Providers | yes | no | no |
This simplified valley-free model prevents many route leaks: a route learned from a provider or peer must not be offered to another provider or peer as if it were a transit route.
Default Reject
New eBGP sessions should accept or export no usable routes without an explicit policy. RFC 8212 defines this secure default behavior.
A robust policy includes:
- exact prefix lists for the operator’s own exports;
- customer-specific prefix and AS-path filters;
- RPKI Origin Validation;
- filters for the operator’s own, special-purpose, and invalid prefixes and ASNs;
- realistic prefix limits with warning thresholds;
- a final deny rule;
- documented communities instead of opaque side effects.
RIPE Database, IRR, and RPSL
The RIPE Database contains resource, contact, and routing-policy data. As an Internet Routing Registry (IRR), it provides information from which operators can generate filters. These objects document intent, but they do not replace router policy or cryptographic authorization.
Core Objects
| Object | Purpose |
|---|---|
mntner |
Defines who may modify other objects |
person / role |
Contact for individuals or enduring functions such as NOC and abuse handling |
organisation |
Associates resources and contacts with an organization |
aut-num |
Describes an AS and, optionally, its RPSL policy |
route / route6 |
Associates an IPv4/IPv6 prefix with its intended origin AS |
as-set |
Groups ASNs for customer cones and filter generation |
domain |
Delegates reverse DNS zones |
Role objects are preferable to personal addresses for long-lived functions. Maintainer rights should be granted only to trusted accounts; NOC and abuse contacts must remain reachable.
IRR Is Not RPKI
A route or route6 object helps providers generate filters, but it is not a cryptographic assertion. A ROA cryptographically authorizes the origin, but it does not describe a complete routing policy. In practice, both systems are used in parallel.
Useful tools include the RIPE Database, IRRexplorer, and bgpq4. Recursive AS-SETs must remain small, understandable, and current.
RPKI, ROAs, and Origin Validation
The Resource Public Key Infrastructure (RPKI) binds Internet number resources to certificates. A Route Origin Authorisation (ROA) specifies which ASN may announce a prefix and up to what prefix length.
The Three ROV States
| State | Meaning | Typical Treatment |
|---|---|---|
| Valid | The prefix, origin AS, and length are authorized by a ROA | accept and evaluate normally |
| Invalid | A covering ROA exists but does not authorize the ASN or length | reject after a controlled rollout |
| Not Found | No covering ROA provides a decision | do not treat as Invalid |
maxLength is an additional authorization, not a convenience setting. A ROA for 203.0.113.0/24, origin AS64512, and maxLength /24 permits only that exact prefix. An unnecessarily permissive maxLength authorizes additional more-specifics and therefore expands the attack surface.
Safe Rollout
- Inventory all legitimate prefix/origin combinations.
- Create ROAs that are as restrictive as practical.
- Verify publication and expiration with an independent tool.
- Initially monitor validation states without a drop policy.
- Correct legitimate Invalids.
- Reject Invalids in a controlled manner, and monitor validator freshness and RTR sessions.
RPKI validates the origin, not the complete AS path. Fundamentals and operational models are documented in RFC 6480, RFC 6811, and the RIPE NCC RPKI documentation.
ASPA and Route Leak Protection
A ROA answers: May AS X originate this prefix? An Autonomous System Provider Authorization (ASPA) answers: Which ASNs may act as transit providers for this customer AS? ASPA therefore extends Origin Validation with cryptographically verifiable information about provider relationships.
Status as of October 2026
The RIPE NCC supports signing ASPA objects in the RPKI Dashboard. However, the object profile and AS_PATH verification procedures remain IETF Internet-Drafts rather than final RFCs. Implementations and operating practices continue to evolve, so production decisions must follow the current specifications.
An ASPA contains:
- the Customer ASN (CAS) whose holder signs the object;
- the complete set of authorized Provider ASNs (PAS);
- for a transit-free AS, the designated provider value
AS 0.
What Belongs in the Provider List?
Include all actual transit providers, regardless of whether they carry only IPv4, only IPv6, or both. A non-transparent route server or complex relationship also belongs in the list when the neighboring AS actually performs a provider role. Ordinary customers, bilateral peers, and transparent IXP route servers are not providers and are not added automatically.
Operational risk: An incomplete ASPA can cause legitimate paths to appear Invalid to validating networks. A provider migration, backup transit activation, and the ASPA update must therefore be managed as one coordinated change.
Path Verification
For each AS adjacency, the ASPA data can conceptually yield Provider, Not Provider, or No Attestation. This produces the following path states:
| State | Interpretation |
|---|---|
| Valid | All relationships required for the verification direction are authorized |
| Invalid | At least one published ASPA contradicts the claimed provider relationship or proves a prohibited path form |
| Unknown | Data is missing, but there is no provable contradiction |
Invalid paths can indicate route leaks or manipulated AS paths. Unknown is expected while global deployment remains incomplete and must not be rejected wholesale as if it were Invalid. Verification also distinguishes whether a path was received from a customer/peer or from a provider; provider paths are assessed for a valley-free form across the up-ramp and down-ramp.
Authoritative sources are the current ASPA object profile, the current ASPA verification specification, and the RIPE NCC ASPA documentation.
BGP Roles and OTC
RFC 9234 defines BGP Roles and the transitive Only-To-Customer (OTC) attribute. Roles make the expected relationship of an eBGP session explicit; OTC helps prevent or detect violations of export policy. Strict role negotiation should be enabled on existing sessions only after coordination because conflicting roles can prevent the session from being established.
ASPA, Roles, and OTC do not replace filters. They are additional safeguards alongside exact export policy, prefix limits, IRR, ROAs, and monitoring.
Transit, Peering, and Route Servers
IP Transit
A transit provider supplies reachability to networks outside the operator’s own customer cone—as a default route, partial routes, or the full table. The choice affects memory requirements, convergence, and traffic engineering. Two sessions to the same router do not provide true redundancy if the circuit, site, or backbone can fail as a shared dependency. Virtual routers, BGP-enabled servers, and direct IX connectivity are grouped under compute and peering.
Deploy directly: Securebit Virtual Server · RWIX Enterprise VPS
Bilateral Peering
Peers typically exchange their own and customer routes without providing transit for provider- or peer-learned paths. Before establishing the session, coordinate ASNs, addresses, prefix counts, policy, communities, and contacts. PeeringDB serves as a public directory, but it does not replace direct operational coordination.
IXP Route Servers
A route server reduces the number of bilateral sessions. It relays routes between participants without normally being in the forwarding path. Verify in particular:
- whether your own ASN is handled correctly in the AS_PATH;
- which communities control exports;
- whether RPKI, IRR, and prefix limits are applied;
- whether direct sessions are appropriate for important paths;
- whether the route server operates transparently or non-transparently—also relevant to ASPA.
Secure Production Operations
Before Activation
- IPv4 and IPv6 policies have been validated separately.
- Import and export policies end with a deny rule.
- Export permits only approved own prefixes or explicitly delegated prefixes.
- IRR objects, ROAs, and ASPA reflect the intended operation.
- Prefix limits have appropriate warning and shutdown thresholds.
- Out-of-band access and operational contacts are working.
- A known-good configuration and specific rollback steps are ready.
- External monitoring is already open and active.
- A second person has reviewed the change where possible.
Session Protection
Depending on the platform and counterpart, TCP authentication, GTSM/TTL protection, ACLs for TCP/179, and BFD may be appropriate. BFD accelerates failure detection, but overly aggressive timers can themselves cause instability. None of these mechanisms replaces route filtering.
After Activation
Verify session state, received and advertised route counts, selected paths, RPKI states, and the external view. Explicitly inspect the Adj-RIB-Out, or the routes advertised per neighbor; the local routing table alone does not prove that exports are correct.
For general best practices, see RFC 7454, the NLNOG BGP Filter Guide, and the MANRS Actions.
Monitoring and Troubleshooting
Effective monitoring combines local telemetry with independent observation points.
| Symptom | Check First | Common Cause |
|---|---|---|
| Session remains Idle/Active | TCP/179, source address, ASN, TTL, authentication | Reachability or parameter mismatch |
| Established, but no routes | Address Family, import policy, prefix limit | AFI/SAFI not enabled or all routes filtered |
| Route received, not installed | NEXT_HOP, RPKI, LOCAL_PREF, better route | Next hop unreachable or path not selected as best |
| Own prefix not visible externally | Adj-RIB-Out, IRR/ROA, provider filter | Export missing or authorization mismatch |
| Only some networks unreachable | More-specifics, return path, RPKI, MTU | Asymmetric policy or filtered prefix length |
| Unexpected AS path | Leak, route server, prepends, aggregation | Incorrect export or incomplete visibility |
Use the bgp.cat Looking Glass, Live Events, MRT Downloads, RIPEstat, RIPE BGPlay, and additional external looking glasses. At minimum, alert on session changes, prefix counts, unexpected origins, RPKI Invalid, ASPA Invalid, new more-specifics, and loss of visibility.
During a Route Leak
- Stop the incorrect export at its source; if necessary, disable the affected address family or session.
- Avoid unrelated parallel changes.
- Confirm withdrawals through external collectors.
- Notify affected providers and peers with the ASN, prefixes, start time, and remediation taken.
- Preserve logs, the configuration diff, and timestamps.
- Correct the policy and, where necessary, IRR, ROA, or ASPA data.
- Add a reproducible lab test and document the cause and preventive action.
Reverse DNS and Operational Data
Reverse DNS maps IP addresses to names. IPv4 uses in-addr.arpa; IPv6 uses the nibble-based ip6.arpa zone. Delegations must point to authoritative name servers; forward and reverse records should match where applications expect this.
Also keep NOC, abuse, and peering contacts current. Outdated contact data prolongs incidents. PeeringDB should reflect actual locations, policy, prefix counts, and contact roles; sensitive personal data does not belong in public role records.
Lab and Readiness Check
Your first BGP experience should not take place on the public Internet. A suitable lab uses private ASNs, documentation prefixes, and a separate management path. BGP Labs, Containerlab, or FRRouting can be used to build a reproducible topology.
At minimum, practice:
- dual-stack eBGP with explicit import and export policy;
- two providers and selection using LOCAL_PREF;
- communities and controlled prepending;
- prefix limits and their restart behavior;
- an intentionally generated route leak that is blocked by the export filter;
- session failure, Graceful Shutdown, and rollback;
- verification of the routes actually sent to each neighbor.
DN42 is then a useful private practice network, but it must remain strictly separated from the public routing table.
You are ready for a controlled activation when you can explain every accepted and exported route, demonstrably block a leak, roll back through out-of-band access, and verify your announcements from multiple external networks.
References and Further Learning
- RIPE NCC Academy — routing, RPKI, and registry operations
- APNIC Academy — routing fundamentals, BGP, and MANRS
- DE-CIX Academy — peering and interconnection
- Interconnection Academy — technical and commercial aspects of interconnection
- BGP for networks who peer — open BGP textbook
- Team Cymru Bogon Reference — current special-purpose and bogon data
This documentation provides a robust starting point, not a universal policy. Agreements with neighboring networks, current standards, and the behavior of the deployed router software remain authoritative.
Guide Overview
BGP connects autonomous systems, but it does not determine which route makes business or technical sense. BGP carries policy. An established session is therefore only the beginning; secure operation requires explicit import and export rules, accurate registry data, and independent monitoring.
This guide takes you from routing fundamentals to controlled production operations. It is intended for operators of their own ASN, technical decision-makers, and teams seeking to manage routing risks effectively.
Recommended Sequence
- Understand routing, CIDR, and BGP path selection.
- Document the addressing plan and relationships with providers, customers, and peers.
- Publish IRR, ROA, and ASPA data that reflects the actual policy.
- Test import and export policies in a lab, including a final deny rule.
- Plan activation, monitoring, and rollback as a single change.
Important: The examples explain concepts and are not production-ready router configurations. Syntax, default behavior, and security features vary by platform and version.
Routing Fundamentals
Control Plane and Data Plane
The control plane learns and evaluates routes. BGP, OSPF, IS-IS, and static configuration populate the Routing Information Base (RIB). The data plane forwards packets according to the installed Forwarding Information Base (FIB). A route may be visible in BGP without being installed in the FIB because of policy, next-hop resolution, or the presence of a better route.
CIDR and Longest Prefix Match
A prefix describes a contiguous address range. /24 for IPv4 and /48 for IPv6 indicate the number of fixed network bits. The most specific matching route always wins during forwarding:
203.0.113.0/24covers the entire block;203.0.113.128/25is more specific;- a packet destined for
203.0.113.200therefore follows the/25, provided it is installed.
More-specific routes can support traffic engineering, but they increase the size of the global routing table and expand the potential impact of errors. Aggregation should remain the default.
Autonomous Systems
An autonomous system (AS) is a network operating under a common external routing policy. Its ASN identifies the system in the AS path. Public ASNs are assigned by the Regional Internet Registries; private ASNs are intended for isolated labs and internal handoffs and must not leak into the global routing table.
| Term | Meaning |
|---|---|
| eBGP | Route exchange between different autonomous systems |
| iBGP | Distribution of external routes within the same AS |
| Origin | The AS at the end of the AS_PATH that originates a prefix into BGP |
| Upstream | A provider that supplies connectivity to other networks |
| Peer | A network with which an operator exchanges its own and customer routes as an equal |
The protocol foundation is defined in RFC 4271.
BGP Session and Path Selection
From Idle to Established
A BGP session runs over TCP port 179. OPEN messages negotiate the ASN, Hold Time, and capabilities such as Multiprotocol BGP. KEEPALIVE messages keep the session active; UPDATE messages announce or withdraw routes. The Established state confirms only that the protocol exchange is operational—not that policy and reachability are correct.
Before activation, the following values must at minimum match on both sides:
- local and remote ASN;
- source and neighbor address;
- IPv4/IPv6 address families;
- multihop and TTL requirements;
- authentication, if agreed;
- expected prefixes, communities, and prefix limits.
Key Path Attributes
| Attribute | Operational Significance |
|---|---|
LOCAL_PREF |
Selects the preferred exit within the local AS; higher is usually better |
AS_PATH |
Supports loop detection and policy; a shorter path is only one selection factor |
NEXT_HOP |
Must be reachable through the routing table, or the path is unusable |
MED |
Signals a preference to a neighboring AS across multiple interconnections; comparability is limited |
| Communities | Tags that trigger documented policy actions |
| Large Communities | Fixed 32-bit form global:funktion:parameter, robust for modern ASNs |
The exact best-path decision sequence is vendor-specific. Therefore, verify not only the received route, but also the selected path and the routes actually exported to each neighbor.
Operational rule:
LOCAL_PREFreliably controls the preferred egress within your own AS. AS-path prepending and MED influence inbound traffic only indirectly and provide no guarantee of the desired result.
Address Planning and Announcements
A sound plan separates assignment, internal use, and global advertisement. Not every internally assigned subnet needs to be visible individually on the Internet.
Default-Free Zone (DFZ)
The Default-Free Zone is the part of the Internet where routers carry the global BGP table instead of relying only on a default route. bgp.cat marks a prefix as DFZ visible when it observes both a current direct-origin path and independent propagation. For prefixes without a direct feed, consensus from at least 80 percent of fresh, established full-table feeds is accepted instead. An isolated residual transit path is explicitly insufficient.
The indicator uses only bgp.cat collector session and route state no older than five minutes. It is recalculated immediately on BGP updates and every 30 seconds as a fallback. Registry, IRR, and RPKI data do not establish current global visibility.
Important: A router query may return the best covering route and therefore show only the default route. A local check must query the exact prefix in the BGP RIB.
Aggregate First
- Announce a stable aggregate route.
- Use more-specifics only for a documented purpose.
- Maintain a controlled origin for each announced prefix in the local routing table, commonly as a static discard/null route.
- Avoid blanket redistribution of connected, IGP, or third-party BGP routes.
- Maintain IPv4 and IPv6 as separate policies; a secure IPv4 configuration does not automatically protect IPv6.
In the global Internet, IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are commonly filtered. This is an operational convention, not a guarantee. Providers and peers define their own limits.
PA and PI
Provider Aggregatable (PA) space belongs to a provider’s address pool and can be aggregated by that provider. Changing providers generally requires renumbering. Provider Independent (PI) space is independent of the transit provider, but requires the holder to operate its own registry, routing, and security processes. The responsible RIR defines the applicable allocation policy. Suitable ASN, IPv4, and IPv6 services as well as limited resources are available under network solutions.
Order directly: 32-bit ASN + IPv6 /44 · 16-bit ASN + IPv6 /44 · IPv4 offers · IPv6 offers
Relationships and Routing Policy
BGP policy follows the relationship, not merely the existence of a session.
| Route Learned From | Export to Customers | Export to Peers | Export to Providers |
|---|---|---|---|
| Own prefixes | yes | yes | yes |
| Customers | yes | yes | yes |
| Peers | yes | no | no |
| Providers | yes | no | no |
This simplified valley-free model prevents many route leaks: a route learned from a provider or peer must not be offered to another provider or peer as if it were a transit route.
Default Reject
New eBGP sessions should accept or export no usable routes without an explicit policy. RFC 8212 defines this secure default behavior.
A robust policy includes:
- exact prefix lists for the operator’s own exports;
- customer-specific prefix and AS-path filters;
- RPKI Origin Validation;
- filters for the operator’s own, special-purpose, and invalid prefixes and ASNs;
- realistic prefix limits with warning thresholds;
- a final deny rule;
- documented communities instead of opaque side effects.
RIPE Database, IRR, and RPSL
The RIPE Database contains resource, contact, and routing-policy data. As an Internet Routing Registry (IRR), it provides information from which operators can generate filters. These objects document intent, but they do not replace router policy or cryptographic authorization.
Core Objects
| Object | Purpose |
|---|---|
mntner |
Defines who may modify other objects |
person / role |
Contact for individuals or enduring functions such as NOC and abuse handling |
organisation |
Associates resources and contacts with an organization |
aut-num |
Describes an AS and, optionally, its RPSL policy |
route / route6 |
Associates an IPv4/IPv6 prefix with its intended origin AS |
as-set |
Groups ASNs for customer cones and filter generation |
domain |
Delegates reverse DNS zones |
Role objects are preferable to personal addresses for long-lived functions. Maintainer rights should be granted only to trusted accounts; NOC and abuse contacts must remain reachable.
IRR Is Not RPKI
A route or route6 object helps providers generate filters, but it is not a cryptographic assertion. A ROA cryptographically authorizes the origin, but it does not describe a complete routing policy. In practice, both systems are used in parallel.
Useful tools include the RIPE Database, IRRexplorer, and bgpq4. Recursive AS-SETs must remain small, understandable, and current.
RPKI, ROAs, and Origin Validation
The Resource Public Key Infrastructure (RPKI) binds Internet number resources to certificates. A Route Origin Authorisation (ROA) specifies which ASN may announce a prefix and up to what prefix length.
The Three ROV States
| State | Meaning | Typical Treatment |
|---|---|---|
| Valid | The prefix, origin AS, and length are authorized by a ROA | accept and evaluate normally |
| Invalid | A covering ROA exists but does not authorize the ASN or length | reject after a controlled rollout |
| Not Found | No covering ROA provides a decision | do not treat as Invalid |
maxLength is an additional authorization, not a convenience setting. A ROA for 203.0.113.0/24, origin AS64512, and maxLength /24 permits only that exact prefix. An unnecessarily permissive maxLength authorizes additional more-specifics and therefore expands the attack surface.
Safe Rollout
- Inventory all legitimate prefix/origin combinations.
- Create ROAs that are as restrictive as practical.
- Verify publication and expiration with an independent tool.
- Initially monitor validation states without a drop policy.
- Correct legitimate Invalids.
- Reject Invalids in a controlled manner, and monitor validator freshness and RTR sessions.
RPKI validates the origin, not the complete AS path. Fundamentals and operational models are documented in RFC 6480, RFC 6811, and the RIPE NCC RPKI documentation.
ASPA and Route Leak Protection
A ROA answers: May AS X originate this prefix? An Autonomous System Provider Authorization (ASPA) answers: Which ASNs may act as transit providers for this customer AS? ASPA therefore extends Origin Validation with cryptographically verifiable information about provider relationships.
Status as of October 2026
The RIPE NCC supports signing ASPA objects in the RPKI Dashboard. However, the object profile and AS_PATH verification procedures remain IETF Internet-Drafts rather than final RFCs. Implementations and operating practices continue to evolve, so production decisions must follow the current specifications.
An ASPA contains:
- the Customer ASN (CAS) whose holder signs the object;
- the complete set of authorized Provider ASNs (PAS);
- for a transit-free AS, the designated provider value
AS 0.
What Belongs in the Provider List?
Include all actual transit providers, regardless of whether they carry only IPv4, only IPv6, or both. A non-transparent route server or complex relationship also belongs in the list when the neighboring AS actually performs a provider role. Ordinary customers, bilateral peers, and transparent IXP route servers are not providers and are not added automatically.
Operational risk: An incomplete ASPA can cause legitimate paths to appear Invalid to validating networks. A provider migration, backup transit activation, and the ASPA update must therefore be managed as one coordinated change.
Path Verification
For each AS adjacency, the ASPA data can conceptually yield Provider, Not Provider, or No Attestation. This produces the following path states:
| State | Interpretation |
|---|---|
| Valid | All relationships required for the verification direction are authorized |
| Invalid | At least one published ASPA contradicts the claimed provider relationship or proves a prohibited path form |
| Unknown | Data is missing, but there is no provable contradiction |
Invalid paths can indicate route leaks or manipulated AS paths. Unknown is expected while global deployment remains incomplete and must not be rejected wholesale as if it were Invalid. Verification also distinguishes whether a path was received from a customer/peer or from a provider; provider paths are assessed for a valley-free form across the up-ramp and down-ramp.
Authoritative sources are the current ASPA object profile, the current ASPA verification specification, and the RIPE NCC ASPA documentation.
BGP Roles and OTC
RFC 9234 defines BGP Roles and the transitive Only-To-Customer (OTC) attribute. Roles make the expected relationship of an eBGP session explicit; OTC helps prevent or detect violations of export policy. Strict role negotiation should be enabled on existing sessions only after coordination because conflicting roles can prevent the session from being established.
ASPA, Roles, and OTC do not replace filters. They are additional safeguards alongside exact export policy, prefix limits, IRR, ROAs, and monitoring.
Transit, Peering, and Route Servers
IP Transit
A transit provider supplies reachability to networks outside the operator’s own customer cone—as a default route, partial routes, or the full table. The choice affects memory requirements, convergence, and traffic engineering. Two sessions to the same router do not provide true redundancy if the circuit, site, or backbone can fail as a shared dependency. Virtual routers, BGP-enabled servers, and direct IX connectivity are grouped under compute and peering.
Deploy directly: Securebit Virtual Server · RWIX Enterprise VPS
Bilateral Peering
Peers typically exchange their own and customer routes without providing transit for provider- or peer-learned paths. Before establishing the session, coordinate ASNs, addresses, prefix counts, policy, communities, and contacts. PeeringDB serves as a public directory, but it does not replace direct operational coordination.
IXP Route Servers
A route server reduces the number of bilateral sessions. It relays routes between participants without normally being in the forwarding path. Verify in particular:
- whether your own ASN is handled correctly in the AS_PATH;
- which communities control exports;
- whether RPKI, IRR, and prefix limits are applied;
- whether direct sessions are appropriate for important paths;
- whether the route server operates transparently or non-transparently—also relevant to ASPA.
Secure Production Operations
Before Activation
- IPv4 and IPv6 policies have been validated separately.
- Import and export policies end with a deny rule.
- Export permits only approved own prefixes or explicitly delegated prefixes.
- IRR objects, ROAs, and ASPA reflect the intended operation.
- Prefix limits have appropriate warning and shutdown thresholds.
- Out-of-band access and operational contacts are working.
- A known-good configuration and specific rollback steps are ready.
- External monitoring is already open and active.
- A second person has reviewed the change where possible.
Session Protection
Depending on the platform and counterpart, TCP authentication, GTSM/TTL protection, ACLs for TCP/179, and BFD may be appropriate. BFD accelerates failure detection, but overly aggressive timers can themselves cause instability. None of these mechanisms replaces route filtering.
After Activation
Verify session state, received and advertised route counts, selected paths, RPKI states, and the external view. Explicitly inspect the Adj-RIB-Out, or the routes advertised per neighbor; the local routing table alone does not prove that exports are correct.
For general best practices, see RFC 7454, the NLNOG BGP Filter Guide, and the MANRS Actions.
Monitoring and Troubleshooting
Effective monitoring combines local telemetry with independent observation points.
| Symptom | Check First | Common Cause |
|---|---|---|
| Session remains Idle/Active | TCP/179, source address, ASN, TTL, authentication | Reachability or parameter mismatch |
| Established, but no routes | Address Family, import policy, prefix limit | AFI/SAFI not enabled or all routes filtered |
| Route received, not installed | NEXT_HOP, RPKI, LOCAL_PREF, better route | Next hop unreachable or path not selected as best |
| Own prefix not visible externally | Adj-RIB-Out, IRR/ROA, provider filter | Export missing or authorization mismatch |
| Only some networks unreachable | More-specifics, return path, RPKI, MTU | Asymmetric policy or filtered prefix length |
| Unexpected AS path | Leak, route server, prepends, aggregation | Incorrect export or incomplete visibility |
Use the bgp.cat Looking Glass, Live Events, MRT Downloads, RIPEstat, RIPE BGPlay, and additional external looking glasses. At minimum, alert on session changes, prefix counts, unexpected origins, RPKI Invalid, ASPA Invalid, new more-specifics, and loss of visibility.
During a Route Leak
- Stop the incorrect export at its source; if necessary, disable the affected address family or session.
- Avoid unrelated parallel changes.
- Confirm withdrawals through external collectors.
- Notify affected providers and peers with the ASN, prefixes, start time, and remediation taken.
- Preserve logs, the configuration diff, and timestamps.
- Correct the policy and, where necessary, IRR, ROA, or ASPA data.
- Add a reproducible lab test and document the cause and preventive action.
Reverse DNS and Operational Data
Reverse DNS maps IP addresses to names. IPv4 uses in-addr.arpa; IPv6 uses the nibble-based ip6.arpa zone. Delegations must point to authoritative name servers; forward and reverse records should match where applications expect this.
Also keep NOC, abuse, and peering contacts current. Outdated contact data prolongs incidents. PeeringDB should reflect actual locations, policy, prefix counts, and contact roles; sensitive personal data does not belong in public role records.
Lab and Readiness Check
Your first BGP experience should not take place on the public Internet. A suitable lab uses private ASNs, documentation prefixes, and a separate management path. BGP Labs, Containerlab, or FRRouting can be used to build a reproducible topology.
At minimum, practice:
- dual-stack eBGP with explicit import and export policy;
- two providers and selection using LOCAL_PREF;
- communities and controlled prepending;
- prefix limits and their restart behavior;
- an intentionally generated route leak that is blocked by the export filter;
- session failure, Graceful Shutdown, and rollback;
- verification of the routes actually sent to each neighbor.
DN42 is then a useful private practice network, but it must remain strictly separated from the public routing table.
You are ready for a controlled activation when you can explain every accepted and exported route, demonstrably block a leak, roll back through out-of-band access, and verify your announcements from multiple external networks.
References and Further Learning
- RIPE NCC Academy — routing, RPKI, and registry operations
- APNIC Academy — routing fundamentals, BGP, and MANRS
- DE-CIX Academy — peering and interconnection
- Interconnection Academy — technical and commercial aspects of interconnection
- BGP for networks who peer — open BGP textbook
- Team Cymru Bogon Reference — current special-purpose and bogon data
This documentation provides a robust starting point, not a universal policy. Agreements with neighboring networks, current standards, and the behavior of the deployed router software remain authoritative.