Kann jemand erklären, warum wir iBGP für die Routen benötigen, wenn wir die IGP-Protokolle (OSPF, RIP) für die interne Kommunikation innerhalb des AS haben?
Ich habe viele Artikel und Bücher gelesen, konnte aber keine Antwort finden.
Kann jemand erklären, warum wir iBGP für die Routen benötigen, wenn wir die IGP-Protokolle (OSPF, RIP) für die interne Kommunikation innerhalb des AS haben?
Ich habe viele Artikel und Bücher gelesen, konnte aber keine Antwort finden.
Antworten:
Kann mir jemand erklären, was die IBGP-Kommunikation für die Routen erfordert, wenn wir die IGP-Protokolle (OSPF, RIP) für die interne Kommunikation haben?
Grenzen des Vertrauens / der Kontrolle durchsetzen: BGP bietet mehr Möglichkeiten zum Filtern von Peers als IGPs (um zu steuern, was Sie bewerben und erhalten).
Flexible Datenstrukturen (etwas im Zusammenhang mit dem vorherigen Aufzählungszeichen): BGP-Communities , BGP Extended-Communities , Local-Pref , usw. Diese machen BGP zu einer attraktiven Möglichkeit, benutzerdefinierte Routing-Richtlinien in Ihrem eigenen autonomen System zu implementieren (mithilfe von iBGP).
Wie bei allem gibt es Kompromisse; Die Skalierbarkeit, Steuerung und Flexibilität von iBGP bedeutet, dass das Konvergenzprotokoll langsamer ist als bei IGPs (im Allgemeinen).
1 Skalierbarkeit :
2 iBGP-Routing-Beispiel :
Um zu verstehen, warum Sie möglicherweise iBGP möchten, lesen Sie diesen Routing-Eintrag in 4.2.2.2 ...
R2>sh ip bgp 4.2.2.2
BGP routing table entry for 4.0.0.0/9, version 3146
Paths: (32 available, best #7, table Default-IP-Routing-Table)
... <!-- extra BGP RIB entries deleted -->
7660 2516 3356, (aggregated by 3356 4.69.130.4)
203.181.248.168 from 203.181.248.168 (203.181.248.168)
Origin IGP, localpref 100, valid, internal, atomic-aggregate
Community: 2516:1030
3356, (aggregated by 3356 4.69.130.6)
4.69.184.193 from 4.69.184.193 (4.69.184.193)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2012
... <!-- extra BGP RIB entries deleted -->
Es sind 32 Pfade zu berücksichtigen ... In diesem Fall hat sich BGP entschieden, über 4.69.184.193 zu 4.0.0.0/9 zu wechseln (beachten Sie den bestunter dem RIB-Eintrag). In diesem Fall hat BGP dies gewählt, da diese Route die kürzeste AS-Pfad-Liste hat. Es werden jedoch nicht alle Routen über AS3356 (an R1 angehängt) bevorzugt. Einige können aus R3 (über AS7660) bevorzugt werden. iBGP gibt Ihnen die Möglichkeit (bei R2) zu wissen, welchen Weg Sie gehen müssen, um den kürzesten BGP-Pfad zu wählen.
BGP route to 4.0.0.0/9 via
NH: 4.69.184.193 [Path: 3356]
-------->
eBGP w/ AS3356 }{ iBGP inside AS64000 }{ eBGP w/ AS7660
S1/0 S1/2 S2/1 S2/3 S3/2 S3/0
Peered w/ AS3356 +------+ +------+ +------+ Peered w/ AS7660
4.69.184.193 <------| R1 |---------| R2 |--------| R3 |-----> 203.181.248.168
+------+ +------+ +------+
| S2/0
|
^
^
| Ingress packet to 4.2.2.2
|
R1, R2 und R3 sind vollständig mit iBGP vermascht. Wenn iBGP eine Route ankündigt, bleibt der nächste Hop unverändert . Dies bedeutet, ich muss das Subnetz für 4.69.184.193 in OSPF tragen ...
R2>sh ip route 4.69.184.193
Routing entry for 4.69.184.192/30
Known via "ospf 100", distance 110, metric 65536, type intra area
Last update from 192.0.2.109 on GigabitEthernet3/1, 1w0d ago
Routing Descriptor Blocks:
* 192.0.2.109, from 192.0.2.3, 1w0d ago, via Serial2/1
Route metric is 65536, traffic share count is 1
R2>
Wenn also ein Paket für 4.2.2.2 bei R2 ankommt, sendet R2 es an Serial2 / 1, da iBGP uns sagt, dass der nächste Hop ist.
IGP ist normalerweise OSPF oder ISIS, die auf dem Verbindungsstatus basieren. Dies gibt uns alle Informationen des Netzwerks, jeder kennt das Netzwerk aus der Sicht eines jeden, was sehr interessante Konvergenzoptionen und verkehrstechnische Optionen ermöglicht.
BGP ist im Wesentlichen ein Entfernungsvektor, der eine sehr eingeschränkte Sicht auf das gesamte Netzwerk hat. BGP kann Routing-Informationen sehr gut filtern und ändern.
Das Verbindungsstatusprotokoll ist im Vergleich zum Distanzvektor ziemlich teuer, es wäre ziemlich problematisch, es auf die INET-DFZ-Größe zu skalieren.
Der Grund, warum wir beides haben, ist, dass wir innerhalb eines bestimmten Netzwerks eine ausreichend geringe Komplexität haben, um es mit dem Verbindungsstatusprotokoll zu handhaben, wodurch wir alle Vorteile eines hohen Kenntnisstands des Netzwerks erlangen können.
Da es sich jedoch nicht auf die Internetgröße skalieren lässt, benötigen wir ein anderes Netzwerk, um diese vielen Verbindungsstatusinseln zu verbinden.
Sie könnten in Ihrem eigenen Netzwerk alle Präfixe (einschließlich Kunden) in Ihrem IGP tragen, aber dies wirkt sich negativ auf die IGP-Leistung aus, während alle Konvergenz- und TE-Vorteile erzielt werden können, wenn Sie nur Loopback-Adressen von Core-Routern mitführen. Das Hinzufügen von Kundenpräfixen zu IGP beeinträchtigt nur die Netzwerkleistung, da IGP unnötig komplex wird.
Ein Grund, den ich oft gesehen habe, ist die Klarheit: Alle Routen werden innerhalb eines Routing-Protokolls (BGP) übertragen, IS-IS, OSPF oder RIP werden nur für die Nachbarschaft verwendet. Infolgedessen ist es nicht erforderlich, Routen von einem Routing-Protokoll zu einem anderen umzuverteilen.
iBGP wird nicht wirklich für das interne Routing verwendet, sondern wird von allen eBGP-Routern verwendet, um ihre Routen gemeinsam zu nutzen.
Beispiel: Wenn Sie mit 3 anderen Netzwerken zusammenarbeiten, möchten Sie, dass alle Ihre eBGP-Router die von den anderen empfangenen Routen kennen, damit sie diese Informationen bei Bedarf / Bedarf an die Peers weitergeben können (dies eröffnet Ihrem Peer die Möglichkeit des Transits durch Sie)