„Border Gateway Protocol“ – Versionsunterschied
[gesichtete Version] | [ungesichtete Version] |
Thwien (Diskussion | Beiträge) →BGP-Protokoll: Erweiterung der Protokolltabelle um Message-Block |
Thwien (Diskussion | Beiträge) →Protokollübersicht: Verbindungsstatus |
||
Zeile 44: | Zeile 44: | ||
== Protokollübersicht == |
== Protokollübersicht == |
||
⚫ | |||
Die direkten Verbindungen zwischen benachbarten Routern werden manuell angegeben. |
Die direkten Verbindungen zwischen benachbarten Routern werden manuell angegeben. |
||
Router, welche miteinander über BGP Routinginformationen austauschen wollen, bauen zunächst eine [[Transmission Control Protocol|TCP]]-Verbindung auf, über welche dann die BGP-Nachrichten gesendet werden. Diese Verbindung nennt man eine ''BGP-Session''. |
Router, welche miteinander über BGP Routinginformationen austauschen wollen, bauen zunächst eine [[Transmission Control Protocol|TCP]]-Verbindung auf, über welche dann die BGP-Nachrichten gesendet werden. Diese Verbindung nennt man eine ''BGP-Session''. |
||
Zeile 98: | Zeile 98: | ||
'''KEEPALIVE'''<br /> |
'''KEEPALIVE'''<br /> |
||
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. |
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 === |
|||
⚫ | |||
In der Grafik werden die verschiedenen Zustände eine BGP-Verbindung dargestellt. In der Praxis ist es wichtig zu wissen, dass wenn in einer Routerkonfiguration der Status ''Active'' angezeigt wird, noch keine Routingeinträge ausgetauscht werden. 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 == |
== Genauere Beschreibung == |
Version vom 23. April 2012, 18:49 Uhr
Anwendung | BGP | ||||
Transport | TCP | ||||
Internet | IP (IPv4, IPv6) | ||||
Netzzugang | Ethernet | Token Bus |
Token Ring |
FDDI | … |
Das Border Gateway Protocol (BGP) ist das im Internet eingesetzte Routingprotokoll und verbindet Autonome Systeme (AS) miteinander. Diese Autonomen Systeme werden in der Regel von Internetprovidern gebildet. BGP wird allgemein als Exterior Gateway Protokoll (EGP) und Pfadvektorprotokoll bezeichnet und verwendet für Routing-Entscheidungen betriebswirtschaftliche und nicht technisch-metrische Kriterien. Innerhalb Autonomer Systeme kommen Interior Gateway Protokolle (IGP) wie z.B. OSPF zum Einsatz.
BGP-Protokoll
Das BGP-Protokoll 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 sog. 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).
IBGP
BGP kann auch innerhalb eines autonomen Systems angewendet werden. Typischerweise geschieht dies, um die von EBGP-Routern gelernten Routen an die anderen Router des eigenen Autonomen Systems zu propagieren. Diese Verwendung wird als Internal BGP (IBGP) bezeichnet. Alle IBGP-Router, die zusammen Routen austauschen, verwenden dieselbe AS-Nummer.
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. Üblicherweise werden diese Verbindungen zwischen den Loopbackadressen der beteiligten Router eingerichtet, so dass ein darunterliegendes Interior Gateway Protocol (IGP) erforderlich ist. 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.
Route Reflector
Verwendet ein AS stattdessen einen Route Reflector, so schickt jeder EBGP-Router seine via EBGP gelernten Routen via IBGP nur noch an einen bestimmten Router (den Routen-Reflektor), der sie sammelt und wiederum via IBGP an die anderen Router im AS verteilt. Da nun jeder BGP-Router nur eine einzige BGP-Verbindung zum Route Reflector halten muss, 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 jeden der Cluster-Router muss von den IBGP-Routern jeweils eine Verbindung hergestellt werden. Bei n Routern ergeben sich beispielsweise bei zwei Routern als Route Reflector n·2 Verbindungen.
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 ein Bereich von 64512 bis 65535 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.[1]

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.
Protokollübersicht
Die direkten Verbindungen zwischen benachbarten Routern werden manuell angegeben. Router, welche miteinander über BGP Routinginformationen austauschen wollen, bauen zunächst eine TCP-Verbindung auf, über welche dann die BGP-Nachrichten gesendet werden. Diese Verbindung nennt man eine BGP-Session.
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
- 2 = Update
- 3 = Notification
- 4 = KeepAlive
- 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

In der Grafik werden die verschiedenen Zustände eine BGP-Verbindung dargestellt. In der Praxis ist es wichtig zu wissen, dass wenn in einer Routerkonfiguration der Status Active angezeigt wird, noch keine Routingeinträge ausgetauscht werden. 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-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).
- Die IGP-Metrik beschreibt die Kosten durch das eigene Netzwerk, um den Austrittspunkt in das nächste AS auf dem AS-Pfad zu erreichen.
- Der Multi-Exit Discriminator (MED) wird verwendet, um verschiedene parallele Verbindungen zum gleichen Nachbar-AS zu priorisieren, bevorzugt wird der jeweils kleinste Wert. Dieses Attribut wird zwischen EBGP-Peers verwendet.
- Communities sind Routing Tags, anhand welcher Updates bzw. übermittelte Präfixe zu anderen BGP-Peers markiert werden können. Eine BGP-Community ist ein 32-Bit-Wert, der von anderen BGP-Routern als Filterkriterium verwendet werden kann. Neben Standard-Communities können sog. Extended Communities in der Notation 12345:12345 oder als Dezimalzahl frei verwendet werden.
- Local Preference legt durch den jeweils höheren Wert einen bevorzugten Pfad aus mehreren Pfaden innerhalb des gleichen AS fest. Falls es zum gleichen Zielpräfix mehrere Routen mit gleich langen AS-Pfaden gibt, dann kann man über Local Preference bestimmte Routen bevorzugen; vgl. Abschnitt „Pfadauswahl“.
- Next Hop ist die Angabe der IP-Adresse des Next-Hop-Routers zu einem Präfix. Der Next-Hop-Router ist derjenige Gateway-Router, welcher das eigene AS mit dem nächsten AS auf dem AS-Pfad verbindet.
- Weight ist ein lokales Attribut (proprietär); vgl. Abschnitt „Pfadauswahl“.
- Origin gibt die Quelle eines Präfixes an: IGP, EGP oder Incomplete.
Pfadauswahl
Sehr oft kommt es vor, dass ein Router zum selben Ziel verschiedene Routen mitgeteilt bekommt. Die Auswahl der Route, für welche er sich letztendlich entscheidet, ist als BGP Path Selection Process bekannt. Der Netzwerkbetreiber kann die Pfad-Auswahl im Router durch die Wahl geeigneter Regeln im Router steuern und beeinflussen.
Grundsätzlich läuft der BGP Path Selection Process nach folgenden Regeln ab:
- Der Pfad mit dem größten Wert für Weight wird bevorzugt (proprietär).
- Wenn der Wert für Weight identisch ist, wird der Wert mit der größten Local Preference bevorzugt.
- Wenn die Werte für Local Preference gleich sind, wird der Pfad bevorzugt, der von BGP auf diesem Router generiert wurde.
- Wenn kein Pfad auf diesem Router generiert wurde, bevorzuge den Pfad mit dem kürzesten AS_PATH-Attribut.
- Wenn alle AS_PATH-Attribute die gleiche Länge haben, bevorzuge den niedrigsten Origin-Typ (IGP ist niedriger als EGP, EGP ist niedriger als Incomplete)
- Wenn alle Origin-Typen gleich sind, bevorzuge den Pfad mit dem niedrigsten MED-Attribut.
- Wenn alle Pfade den gleichen Wert für MED haben, bevorzuge externe Pfade gegenüber interner Pfade.
- Wenn immer noch alle Pfade die gleiche Priorität haben, bevorzuge den Pfad zum nächstgelegenen IGP-Nachbarn.
- Sollten alle Pfade gleich sein, bevorzuge den Pfad mit der niedrigsten IP Adresse des BGP-Peers bezogen auf die Router-ID.
Zusammenspiel von IBGP mit dem IGP
Damit ein Router ein Paket an ein anderes Netz weiterleiten kann, zu welchem er keine unmittelbare Verbindung hat, ist in der Regel ein Zusammenspiel von IBGP und dem IGP (dem Intradomain-Routingprotokoll, also beispielsweise OSPF, IS-IS, (E)IGRP, RIP) vonnöten, welches benötigt wird, um Pakete zum entsprechenden Gateway-Router weiterzuleiten. Hierzu dient das BGP-Attribut Next Hop.
Beispiel: Ein Router R1 in AS1 soll ein Paket zur Zieladresse 10.1.2.3 forwarden. Durch eine IBGP-Update-Nachricht hat er zuvor erfahren, dass das Zielnetz 10.0.0.0/8 über das Nachbar-AS 4711 erreichbar ist. Allerdings hat R1 keine unmittelbare Verbindung zu AS4711; diese Verbindung existiert nur an einem anderen Router R2 (Gateway-Router). Durch das BGP-Attribut Next Hop kennt R1 jedoch die IP-Adresse von R2. Aufgrund der Informationen des IGP kennt R1 den kürzesten Pfad innerhalb von AS1 zu R2 und weiß somit, zu welchem Nachbar-Router Rx er das Paket schicken muss, so dass es beim Gateway-Router R2 ankommt, welcher es schließlich in AS4711 weiterleiten kann.
Besonderheiten bei BGP
Routingschleifen
BGP ist ein Pfadvektorprotokoll. Seine Funktionsweise ist stark an Distanzvektoralgorithmen und -protokollen wie z.B. Routing Information Protocol (RIP) angelehnt, jedoch wird dem dort vorkommenden Problem der Routingschleifen effektiv vorgebeugt. Eine Routingschleife entsteht, wenn ein IP-Paket auf seinem Weg durch das Internet ein- und dasselbe AS mehrmals passiert. Ein BGP-Router teilt beim Senden von Routinginformationen (Update) dem Kommunikationspartner nicht nur mit, dass er einen bestimmten Abschnitt des Internets erreichen kann, sondern auch die komplette Liste aller Autonomer Systeme (AS-Path), die IP-Pakete bis zu diesem Abschnitt passieren müssen (sein eigenes AS steht dabei an erster, das Ziel-AS an letzter Stelle). Merkt der Kommunikationspartner nun, dass das AS, dem er selbst angehört, bereits in dieser Liste vorhanden ist, verwirft er dieses Update und vermeidet so, dass eine Routingschleife entsteht.
Route Aggregation
Bei BGP kann jeder Router gemeinsame Routen zusammenfassen. Im Gegensatz z.B. bei OSPF, auf deren Routern eine Routing-Zusammenfassung nur auf den Area Border Routern durchgeführt werden kann.
Link-State
Unterschiedliche Linkgeschwindigkeiten werden nicht berücksichtigt. Die Routen werden hauptsächlich nach der Länge und nach betriebswirtschaftlichen Aspekten ausgewählt.
Hop-Länge
Die Hop-Länge wird nicht berücksichtigt – nur die Anzahl der autonomen Systeme ist wichtig (abgesehen vom Attribut IGP-Metrik).
Probleme bei BGP
Allgemein
BGP weist prinzipbedingt eine Reihe von Schwächen auf, die in einer Minimalkonfiguration entstehen können. Die Schwächen werden jedoch in der Regel dadurch kompensiert, dass die Priorisierung von Pfaden Routing-Policies unterliegt, die der jeweilige Netzbetreiber steuert.
Wachstum von Routingtabellen

Da jeder BGP-Router über Routeninformationen von anderen, insbesondere der benachbarten BGP-Routern verfügt, baut sich jeder BGP-Router eine Datenbank für die Routen zu allen erreichbaren autonomen Systemen auf. Die Größe der Tabelle mit den Routen-Informationen im April 2012 bei etwa 408.000 Einträgen bei über 40.800 autonomen Systemen.[2]
Ende 2005 | April 2011 | April 2012 | |
---|---|---|---|
Routingeinträge | 170.000 | 360.000 | 408.000 |
Autonome Systeme | 26.000 | 37.000 | 40.800 |
Dem Wachstum der Routingtabellen kann in Grenzen durch Route Aggregation entgegengewirkt werden.
Lastverteilung
BGP bringt standardmäßig keine Verfahren zur Lastverteilung mit. Es wird immer nur eine mögliche Route ausgewählt. Es existieren jedoch proprietäre Erweiterungen, die eine Konfiguration zur Lastverteilung ermöglichen.[3] Diese Erweiterungen ermöglichen im Gegensatz z.B. zu OSPF eine Lastverteilung auf unterschiedlich gewichteten Verbindungen.
Sicherheit
In der Grundkonfiguration ist ein BGP-Router anfällig für Spoofing-Angriffe, durch die Angreifer Routen manipulieren können.[4][5][6][7] Durch den Einsatz von Authentifizierung mit einem zwischen den BGP-Peers individuell festgelegten Passwort (basierend auf MD5-Hashes), kann der Datenaustausch zwischen den BGP-Routern gesichert werden. Dies erschwert Spoofing-Angriffe zwar stark, ist aber insbesondere von der Sicherheit von MD5 abhängig, welches inzwischen von Krypto-Experten als nicht mehr sicher angesehen wird.
Daneben wurden und werden verschiedene weitere Sicherheitsmechanismen für BGP vorgeschlagen[4]; allerdings wäre es selbst bei einem flächendeckenden Einsatz vorgeschlagener Verfahren nahezu unmöglich, Angriffe, welche die Umleitung von Verkehrsströmen beabsichtigen, vollständig zu unterbinden.[8]
Route Flap
Route Flaps werden von Routen verursacht, welche über längere Zeiträume hinweg immer wieder hin- und herschwanken, annonciert und wieder zurückgezogen werden.[9] Als Gegenmaßnahme bieten moderne BGP-Implementierungen ein Verfahren namens Route Flap Damping, welches jedoch unter bestimmten Bedingungen zu unerwünscht langen Verzögerungen bei der Weiterleitung von Routenänderungen führen kann.[10]
Update Bursts
Update Bursts sind plötzlich auftretende große Mengen an UPDATE-Nachrichten, oft zu miteinander nicht näher korrelierten Zielen.[11]
Besondere Ereignisse
YouTube-Blockade
Im Februar 2008 wurde Pakistan Telecom durch einen Gerichtsbeschluss dazu gezwungen, YouTube-Verkehr in Pakistan zu blockieren. Technisch wurde dies umgesetzt, indem eine falsche Route zum Netzwerk von YouTube in IBGP eingespeist wurde. Durch einen Konfigurationsfehler wurde diese falsche Route jedoch nicht nur in Pakistan verwendet, sondern irrtümlich auch via EBGP an andere Internetprovider verteilt, was insbesondere in Asien zu mehrstündigen Blockaden von YouTube führte.[12][13]
Fehlkonfigurierter BGP-Router
Im Februar 2009 wurde über einen tschechischen BGP-Router zu lange AS-Pfade an öffentliche BGP-Router weitergeleitet. Einige BGP-Router hatten Probleme in der Verarbeitung dieser langen AS-Pfade, so dass es zu Beeinträchtigungen des Internetverkehrs kam. Administratoren können durch eine Konfiguration, in welche die maximale Länge des akzeptierten AS-Pfads beschränkt wird, einem solchen Problem entgegenwirken.[14][15]
Revolution in Ägypten 2011/2012
Während der Revolution in Ägypten wurden im Januar 2011 in wenigen Minuten ca. 3.500 Routen via BGP aller ägyptischer Internetprovider zurückgezogen, so dass fast ganz Ägypten vom Internet getrennt war. Auch Mobilfunkdienste und soziale Netze waren nicht mehr erreichbar. Dieses scheint der erste Fall in der Geschichte des Internets zu sein, in welchem aus politischen Gründen ein gesamtes Land vom Internet abgeschottet wurde.[16]
Freie Software-Implementierungen
- Bird Internet Routing Daemon
- GNU Zebra (Entwicklung eingestellt)
- Quagga (Weiterentwicklung von Zebra)
- OpenBGPD
- eXtensible Open Router Platform
Siehe auch
- Interior Gateway Protokoll (IGP)
- Exterior Gateway Protokoll (EGP)
- Autonome Systeme (AS)
- Pfadvektorprotokoll
Weblinks
- RFC 4271 - "A Border Gateway Protocol 4 (BGP-4)"
- RFC 4456 - "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)"
- RFC 4275 - "BGP-4 MIB Implementation Survey"
- RFC 5065 - "Autonomous System Confederations for BGP"
- RFC 4893 - "BGP Support for Four-octet AS Number Space"
- RFC 2439 - "BGP Route Flap Damping"
- RFC 4760 - "Multiprotocol Extensions for BGP-4"
- BGPlay - Ein Java-Programm zur grafischen Darstellung von BGP-Routingaktivitäten
Einzelnachweise
- ↑ Cisco-Referenz zu BGP Confederation (Englisch)
- ↑ bgp.potaroo.net – AS65000 BGP Routing Table Analysis Report (englisch) abgerufen am 13. April 2012
- ↑ IP Routing: BGP Best Path Selection Algorithm. auf: cisco.com
- ↑ a b Kevin Butler, Toni Farley, Patrick McDaniel, and Jennifer Rexford: A survey of BGP security issues and solutions. In: Proceedings of the IEEE, Januar 2010
- ↑ Barry Raveendran Greene: BGPv4 Security Risk Assessment. auf: cymru.com
- ↑ Auflistung wissenschaftlicher Veröffentlichungen zum Thema BGP-Sicherheit
- ↑ Router lügen nicht - Was wenn doch? auf: heise security online 27. August 2008.
- ↑ Sharon Goldberg, Michael Schapira, Peter Hummon, and Jennifer Rexford: How secure are secure interdomain routing protocols? In: Proceedings of the ACM SIGCOMM conference, August 2010.
- ↑ C. Labovitz, G. Malan, F. Jahanian: Internet routing instability. IEEE/ACM Transactions on Networking, 6(5) 1998, S. 515–528.
- ↑ Zhenhai Duan, Jaideep Chandrashekar, Jeffrey Krasky, Kuai Xu, Zhi-Li Zhang: Damping BGP Route Flaps. Proceedings of the 23rd IEEE International Performance Computing and Communications Conference (IPCCC), 2004.
- ↑ Ke Zhang, Amy Yen, Xiaoliang Zhao, Dan Massey, S. Felix Wu, Lixia Zhang: On Detection of Anomalous Routing Dynamics in BGP. In: LNCS NETWORKING 2004. ISBN 3-540-21959-5.
- ↑ heise.de - Pakistan sperrt YouTube
- ↑ Renesys: Pakistan hijacks Youtube
- ↑ heise.de - Fehlkonfigurierter Router
- ↑ Renesys: Reckless Driving on the Internet sowie Longer is not Always Better
- ↑ heise.de - Ägypten ist offline