Das Border Gateway Protocol (BGP) ist das im Internet eingesetzte Routingprotokoll, welches autonome Systeme (AS) miteinander verbindet. Diese autonomen Systeme werden in der Regel von Internetdienstanbietern gebildet. BGP wird allgemein als Exterior-Gateway-Protokoll (EGP) und Pfadvektorprotokoll bezeichnet und verwendet für Routing-Entscheidungen sowohl strategische als auch technisch-metrische Kriterien, wobei in der Praxis meist betriebswirtschaftliche Aspekte berücksichtigt werden. Innerhalb autonomer Systeme werden Interior Gateway Protokolle (IGP) wie z. B. OSPF eingesetzt.
Protokollbeschreibung
BGP ist in RFC 1163 beschrieben. In der derzeit eingesetzten Version 4 ist es im RFC 4271 beschrieben. Die BGP-Router verwenden den TCP-Port 179.
1991 wurde im RFC 1269 die Border Gateway Protocol (Version 3) MIB veröffentlicht. Diese MIB ermöglicht das Management von Geräten mittels SNMP, die das BGP-Protokoll als Autonomous System Routing Protocol unterstützen.
Im Februar 1998 wurde das BGPv4 in RFC 2283 mit sogenannten Multiprotocol Extensions versehen. Die aktuelle Version findet sich in RFC 4760. Damit ist BGPv4 nicht mehr rein IPv4-spezifisch, sondern unterstützt ebenso das Routing mit weiteren Protokollen der Vermittlungsschicht. U. a. ist so auch der Austausch von MPLS-Labels möglich, dies war Voraussetzung für den Einsatz von BGP/MPLS IP VPNs (RFC 4364).
Anwendungsbereich
EBGP BGP, das derzeit einzige eingesetzte Exterior-Gateway-Protokoll, ist ein Protokoll für das Routing zwischen autonomen Systemen (AS). Man spricht bei dieser Verwendung von External BGP (EBGP).
Route Server An Internet Exchanges, zum Beispiel dem deutschen DE-CIX, treffen viele autonome Systeme zum Zwecke des Peerings zusammen. Um die Notwendigkeit sehr vieler BGP-Verbindungen bis hin zur Vollvermaschung zu vermeiden, werden dort in der Regel sogenannte Route Server angeboten. Die Border-Router, die zu den angeschlossenen Netzen vermitteln, senden ihre Routen an den Routing-Server, also den Route Reflector, von dem alle anderen Router diese Routen wieder beziehen können. Dadurch kann ein Netzwerk auf einfache Art und Weise mit fast allen angeschlossenen Netzen zusammengeschlossen werden.
IBGP BGP kann auch innerhalb eines autonomen Systems angewendet werden. Typischerweise geschieht dies, um die von EBGP-Routern gelernten Routen innerhalb des eigenen autonomen Systems zu propagieren. Zwar wäre es auch mit Hilfe eines IGP möglich, die BGP-Attribute (siehe unten) zu übermitteln, jedoch sind diese nicht dafür ausgelegt. Diese Verwendung wird als Internal BGP (IBGP) bezeichnet. Alle IBGP-Router, die zusammen Routen austauschen, verwenden dieselbe AS-Nummer des eigenen AS, wenn keine BGP-Confederations (siehe unten) verwendet werden.
Vollständige Vermaschung Beim Einsatz innerhalb eines autonomen Systems müssen BGP-Verbindungen zwischen allen Routern des AS eingerichtet werden, so dass eine vollständige Vermaschung entsteht. Enthält ein autonomes System n Router, so resultiert dies also in BGP-Verbindungen. Aufgrund der hierdurch entstehenden Skalierungsprobleme wird bei größeren Netzwerken ein sogenannter Route Reflector (RR) eingesetzt. Durch diesen entfällt die Notwendigkeit einer Vollvermaschung der IBGP-Router; stattdessen bauen diese eine BGP-Verbindung zu einem oder aus Redundanzgründen zu mehreren Route-Reflektoren auf.
Der Grund der Notwendigkeit einer vollständigen Vermaschung liegt darin, dass IBGP innerhalb eines autonomen Systems empfangene BGP-Informationen von benachbarten BGP-Routern selber nicht an andere IBGP-Router weitergibt („Split-Horizon-Prinzip“). Dies dient der Vermeidung von Routing-Schleifen.
Route Reflector Um das Problem der bei einer vollständigen Vermaschung auftretenden Vielzahl an BGP-Sessions zu lösen, können in einem AS ein oder aus Redundanzgründen mehrere BGP-Router als Route Reflector konfiguriert werden. So schickt jeder EBGP-Router seine via EBGP gelernten Routen via IBGP nur noch an einen bestimmten BGP-Peer, den Route Reflector, der sie sammelt und wiederum via IBGP an die anderen BGP-Router im AS verteilt. Da nun jeder BGP-Router nur eine einzige BGP-Verbindung zu seinem Route Reflector zu halten braucht, fallen insgesamt nur noch n Verbindungen an.
Ein einzelner Route Reflector stellt einen Single Point of Failure dar. Zur Ausfallsicherheit können daher mehrere dieser Router als Cluster zusammengeschaltet werden. Zu jedem der Cluster-Router muss von den IBGP-Routern jeweils eine Verbindung hergestellt werden. Bei n Routern und m Route-Reflektoren ergeben sich n·m Verbindungen.
Route-Reflektoren können Router sein, die dediziert für diese Aufgabe im Netz bereitgestellt werden oder als gewöhnlicher Router im Datenpfad liegen und Route-Reflector-Funktionalität wahrnehmen.
Confederation
Durch Confederation kann ein autonomes System (AS) wiederum in autonome Systeme (Sub-AS) unterteilt werden. Diese Sub-AS erhalten unterschiedliche private AS-Nummern (ASN), für die der Bereich 64512–65535 (16-Bit-AS-Nummernbereich) bzw. 4200000000–4294967294 (32-Bit-AS-Nummernbereich) reserviert und frei verfügbar ist. Es bedarf für die Nutzung dieser AS-Nummern keiner Registrierung z. B. bei der RIPE NCC. Die AS-Nummern aus diesen privaten Bereich werden von EBGP-Routern mit öffentlichen AS-Nummern nicht an andere EBGP-Router weitergeleitet. Innerhalb des AS werden somit unterschiedliche AS-Nummern verwendet, über einen öffentlichen EBGP-Router wird aber nur die externe AS-Nummer präsentiert. Zwischen den Sub-AS kommt EBGP für den Routenaustausch zum Einsatz. Zum einen kann durch den Einsatz von Confederation die Verwaltung großer AS vereinfacht und zum anderen die Verbindungskomplexität durch die Vollvermaschung aller IBGP-Router verringert werden.Cisco-Referenz zu BGP Confederation (englisch)
hochkant=2|mini|EBGP, IBGP, Confederation und Route Reflector
In der Grafik stellen AS100 und AS200 öffentliche autonome Systeme (AS) dar, die Routen über EBGP austauschen. AS100 teilt sich durch Confederation in zwei private autonome System AS65050 und AS65100 auf. Die beiden privaten AS tauschen untereinander auch ihre Routen über EBGP aus. Innerhalb beider privater AS ist jeweils ein BGP-Router als Route Reflector (RR) konfiguriert. Alle anderen BGP-Router innerhalb eines privaten AS tauschen mit dem Route Reflector über IBGP ihre Routen untereinander aus.
Loopbackadressen
Im Gegensatz zu EBGP-Verbindungen, die in der Regel auf physischen Routerschnittstellen terminieren, werden IBGP-Verbindungen zwischen Router-Loopback-Adressen definiert. Hierdurch soll vermieden werden, dass bei Deaktivierung/Ausfall einer physischen Router-Schnittstelle die IBGP-Verbindung abbricht, obwohl der Router diese bei entsprechender Redundanzbereitstellung innerhalb des autonomen Systems über eine alternative Schnittstelle umschwenken könnte. Da aber ohne eine bereits bestehende IBGP-Verbindung die Loopback-Adressen als Route noch nicht propagiert werden können, ist ein darunterliegendes Interior Gateway Protocol (IGP) wie z. B. OSPF erforderlich. Dies bedeutet, dass auf jedem IBGP-Router auch ein IGP-Router-Prozess konfiguriert wird. Da jeder IBGP-Router mindestens zwei physische Netzwerkkarten besitzt, wird das IGP mehrere mögliche Pfade zwischen den Loopback-Adressen kennen. Fällt nun eine physische Netzwerkschnittstelle eines IBGP-Routers aus, dann wird über IGP ein alternativer Pfad propagiert. Solange mindestens eine physische Schnittstelle erreichbar ist, ist auch die auf dem Router konfigurierte Loopback-Adresse erreichbar und die IBGP-Verbindung kann innerhalb des AS unterbrechungsfrei umgeroutet werden.
Ohne Loopback-Adressen wären die IBGP-Router untereinander an physischen Schnittstellen gebunden. Bei einem Ausfall einer solchen Schnittstelle wäre die Verbindung unterbrochen und eine konsistente Verteilung von Routen innerhalb eines autonomen Systems selbst dann nicht mehr sichergestellt, wenn die interne Netzwerkinfrastruktur redundant realisiert ist.
Protokollübersicht
Die direkten Verbindungen zwischen benachbarten Routern werden manuell angegeben. Router, welche miteinander über BGP Routing-Informationen austauschen wollen, bauen zunächst eine TCP-Verbindung auf, über welche dann die BGP-Nachrichten gesendet werden. Diese Verbindung nennt man eine BGP-Session („Sitzung“).
BGP-Protokoll
Bit Offset 0–15 16–23 24–31 0 Marker (16 Bytes) 32 64 96 128 Message Length Message Type Message
Marker: Alle Bits der ersten 16 Bytes sind aus Kompatibilitätsgründen auf „1“ gesetzt. Message Length: Gesamtgröße der BGP-Nachricht Message Type: Art der BGP-Nachricht 1 = Open RFC 42712 = Update RFC 42713 = Notification RFC 42714 = KeepAlive RFC 42715 = ROUTE-REFRESH RFC 2918 Message: Bei einer Routenaktualisierung werden in diesem Bereich die Routen angegeben, welche hinzugefügt oder gelöscht wurden.
Arten von BGP-Nachrichten BGP verwendet vier verschiedene Arten von Nachrichten im Protokoll:
OPEN Wird nur zu Beginn einer Verbindung gesendet und muss mit einer KEEPALIVE-Nachricht beantwortet werden. Bei der OPEN-Nachricht werden die Parameter BGP-Version, AS-Nummer, Hold Timer, BGP Identifier sowie optionale Parameter mitgeschickt. Danach werden die Routeninformationen zwischen den Routern ausgetauscht.
UPDATE Teilt eine Pfadänderung mit. Es können pro UPDATE-Nachricht gleichzeitig mehrere Pfade hinzugefügt und mehrere entfernt werden. UPDATE-Nachrichten sind das Kernstück von BGP.
NOTIFICATION Beendet eine Verbindung und gibt Fehler- bzw. Statuscodes an. Alle Pfade, die über diese beendete Verbindung empfangen wurden, müssen nun gelöscht werden. Über ein BGP-Update würde dann verbreitet werden, dass diese Route nicht mehr verfügbar ist.
KEEPALIVE Bestätigt die OPEN-Anfrage. Zur regelmäßigen Überprüfung, ob der verbundene Router noch online ist oder ob die Verbindung unterbrochen ist und die Pfade über den verbundenen Router somit ungültig geworden sind. Die Router, welche gerade eine BGP-Session aufgebaut haben, senden sich gegenseitig in regelmäßigen Abständen eine KEEPALIVE-Nachricht. Diese besteht nur aus dem Message Header. Im Attribut Hold Time einer OPEN-Nachricht wird die maximale Zeit angegeben, in der ein BGP-Router eine KEEPALIVE-Nachricht vom BGP-Partner der Session erwartet. Kommt innerhalb der Hold Time keine KEEPALIVE-Nachricht an, wird die BGP-Session mit einer NOTIFICATION beendet.
Verbindungsstatus bei BGP
mini|Zustandsgraph von BGP
In der Grafik werden die verschiedenen Zustände einer BGP-Verbindung dargestellt. In der Praxis ist es wichtig zu wissen, dass noch keine Routingeinträge ausgetauscht werden, wenn in einer Routerkonfiguration der Status Active angezeigt wird. Dieser Status bedeutet, dass versucht wird, eine Verbindung aufzubauen. Erst wenn der Status established erreicht wurde, besteht eine funktionierende Verbindung zwischen den BGP-Routern.
Genauere Beschreibung Kernstück von BGP ist die UPDATE-Nachricht, über welche sich BGP-Router die Existenz neuer Routen (Announcement) oder den Wegfall bestehender Routen (Withdrawal) mitteilen. Der Empfänger einer UPDATE-Nachricht entscheidet anhand seiner Routing-Richtlinien („policies“), ob er sein Routing umstellt (und daraufhin selbst UPDATE-Nachrichten versenden muss), die Nachricht einfach nur weiterleitet (z. B. via IBGP) oder schlicht ignoriert.
Attribute Eine Route in BGP hat mehrere Attribute. Im Folgenden werden die wichtigsten erklärt. Der AS Path beschreibt, über welche autonomen Systeme das angegebene Ziel (ein CIDR-Präfix) erreicht werden kann. Die autonomen Systeme werden hierbei über ihre AS-Nummer (ASN) identifiziert. Im AS-Pfad darf zwar keine Schleife vorkommen; jedoch ist es erlaubt, dass sich ein AS mehrmals hintereinander einträgt und somit den AS-Pfad künstlich verlängert, um die Route zwar verfügbar, aber unattraktiv zu machen (AS Path Prepending).cisco.com: