Externes Routing mit BGP: Wie das Internet wirklich funktioniert

Warum externes Routing nicht wie internes Routing funktioniert

In meinen Seminaren behandele ich das Thema Routing meist mit der gleichsamen Betrachtung interner Routingprotokollen wie OSPF und – historisch bedingt – gelegentlich auch noch mit RIP. Sobald die Teilnehmenden diese Mechanismen verstanden haben, stellt sich fast zwangsläufig eine zentrale Frage: Wenn das intern so funktioniert, warum nutzt das Internet nicht dieselben Prinzipien? Genau an diesem Punkt lohnt sich ein bewusster Perspektivwechsel.

Internes Routing: permanente Kommunikation als Stabilitätsprinzip

Interne Routingprotokolle gehen von einer hohen Dynamik aus. Links können ausfallen, Bandbreiten sich ändern oder Geräte kurzfristig verschwinden. Deshalb kommunizieren Router regelmäßig miteinander. Diese Kommunikation dient nicht nur dem Austausch von Routinginformationen, sondern auch als permanenter Verfügbarkeitsnachweis.

Bleibt dieser aus, reagieren die Router sofort:

OSPF berechnet neue Pfade vergleichsweise schnell
RIP reagiert langsamer, aber nach dem gleichen Grundprinzip

Dieses Verhalten ist sinnvoll, denn interne Netze unterliegen ständigen Veränderungen und stehen unter einheitlicher administrativer Kontrolle.

Externes Routing: Stabilität durch Zurückhaltung

Im globalen Kontext verfolgen externe Routingprotokolle, wie das Border Gateway Protocol (BGP), einen völlig anderen Ansatz. Hier gehen wir nicht von permanenter Veränderung aus, sondern von langfristig stabilen Kommunikationspfaden zwischen autonomen Systemen. Deshalb wird nicht ständig kommuniziert, sondern nur dann, wenn sich tatsächlich etwas ändert.

BGP arbeitet bewusst ruhig:

keine periodischen Updates
Kommunikation nur bei relevanten Änderungen
Fokus auf kontrollierte Stabilität statt schnelle Reaktion

Dieser Ansatz schützt das Internet vor unnötiger Dynamik und verhindert Kettenreaktionen auf globaler Ebene. Externes Routing ist damit kein Optimierungswerkzeug, sondern ein Stabilisierungsmechanismus für ein weltweites Netzwerk unabhängiger Akteure.

Autonome Systeme als Fundament des Internet-Routings

Um externes Routing wirklich zu verstehen, müssen wir einen Schritt zurückgehen und die organisatorische Grundlage des Internets betrachten. Technisch betrachtet besteht das Internet nicht aus einem einzigen großen Netzwerk, sondern aus tausenden eigenständigen Netzen, die miteinander verbunden sind. Genau hier kommen autonome Systeme ins Spiel.

Was ist ein autonomes System?

Ein autonomes System ist ein zusammenhängendes IP-Netz oder eine Gruppe von Netzen, die unter einer gemeinsamen administrativen Kontrolle stehen. Diese Kontrolle umfasst nicht nur den technischen Betrieb, sondern vor allem auch Routing-Entscheidungen und Richtlinien. Jedes autonome System entscheidet selbst, welche Routen es akzeptiert, weiterleitet oder verwirft.

Damit bildet ein autonomes System eine klare Grenze:

technisch
organisatorisch
und politisch

Diese Trennung ist essenziell, denn sie schafft Verantwortung und Verlässlichkeit in einem global verteilten Netzwerk.

Warum autonome Systeme notwendig sind

Ohne autonome Systeme müsste das Internet wie ein internes Netzwerk funktionieren. Alle Router würden denselben Regeln folgen, sich gegenseitig vollständig vertrauen und permanent Informationen austauschen. Genau das ist im globalen Maßstab weder realistisch noch wünschenswert.

Autonome Systeme ermöglichen stattdessen:

klare Zuständigkeiten für Netzbereiche
unabhängige technische Entscheidungen
individuelle Routing Policies
wirtschaftliche Modelle wie Peering und Transit

Dadurch bleibt das Internet skalierbar, auch wenn neue Netze hinzukommen oder bestehende Strukturen wachsen.

Routing Policies als zentrales Element

Innerhalb eines autonomen Systems entscheiden technische Metriken. Zwischen autonomen Systemen hingegen bestimmen Policies, welche Wege genutzt werden dürfen. Diese Policies berücksichtigen:

vertragliche Vereinbarungen
Sicherheitsaspekte
wirtschaftliche Interessen

Externes Routing ist damit weniger eine Frage der Effizienz, sondern eine Frage der Kontrolle und Stabilität. Genau deshalb benötigt das Internet ein Routingprotokoll, das diese Unterschiede respektiert und abbilden kann.

Exkurs: Die historische Entwicklung autonomer Systeme

Wie organisatorische Grenzen das Wachstum des Internets ermöglichten

Die Idee autonomer Systeme entstand nicht aus theoretischen Überlegungen, sondern aus einer sehr praktischen Notwendigkeit. In den frühen Phasen des Internets war das Netz überschaubar, die Anzahl der beteiligten Organisationen gering und die Routing-Struktur vergleichsweise einfach. Doch mit zunehmender Verbreitung änderte sich diese Situation grundlegend.

Wer diesen frühen Abschnitt der Internetgeschichte vertiefen möchte, findet dazu eine ausführliche Einordnung im Beitrag ARPANET, TCP/IP und das World Wide Web – Wie das Internet die Welt vernetzte hier im Blog.

Vom Forschungsnetz zum globalen Verbund

In den Anfangsjahren des Internets dominierten universitäre und staatliche Einrichtungen. Routing erfolgte weitgehend koordiniert und auf Vertrauensbasis. Mit dem Eintritt kommerzieller Anbieter, nationaler Netze und internationaler Provider wurde jedoch schnell klar, dass ein zentrales Routing-Modell nicht skalierbar war.

Unterschiedliche Betreiber verfolgten unterschiedliche Ziele:

technische Stabilität
wirtschaftliche Interessen
nationale und organisatorische Anforderungen

Damit entstand der Bedarf, Netze logisch voneinander abzugrenzen, ohne ihre physische Verbindung aufzugeben.

Einführung autonomer Systeme und AS-Nummern

Autonome Systeme schufen genau diese Trennung. Jedes Netz erhielt eine eindeutige Autonomous System Number (ASN), die es im globalen Routing identifizierbar machte. Diese Nummern sind keine rein technischen Kennzeichen, sondern Ausdruck administrativer Verantwortung.

Die Vergabe der AS-Nummern folgt bis heute klaren Regeln und wird zentral durch die Internet Assigned Numbers Authority (IANA) koordiniert und durch die angebundenen Regional Internet Registries (RIRs) organisiert. Dadurch bleibt sichergestellt, dass:

jedes autonome System eindeutig identifizierbar ist
Routing-Entscheidungen nachvollziehbar bleiben
globale Kollisionen vermieden werden

Diese Struktur bildete die Grundlage für ein verlässliches externes Routing.

Autonome Systeme als Voraussetzung für externes Routing

Mit der Einführung autonomer Systeme wandelte sich das Internet von einem technischen Experiment zu einer föderierten Infrastruktur. Netze konnten nun unabhängig betrieben werden und dennoch kontrolliert miteinander kommunizieren. Erst dadurch wurde es möglich, Routing-Policies einzuführen, Verantwortlichkeiten zu definieren und das Wachstum des Internets langfristig abzusichern.

Autonome Systeme sind damit nicht nur ein technisches Konzept, sondern ein organisatorisches Fundament, ohne das externes Routing – und damit das Internet in seiner heutigen Form – nicht denkbar wäre.

Frühe externe Routingprotokolle und ihre Grenzen

Nachdem autonome Systeme als organisatorisches Fundament etabliert waren, stellte sich zwangsläufig die nächste Frage: Wie lassen sich diese autonomen Netze miteinander verbinden? In den frühen Jahren des Internets entstanden dafür erste externe Routingprotokolle. Diese waren jedoch stark von den damaligen Netzstrukturen geprägt – und genau darin lag ihre spätere Begrenzung.

Gateway-to-Gateway Protocol und Exterior Gateway Protocol

Zu den frühen Ansätzen zählten unter anderem das Gateway-to-Gateway Protocol (1982) und später das Exterior Gateway Protocol (um 1985). Beide verfolgten das Ziel, Routing-Informationen zwischen klar abgegrenzten Netzen auszutauschen. Dabei gingen sie von einer vergleichsweise einfachen, hierarchischen Internetstruktur aus.

Das Internet war zu dieser Zeit noch stark baumartig aufgebaut. Zentrale Knoten verbanden untergeordnete Netze, und die Anzahl der beteiligten Organisationen blieb überschaubar. Unter diesen Bedingungen funktionierten einfache externe Routingmechanismen ausreichend gut.

Fehlende Skalierbarkeit und fehlende Policy-Steuerung

Mit dem Wachstum des Internets traten jedoch grundlegende Probleme zutage. Die frühen Protokolle konnten weder mit der steigenden Anzahl autonomer Systeme noch mit deren zunehmender Vernetzung umgehen. Vor allem fehlte ein Mechanismus, um Routing-Entscheidungen gezielt zu steuern.

Die Protokolle kannten:

keine ausgereiften Routing Policies
keine saubere Trennung von technischer Erreichbarkeit und gewünschter Pfadwahl
keine ausreichenden Schutzmechanismen gegen Instabilität

Damit wurden sie zunehmend zum Risiko für die Stabilität des Gesamtnetzes.

Warum diese Ansätze scheitern mussten

Die frühen externen Routingprotokolle waren für ein Internet gedacht, das es so nicht mehr gab. Sie gingen von Kooperation, zentraler Struktur und begrenzter Dynamik aus. Mit der Kommerzialisierung und Globalisierung des Internets verloren diese Annahmen ihre Gültigkeit.

Genau aus diesen Grenzen heraus entstand der Bedarf nach einem neuen Ansatz – einem Protokoll, das Skalierung, Policy-Steuerung und Stabilität von Beginn an berücksichtigt. Dieser Bedarf ebnete den Weg für das Border Gateway Protocol.

Exkurs: Cisco Systems und die Professionalisierung des Internet-Routings

Wie Routing und Switching gemeinsam das moderne Netz formten

Die Entwicklung externer Routingprotokolle lässt sich nicht losgelöst von der zugrunde liegenden Netzwerkinfrastruktur betrachten. Während frühe Internetarchitekturen stark akademisch geprägt waren, änderte sich dieses Bild ab Mitte der 1980er- und insbesondere in den 1990er-Jahren grundlegend. Eine zentrale Rolle spielte dabei Cisco Systems, das früh erkannte, dass Routing allein nicht ausreichen würde, um wachsende Netze effizient zu betreiben.

Vom Campus-Problem zum Routergeschäft

Cisco entstand aus einem sehr konkreten praktischen Bedarf heraus. An der Stanford University mussten unterschiedliche, zuvor isolierte Netzwerke miteinander verbunden werden. Die Lösung war ein dediziertes Gerät, das Pakete zwischen diesen Netzen weiterleiten konnte: der Router.

Was zunächst als akademisches Hilfsmittel begann, entwickelte sich rasch zu einem marktfähigen Produkt. Mit dem Verkauf der ersten Router an Universitäten und Forschungseinrichtungen etablierte Cisco ein Geschäftsmodell, das den Nerv der Zeit traf. Netze wuchsen, wurden heterogener und benötigten verlässliche Kopplungspunkte.

Die Switch-Revolution der 1990er-Jahre

Mit dem Wachstum lokaler Netze änderten sich jedoch auch deren Anforderungen. In den frühen LANs waren Router allgegenwärtig, da sie sowohl Segmentierung als auch Weiterleitung übernahmen. Mit steigenden Datenraten und wachsendem Verkehrsaufkommen erwies sich dieses Modell als ineffizient.

In den 1990er-Jahren setzte daher eine grundlegende Verschiebung ein: Switches übernahmen die Aufgabe der schnellen Paketvermittlung im lokalen Netz, während Router zunehmend an den Rand der Netzwerke rückten. Dort übernahmen sie die Kopplung unterschiedlicher Segmente, Netze und Organisationen.

Cisco erkannte diese Entwicklung frühzeitig und traf eine strategische Entscheidung: Mit der Übernahme von Kalpana setzte das Unternehmen bewusst auf Ethernet-Switching als Schlüsseltechnologie. Diese Entscheidung erwies sich als richtungsweisend und prägte die Architektur moderner LANs nachhaltig.

Routing und Switching als arbeitsteiliges Modell

Aus dieser Entwicklung entstand ein bis heute gültiges Architekturprinzip:

Switching sorgt für schnelle, effiziente Weiterleitung innerhalb lokaler Netze
Routing übernimmt die kontrollierte Kopplung von Netzen, Standorten und Organisationen

Router verschwanden nicht, sie veränderten ihre Rolle. Sie wurden zu strategischen Knotenpunkten – technisch anspruchsvoller, softwaregetriebener und zunehmend policy-orientiert.

Bedeutung von Switching im WAN-Kontext

Auch im WAN-Bereich gewann Switching an Bedeutung. Technologien wie MPLS (Multiprotocol Label Switching) zeigen, dass moderne Weitverkehrsnetze längst nicht mehr rein paketvermittelnd im klassischen IP-Sinn arbeiten. Label-basiertes Switching ermöglicht dort:

effiziente Pfadsteuerung
logische Trennung von Verkehrsströmen
skalierbare Service-Architekturen

Routingprotokolle wie BGP liefern in diesen Szenarien die Erreichbarkeits- und Policy-Informationen, während das eigentliche Transportnetz stark switching-orientiert arbeitet.

Infrastruktur als Voraussetzung für Protokollinnovation

Diese arbeitsteilige Entwicklung war eine zentrale Voraussetzung für die Entstehung moderner externer Routingprotokolle. Ohne leistungsfähige Routerplattformen am Netzrand und hochskalierende Switching-Infrastrukturen im Kern hätte sich ein bewusst konservatives, policybasiertes Protokoll wie BGP kaum durchsetzen können.

Cisco trug damit nicht nur zur Verbreitung von Routingtechnologie bei, sondern prägte auch die architektonische Trennung von Transport und Steuerung, die das Internet bis heute stabil hält.

Der Übergang von experimentellen Netzwerken zu einer globalen Infrastruktur war somit nicht nur eine Frage von Protokollen, sondern ebenso eine Frage von Hardware, Architektur und strategischen Technologieentscheidungen.

Die Entstehung von BGP – Lehren aus EGP

Die Grenzen früher externer Routingprotokolle waren kein theoretisches Problem, sondern wurden im laufenden Betrieb immer deutlicher spürbar. Mit der wachsenden Zahl autonomer Systeme, neuen kommerziellen Akteuren und einer zunehmenden Vernetzung verlor das Internet jene Eigenschaften, von denen frühe Protokolle wie EGP stillschweigend ausgegangen waren. Genau aus diesem Spannungsfeld heraus entstand das Border Gateway Protocol.

Vom Topologie-Denken zum Policy-Denken

Frühe externe Routingansätze versuchten, das Internet wie ein strukturiertes Gesamtnetz zu behandeln. Sie gingen davon aus, dass sich eine stabile, möglichst optimale Topologie beschreiben lässt. Doch diese Annahme erwies sich als nicht tragfähig. Autonome Systeme wollten – und mussten – selbst entscheiden, welche Routen sie akzeptieren, bevorzugen oder weitergeben.

BGP brach bewusst mit diesem Ansatz. Anstatt eine globale Topologie abzubilden, konzentrierte sich das Protokoll darauf, Pfadinformationen inklusive Kontext weiterzugeben. Damit rückten Richtlinien, nicht Metriken, in den Mittelpunkt der Routingentscheidung.

Das Two Napkin Protocol – Pragmatismus statt formaler Perfektion

Die grundlegende Idee hinter BGP entstand nicht in einem formalen Standardisierungsgremium, sondern in einem sehr pragmatischen Kontext. Im Jahr 1989 diskutierten Kirk Lougheed, Len Bosack und Yakov Rekhter über die wachsenden Probleme des bestehenden externen Routings.

Die zentrale Frage lautete nicht: Wie sieht das perfekte Routingprotokoll aus? Sondern: Was funktioniert im realen Internet – mit all seinen organisatorischen und politischen Zwängen?

Die Antwort entstand sinnbildlich auf zwei Servietten – daher der Begriff Two Napkin Protocol. Die Skizzen zeigten kein ausgefeiltes mathematisches Modell, sondern ein simples, aber wirkungsvolles Prinzip: Router sollten nicht versuchen, das gesamte Internet zu verstehen, sondern lediglich wissen, durch welche autonomen Systeme ein Ziel erreichbar ist.

Aus dieser Idee entwickelte sich der Path-Vector-Ansatz, der bis heute das Fundament von BGP bildet. Jede Route trägt ihren Weg durch das Internet gleich mit – transparent, nachvollziehbar und kontrollierbar.

Dieser Ursprung verdeutlicht einen entscheidenden Paradigmenwechsel: BGP ist kein akademisch optimiertes Protokoll, sondern ein ingenieurgetriebenes Werkzeug, entstanden aus realem Betriebsdruck.

Stabilität als zentrales Designziel

Eine weitere zentrale Lehre aus EGP war der Umgang mit Dynamik. Häufige Änderungen und unkontrollierte Reaktionen konnten im globalen Maßstab fatale Folgen haben. Deshalb wurde BGP von Beginn an auf Stabilität und Zurückhaltung ausgelegt.

Das zeigt sich unter anderem darin, dass:

vollständige Routinginformationen nur beim Aufbau einer Sitzung ausgetauscht werden
anschließend ausschließlich Änderungen kommuniziert werden
keine periodischen Updates stattfinden

Dieser Ansatz reduziert unnötige Last und schützt das Internet vor Kaskadeneffekten.

Ein Protokoll für ein föderiertes Internet

BGP entstand nicht als universelles Routingwerkzeug, sondern als Vermittler zwischen unabhängigen Welten. Es akzeptiert die Realität eines föderierten Internets, in dem technische, wirtschaftliche und organisatorische Interessen koexistieren. Genau diese bewusste Einschränkung macht BGP bis heute tragfähig – und erklärt, warum es sich als externes Routingprotokoll durchsetzen konnte.

Grundprinzipien von BGP – Pfad-Vektor-Prinzip und AS_PATH

Das Border Gateway Protocol verfolgt einen grundlegend anderen Ansatz als interne Routingprotokolle wie RIP oder OSPF. Während interne Protokolle regelmäßig Metriken oder vollständige Topologieinformationen austauschen, beschränkt sich BGP bewusst auf das Wesentliche: Erreichbarkeit und Herkunft.

Ein BGP-Router informiert seine Nachbarn darüber, welche IP-Präfixe erreichbar sind – und gleichzeitig darüber, über welche autonomen Systeme dieser Weg führt. Diese Abfolge autonomer Systeme wird im sogenannten AS_PATH festgehalten. Damit weiß jeder Router nicht nur dass ein Ziel erreichbar ist, sondern auch wie der Weg dorthin aussieht.

AS_PATH als Schutz vor Routing-Schleifen

Dieses Pfad-Vektor-Prinzip erfüllt eine zentrale Aufgabe: Loop-Vermeidung. Erkennt ein Router seine eigene AS-Nummer im AS_PATH einer empfangenen Route, verwirft er diese sofort. Eine Weiterleitung würde zwangsläufig zu einer Schleife führen. Auf diese Weise verhindert BGP Routing-Loops ohne aufwändige Topologieberechnungen.

Gleichzeitig liefert der AS_PATH wertvolle Zusatzinformationen für Routing-Entscheidungen. Die Anzahl der durchlaufenen autonomen Systeme – die sogenannte AS-Pfad-Länge – dient als grober Richtwert für die Pfadauswahl. Kürzere AS-Pfade werden in der Regel bevorzugt, da sie häufig auf direktere Verbindungen hindeuten.

Grundlage für policybasiertes Routing

Entscheidend ist jedoch: Der AS_PATH ist kein klassisches Distanzmaß. Er bildet vielmehr die Grundlage für policybasiertes Routing. BGP bewertet Wege nicht nach physischer Entfernung oder Bandbreite, sondern nach administrativen und organisatorischen Kriterien.

Genau deshalb eignet sich BGP für das Routing zwischen autonomen Systemen. In diesem Kontext sind Routing-Policies wichtiger als der kürzeste Weg. Das Pfad-Vektor-Prinzip verbindet technische Erreichbarkeit mit kontrollierbarer Entscheidungsfreiheit – und schafft damit die Grundlage für stabiles externes Routing im Internet.

iBGP und eBGP – zwei Einsatzarten, ein gemeinsames Protokoll

Das Border Gateway Protocol wurde für das Routing zwischen autonomen Systemen entwickelt. Dennoch unterscheidet BGP zwei klar definierte Einsatzarten: externes BGP (eBGP) und internes BGP (iBGP). Beide basieren auf demselben Protokoll, erfüllen jedoch unterschiedliche Aufgaben und folgen bewusst unterschiedlichen Regeln.

Diese Unterscheidung ist zentral, um zu verstehen, wie BGP im Internet und in großen WAN-Architekturen eingesetzt wird.

eBGP: Routing über AS-Grenzen hinweg

eBGP kommt immer dann zum Einsatz, wenn Routing-Informationen zwischen zwei unterschiedlichen autonomen Systemen ausgetauscht werden. Typische Beispiele sind Verbindungen zwischen Internet-Providern oder zwischen einem Unternehmensnetz und seinem Upstream-Anbieter.

Dabei erfüllt BGP seine ursprüngliche Aufgabe: Es verbindet unabhängige Netze, die unter eigener administrativer Kontrolle stehen. Jede Seite entscheidet selbst, welche Routen sie annimmt, weiterleitet oder verwirft.

Charakteristisch für eBGP ist:

eine klare Trennung der Verantwortlichkeiten
der Austausch von Routen über AS-Grenzen hinweg
die konsequente Anwendung von Routing Policies

Damit sorgt eBGP nicht für Optimierung, sondern für kontrollierte Erreichbarkeit zwischen autonomen Systemen.

iBGP: Verteilung externer Routen im eigenen AS

iBGP wird dagegen innerhalb eines autonomen Systems eingesetzt. Sein Zweck besteht nicht darin, interne Pfade zu berechnen. Stattdessen stellt iBGP sicher, dass extern gelernte Routen im gesamten AS bekannt sind.

Erhält ein Router über eBGP Routen von außen, muss er diese Informationen an andere Router im eigenen AS weitergeben. Genau diese Verteilung übernimmt iBGP.

Dabei gilt eine zentrale Regel: Ein iBGP-Router gibt Routen, die er von einem anderen iBGP-Router gelernt hat, nicht automatisch weiter. Diese Einschränkung verhindert Routing-Schleifen, erfordert jedoch eine bewusste Planung der iBGP-Struktur.

Warum diese Trennung entscheidend ist

Die klare Trennung zwischen eBGP und iBGP erklärt, warum BGP kein internes Routingprotokoll ersetzt. Interne Routingprotokolle berechnen Pfade innerhalb eines Netzes. iBGP hingegen verteilt Entscheidungen, die bereits getroffen wurden.

Erst das Zusammenspiel aus internem Routing, iBGP und eBGP ermöglicht ein stabiles, skalierbares Routing – vom lokalen Netzwerk bis zum globalen Internet.

Wichtige BGP-Attribute und ihre Rolle

BGP trifft Routing-Entscheidungen nicht auf Basis einer einzelnen Metrik. Stattdessen nutzt das Protokoll Attribute, die jeder Route mitgegeben werden. Diese Attribute liefern Kontext und ermöglichen es, Routing-Policies technisch umzusetzen. Sie bestimmen, welche Route bevorzugt wird und wie sie weitergegeben werden darf.

Im Folgenden betrachten wir die wichtigsten Attribute, die im praktischen Betrieb eine zentrale Rolle spielen.

NEXT_HOP – Wohin Pakete tatsächlich gesendet werden

Das NEXT_HOP-Attribut gibt an, welcher Router als nächster Hop für ein angekündigtes Präfix verwendet werden soll. Es beschreibt damit nicht den vollständigen Pfad, sondern den konkreten Übergabepunkt.

Bei eBGP-Sitzungen wird der NEXT_HOP in der Regel auf die IP-Adresse des sendenden Routers gesetzt. Bei iBGP bleibt der NEXT_HOP hingegen oft unverändert. Das führt dazu, dass interne Router zusätzlich ein internes Routingprotokoll benötigen, um den Next Hop überhaupt erreichen zu können.

Eine zentrale Regel lautet daher: Eine BGP-Route ist nur nutzbar, wenn der NEXT_HOP im eigenen Routingtable erreichbar ist. Andernfalls wird die Route zwar gelernt, aber nicht verwendet.

LOCAL_PREF – Bevorzugte Wege im eigenen AS

LOCAL_PREF steuert, welcher Ausgangspfad innerhalb eines autonomen Systems bevorzugt wird. Es ist ein rein internes Attribut und wird ausschließlich zwischen iBGP-Nachbarn ausgetauscht.

Dabei gilt: Je höher der LOCAL_PREF-Wert, desto bevorzugter ist der Pfad.

Dieses Attribut ist meist das erste Entscheidungskriterium im BGP-Auswahlprozess. Netzwerkbetreiber nutzen es gezielt, um festzulegen, über welchen Upstream-Anbieter ausgehender Datenverkehr bevorzugt laufen soll. Da LOCAL_PREF niemals an eBGP-Nachbarn weitergegeben wird, bleiben interne Entscheidungen vollständig im eigenen AS verborgen.

MED – Empfehlung an benachbarte autonome Systeme

Der Multi-Exit Discriminator (MED) dient dazu, einem Nachbar-AS eine präferierte Eintrittsstelle mitzuteilen. Er kommt vor allem dann zum Einsatz, wenn zwei autonome Systeme über mehrere physische Verbindungen gekoppelt sind.

Ein niedrigerer MED-Wert signalisiert eine höhere Präferenz. Wichtig ist jedoch: MED wird nur zwischen Routen aus demselben externen AS verglichen. Er ist somit kein globales Optimierungsinstrument, sondern eine gezielte Empfehlung.

In der Praxis ist MED ein feines Steuerungswerkzeug, wird jedoch bewusst vorsichtig eingesetzt, da es stark von der Akzeptanz durch den Nachbarn abhängt.

ORIGIN – Historische Herkunft einer Route

Das ORIGIN-Attribut beschreibt, wie eine Route ursprünglich in BGP gelangt ist. Es unterscheidet drei Werte:

IGP: intern angekündigte Netze
EGP: historisch über EGP gelernt
INCOMPLETE: Ursprung unbekannt, z.B. durch Redistribution

In der Pfadauswahl wird ORIGIN nur nachrangig berücksichtigt. Dennoch spielt es eine Rolle, wenn mehrere Pfade ansonsten gleichwertig sind. Dabei gilt die Reihenfolge: IGP vor EGP vor INCOMPLETE.

COMMUNITY – Routing-Policies skalierbar kennzeichnen

Communities sind flexible Markierungen, mit denen Routen gruppiert und gemeinsam behandelt werden können. Sie bestehen aus 32 Bit und werden häufig im Format ASN:Wert dargestellt.

Ein klassisches Beispiel ist NO_EXPORT, das signalisiert, dass eine Route nicht an externe Nachbarn weitergegeben werden soll. Communities sind optional und transitiv, können also AS-übergreifend propagiert werden.

In der Praxis nutzen Provider Communities, um Kund:innen gezielte Steuerungsmöglichkeiten zu bieten, etwa für Traffic-Lenkung oder Sichtbarkeit von Routen.

Einordnung weiterer Attribute

Zusätzlich existieren weitere Attribute wie Weight oder AGGREGATOR, die jedoch entweder herstellerspezifisch sind oder nur Spezialfälle abdecken. Für das grundlegende Verständnis von BGP sind sie nicht zwingend erforderlich.

Warum Attribute das Herz von BGP bilden

BGP-Attribute sind der Schlüssel zu policybasiertem Routing. Sie trennen technische Erreichbarkeit von administrativer Entscheidung und ermöglichen genau jene Kontrolle, die externes Routing im Internet benötigt.

BGP-Nachbarschaften und die Finite State Machine

BGP unterscheidet sich grundlegend von internen Routingprotokollen: Es entdeckt Nachbarn nicht automatisch. Stattdessen werden BGP-Peers bewusst konfiguriert. Diese Entscheidung ist kein Nachteil, sondern ein zentrales Stabilitätsmerkmal.

Jede BGP-Nachbarschaft basiert auf einer expliziten Beziehung zwischen zwei Routern, inklusive IP-Adresse und AS-Nummer. Erst danach wird eine TCP-Verbindung auf Port 179 aufgebaut. Diese zuverlässige Transportebene bildet die Grundlage für kontrollierten Austausch und langfristige Stabilität.

Warum BGP auf TCP setzt

Während IGPs häufig direkt über IP kommunizieren, nutzt BGP bewusst TCP. Dadurch profitieren BGP-Sessions von:

zuverlässiger Zustellung
geordneter Paketverarbeitung
integrierter Fehlerbehandlung

BGP muss sich nicht selbst um Paketverluste oder Reihenfolgen kümmern. Stattdessen konzentriert sich das Protokoll vollständig auf Routing-Logik und Policy-Kontrolle.

Die Finite State Machine als Sicherheitsmechanismus

Der Aufbau einer BGP-Nachbarschaft folgt einer Finite State Machine (FSM). Sie stellt sicher, dass beide Seiten denselben Verbindungszustand teilen und Parameter sauber ausgehandelt werden.

Der Ablauf lässt sich vereinfacht so verstehen:

Idle: BGP ist bereit, aber inaktiv
Connect / Active: TCP-Verbindung wird aufgebaut oder erneut versucht
OpenSent: Ein OPEN-Paket mit Basisparametern wurde gesendet
OpenConfirm: Parameter wurden akzeptiert, Bestätigung wird erwartet
Established: Die Session ist aktiv, Routing-Informationen dürfen ausgetauscht werden

Erst im Zustand Established gilt eine BGP-Nachbarschaft als funktionsfähig. Vorher werden keine Routen akzeptiert.

Austausch von Routing-Informationen im Established-Zustand

Nach erfolgreichem Aufbau tauschen die Router zunächst ihre bekannten Routen aus. Anschließend kommuniziert BGP nur noch Änderungen. Regelmäßige KEEPALIVE-Nachrichten halten die Sitzung aktiv und dienen als Lebenszeichen, nicht als Routing-Update.

Diese Zurückhaltung unterscheidet BGP bewusst von internen Protokollen.

eBGP und iBGP im Nachbarschaftsmodell

BGP unterscheidet klar zwischen:

eBGP-Nachbarn zwischen verschiedenen autonomen Systemen
iBGP-Nachbarn innerhalb eines autonomen Systems

Aus Gründen der Loop-Vermeidung gibt iBGP keine von iBGP gelernten Routen automatisch weiter. Diese Regel erfordert geplante Strukturen, sorgt jedoch für hohe Skalierbarkeit.

Warum dieses Design so wichtig ist

BGP setzt auf wenige, stabile und bewusst konfigurierte Nachbarschaften. Genau dieses Design ermöglicht Routing im globalen Maßstab. Statt ständiger Dynamik steht kontrollierte Kommunikation im Mittelpunkt – eine Voraussetzung für ein stabiles Internet.

Routenentscheidungsprozess (Best Path Selection)

Ein zentrales Merkmal von BGP ist die Fähigkeit, aus mehreren möglichen Wegen genau einen Pfad auszuwählen. In der Praxis ist das die Regel, nicht die Ausnahme: Für ein einzelnes Zielpräfix lernt ein BGP-Router häufig mehrere Routen von unterschiedlichen Nachbarn.

Im Unterschied zu internen Routingprotokollen nutzt BGP keine aggregierte Metrik. Stattdessen folgt die Pfadauswahl einer fest definierten Reihenfolge von Kriterien, die bewusst policyorientiert aufgebaut ist.

Policy schlägt Topologie

Der Auswahlprozess beginnt nicht mit technischen Eigenschaften, sondern mit administrativen Entscheidungen. Das erste und wichtigste Kriterium ist die Local Preference (LOCAL_PREF).

Hat eine Route einen höheren LOCAL_PREF-Wert als eine andere, gewinnt sie – unabhängig davon, wie lang oder kurz der tatsächliche Weg ist. Damit stellt BGP sicher, dass interne Routing-Policies immer Vorrang vor topologischen Überlegungen haben.

Erst wenn diese Präferenz identisch ist, betrachtet BGP weitere Merkmale.

AS_PATH und Herkunft als nächste Filterstufe

In einem zweiten Schritt bewertet BGP die AS-Pfad-Länge. Kürzere AS_PATHs werden bevorzugt, da sie meist auf direktere Verbindungen hindeuten. Anschließend berücksichtigt BGP den Origin-Type. Routen mit Ursprung IGP gelten als vertrauenswürdiger als solche mit EGP oder Incomplete.

Diese Kriterien dienen nicht der Feinoptimierung, sondern helfen, gleichwertige Alternativen sinnvoll einzugrenzen.

MED und Nachbarschaftskontext

Der Multi-Exit Discriminator (MED) kommt nur dann zum Einsatz, wenn mehrere Routen vom selben externen AS stammen. In diesem Fall bevorzugt BGP den Pfad mit dem niedrigeren MED-Wert.

Wichtig ist: MED ist keine globale Bewertung, sondern eine gezielte Empfehlung an Nachbarn. BGP respektiert diese Empfehlung nur im passenden Kontext.

eBGP vor iBGP – und der Blick ins interne Netz

Sind weiterhin mehrere Routen gleichwertig, bevorzugt BGP extern gelernte Routen vor intern verteilten. Dieses Verhalten unterstützt das sogenannte Hot-Potato-Routing: Verkehr verlässt das eigene AS möglichst früh.

Erst danach fließt internes Routing ein. BGP betrachtet dann, welcher Next Hop intern am nächsten liegt, etwa gemessen an OSPF-Kosten. Damit verbindet BGP externe Entscheidungen mit interner Topologie – jedoch bewusst erst sehr spät.

Letzte Entscheidung und Konsequenz

Bleibt danach noch mehr als ein Pfad übrig, entscheidet die Router-ID als technischer Tie-Breaker. Dieser Fall ist selten und rein deterministisch.

Am Ende bleibt genau ein bester Pfad. Dieser wird in die lokale BGP-Routingtabelle übernommen und – abhängig von Richtlinien – an andere Nachbarn weitergegeben. Standardmäßig verteilt BGP pro Präfix nur eine Route, um Stabilität zu gewährleisten. Lastverteilung ist möglich, aber bewusst optional.

Warum dieser Prozess so aufgebaut ist

Die Best Path Selection von BGP ist kein Optimierungsalgorithmus, sondern ein Kontrollmechanismus. Er stellt sicher, dass Routing-Entscheidungen vorhersehbar, steuerbar und stabil bleiben – selbst im globalen Maßstab des Internets.

Inkrementelle Updates statt permanenter Kommunikation

Ein wesentliches Merkmal von BGP ist sein bewusst zurückhaltendes Kommunikationsverhalten. Anders als klassische Routingprotokolle verzichtet BGP vollständig auf periodische Routing-Updates. Diese Entscheidung ist kein Zufall, sondern eine direkte Konsequenz aus der Größe und Struktur des Internets.

Einmal austauschen, dann beobachten

Beim Aufbau einer BGP-Nachbarschaft tauschen die beteiligten Router zunächst einmalig ihre vollständigen Routinginformationen aus. Dieser initiale Austausch stellt sicher, dass beide Seiten einen gemeinsamen Ausgangspunkt haben. Danach ändert sich das Kommunikationsverhalten grundlegend.

Ab diesem Moment gilt: BGP kommuniziert nur noch bei tatsächlichen Änderungen.

Lernt ein Router ein neues Präfix, verliert eine Route ihre Gültigkeit oder ändern sich Attribute eines bestehenden Pfades, wird eine UPDATE-Nachricht versendet. Bleibt die Situation stabil, bleibt auch die Kommunikation ruhig.

Der bewusste Gegensatz zu internen Routingprotokollen

Dieses inkrementelle Vorgehen unterscheidet BGP klar von internen Routingprotokollen. Protokolle wie RIP versenden in festen Intervallen ihre komplette Routingtabelle. Auch OSPF erneuert regelmäßig Link-State-Informationen, selbst wenn sich an der Topologie nichts geändert hat.

Im lokalen Netzwerk ist dieses Verhalten sinnvoll, da dort jederzeit mit Veränderungen zu rechnen ist. Im globalen Kontext des Internets wäre es jedoch fatal. Millionen von Routen periodisch zu aktualisieren würde zu unnötiger Last und Instabilität führen.

KEEPALIVE statt Routing-Overhead

Die einzige regelmäßig gesendete Nachricht in einer BGP-Sitzung ist das KEEPALIVE. Diese Nachricht dient ausschließlich als Lebenszeichen und enthält keine Routinginformationen. Sie stellt sicher, dass die TCP-Verbindung aktiv bleibt und beide Seiten erreichbar sind.

Routing-Daten selbst bleiben davon unberührt.

Skalierbarkeit durch Zurückhaltung

Durch die Bündelung von Präfixen und gemeinsamen Attributen in UPDATE-Nachrichten hält BGP die Netzlast und CPU-Belastung der Router bewusst niedrig. Dieses Design ist ein entscheidender Faktor dafür, dass BGP auch bei einer Routingtabelle mit weit über einer Million Präfixen effizient funktioniert.

Nicht Geschwindigkeit, sondern Kontrolle und Skalierbarkeit stehen im Vordergrund. Genau diese Zurückhaltung macht BGP zum tragenden Protokoll des globalen Internets.

Stabilität und Zurückhaltung im Protokolldesign

BGP wurde nicht für maximale Reaktionsgeschwindigkeit entworfen, sondern für globale Stabilität. Im Internet-Routing hat jede Änderung potenziell Auswirkungen auf tausende autonome Systeme. Deshalb verarbeitet BGP Änderungen bewusst kontrolliert und verzögert, um unnötige Dynamik zu vermeiden.

Timer als Schutzmechanismus

Bereits auf Sitzungsebene zeigt sich diese Philosophie. BGP nutzt einen Hold Timer, der standardmäßig bei 180 Sekunden liegt. KEEPALIVE-Nachrichten werden typischerweise alle 60 Sekunden gesendet. Kurzzeitige Paketverluste oder kleinere Störungen führen dadurch nicht sofort zum Abbruch einer Sitzung.

Auch bei Routing-Updates gilt Zurückhaltung. Mit dem Minimum Route Advertisement Interval begrenzt BGP, wie schnell Änderungen für dasselbe Präfix an denselben Nachbarn weitergegeben werden. Diese Pause glättet kurzfristige Fluktuationen und verhindert Update-Stürme.

Langsame Konvergenz als bewusste Entscheidung

Die Kehrseite dieses Designs ist eine vergleichsweise langsame Konvergenz. Während interne Routingprotokolle wie OSPF innerhalb von Sekunden reagieren, kann BGP nach größeren Ereignissen Minuten benötigen, um wieder stabil zu werden.

Diese Verzögerung ist kein Fehler, sondern ein Schutzmechanismus. Jeder Router prüft Änderungen gegen lokale Routing-Policies, bewertet Pfade neu und gibt Informationen kontrolliert weiter. So werden Oszillationen, Schleifen und unkontrollierte Präfix-Verbreitung vermieden.

Route Flap Damping – gut gemeint, vorsichtig eingesetzt

Um instabile Routen weiter einzudämmen, wurde Route Flap Damping eingeführt. Präfixe, die häufig zwischen erreichbar und unerreichbar wechseln, werden temporär unterdrückt. Dadurch gelangen instabile Informationen nicht ständig weiter ins Netz.

In der Praxis zeigte sich jedoch, dass zu aggressives Damping auch legitime Routen unnötig lange blockieren kann. Viele Betreiber haben diese Funktion daher abgeschwächt oder deaktiviert. Moderne Verfahren setzen stattdessen auf kontrollierte Neustarts und Zustandsübergänge.

Graceful Restart statt harter Abbrüche

Aktuelle Mechanismen wie Graceful Restart erlauben es, BGP-Sitzungen neu aufzubauen, ohne sofort alle Routen zu verwerfen. Präfixe werden dabei kurzfristig als stale markiert, bleiben jedoch nutzbar, solange sich die Sitzung stabilisiert. Auch hier steht Stabilität vor Geschwindigkeit.

Der Pakistan-YouTube-Vorfall als Mahnung

Im Jahr 2008 kam es zu einer der bekanntesten Störungen im Internet-Routing. Ein pakistanischer Internetprovider wollte den Zugriff auf YouTube im eigenen Land blockieren und kündigte dafür über BGP ein sehr spezifisches IP-Präfix an, das eigentlich zu YouTube gehörte. Diese Route war technisch korrekt, jedoch nicht ausreichend gefiltert.

Anstatt lokal begrenzt zu bleiben, wurde die Ankündigung an einen Upstream-Provider weitergegeben und von dort weltweit propagiert. Da das angekündigte Präfix spezifischer war als die regulären YouTube-Routen, bevorzugten viele BGP-Router diesen Pfad. Der Datenverkehr wurde global umgeleitet und landete in einem Netz, das dafür nicht ausgelegt war. YouTube war dadurch für große Teile des Internets zeitweise nicht erreichbar.

Der Vorfall zeigt eindrücklich, dass BGP keine zentrale Instanz zur Plausibilitätsprüfung besitzt. Das Protokoll vertraut darauf, dass Betreiber ihre Routen korrekt ankündigen und filtern. Stabilität entsteht daher nicht durch schnelle Reaktionen, sondern durch konservative Konfigurationen, saubere Policies und verantwortungsvollen Betrieb.

Stabilität als oberstes Designziel

BGP folgt einer klaren Maxime:Lieber langsamer und stabil, als schnell und unkontrollierbar.

Diese Philosophie mag im lokalen Netzwerk ungewohnt wirken, ist jedoch der Grund dafür, dass das Internet trotz seiner Größe und Heterogenität zuverlässig funktioniert. Genau diese Zurückhaltung macht BGP bis heute zum Rückgrat des globalen Routings.

Ausblick: Multiprotocol-BGP (MP-BGP)

BGP-4 wurde ursprünglich für das Routing von IPv4-Netzen entwickelt. Mit dem Wachstum des Internets und neuen Anforderungen zeigte sich jedoch schnell, dass ein externes Routingprotokoll mehr als eine einzige Adressfamilie unterstützen muss. Genau an dieser Stelle setzen die Multiprotocol Extensions for BGP an, kurz MP-BGP.

MP-BGP erweitert BGP nicht durch ein neues Protokoll, sondern durch zusätzliche Adressfamilien. Bereits beim Aufbau einer BGP-Sitzung handeln die beteiligten Router aus, welche Routing-Informationen sie austauschen können. Dazu zählen unter anderem IPv6-Unicast-Routen, Multicast-Informationen oder VPN-Routen im Kontext von MPLS-Netzen.

Ein Protokoll, mehrere Aufgaben

Durch diese Erweiterung kann ein einzelnes BGP-Peering parallel unterschiedliche Routing-Domänen bedienen. In der Praxis ist dies heute Standard, etwa im Dual-Stack-Betrieb, bei dem IPv4- und IPv6-Routen gleichzeitig ausgetauscht werden. Auch viele Provider-Dienste, wie Layer-3-VPNs, basieren vollständig auf MP-BGP.

Entscheidend ist dabei: Die Grundprinzipien von BGP bleiben unverändert.

Pfad-Vektor-Mechanismus, Attributsteuerung, Nachbarschaftsmodell, Best-Path-Auswahl und die konservative Stabilitätsphilosophie gelten weiterhin – unabhängig davon, welche Adressfamilie transportiert wird.

MP-BGP zeigt, wie flexibel BGP geworden ist, ohne seine Grundidee aufzugeben. Genau diese Fähigkeit macht das Protokoll zum zentralen Baustein moderner Internet- und WAN-Architekturen.

Im nächsten Kapitel greifen wir diesen Gedanken auf und betrachten, wie BGP heute konkret im Internet, in Provider-Backbones und in modernen WAN-Szenarien eingesetzt wird – von klassischem eBGP bis hin zu cloud- und serviceorientierten Architekturen.

Exkurs: Die Entstehung der Internet Service Provider

Wie aus Einwahlgeräuschen globale Netzinfrastrukturen wurden

Bevor das Internet als allgegenwärtige Infrastruktur wahrgenommen wurde, begann es für viele Nutzer:innen mit einem sehr konkreten Erlebnis: dem Einwählen per Modem. Piepsende Verbindungsversuche, minutenlange Handshakes und begrenzte Übertragungsraten prägten den frühen Zugang zum Netz. Hinter diesen Einwahlpunkten standen die ersten Internet Service Provider, die das Internet aus der Forschung in den Alltag brachten.

Die ersten Provider weltweit: Zugang als Dienstleistung

International entstanden Internetanbieter zunächst aus bestehenden Online-Diensten und Telekommunikationsunternehmen. Anbieter wie CompuServe oder AOL boten ihren Kund:innen zunächst geschlossene Plattformen mit E-Mail, Foren und Inhalten an. Der Zugang zum offenen Internet folgte später – und veränderte diese Geschäftsmodelle grundlegend.

Parallel dazu etablierten sich erste Backbone-Betreiber, die nicht Inhalte, sondern Netzverbindungen verkauften. Unternehmen wie MCI betrieben leistungsfähige Weitverkehrsnetze und wurden zu zentralen Akteuren im globalen Routing. Spätestens hier zeigte sich: Das Internet war kein einzelnes Netz, sondern ein Verbund unabhängiger Betreiber.

Deutschland: Vom Forschungsnetz zum Massenmarkt

In Deutschland verlief die Entwicklung zeitlich versetzt, aber strukturell ähnlich. Zunächst dominierten wissenschaftliche Netze und universitäre Anbindungen. Der DFN-Verein spielte mit dem Deutschen Forschungsnetz dabei eine Schlüsselrolle und verband Hochschulen sowie Forschungseinrichtungen deutschlandweit.

Mit der Öffnung des Marktes und der zunehmenden Verfügbarkeit von Einwahlzugängen entstanden ab Mitte der 1990er-Jahre erste kommerzielle Provider. Anbieter wie T-Online, EUnet oder regionale City-Provider machten Internetzugang für Privatpersonen und Unternehmen verfügbar. Die Rolle der Provider wandelte sich dabei schnell: vom reinen Zugangsanbieter zum Netzbetreiber mit eigener Routing-Verantwortung.

Ein besonderer historischer Kontext: Internet und DDR

Ein oft übersehener Aspekt ist die Internetentwicklung in der DDR. Zwar existierte dort kein öffentlich zugängliches Internet, jedoch wurden wissenschaftliche Rechnernetze und internationale Datenverbindungen unter staatlicher Kontrolle genutzt. E-Mail-ähnliche Dienste und Datenaustausch waren vorhanden, jedoch stark reglementiert.

Nach der Wiedervereinigung wurden diese Strukturen schrittweise in die westdeutsche Netzlandschaft integriert. Der Übergang verdeutlicht eindrücklich, wie sehr politische Rahmenbedingungen den Ausbau und Betrieb von Netzen beeinflussen – ein Gedanke, der sich später auch im policybasierten Routing widerspiegelt.

Provider als neue Macht im Internet

Mit dem Aufstieg der Internet Service Provider wurde Routing endgültig zu einer wirtschaftlichen und organisatorischen Disziplin. Peering, Transit, Redundanz und Ausfallsicherheit bestimmten nun den Netzbetrieb. Genau in diesem Umfeld setzte sich BGP als verbindendes Protokoll durch, weil es die Interessen unabhängiger Betreiber respektiert.

Der Blick auf die frühen Provider zeigt: Das Internet wuchs nicht nur technisch, sondern auch organisatorisch – und genau dafür brauchte es ein externes Routingprotokoll.

Routing Policies als Steuerungsinstrument

Mit der Entstehung der Internet Service Provider änderte sich der Charakter des Routings grundlegend. Netze wurden nicht mehr nur verbunden, sondern gezielt gesteuert. Genau hier setzen Routing Policies an. Sie definieren, welche Routen akzeptiert, bevorzugt oder weitergegeben werden – und welche bewusst nicht.

Was eine Routing Policy beschreibt

Eine Routing Policy ist keine Richtlinie im klassischen Sinn, wie man sie etwa von Firewalls oder Zugriffskontrolllisten kennt. Es existiert kein festes Regelwerk, das einzelne Pakete erlaubt oder blockiert. Stattdessen beschreibt eine Routing Policy einen strategischen Rahmen für Routing-Entscheidungen.

Sie beantwortet unter anderem folgende Fragen:

Über welche Nachbarn nehme ich Erreichbarkeitsinformationen an?
Welche Pfade bevorzuge oder benachteilige ich bewusst?
Welche Routen gebe ich weiter, welche halte ich zurück?

Im externen Routing stehen dabei nicht technische Feinoptimierung, sondern Kontrolle, Wirtschaftlichkeit und Stabilität im Vordergrund.

Policies entstehen aus Attributen – nicht aus Regeln

Der entscheidende Unterschied zu klassischen Sicherheitsrichtlinien liegt in der Umsetzung. Routing Policies werden nicht als explizite Regeln formuliert, sondern ergeben sich aus der gezielten Kombination und Bewertung von BGP-Attributen.

Attribute wie:

Local Preference
AS_PATH
MED
Communities

wirken zusammen und beeinflussen die Pfadauswahl. Erst aus dieser Wechselwirkung entsteht das gewünschte Verhalten. BGP selbst bewertet diese Attribute strikt mechanisch und deterministisch.

BGP entscheidet dabei nicht, was richtig oder falsch ist. Es stellt lediglich die Werkzeuge zur Verfügung, mit denen Betreiber ihre eigenen Entscheidungen technisch abbilden können.

Praxisbeispiel: Priorisierung von Datenverkehr

Ein anschauliches Beispiel für Routing Policies ist die Priorisierung bestimmter Datenströme gegen Entgelt. In der Vergangenheit boten einige Internetanbieter Inhalte- oder Plattformbetreibern an, deren Datenverkehr bevorzugt durch das eigene Netz zu leiten – etwa durch günstigere Pfade, geringere Latenz oder höhere Verfügbarkeit.

Technisch umgesetzt wurde dies nicht durch Inhaltsanalyse, sondern durch Routing-Entscheidungen:

bestimmte Präfixe wurden bevorzugt geroutet
alternative Pfade bewusst benachteiligt
Communities oder Local Preference gezielt gesetzt

Das Beispiel zeigt deutlich: Routing Policies wirken auf der Steuerungsebene, nicht auf Paketebene. BGP entscheidet nicht, was übertragen wird, sondern wie Netze miteinander verbunden sind.

Warum Policies im Internet unverzichtbar sind

Ohne Routing Policies wäre das Internet nicht betreibbar. Peering- und Transitmodelle, Redundanzkonzepte oder Schutzmechanismen wären nicht umsetzbar. Policies ermöglichen es, das Internet als föderierte Infrastruktur zu betreiben, in der jedes autonome System Verantwortung für seine Entscheidungen trägt.

Externes Routing ist damit keine Frage der optimalen Route, sondern eine Frage der Governance. Mit diesem Verständnis wird deutlich, warum BGP in modernen Netzen so eingesetzt wird, wie wir es heute sehen. Im nächsten Kapitel betrachten wir, wie Routing Policies und BGP konkret in Provider-Backbones, Unternehmens-WANs und Cloud-Architekturen zusammenwirken.

Exkurs: Multiprotocol BGP

Wie ein Routingprotokoll zum universellen Transportmechanismus wurde

Routing Policies definieren was gesteuert werden soll. Multiprotocol BGP (MP-BGP) erklärt, wie diese Steuerung über unterschiedliche Netztypen hinweg möglich wird. Denn moderne Netze transportieren längst nicht mehr nur IPv4-Routen. Genau an diesem Punkt beginnt die Rolle von Multiprotocol BGP.

Ausgangspunkt: Die Grenzen von klassischem BGP-4

Das ursprüngliche BGP-4 war auf IPv4-Unicast-Routing ausgelegt. Dieses Modell funktionierte hervorragend, solange das Internet im Wesentlichen aus IPv4-Netzen bestand. Mit dem Wachstum des Internets änderten sich jedoch die Anforderungen:

Einführung von IPv6
Bedarf an Multicast-Routing
Aufbau providerbasierter VPN-Dienste
Trennung mehrerer logischer Netze über dieselbe Infrastruktur

Ein neues Protokoll war jedoch keine Option. Stattdessen wurde BGP erweitert.

Grundidee von MP-BGP

MP-BGP erweitert BGP nicht funktional, sondern semantisch. Das Protokoll transportiert nicht mehr nur IPv4-Präfixe, sondern beliebige Adressfamilien. Technisch geschieht dies über sogenannte Address Family Identifier und Subsequent Address Family Identifier.

Damit wird jede Routing-Information eindeutig beschrieben durch:

welcher Adresstyp transportiert wird
in welchem Kontext diese Route gilt

BGP selbst bleibt dabei unverändert. Peering, Attribute, Policies und Best-Path-Selection funktionieren genauso wie zuvor.

Capabilities und Aushandlung

Bereits beim Aufbau einer BGP-Sitzung handeln die Router aus, welche Address Families unterstützt werden. Eine einzelne BGP-Session kann dadurch parallel mehrere logische Routing-Instanzen tragen, etwa:

IPv4-Unicast
IPv6-Unicast
VPN-IPv4 oder VPN-IPv6
Multicast

Jede dieser Address Families besitzt ihre eigene Routing-Logik, nutzt jedoch dieselben Policy-Mechanismen.

MP-BGP als Policy-Multiplikator

Hier zeigt sich die eigentliche Stärke von MP-BGP. Routing Policies lassen sich konsistent über unterschiedliche Dienste hinweg anwenden. Ein Provider kann beispielsweise:

IPv6-Traffic anders behandeln als IPv4
VPN-Kundennetze strikt voneinander isolieren
Multicast-Routen gezielt begrenzen

BGP wird damit nicht nur zum Routing-, sondern zum Policy-Transportprotokoll.

VPNs und logische Netze

Besonders prägend ist MP-BGP im Kontext von providerbasierten VPNs. Hier transportiert BGP nicht nur Präfixe, sondern auch Kontextinformationen, die bestimmen, zu welchem logischen Netz eine Route gehört. Erst dadurch lassen sich tausende isolierte Kundennetze über eine gemeinsame Infrastruktur betreiben.

Warum MP-BGP kein eigenes Protokoll ist

Ein entscheidender Punkt: MP-BGP ist kein neues Routingprotokoll. Es nutzt dieselben konservativen Designprinzipien:

inkrementelle Updates
policybasierte Entscheidungen
stabile Peering-Beziehungen

Damit bleibt die Grundphilosophie von BGP vollständig erhalten.

Einordnung im Gesamtbild

MP-BGP ist der Grund, warum BGP heute weit über klassisches Internet-Routing hinausgeht. Ohne MP-BGP wären moderne Provider-Backbones, Cloud-Interconnects und servicebasierte WAN-Architekturen nicht realisierbar.

BGP als Fundament moderner Internet- und WAN-Architekturen

Das Border Gateway Protocol ist längst mehr als ein reines Internet-Routingprotokoll. Heute bildet BGP das verbindende Element zwischen Provider-Backbones, Cloud-Plattformen und unternehmensweiten WAN-Architekturen. Die zuvor erläuterten Grundprinzipien zeigen hier ihre praktische Wirkung.

BGP in Internet-Backbones und Provider-Netzen

Nach der historischen Entwicklung der Providerlandschaft und der konzeptionellen Einführung von Routing Policies wird deutlich: BGP ist heute vor allem ein Werkzeug zur Umsetzung strategischer Entscheidungen. Moderne Internet- und WAN-Architekturen nutzen BGP nicht primär, um den besten technischen Pfad zu finden, sondern um Erreichbarkeit bewusst zu steuern.

BGP in Provider-Backbones: Verträge werden zu Routen

In Provider-Netzen bildet BGP die technische Abbildung wirtschaftlicher Beziehungen. Peering- und Transitverträge entscheiden darüber, welche Routen bevorzugt, akzeptiert oder weitergegeben werden. Routing Policies übersetzen diese Vereinbarungen in konkrete Pfadentscheidungen.

Typische Einsatzszenarien sind:

Bevorzugung eigener Peering-Partner gegenüber Transitpfaden
gezielte Steuerung von ein- und ausgehendem Datenverkehr
Isolation problematischer oder unerwünschter Routen

BGP fungiert hier als Policy-Engine, nicht als Optimierer. Der Datenverkehr folgt nicht dem kürzesten Weg, sondern dem vereinbarten Weg.

Internet Exchange Points als Policy-Knoten

An Internet Exchange Points treffen viele autonome Systeme aufeinander. Jeder Teilnehmer bringt eigene Routing Policies mit. BGP ermöglicht es, diese Interessen parallel abzubilden, ohne zentrale Koordination.

Gerade hier zeigt sich die Stärke von BGP:

gleiche technische Sprache für unterschiedliche Ziele
klare Trennung von Verantwortung
stabile Koexistenz konkurrierender Netze

Routing Policies sorgen dafür, dass dieser Austausch kontrolliert bleibt.

BGP im Unternehmens-WAN: Kontrolle statt Automatismus

Auch in Unternehmensnetzen wird BGP gezielt eingesetzt, insbesondere bei Multi-Homing und hybriden WAN-Architekturen. Unternehmen nutzen BGP, um:

mehrere Internetanbieter parallel anzubinden
Ausfallsicherheit zu erhöhen
Traffic gezielt über bestimmte Anbindungen zu lenken

Routing Policies definieren dabei, welcher Provider bevorzugt wird und unter welchen Bedingungen ein Wechsel erfolgt. Interne Routingprotokolle optimieren weiterhin innerhalb des Netzes – BGP übernimmt die strategische Außenanbindung.

Cloud-Interconnects: Policies über Organisationsgrenzen hinweg

In hybriden Architekturen verbindet BGP klassische Rechenzentren mit Cloud-Plattformen. Dedizierte Leitungen und virtuelle Gateways tauschen Routing-Informationen über BGP aus und respektieren dabei die Policies beider Seiten.

BGP ermöglicht:

konsistente Routing-Entscheidungen zwischen On-Premises und Cloud
parallelen Betrieb von IPv4 und IPv6
klare Abgrenzung von Verantwortlichkeiten

Auch hier bleibt das Prinzip gleich: BGP setzt Policies um, es definiert sie nicht.

Zusammenführung der Perspektiven

In allen Szenarien – Provider, Unternehmen, Cloud – zeigt sich dasselbe Muster. BGP verbindet technische Erreichbarkeit mit administrativer Kontrolle. Routing Policies sind dabei das eigentliche Steuerungsinstrument.

BGP ist damit weniger ein klassisches Routingprotokoll als ein Mechanismus zur Koordination unabhängiger Netzbetreiber. Genau diese Eigenschaft macht es zum Fundament moderner Internet- und WAN-Architekturen.

Externes Routing verstehen heißt, das Internet zu verstehen

Externes Routing unterscheidet sich grundlegend von internem Routing. Während interne Routingprotokolle auf schnelle Reaktion und technische Optimierung ausgelegt sind, verfolgt externes Routing ein anderes Ziel: Stabilität in einem globalen, föderierten Netzwerk. Diese Unterscheidung zieht sich wie ein roter Faden durch die Entwicklung des Internets.

BGP als bewusste Antwort auf Komplexität

Das Border Gateway Protocol entstand nicht als eleganter Algorithmus, sondern als pragmatische Lösung für reale Probleme. Die Trennung in autonome Systeme, das Fehlen zentraler Kontrolle und die Vielfalt wirtschaftlicher Interessen machten ein Routingprotokoll notwendig, das Zurückhaltung, Kontrolle und Vorhersehbarkeit priorisiert.

BGP verzichtet bewusst auf:

schnelle Konvergenz um jeden Preis
automatische Optimierung
zentrale Steuerung

Stattdessen bietet es Mechanismen, mit denen Betreiber Verantwortung übernehmen und Routing-Entscheidungen bewusst gestalten können.

Routing Policies als Schlüsselkonzept

Im Zentrum des externen Routings stehen Routing Policies. Sie verbinden Technik mit Organisation, Wirtschaft und Sicherheit. BGP dient dabei nicht als Entscheidungsinstanz, sondern als Umsetzungswerkzeug. Diese Trennung ist essenziell für den stabilen Betrieb des Internets.

Historische Ereignisse, der Aufstieg der Internet Service Provider und moderne Cloud-Architekturen zeigen: Ohne Policies wäre das Internet weder skalierbar noch beherrschbar.

Ein Protokoll mit erstaunlicher Langlebigkeit

Trotz seines Alters ist BGP hochaktuell. Erweiterungen wie MP-BGP zeigen, dass sich neue Anforderungen integrieren lassen, ohne die Grundprinzipien zu verändern. Pfad-Vektor-Mechanismus, Attributsteuerung und konservatives Update-Verhalten bilden weiterhin das stabile Fundament.

BGP ist damit kein Relikt, sondern ein bewusst konservatives Design, das sich über Jahrzehnte bewährt hat.

Blick nach vorn: Sicherheit, Verantwortung und Evolution

Mit der wachsenden gesellschaftlichen und wirtschaftlichen Abhängigkeit vom Internet rückt BGP zunehmend auch in den Fokus von Sicherheitsinitiativen, Regulierungsbehörden und politischen Akteuren. Fehlkonfigurationen und gezielte Manipulationen haben gezeigt, dass externes Routing technisch korrekt funktionieren kann, ohne inhaltlich vertrauenswürdig zu sein.

Die Antwort darauf ist keine Ablösung von BGP, sondern seine gezielte Weiterentwicklung. Mechanismen zur Absicherung der Routenherkunft, erhöhte Transparenz und klarere Verantwortlichkeiten ergänzen das bestehende Modell. Entscheidend ist dabei: Auch diese Maßnahmen respektieren die föderierte Struktur des Internets. Es entsteht keine zentrale Kontrolle, sondern ein Rahmen für verantwortungsvolles Handeln.

Die Zukunft von BGP liegt damit weniger in neuen Algorithmen als in Governance, Kooperation und verbindlichen Mindeststandards. Evolution ersetzt Revolution.

Schlussgedanke

Wer BGP versteht, versteht nicht nur ein Routingprotokoll, sondern das Internet selbst: als Zusammenspiel unabhängiger Akteure, verbunden durch Technik, getragen von Verantwortung und stabilisiert durch Zurückhaltung.

Gerade im Blick auf kommende Sicherheits- und Regulierungsfragen gilt deshalb auch in Zukunft: Externes Routing zu verstehen heißt, das Internet zu verstehen – technisch, organisatorisch und gesellschaftlich.

Quellenangaben

(Abgerufen am 02.01.2026)

Externes Routing im Internet und WAN – Architektur, Historie und Bedeutung von BGP