Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP – Übersicht

Verstehen von BGP

BGP ist ein Exterieur-Gateway-Protokoll (EGP), das zum Austausch von Routing-Informationen zwischen Routern in verschiedenen autonomen Systemen (ASs) verwendet wird. BGP-Routinginformationen enthalten die vollständige Route zu jedem Ziel. BGP verwendet die Routing-Informationen, um eine Datenbank mit Netzwerkverfügbarkeitsinformationen zu pflegen, die mit anderen BGP-Systemen ausgetauscht werden. BGP verwendet die Informationen zur Netzwerkverfügbarkeit, um ein Diagramm der AS-Konnektivität zu erstellen, mit dem BGP Routing-Schleifen entfernen und Richtlinienentscheidungen auf AS-Ebene durchsetzen kann.

Multiprotocol BGP (MBGP)-Erweiterungen ermöglichen BGP die Unterstützung von IP-Version 6 (IPv6).MBGP definiert die Attribute MP_REACH_NLRI und MP_UNREACH_NLRI, die zur Übertragung von IPv6-Erreichbarkeitsinformationen verwendet werden. NLRI-Aktualisierungsmeldungen (Network Layer Reachability Information) tragen IPv6-Adress-Präfixe möglicher Routen.

BGP ermöglicht richtlinienbasiertes Routing. Sie können Routing-Richtlinien verwenden, um zwischen mehreren Pfaden zu einem Ziel zu wählen und die Neuverteilung von Routing-Informationen zu steuern.

BGP verwendet TCP als Transportprotokoll und verwendet Port 179 zum Herstellen von Verbindungen. Durch die Ausführung eines zuverlässigen Transportprotokolls entfällt die Notwendigkeit von BGP zur Implementierung von Update-Fragmentierung, Retransmission, Bestätigung und Sequenzierung.

Die Routingprotokollsoftware Junos OS unterstützt BGP Version 4. Diese BGP-Version bietet zusätzliche Unterstützung für Classless Interdomain Routing (CIDR), wodurch das Konzept der Netzwerkklassen entfällt. Anstatt davon auszugehen, welche Bits einer Adresse das Netzwerk darstellen, indem Sie sich das erste Oktett ansehen, ermöglicht CIDR es Ihnen, die Anzahl der Bits in der Netzwerkadresse explizit anzugeben, wodurch eine Möglichkeit zur Verkleinerung der Größe der Routingtabellen bereitgestellt wird. BGP Version 4 unterstützt auch die Aggregation von Routen, einschließlich der Aggregation von AS-Pfaden.

In diesem Abschnitt werden die folgenden Themen behandelt:

Autonome Systeme

Ein autonomes System (AS) ist ein Satz von Routern, die einer einzigen technischen Verwaltung unterliegen und normalerweise ein einziges Interior Gateway-Protokoll und eine gemeinsame Reihe von Metriken verwenden, um Routing-Informationen innerhalb des Router-Satzes weiterzuverbreiten. Für andere ASs scheint ein AS einen einzigen, kohärenten Innenroutingplan zu haben und bietet ein einheitliches Bild davon, welche Ziele über sie erreichbar sind.

AS-Pfade und -Attribute

Die Routing-Informationen, die von BGP-Systemen ausgetauscht werden, umfassen die vollständige Route zu jedem Ziel sowie zusätzliche Informationen über die Route. Die Route zu jedem Ziel wird AS-Pfad genannt, und die zusätzlichen Routeninformationen sind in den Pfadattributen enthalten. BGP verwendet den AS-Pfad und die Pfadattribute, um die Netzwerktopologie vollständig zu bestimmen. Sobald BGP die Topologie versteht, kann es Routing-Schleifen erkennen und beseitigen und zwischen Routengruppen auswählen, um administrative Präferenzen und Entscheidungen von Routing-Richtlinien durchzusetzen.

Externes und internes BGP

BGP unterstützt zwei Arten des Austauschs von Routing-Informationen: Austausch zwischen verschiedenen ASS und Austausch innerhalb eines einzigen AS. Bei Verwendung unter ASs wird BGP als externe BGP (EBGP) bezeichnet, und BGP-Sitzungen führen Inter-AS-Routing durch. Bei Verwendung innerhalb eines AS wird BGP als interne BGP (IBGP) bezeichnet, und BGP-Sitzungen führen intra-AS-Routing durch. Abbildung 1 zeigt ASs, IBGP und EBGP.

Abbildung 1: ASs, EBGP und IBGPASs, EBGP und IBGP

Ein BGP-System teilt Die Informationen zur Erreichbarkeit des Netzwerks mit benachbarten BGP-Systemen, die als Nachbarn oder Peers bezeichnet werden.

BGP-Systeme werden in Gruppen geordnet. In einer IBGP-Gruppe befinden sich alle Peers in der Gruppe ( interne Peers genannt ) in der gleichen AS. Interne Peers können überall im lokalen AS sein und müssen nicht direkt miteinander verbunden werden. Interne Gruppen verwenden Routen von einem IGP, um Weiterleitungsadressen aufzulösen. Sie verbreiten auch externe Routen unter allen anderen internen Routern, auf denen IBGP ausgeführt wird, indem sie den nächsten Hop berechnen, indem sie den empfangenen BGP Next Hop mit der Route nehmen und ihn mitHilfe von Informationen von einem der Internen Gateway-Protokolle auflösen.

In einer EBGP-Gruppe befinden sich die Peers in der Gruppe ( externe Peers genannt ) in verschiedenen ASs und teilen sich normalerweise ein Subnetz. In einer externen Gruppe wird der nächste Hop in Bezug auf die Schnittstelle berechnet, die zwischen dem externen Peer und dem lokalen Router gemeinsam genutzt wird.

Mehrere Instanzen von BGP

Sie können mehrere Instanzen von BGP auf den folgenden Hierarchieebenen konfigurieren:

  • [edit routing-instances routing-instance-name protocols]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

Mehrere Instanzen von BGP werden in erster Linie zur Layer 3-VPN-Unterstützung verwendet.

IGP-Peers und externe BGP (EBGP)-Peers (sowohl Nonmultihop als auch Multihop) werden für Routing-Instanzen unterstützt. BGP-Peering wird über eine der in der routing-instances Hierarchie konfigurierten Schnittstellen eingerichtet.

Anmerkung:

Wenn ein BGP-Nachbar BGP-Nachrichten an das lokale Routinggerät sendet, muss die eingehende Schnittstelle, an der diese Nachrichten empfangen werden, in derselben Routinginstanz konfiguriert werden, in der die BGP-Nachbarkonfiguration vorhanden ist. Dies gilt für Nachbarn, die einen einzelnen Hop entfernt oder mehrere Hops entfernt sind.

Die vom BGP-Peer gelernten Routen werden standardmäßig der instance-name.inet.0 Tabelle hinzugefügt. Sie können Import- und Exportrichtlinien konfigurieren, um den Datenfluss in und aus der Routingtabelle der Instanz zu steuern.

Konfigurieren Sie für layer 3-VPN-Unterstützung BGP auf dem Provider Edge (PE)-Router, um Routen vom Customer Edge (CE)-Router zu erhalten und gegebenenfalls die Routen der Instanzen an den CE-Router zu senden. Sie können mehrere Instanzen von BGP verwenden, um separate Weiterleitungstabellen pro Standort zu pflegen, um den VPN-Datenverkehr auf dem PE-Router getrennt zu halten.

Sie können Import- und Exportrichtlinien konfigurieren, mit denen Service Provider den Datenverkehr zum und vom Kunden steuern und die Übertragungsrate begrenzen können.

Sie können eine EBGP-Multihop-Sitzung für eine VRF-Routinginstanz konfigurieren. Außerdem können Sie den EBGP-Peer zwischen den PE- und CE-Routern einrichten, indem Sie die Loopback-Adresse des CE-Routers anstelle der Schnittstellenadressen verwenden.

Protokolldatenverkehr für Schnittstellen in einer Sicherheitszone zulassen

Auf Geräten der SRX-Serie müssen Sie den erwarteten Host-eingehenden Datenverkehr auf den angegebenen Schnittstellen oder allen Schnittstellen der Zone aktivieren. Andernfalls wird standardmäßig eingehender Datenverkehr, der zu diesem Gerät bestimmt ist, abgebrochen.

Verwenden Sie z. B. den folgenden Schritt, um BGP-Datenverkehr auf einer bestimmten Zone Ihres Geräts der SRX-Serie zuzulassen:

(Alle Schnittstellen) (Angegebene Schnittstelle)

BGP-Routen – Übersicht

Eine BGP-Route ist ein Ziel, das als IP-Adressen-Präfix beschrieben wird, und Informationen, die den Pfad zum Ziel beschreiben.

Die folgenden Informationen beschreiben den Pfad:

  • AS-Pfad, eine Liste der Nummern der ASs, die eine Route durchläuft, um den lokalen Router zu erreichen. Die erste Nummer im Pfad ist die des letzten AS im Pfad – die AS, die dem lokalen Router am nächsten kommt. Die letzte Nummer im Pfad ist die am weitesten vom lokalen Router entfernte Zahl, die im Allgemeinen der Ursprung des Pfads ist.

  • Pfadattribute, die zusätzliche Informationen über den AS-Pfad enthalten, der in der Routing-Richtlinie verwendet wird.

BGP-Peers werben Routen zueinander in Update-Nachrichten.

BGP speichert seine Routen in der Junos OS-Routingtabelle (inet.0). Die Routingtabelle speichert die folgenden Informationen zu BGP-Routen:

  • Routing-Informationen, die aus von Peers empfangenen Update-Nachrichten gelernt wurden

  • Lokale Routing-Informationen, die BGP aufgrund lokaler Richtlinien auf Routen anwendet

  • Informationen, die BGP BGP-Peers in Aktualisierungsmeldungen angibt

Für jedes Präfix in der Routingtabelle wählt der Routingprotokollprozess einen einzigen besten Pfad, den aktiven Pfad. Wenn Sie BGP nicht so konfigurieren, dass mehrere Pfade zum selben Ziel angeboten werden, gibt BGP nur den aktiven Pfad an.

Der BGP-Router, der zuerst eine Route angibt, weist ihm einen der folgenden Werte zu, um den Ursprung zu identifizieren. Bei der Routenauswahl wird der niedrigste Ursprungswert bevorzugt.

  • 0— Der Router erlernte die Route ursprünglich über eine IGP (OSPF, IS-IS oder eine statische Route).

  • 1—Der Router hatte ursprünglich die Route über ein EGP (höchstwahrscheinlich BGP) gelernt.

  • 2— Der Ursprung der Route ist unbekannt.

Übersicht über die BGP-Routenauflösung

Eine interne BGP -Route (IBGP) mit einer Next-Hop-Adresse zu einem entfernten BGP-Nachbarn (Protocol Next Hop) muss mithilfe einer anderen Route gelöst werden. BGP fügt diese Route dem RPD-Resolver-Modul für die Next-Hop-Auflösung hinzu. Wenn RSVP im Netzwerk verwendet wird, wird der nächste BGP-Hop über die RSVP-Ingress-Route aufgelöst. Dies führt dazu, dass die BGP-Route auf einen indirekten nächsten Hop und den indirekten nächsten Hop auf einen weiterleitungsnächsten Hop führt. Die Weiterleitung next hop wird von der RSVP-Route Next Hop abgeleitet. Es gibt oft eine große Gruppe interner BGP-Routen, die das gleiche Protokoll next hop haben, und in solchen Fällen würde die Gruppe von BGP-Routen auf denselben indirekten nächsten Hop verweisen.

Vor Junos OS Version 17.2R1 hat das Resolvermodul des Routing-Protokollprozesses (rpd) Routen innerhalb der IBGP-empfangenen Routen auf folgende Weise aufgelöst:

  1. Teilweise Routenauflösung: Der Protokoll-Next Hop wird basierend auf Helper-Routen wie RSVP- oder IGP-Routen aufgelöst. Die Metrikwerte werden von den Helper-Routen abgeleitet, und der nächste Hop wird als resolver forwarding next hop bezeichnet, der von Helper-Routen geerbt wird. Diese Metrikwerte werden für die Auswahl von Routen in der Routing Information Base (RIB), auch bekannt als Routing-Tabelle, verwendet.

  2. Vollständige Routenauflösung: Der letzte nächste Hop wird abgeleitet und wird als Kernel Routing Table (KRT) Forwarding Next Hop basierend auf der Weiterleitungsexportrichtlinie bezeichnet.

Ab Junos OS Version 17.2R1 ist das Resolvermodul von rpd optimiert, um den Durchsatz des eingehenden Verarbeitungsflusses zu erhöhen und so die Lernrate von RIB und FIB zu beschleunigen. Mit dieser Erweiterung ist die Routenauflösung wie folgt betroffen:

  • Die teilweisen und vollständigen Routenauflösungsmethoden werden für jede IBGP-Route ausgelöst, obwohl jede Route möglicherweise dieselbe aufgelöste Weiterleitung des nächsten Hops oder KRT-Weiterleitungs-Next Hops erbt.

  • Die BGP-Pfadauswahl wird verschoben, bis die vollständige Routenauflösung für NLRI (Network Layer Reachability Information) durchgeführt wird, die von einem BGP-Nachbarn empfangen wurden. Dies ist möglicherweise nicht die beste Route in der RIB nach der Routenauswahl.

Zu den Vorteilen der RPD-Resolver-Optimierung gehören:

  • Niedrigere Kosten für die RIB-Auflösungssuche: Die Ausgabe des aufgelösten Pfads wird in einem Resolver-Cache gespeichert, sodass die gleichen abgeleiteten Next Hop- und Metrikwerte auf eine andere Reihe von Routen mit demselben Pfadverhalten vererbt werden können, anstatt einen partiellen und vollständigen Routenauflösungsfluss durchzuführen. Dadurch werden die Suchkosten für die Routenauflösung reduziert, da nur der am häufigsten auftretende Resolverstatus in einem Cache mit begrenzter Tiefe beibehalten wird.

  • Optimierung der BGP-Routenauswahl: Der Algorithmus für die BGP-Routenauswahl wird zweimal für jede empfangene IBGP-Route ausgelöst– erstens, während die Route in der RIB mit dem nächsten Hop als unbrauchbar hinzugefügt wird, während die Route mit einem aufgelösten nächsten Hop in der RIB (nach Routenauflösung) hinzugefügt wird. Dies führt dazu, dass Sie die beste Route zweimal wählen. Mit der Resolver-Optimierung wird der Routenauswahlprozess im Empfangsfluss erst ausgelöst, nachdem die Next-Hop-Informationen vom Resolvermodul abgerufen wurden.

  • Internes Caching zur Vermeidung häufiger Nachschlagen: Der Resolver-Cache hält den am häufigsten auftretenden Resolver-Status aufrecht, und infolgedessen werden die Suchfunktionen wie Next-Hop-Suche und Routensuche aus dem lokalen Cache ausgeführt.

  • Pfadgleichheitsgruppe: Wenn verschiedene Pfade den gleichen Weiterleitungsstatus haben oder vom selben Protokoll next Hop empfangen werden, können die Pfade zu einer Pfadäquivalenzgruppe gehören. Dieser Ansatz vermeidet die Notwendigkeit einer vollständigen Routenauflösung für solche Pfade. Wenn ein neuer Pfad eine vollständige Routenauflösung erfordert, wird er zuerst in der Datenbank der Pfadgleichheitsgruppe nachgeschaut, die die Ausgabe des aufgelösten Pfads enthält, z. B. indirekter next Hop und Forwarding Next Hop.

Übersicht über BGP-Nachrichten

Alle BGP-Nachrichten haben den gleichen Header mit fester Größe, der ein Markerfeld enthält, das sowohl für die Synchronisierung als auch für die Authentifizierung verwendet wird, ein Längenfeld, das die Länge des Pakets angibt, und ein Typfeld, das den Nachrichtentyp angibt (z. B. offen, aktualisieren, Benachrichtigung, Keepalive usw.).

In diesem Abschnitt werden die folgenden Themen behandelt:

Offene Nachrichten

Nachdem eine TCP-Verbindung zwischen zwei BGP-Systemen hergestellt wurde, tauschen sie BGP-offene Nachrichten aus, um eine BGP-Verbindung zwischen ihnen zu erstellen. Sobald die Verbindung hergestellt ist, können die beiden Systeme BGP-Nachrichten und Datenverkehr austauschen.

Offene Nachrichten bestehen aus dem BGP-Header und den folgenden Feldern:

  • Version: Die aktuelle BGP-Versionsnummer ist 4.

  • Lokale AS-Nummer: Sie konfigurieren dies, indem Sie die autonomous-system Anweisung auf der [edit routing-options] oder [edit logical-systems logical-system-name routing-options] Hierarchieebene einbeziehen.

  • Haltezeit – Vorgeschlagener Hold-Time-Wert. Sie konfigurieren die lokale Haltezeit mit der BGP-Anweisung hold-time .

  • BGP-Kennung – IP-Adresse des BGP-Systems. Diese Adresse wird beim Start des Systems ermittelt und ist für jede lokale Schnittstelle und jeden BGP-Peer gleich. Sie können den BGP-Identifier konfigurieren, indem Sie die router-id Anweisung auf der [edit routing-options] Oderhierarchieebene [edit logical-systems logical-system-name routing-options] einbeziehen. BGP verwendet standardmäßig die IP-Adresse der ersten Schnittstelle, die im Router gefunden wird.

  • Parameterfeldlänge und parameter selbst – Dies sind optionale Felder.

Nachrichten aktualisieren

BGP-Systeme senden Aktualisierungsmeldungen an Austausch von Netzwerkverfügbarkeitsinformationen. BGP-Systeme verwenden diese Informationen, um ein Diagramm zu erstellen, das die Beziehungen zwischen allen bekannten ASs beschreibt.

Aktualisierungsmeldungen bestehen aus dem BGP-Header und den folgenden optionalen Feldern:

  • Nicht realisierbare Routenlänge – Länge des Feldes für zurückgezogene Routen

  • Zurückgenommene Routen – IP-Adressen-Präfixe für die vom Dienst genommenen Routen, da sie nicht mehr erreichbar sind

  • Pfadattributlänge insgesamt – Länge des Pfadattributefelds; es listet die Pfadattribute für eine praktikable Route zu einem Ziel auf

  • Pfadattribute: Eigenschaften der Routen, einschließlich des Pfadursprungs, des Multiple Exit Discriminator (MED), der Präferenz des Ursprungssystems für die Route und Informationen über Aggregation, Gemeinschaften, Konföderationen und Routenreflektion

  • Network Layer Reachability Information (NLRI): IP-Adressen-Präfixe möglicher Routen, die in der Update-Nachricht angekündigt werden

Bleibende Nachrichten

BGP-Systeme tauschen keepalive Nachrichten aus, um festzustellen, ob eine Verbindung oder ein Host fehlgeschlagen ist oder nicht mehr verfügbar ist. Keepalive-Nachrichten werden oft genug ausgetauscht, damit der Wartezeit-Timer nicht abläuft. Diese Nachrichten bestehen nur aus dem BGP-Header.

Benachrichtigungen

BGP-Systeme senden Benachrichtigungen, wenn eine Fehlerbedingung erkannt wird. Nachdem die Nachricht gesendet wurde, werden die BGP-Sitzung und die TCP-Verbindung zwischen den BGP-Systemen geschlossen. Benachrichtigungen bestehen aus dem BGP-Header sowie dem Fehlercode und -subcode sowie Daten, die den Fehler beschreiben.

Nachrichten zur Routenaktualisierung

BGP-Systeme senden Nachrichten zur Routenaktualisierung nur dann an einen Peer, wenn sie die Ankündigung zur Routenaktualisierungsfunktion vom Peer erhalten haben. Ein BGP-System muss seinen Peers die Routenaktualisierungsfunktion mithilfe von BGP-Funktionen anzeigen, wenn es Nachrichten über die Routenaktualisierung erhalten möchte. Diese optionale Nachricht wird gesendet, um dynamische, eingehende BGP-Routenaktualisierungen von BGP-Peers anzufordern oder ausgehende Routenaktualisierungen an einen BGP-Peer zu senden.

Nachrichten zur Routenaktualisierung bestehen aus den folgenden Feldern:

  • AFI – Address Family Identifier (16 Bit).

  • Res– Reserviertes Feld (8-Bit), das vom Sender auf 0 eingestellt und vom Empfänger ignoriert werden muss.

  • SAFI – Subsequent Address Family Identifier (8 Bit).

Wenn ein Peer ohne die Routenaktualisierungsfunktion eine Anforderungsnachricht zur Routenaktualisierung von einem Remote-Peer erhält, ignoriert der Empfänger die Nachricht.

Understanding BGP RIB Sharding and BGP Update IO Thread (Verstehen von BGP RIB-Sharding und BGP Update IO-Thread)

Die BGP-Routenverarbeitung umfasst in der Regel mehrere Pipeline-Stufen, wie das Empfangen von Aktualisierungen, das Analysieren von Aktualisierungen, das Erstellen von Route, das Auflösen des nächsten Hops, die Anwendung der Exportrichtlinie einer BGP-Peer-Gruppe, das Erstellen von Peer-Updates und das Senden von Updates an Peers.

BGP RIB-Sharding unterteilt eine einheitliche BGP-RIB in mehrere Unter-RIBs und jede Sub-RIB verarbeitet eine Teilmenge von BGP-Routen. Separater RPD-Thread, der als BGP-Shard-Thread bezeichnet wird, dient jeder Sub-RIB, um Parallelität zu erreichen. BGP-Shard-Threads sind für alle Phasen der BGP-Routenverarbeitungs-Pipeline verantwortlich, mit Ausnahme der Bildung von Peer-Updates und dem Senden von Updates an Peers. BGP-Shard-Threads erhalten die von Peers gesendeten Updates vom BGP Aktualisieren von IO-Threads mit dem BGP Update IO-Threads Hashing der Präfixe in den Updates und sendet die Updates an die entsprechenden BGP-Shard-Threads basierend auf der Hashberechnung. BGP-Shard-Thread verarbeitet die Konfiguration auf die gleiche Weise wie der RPD-Hauptthread, erstellt Peers, Gruppen, Routentabellen und verwendet die Konfigurationsinformationen für die BGP-Routenverarbeitung.

BGP Update IO-Threads sind für das Tail-End dieser BGP-Pipeline verantwortlich, das das Generieren von Peer-Updates für einzelne BGP-Gruppen und das Senden an die Peers umfasst. Ein Update-Thread kann eine oder mehrere BGP-Gruppen bedienen. BGP AKTUALISIEREN IO-Threads erstellen Updates für Gruppen parallel und unabhängig von anderen Gruppen, die von anderen Aktualisierungs-Threads gewartet werden. Dies könnte zu einer erheblichen Konvergenzverbesserung bei einer schreiblastigen Arbeitslast führen, die Werbung für viele Peers erfordert, die über mehrere Gruppen verteilt sind. BGP Update IO-Threads sind auch für das Schreiben von TCP-Sockets der BGP-Peers und das Lesen von tcp-Sockets von BGP Peers verantwortlich, die zuvor von BGPIO-Threads bereitgestellt wurden (daher das Suffix IO in BGP Update IO).

BGP Update IO-Threads können unabhängig von RIB-Sharding-Funktion konfiguriert werden, sind jedoch zwingend erforderlich, um mit RIB-Sharding zu verwenden, um eine bessere Prefix-Packeffizienz bei ausgehender BGP-Update-Nachricht zu erreichen. BGP-Sharding unterteilt die RIB in mehrere Unter-RIBs, die von separaten RPD-Threads bedient werden. Daher landen Präfixe, die in ein einzelnes Outbound-Update hätten gehen können, in verschiedenen Shards. Um BGP-Updates mit Präfixen mit demselben Ausgangsattribut zu erstellen, das zu verschiedenen RPD-Shard-Threads gehören könnte, senden alle Shard-Threads kompakte Werbeinformationen für Präfixe, die an einen Update-Thread gesendet werden, der diese BGP-Peergruppe bedient. Auf diese Weise kann der Update-Thread, der diese BGP-Peergruppe bedient, Präfixe mit den gleichen Attributen packen, die möglicherweise zu verschiedenen Shards in derselben Ausgehenden Update-Nachricht gehören. Dadurch wird die Anzahl der zu bewerbenden Updates minimiert und die Konvergenz verbessert. Update-IO-Thread verwaltet lokale Caches von Peer-, Gruppen-, Prefix-, TSI- und RIB-Containern.

BGP Update Thread und BGP RIB Sharding sind standardmäßig deaktiviert. Wenn Sie Update-Threading und Rib-Sharding auf einer Routing-Engine konfigurieren, erstellt RPD Update-Threads. Standardmäßig entspricht die Anzahl der erstellten Update-Threads und Shard-Threads der Anzahl der CPU-Cores der Routing-Engine. Update-Threading wird nur bei einem 64-Bit-Routingprotokollprozess (RPD) unterstützt. Optional können Sie die Anzahl der Threads angeben, die Sie mithilfe set update-threading <number-of-threads> von und set rib-sharding <number-of-threads> Anweisungen auf Hierarchieebene [edit system processes routing bgp] erstellen möchten. Für BGP-Update-Thread beträgt der Bereich derzeit 1 bis 128 und für BGP RIB-Sharding ist der Bereich derzeit 1 bis 31.

Wenn Sie NSR für die BGP RIB Sharding- und BGP Update IO-Funktionen konfigurieren, erzeugt das Backup-RPD die gleiche Anzahl von BGP Shard und BGP Aktualisieren von IO-Threads in der Backup-Routing-Engine. Die Backup-RPD-BGP-Update-IO-Threads lesen das replizierte BGP-Update, andere Nachrichten, die von den Peers empfangen wurden, sowie das replizierte BGP-Update und andere Nachrichten, die an die Peers gesendet werden. Basierend auf Hashing von Präfixen senden die Backup-RPD-BGP-Aktualisierungs-IO-Threads diese BGP-Nachrichten an die entsprechenden BGP-Shard- und RPD-Haupt-Threads. Der BGP-Shard und die RPD-Haupt-Threads in der Backup-RPD erstellt den empfangenen und angekündigten Routenstatus unter Verwendung dieser replizierten BGP-Nachrichten. Wenn die primäre Routing-Engine ausfällt, wird die Backup-Routing-Engine zur primären Routing-Engine und die Backup-RPD wird nahtlos zur primären RPD, ohne die BGP-Sitzungen mit den Peers zu beeinträchtigen.

Informationen zur BGP-Pfadauswahl

Für jedes Präfix in der Routingtabelle wählt der Routingprotokollprozess einen einzelnen besten Pfad aus. Nachdem der beste Pfad ausgewählt wurde, wird die Route in der Routingtabelle installiert. Der beste Pfad wird zur aktiven Route, wenn das gleiche Präfix von einem Protokoll mit einem niedrigeren (bevorzugteren) globalen Präferenzwert, auch bekannt als administrative Entfernung, nicht erlernt wird. Der Algorithmus zur Bestimmung der aktiven Route lautet wie folgt:

  1. Vergewissern Sie sich, dass der nächste Hop gelöst werden kann.

  2. Wählen Sie den Pfad mit dem niedrigsten Präferenzwert (Einstellung des Routingprotokollprozesses).

    Routen, die nicht für die Weiterleitung verwendet werden können (z. B. weil sie von der Routing-Richtlinie abgelehnt wurden oder weil ein nächster Hop nicht zugänglich ist), haben die Option -1 und werden nie ausgewählt.

  3. Bevorzugen Sie den Pfad mit einer höheren lokalen Präferenz.

    Wählen Sie für Nicht-BGP-Pfade den Pfad mit dem niedrigsten preference2 Wert.

  4. Wenn das Accumulated Interior Gateway Protocol (AIGP)-Attribut aktiviert ist, bevorzugen Sie den Pfad mit dem niedrigeren AIGP-Attribut.

  5. Bevorzugen Sie den Pfad mit dem kürzesten Autonomen System (AS)-Pfadwert (übersprungen, wenn die as-path-ignore Anweisung konfiguriert ist).

    Ein Confederation-Segment (Sequenz oder Set) hat eine Pfadlänge von 0. Ein AS-Set hat eine Pfadlänge von 1.

  6. Bevorzugen Sie die Route mit dem code des unteren Ursprungs.

    Die von einem IGP erlernten Routen haben einen niedrigeren Ursprungscode als die aus einem Exterieur-Gateway-Protokoll (EGP) gelernten, und beide haben niedrigere Ursprungscodes als unvollständige Routen (Routen, deren Ursprung unbekannt ist).

  7. Wählen Sie den Pfad mit der geringsten Metrik für mehrfache Ausstiegsdiskriminierende (MED).

    Je nachdem, ob das Verhalten bei der Routing-Tabellenauswahl nichtdeterministisch konfiguriert ist, gibt es zwei mögliche Fälle:

    • Wenn nichtdeterministisches Verhalten bei der Routingtabellenauswahl nicht konfiguriert ist (d. h. wenn die path-selection cisco-nondeterministic Anweisung nicht in der BGP-Konfiguration enthalten ist), bevorzugen Pfade mit den gleichen benachbarten AS-Nummern an der Vorderseite des AS-Pfads den Pfad mit der niedrigsten MED-Metrik. Um MEDs immer zu vergleichen, ob die Peer-ASs der verglichenen Routen gleich sind, fügen Sie die path-selection always-compare-med Anweisung ein.

    • Wenn nichtdeterministisches Verhalten bei der Routingtabellenauswahl konfiguriert ist (d. h. die path-selection cisco-nondeterministic Anweisung ist in der BGP-Konfiguration enthalten), bevorzugen Sie den Pfad mit der niedrigsten MED-Metrik.

    Konföderationen werden bei der Bestimmung benachbarter ASS nicht berücksichtigt. Eine fehlende MED-Metrik wird so behandelt, als wäre eine MED vorhanden, aber null.

    Anmerkung:

    Der MED-Vergleich funktioniert für die Auswahl eines einzelnen Pfads innerhalb eines AS (wenn die Route keinen AS-Pfad enthält), obwohl diese Verwendung unüblich ist.

    Standardmäßig werden nur die MEDs von Routen mit denselben autonomen Peer-Systemen (Peer Autonomous Systems, ASs) verglichen. Sie können Optionen zur Auswahl von Routingtabellenpfaden konfigurieren, um unterschiedliche Verhaltensweisen zu erhalten.

  8. Bevorzugen Sie streng interne Pfade, die IGP-Routen und lokal generierte Routen enthalten (statisch, direkt, lokal usw.).

  9. Bevorzugen Sie strikt externe BGP -Pfade (EBGP) gegenüber externen Pfaden, die durch interne BGP (IBGP)-Sitzungen erlernt werden.

  10. Bevorzugen Sie den Pfad, dessen nächster Hop über die IGP-Route mit der niedrigsten Kennzahl aufgelöst wird.

    Anmerkung:

    Ein Pfad gilt als BGP-Pfad zu gleichen Kosten (und wird für die Weiterleitung verwendet), wenn nach dem vorherigen Schritt ein Tie-Break durchgeführt wird. Alle Pfade mit dem gleichen benachbarten AS, die von einem Multipath-fähigen BGP-Nachbarn gelernt werden, werden berücksichtigt.

    BGP-Multipath gilt nicht für Pfade, die die gleichen MED-plus-IGP-Kosten haben, sich jedoch von den IGP-Kosten unterscheiden. Die Multipath-Pfadauswahl basiert auf der IGP-Kostenmetrik, auch wenn zwei Pfade die gleichen MED-plus-IGP-Kosten haben.

    BGP vergleicht die Art der IGP-Metrik, bevor der Metrikwert selbst in rt_metric2_cmpverglichen wird. BGP-Routen, die durch IGP gelöst werden, werden beispielsweise über verworfene oder abgelehnte Next-Hops vom Typ RTM_TYPE_UNREACHbevorzugt. Solche Routen werden wegen ihrer metric-typedeklariertinactive.

  11. Wenn beide Pfade extern sind, bevorzugen Sie den derzeit aktiven Pfad, um das Routen-Flapping zu minimieren. Diese Regel wird nicht verwendet, wenn eine der folgenden Bedingungen zutrifft:

    • path-selection external-router-id konfiguriert ist.

    • Beide Peers haben dieselbe Router-ID.

    • Jeder Peer ist ein Konföderations-Peer.

    • Keiner der beiden Pfade ist der aktuelle aktive Pfad.

  12. Bevorzugen Sie eine Primärroute über eine Sekundärroute. Eine primäre Route ist eine, die zur Routingtabelle gehört. Eine sekundäre Route ist eine, die der Routingtabelle über eine Exportrichtlinie hinzugefügt wird.

  13. Bevorzugen Sie den Pfad vom Peer mit der niedrigsten Router-ID. Für jeden Pfad mit einem Originator-ID-Attribut ersetzen Sie die Originator-ID für die Router-ID beim Vergleich der Router-ID.

  14. Bevorzugen Sie den Pfad mit der kürzesten Clusterlistenlänge. Die Länge beträgt 0 für keine Liste.

  15. Bevorzugen Sie den Pfad vom Peer mit der niedrigsten Peer-IP-Adresse.

Routing-Tabellenpfadauswahl

Der kürzeste AS-Pfadschritt des Algorithmus bewertet standardmäßig die Länge des AS-Pfads und bestimmt den aktiven Pfad. Sie können eine Option konfigurieren, mit der Junos OS diesen Schritt des Algorithmus überspringen kann, indem Sie die as-path-ignore Option einbeziehen.

Anmerkung:

Ab Junos OS-Version 14.1R8, 14.2R7, 15.1R4, 15.1F6 und 16.1R1 wird die as-path-ignore Option für Routing-Instanzen unterstützt.

Die Auswahl des Routing-Prozesspfads erfolgt, bevor BGP den Pfad zur Routingtabelle übergibt, um seine Entscheidung zu treffen. Um das Verhalten der Routingtabellenpfadauswahl zu konfigurieren, fügen Sie die path-selection Anweisung ein:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.

Die Auswahl von Routingtabellenpfaden kann auf eine der folgenden Arten konfiguriert werden:

  • Emulieren Sie das Cisco IOS-Standardverhalten (cisco-non-deterministic). Dieser Modus bewertet Routen in der Reihenfolge, in der sie empfangen werden, und gruppiert sie nicht nach ihrem benachbarten AS. Im cisco-non-deterministic Modus steht der aktive Pfad immer an erster Stelle. Alle inaktiven, aber qualifizierten Pfade folgen dem aktiven Pfad und werden in der Reihenfolge beibehalten, in der sie empfangen wurden, wobei der neueste Pfad zuerst angezeigt wurde. Ineligible Pfade bleiben am Ende der Liste.

    Angenommen, Sie haben drei Pfadanzeigen für die Route 192.168.1.0 /24:

    • Pfad 1 – erlernt durch EBGP; AS-Pfad 65010; MED von 200

    • Pfad 2 – erlernt durch IBGP; AS-Pfad 65020; MED von 150; IGP-Kosten von 5

    • Pfad 3 – erlernt durch IBGP; AS-Pfad 65010; MED von 100; IGP-Kosten von 10

    Diese Anzeigen werden in schneller Folge innerhalb einer Sekunde in der angegebenen Reihenfolge erhalten. Pfad 3 wird zuletzt empfangen, sodass das Routinggerät ihn mit Pfad 2, der neuesten Anzeige, vergleicht. Die Kosten für den IBGP-Peer sind besser für Pfad 2, sodass das Routinggerät Pfad 3 aus dem Streit macht. Beim Vergleich der Pfade 1 und 2 bevorzugt das Routinggerät Pfad 1, da es von einem EBGP-Peer empfangen wird. Dadurch kann das Routinggerät Pfad 1 als aktiven Pfad für die Route installieren.

    Anmerkung:

    Wir empfehlen nicht, diese Konfigurationsoption in Ihrem Netzwerk zu verwenden. Sie dient ausschließlich der Interoperabilität, um allen Routing-Geräten im Netzwerk eine konsistente Routenauswahl zu ermöglichen.

  • MeDs immer vergleichen, ob die Peer-ASs der verglichenen Routen gleich sind (always-compare-med).

  • Überschreiben Sie die Regel, dass wenn beide Pfade extern sind, der derzeit aktive Pfad bevorzugt wird (external-router-id). Fahren Sie mit dem nächsten Schritt (Schritt 12) im Pfadauswahlprozess fort.

  • Hinzufügen der IGP-Kosten zum Ziel des nächsten Hops zum MED-Wert, bevor MED-Werte für die Pfadauswahl verglichen werden (med-plus-igp).

    BGP-Multipath gilt nicht für Pfade, die die gleichen MED-plus-IGP-Kosten haben, sich jedoch in den IGP-Kosten unterscheiden. Die Multipath-Pfadauswahl basiert auf der IGP-Kostenmetrik, auch wenn zwei Pfade die gleichen MED-plus-IGP-Kosten haben.

BGP-Tabellenpfadauswahl

Für die Pfadauswahl von BGP werden die folgenden Parameter befolgt:

  1. Bevorzugen Sie den höchsten Wert für lokale Präferenzen.

  2. Bevorzugen Sie die kürzeste AS-Pfadlänge.

  3. Wählen Sie den niedrigsten Ursprungswert.

  4. Bevorzugen Sie den niedrigsten MED-Wert.

  5. Bevorzugen Sie von einem EBGP-Peer erlernte Routen gegenüber einem IBGP-Peer.

  6. Verlassen Sie sich am besten auf AS.

  7. Für EBGP-empfangene Routen bevorzugen Sie die aktuelle aktive Route.

  8. Bevorzugen Sie Routen vom Peer mit der niedrigsten Router-ID.

  9. Bevorzugen Sie Pfade mit der kürzesten Clusterlänge.

  10. Bevorzugen Sie Routen vom Peer mit der niedrigsten Peer-IP-Adresse. Die Schritte 2, 6 und 12 sind die RPD-Kriterien.

Auswirkungen der Werbung für mehrere Pfade zu einem Ziel

BGP gibt nur den aktiven Pfad an, es sei denn, Sie konfigurieren BGP, um mehrere Pfade zu einem Ziel zu werben.

Nehmen wir an, ein Routinggerät hat in seiner Routingtabelle vier Pfade zu einem Ziel und ist so konfiguriert, dass es bis zu drei Pfade anzeigen kann (add-path send path-count 3). Die drei Pfade werden anhand von Pfadauswahlkriterien ausgewählt. Das heißt, die drei besten Pfade werden in der Reihenfolge der Pfadauswahl ausgewählt. Der beste Pfad ist der aktive Pfad. Dieser Pfad wird aus der Erwägung entfernt und ein neuer bester Pfad gewählt. Dieser Vorgang wird wiederholt, bis die angegebene Anzahl von Pfaden erreicht ist.

Unterstützte Standards für BGP

Junos OS unterstützt im Wesentlichen die folgenden RFCs und Internet-Entwürfe, die Standards für IP-Version 4 (IPv4) BGP definieren.

Eine Liste der unterstützten IPv6-BGP-Standards (IP Version 6) finden Sie unter Unterstützte IPv6-Standards.

Junos OS BGP unterstützt die Authentifizierung für den Protokollaustausch (MD5-Authentifizierung).

  • RFC 1745, BGP4/IDRP für IP – OSPF-Interaktion

  • RFC 1772, Anwendung des Border Gateway Protocol im Internet

  • RFC 1997, BGP Communities-Attribut

  • RFC 2283, Multiprotocol-Erweiterungen für BGP-4

  • RFC 2385, Schutz von BGP-Sitzungen über die TCP MD5-Signaturoption

  • RFC 2439, BGP Route Flap Damping

  • RFC 2545, Verwendung von BGP-4 Multiprotocol Extensions für IPv6 Inter-Domain Routing

  • RFC 2796, BGP Route Reflection – eine Alternative zu Full-Mesh-IBGP

  • RFC 2858, Multiprotocol-Erweiterungen für BGP-4

  • RFC 2918, Routenaktualisierungsfunktion für BGP-4

  • RFC 3065, Autonome Systemkonföderationen für BGP

  • RFC 3107, Carrying Label Information in BGP-4

  • RFC 3345, Border Gateway Protocol (BGP) Persistent Route Sollzustand

  • RFC 3392, Anzeige von Funktionen mit BGP-4

  • RFC 4271, A Border Gateway Protocol 4 (BGP-4)

  • RFC 4273, Definitionen verwalteter Objekte für BGP-4

  • RFC 4360, BGP Extended Communities-Attribut

  • RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs)

  • RFC 4456, BGP Route Reflection: Eine Alternative zu Full Mesh Internal BGP (IBGP)

  • RFC 4486, Untercodes für BGP Cease Notification Message

  • RFC 4659, BGP-MPLS IP Virtual Private Network (VPN)-Erweiterung für IPv6 VPN

  • RFC 4632, Classless Inter-Domain Routing (CIDR): Der Internetadresszuweisungs- und Aggregationsplan

  • RFC 4684, eingeschränkte Routenverteilung für Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)

  • RFC 4724, Graceful Restart-Mechanismus für BGP

  • RFC 4760, Multiprotocol-Erweiterungen für BGP-4

  • RFC 4781, Graceful Restart-Mechanismus für BGP mit MPLS

  • RFC 4798, Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)

    Option 4b (eBGP-Neuverteilung von gekennzeichneten IPv6-Routen von AS zu benachbartem AS) wird nicht unterstützt.

  • RFC 4893, BGP-Unterstützung für As-Number Space mit vier Oktetten

  • RFC 5004, Vermeiden Sie BGP Best Path Transitions from One External to Another

  • RFC 5065, Autonome Systemkonföderationen für BGP

  • RFC 5082, The Generalized TTL Security Mechanism (GTSM)

  • RFC 5291, Outbound Route Filtering-Funktion für BGP-4 (teilweise Unterstützung)

  • RFC 5292, Address-Prefix-Based Outbound Route Filter für BGP-4 (teilweise Unterstützung)

    Geräte, auf denen Junos OS ausgeführt wird, können Prefix-basierte ORF-Nachrichten empfangen.

  • RFC 5396, Textual Representation of Autonomous System (AS)-Zahlen

  • RFC 5492, Anzeige von Funktionen mit BGP-4

  • RFC 5512, The BGP Encapsulation Subsequent Address Family Identifier (SAFI) und das BGP Tunnel Encapsulation-Attribut

  • RFC 5549, Werbung für IPv4 Network Layer Reachability-Informationen mit einem IPv6 Next Hop

  • RFC 5575, Regeln zur Verbreitung der Datenstromspezifikation

  • RFC 5668, 4-Octet AS Specific BGP Extended Community

  • RFC 6286, Autonomous-System-Wide Unique BGP Identifier für BGP-4- vollständig konform

  • RFC 6368, Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

  • RFC 6810, The Resource Public Key Infrastructure (RPKI) to Router Protocol

  • RFC 6811, BGP Prefix Origin Validation

  • RFC 6996, Autonomous System (AS)-Reservierung für private Verwendung

  • RFC 7300, Reservation of Last Autonomous System (AS)-Zahlen

  • RFC 7611, BGP ACCEPT_OWN Community-Attribut

    Wir unterstützen den RFC, indem wir Es Juniper-Routern ermöglichen, Von einem Routenreflektor empfangene Routen mit dem accept-own Community-Wert zu akzeptieren.

  • RFC 7752, North-Bound Distribution of Link-State and Traffic Engineering (TE)-Informationen mit BGP

  • RFC 7854, BGP Monitoring Protocol (BMP)

  • RFC 7911, Advertisement of Multiple Paths in BGP (Rfc 7911, Advertisement of Multiple Paths in BGP )

  • RFC 8212, Default External BGP (EBGP) Route Propagation Behavior without Policies- fully compliant

    Ausnahmen:

    Die Verhaltensweisen in RFC 8212 werden standardmäßig nicht implementiert, um Unterbrechungen der vorhandenen Kundenkonfiguration zu vermeiden. Das Standardverhalten wird weiterhin beibehalten, um alle Routen in Bezug auf EBGP-Peers zu akzeptieren und zu werben.

  • RFC 8326, Graceful BGP-Sitzung herunterfahren

  • Internet draft draft-idr-rfc8203bis-00, BGP Administrative Shutdown Communication (läuft bis Oktober 2018)

  • Internet Draft draft-ietf-grow-bmp-adj-rib-out-01, Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) (endet am 3. September 2018)

  • Internet draft-ietf-idr-aigp-06, The Accumulated IGP Metric Attribute for BGP (läuft bis Dezember 2011)

  • Internet draft-ietf-idr-as0-06, Codification of AS 0 processing (läuft bis Februar 2013)

  • Internet draft-ietf-idr-link-bandwidth-06.txt, BGP Link Bandwidth Extended Community (läuft bis Juli 2013)

  • Internet Draft Draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Extended Community (teilweise Unterstützung) (läuft bis Mai 2011)

    Die erweiterte Community (Ursprungsvalidierungsstatus) wird in der Routing-Richtlinie von Junos OS unterstützt. Die angegebene Änderung im Routenauswahlverfahren wird nicht unterstützt.

  • Internet draft draft-kato-bgp-ipv6-link-local-00.txt, BGP4+ Peering Using IPv6 Link-local Address (Internet draft-kato-bgp-ipv6-link-local-00.txt, BGP4+ Peering Mit IPv6 Link-local Address)

Die folgenden RFCs und der Internetentwurf definieren keine Standards, sondern liefern Informationen zu BGP und zugehörigen Technologien. Die IETF klassifiziert sie jeweils als "experimentell" oder "informationell".

  • RFC 1965, Autonome Systemkonföderationen für BGP

  • RFC 1966, BGP Route Reflection – Eine Alternative zu Full-Mesh-IBGP

  • RFC 2270 , Verwendung eines dedizierten AS für Standorte, die an einen einzelnen Anbieter verteilt sind

  • Internet Draft draft-ietf-ngtrans-bgp-tunnel-04.txt, Connecting IPv6 Islands across IPv4 Clouds with BGP (läuft bis Juli 2002)

Release-Verlaufstabelle
Release
Beschreibung
17.2R1
Ab Junos OS Version 17.2R1 ist das Resolvermodul von rpd optimiert, um den Durchsatz des eingehenden Verarbeitungsflusses zu erhöhen und so die Lernrate von RIB und FIB zu beschleunigen.
14.1R8
Ab Junos OS-Version 14.1R8, 14.2R7, 15.1R4, 15.1F6 und 16.1R1 wird die as-path-ignore Option für Routing-Instanzen unterstützt.