Diskussion:Border Gateway Protocol

Artikelqualität

Evtl sollte man sich einfach an der englischen Wikipedia Seite orientieren, die wesentlich weniger Thesen, aber dafür mehr Fakten und Referenzen darstellt.

Dieser Artikel wurde als unvollständig gekennzeichnet und Bedarf dringend einer Überarbeitung und Korrektur. Der Inhalt wurde von Autoren verfasst, die sich offensichtlich mit BGP nicht wirklich auskennen, sondern nur ein wenig nach BGP gegoogelt, und das Ganze mit copy und paste hier zusammengestellt haben.

Es fehlt der eigentliche Überblick zum BGP Protokollmechanismus, u.a. die Erläuterung der Best Path Selection anhand von Attributen, die Möglichkeit deren Values zu kontrollieren und der ganze Zusammenhang zwischen AS's und Network Prefixes - also eigentlich auch der ganze Überblick über den Sinn und Zweck des Protokolls. Kein Wort über Nachbarschaften und Möglichkeiten der Pfadbeeinflussung. Die Darstellung von iBGP und eBGP sind oberflächlich, die Bedeutung von BGP für MPLS fehlt völlig. Route Reflektoren und Confederations als Workaround zur iBGP Vollvermaschung sind auch nirgendwo erwähnt. Auch beim Load Balancing gibt es längst wirkungsvolle Workarounds. TCP 179 (als Well-Known-Port!) ist auch nicht erwähnt. Grenzknotenprotoll? Man kann sicher Alles auch irgendwie sinnentstellend ins Deutsche übersetzen... Zum weiteren Copy and Paste in Ergänzung des Artikels könnte man z.B. bei http://www.cisco.com fündig werden...

Schwächen sind ungenau oder falsch dargestellt. (HOP-Länge wird nicht berücksichtigt?!) Gegen Route Flaps gibt es schon längere Zeit "dampening".

Die Darstellung der Protokollschwächen in diesem Artikel ist zwar im theoretischen Ansatz nicht ganz falsch, aber realitätsfremd oder veraltet (z.B. Sicherheitsaspekte: Prefixes können durch Tags, communities gesichert oder neighbors durch authentisierung gesichert werden). Die Aussagen in dem Artikel insgesamt beziehen sich aber auf eine "Plain-Vanilla"-BGP Implementierung, wie sie keinesfalls eingesetzt wird. Natürlich können Hop-Längen berücksichtigt werden(AS_PATH Attribut), nur nicht im Sinne eines Distance Vektor Protokolls. Und worin besteht denn Bitte die Eingangs erwähnte Gemeinsamkeit zwischen RIP und BGP?

Nebenbei: AS Nummern sind übrigens in Erweiterung auf 4 Bytes geplant http://www.ripe.net/ripe/policies/proposals/2005-12.html (siehe auch RFC: http://tools.ietf.org/html/rfc4893)

Im Artikel über "autonome Systeme"ist aufgeführt, dass deren Anzahl auf 65.536 (16 Bit-Adressierung) begrenzt ist. Wie passt das mit den 160.000 Einträgen der Routing-Tabelle zusammen? Grüße MMS(nicht signierter Beitrag von 193.197.148.126 (Diskussion) 15:19, 4. Mai 2005 (CEST))

Es gibt derzeit etwa 26000 AS mit jeweils ca 200.000 Routen in der Tabelle. Habs mal editiert (Dez 2005)(nicht signierter Beitrag von 129.13.186.2 (Diskussion) 09:37, 10. Dez. 2005 (CET))

Hallo MMS, Zitat aus dem Artikel: "Die Stärke des BGP-Protokolls liegt darin, verschiedene optionale Routing-Pfade in einer einzigen Routing-Tabelle zu vereinen.", heist offenbar das für ein autonomes System mehrere Einträge existieren können. Gruß, Taschenrechner 20:00, 18. Mai 2005 (CEST)

Was ist Marsh? Oder ist damit Mesh von Wireless_mesh_network gemeint? (nicht signierter Beitrag von 217.185.139.123 (Diskussion) 23:58, 31. Mai 2005 (CEST))

zu den Mängel von BGP

• keine Lastverteilung (load balancing) - immer nur eine mögliche Route wird ausgewählt

- für internal-BGP kein Problem, bei external-BGP für Cisco-IOS-Router problemlos möglich

• Geschwindigkeit wird nicht berücksichtigt - Routen werden nach der Länge ausgewählt

- kein Nachteil, Linkgeschwindigkeit kann im Internet-Backbone - und hierfür wird BGP verwendet - kein Kriterium. Es geht ausschliesslich um Administrative/Betriebswirtschaftliche Gesichtspunkte von Provider-zu-Provider Verbindungen, und diese können mit BGP sehr gut abgebildet werden!

• hop Länge wird nicht berücksichtigt - nur die Anzahl der Autonomen System ist wichtig

- s. Geschwindigkeit wird nicht berücksichtigt

insgesamt scheint der Artikel der Wikipedia nicht würdig... Technische Basics wie z.B. dem Unterschied iBGP und eBGP dürfen auch in einem oberflächlichen Grundlagenartikel nicht unerwähnt bleiben... (meine Meinung)(nicht signierter Beitrag von Echoand (Diskussion | Beiträge) 14:32, 29. Dez. 2005 (CET))

Dieser Abschnitt kann archiviert werden. Thwien (Diskussion) 10:40, 20. Apr. 2012 (CEST)

Load Balancing

Sollte dann nicht der nachteil gelöscht werden. Soweit ich mich entsinne kann Juniper das auch. Was andere Hersteller machen oder nicht ist doch relative egal. Load Balancing nicht vom Protokoll abhängt sondern vom Router;-)

Gruss

  Patrick Marc
--Patrick.preuss 23:50, 7. Jan 2006 (CET)

Dieser Abschnitt kann archiviert werden. Thwien (Diskussion) 10:40, 20. Apr. 2012 (CEST)

Sonstige Mängel

Würde ich so nicht als nachteile sehen, da der Design ansatz von BGP ein anderer ist als von Internen Routing Protokollen.

BGP ist ein Politische Routing Protokoll, bei dem nicht die einzelnen Links sondern das Geld, bzw der wille der Firma oder des ISP entscheident ist. z.B. Kann es der will sein das ein einfacher Kunde nicht das Private Peering nutzt weil dieses Geld kostet sondern über den langsamern flatrate link nutzt oder das man HTTP verkeher über einen lansamern link schickt als den Zeit kritischen VPN Verker.

Hier ein Vorschlag BGP

--Patrick.preuss 23:50, 7. Jan 2006 (CET)

Hi Patrick, guck mal in die jetzige Version von Routing; dort habe ich einen Abschnitt "Routing im Internet" hinzugefuegt und die Peer/Peer-, Provider/Customer-, Peer/Customer-Links erklaert. Prinzipiell stellt sich schon die Frage, was man bei BGP und was man generell bei Routing erklaert. Ich wollte eben einen groben, wenig technischen Ueberblick ueber Routing im Internet geben. Das ist m.E. etwas, was man auch viel zu wenig findet, egal ob in der Wikipedia oder sonstwo: wie funktioniert das, dass die Pakete von hier nach Australien den richtigen Weg finden? Von daher fand ich die Erklaerung dort passender als hier, da es hier wohl eher um die technischen Details von BGP gehen sollte (oder was meint ihr?). --Wutzofant (✉✍) 15:19, 7. Feb 2006 (CET)

Dieser Abschnitt kann archiviert werden. Thwien (Diskussion) 10:40, 20. Apr. 2012 (CEST)

eBGP und iBGP

"Beim Einsatz innerhalb eines autonomen Systems müssen BGP-Verbindungen („BGP-Sessions“) zwischen allen Routern des AS eingerichtet werden (genauer: zwischen ihren Loopbackadressen), so dass eine vollständige Vermaschung (full mesh) entsteht."

Mit dem fett hervorgehobenen Teil bin ich nicht zufrieden: Zunächst kann eine Netzwerkverbindung nicht zwischen zwei Adressen hergestellt werden, sondern nur zwischen den beteiligten Netzwerk-Interfaces oder (auf höherem Abstraktionsniveau) zwischen 2 Rechnern (diese können auch Router sein).

Ich vermute mal, dass ursprünglich auf die Tatsache Bezug genommen wurde, dass jeder BGP-sprechende Router einen eindeutigen "BGP Identifier" haben muss. Diese werden üblicherweise mit einer der IP-Adressen des betreffenden Routers initialisiert, und soweit ich das mittels google erschließen konnte, sind hier wiederum Loopback-Adressen gern genommen, da sie im Gegensatz zu "echten" IP-Adressen ausfallsicher sind.

Update: Ich habe mich zwischenzeitig weiter in die Materie eingelesen und weiß jetzt, was gemeint ist: Die Router benutzen für ihre Kommunikation (virtuelle) Loopback-Adressen, die an kein physisches Interface gebunden sind, und die vorher an alle IGP-Peers propagiert werden müssen. Diese Technik ermöglicht einen logischen Full Mesh selbst dann, wenn keine physische vollständige Vermaschung besteht. Da die Verwendung von Loopback-Adressen in diesem Zusammenhang zwar gebräuchlich ist, ich sie jedoch für alles andere als intuitiv verständlich halte (der Artikel Loopback hilft hier leider nicht weiter), bin ich dafür, den erwähnten Satz zunächst zu streichen und die Loopback-Adressen evtl. später ausführlich zu erklären.

Was denkt ihr? --EdwardBaynes 18:31, 1. Mai 2006 (CEST)

Zu den Loopback - Adressen und den BGP Peers: Es ist nirgends zwingend vorgeschrieben, dass BGP Sessions auf Loopback Adressen eingerichtet werden muessen. Das ganze wird aus Gruenden der Ausfallsicherheit gemacht. Router haben fuer gewoehnlich mindestens 2 physikalische Interface. :-) Wenn nun eine BGP Session auf ein physikalisches Interface gebunden wird und dieses Interface ausfaellt, dann ist die BGP Session betroffen und der Peer stirbt; ganz egal ob der Router noch ueber ein anderes physikalisches Interface erreichbar waere. Wenn die BGP Session auf der Loopback Adresse konfiguriert wird, dann bleibt der BGP Peer solange am Leben, solange noch mindestens ein physikalsches Interface den Router erreichbar macht. Bei Nortel Routern wird das Loopback Interface auch als Circuitless IP bezeichnet, was das ganz vielleicht ein wenig deutlicher macht. ---> GRUSS HEIKO

Ich hab mir vorgenommen, den von mir kritisierten Abschnitt grundlegend zu überarbeiten, um die Notwendigkeit des Full Mesh sowie die Relevanz der Loopback-Adressen klarer herauszuarbeiten. Außerdem könnt man zusätzlich zu den Route Reflectors auch noch Confederations erklären, die ja auch ebenso dazu dienen, die schlechte Skalierbarkeit von BGP in den Griff zu kriegen. Aus eigener Erfahrung weiß ich, dass auch einfache Grafiken hier die Verständlichkeit erheblich fördern können.

Als ich den Unterschied zwischen iBGP und eBGP gerade beschreiben wollte, fiel mir auf, dass hierfür erstmal klar sein sollte, dass BGP ein Pfadvektorprotokoll ist und worum es sich dabei handelt, daher hab ich das mal vorangestellt. Mit der Formulierung bin ich selbst nicht 100%-ig glücklich, die Routingschleifen sollten vielleicht gesondert und nicht nur in einem Nebensatz erklärt werden. Wenn jemand dazu eine gute Idee hat, nur zu. Gruß--EdwardBaynes 23:39, 12. Mai 2006 (CEST)

Stimme EdwardBaynes zu: Die iBGP-Verbindungen werden nur üblicherweise zwischen loopback-Adressen aufgebaut. Den oben fett markierten Satzteil habe ich etwas entschärft. Sigkill 20:15, 25. Mär. 2008 (CET)

Dieser Abschnitt kann archiviert werden. Thwien (Diskussion) 17:34, 26. Apr. 2012 (CEST)

Update Messages

Laut dem RFC4271 Können in einem Update auch mehrer Routen hinzugefügt werden solage die Routen die gleichen Attribute besitzen. Sollte man in der beschreibung ändern

Dieser Abschnitt kann archiviert werden. Thwien (Diskussion) 10:40, 20. Apr. 2012 (CEST)

Mängel von BGP

Der Absatz zu "Mängel von BGP" ist so an der Realität vorbei, dass ich Ihn gerne löschen würde. Leider wurde er sofort wieder hergestellt. Keiner der dort aufgeführten "Mängel" lassen sich begründen. Bitte lasst diesen Absatz gelöscht!

Ja nu, wie wäre es, die Hilfe:Zusammenfassung und Quelle zu benutzen und das interwiki drinzulassen? --Löschkandidat 17:22, 21. Dez. 2006 (CET)

Über die Formulierung bei "Mängel" können wir reden. Es geht bei BGP in der Tat um Policys, nicht um Optimalität. Andererseits sollte genau das erwähnt bleiben. Über Update Bursts und Route Flaps gibt's etliche wissenschaftliche Veröffentlichungen; das sollte auf jeden Fall drinbleiben. --Wutzofant (✉✍) 17:29, 21. Dez. 2006 (CET)

Mich stört bei der Auflistung der Mängel vor allem die Tatsache dass dort Fehler drin sind. Man darf BGP auf keinen Fall mit IGPs über einen Kamm scheren. Diese Auflistung sieht für mich eher danach aus, als ob das von irgendeiner Präsentation kopiert wurde.

Lastverteilung kann zumindest bei Cisco konfiguriert werden. Bei anderen Herstellern wird das sicherlich auch gehen. Linkgeschwindigkeit wird nicht berücksichtigt Das ist auch nicht die Aufgabe von BGP. Hier geht es meistens nicht um Geschwindigkeit, sondern darum was die Verwendung eines Links zu einem andern ISP kostet. Hop-Länge wird nicht berücksichtig. Klar, deswegen wird BGP ja auch als Path Vector Protocol bezeichnet und nicht als Distance Vector Protocol. Sicherheitsaspekte werden nur mangelhaft berücksichtig. Welche Sicherheitsaspekte sind das denn? Was könnte man an BGP denn sicherer machen? --Trewwerer 16:58, 22. Dez. 2006 (CET)

Habs nochmal umformuliert -- gefällt's dir so jetzt besser?

Achja: Path Vector deswegen, weil eben der komplette Pfad übermittelt wird anstatt nur der Kosten wie bei Distance-Vector. Man könnte aus BGP genausogut ein Distance-Vector-Protokoll machen, wo einfach die Anzahl der AS-Hops drinsteht statt des kompletten AS-Pfades, aber dann könnte man keine so schöne Spielchen wie "ich möchte über AS xyz nicht routen" spielen... und vermutlich könnten zwischenzeitlich nach einem Update auch mal Routingschleifen temporär auftreten. Aber DV und Path-Vector hat IMO nix damit zu tun, dass man als Metrik einfach die Anzahl der ASe nimmt, statt der Anzahl der Router-Hops oder gar die aufsummierten Link-Delays... --Wutzofant (✉✍) 19:46, 3. Jan. 2007 (CET)

vielleicht ist das interessant: http://www.heise.de/newsticker/Fehlkonfigurierter-Router-beeintraechtigt-Teile-des-Internet--/meldung/132687 --Kazie 14:57, 17. Feb. 2009 (CET)

Oma-Tauglichkeit?

Ich habe hier anlässlich der Massenproteste in Ägypten Proteste in Ägypten 2011 nachlesen wollen, warum und wie es der Regierung möglich war, die gesamte Internetverbindungen lahmzulegen. Eine mir verständliche Antwort habe ich hier nicht gefunden. Mfg --217.247.102.236 11:50, 2. Feb. 2011 (CET)

+1 = In einer offensichtlich konzertierten Aktion ist etwa eine halbe Stunde vor Mitternacht (MEZ) fast der gesamte ägyptische Teil des Internets offline gegangen. Binnen Minuten wurden rund 3.500 individuelle BGP-Routen (Border Gateway Protocol) aller großen ägyptischen ISP zurückgezogen und damit praktisch gelöscht, wie Renesys informiert. Damit ist kaum noch ein Autonomes System (AS) in Ägypten von außen erreichbar. Es handelt sich praktisch um die erste vorsätzliche, nahezu komplette und plötzliche Abschottung eines gesamten Landes vom Internet,... [heise] Dieser Teil ist mir nicht verständlich - ich hätte hier gerne eine laienverständliche Antwort gefúnden. MfG --Maßhaltender 12:13, 2. Feb. 2011 (CET)

Dieser Abschnitt kann archiviert werden. Thwien (Diskussion) 10:40, 20. Apr. 2012 (CEST)

Engpass

Am 12. August 2014 kam es zu einem deutlichen Engpass bei Verwendung von BGP [1] [2] Vielleicht passt die Meldung irgendwo hinein oder ist nützlich, wenn solche Probleme wiederholt auftreten. --Pinguin55 (Diskussion) 19:19, 14. Aug. 2014 (CEST)

facebook problem am 04.10.2021

das problem lag an fehlerhaften bgp-updates https://www.computerbase.de/2021-10/dns-fehler-facebook-whatsapp-und-instagram-sind-offline/ --Dnvuma (Diskussion) 23:02, 4. Okt. 2021 (CEST)