Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP Überblick

Grundlegende BGP

BGP ist ein Gateway Protocol (EGP), das zum Austausch von Routing-Informationen zwischen Routern in verschiedenen autonomen Systemen (ASs) verwendet wird. BGP Routinginformationen enthält die vollständige Route zu jedem Ziel. BGP verwendet die Routinginformationen, um eine Datenbank mit Informationen zur Netzwerkverfügbarkeit zu verwalten, die er mit anderen Systemen BGP austauscht. BGP nutzt die Informationen zur Netzwerkverfügbarkeit, um ein Diagramm über die konnektivität AS zu erstellen, das es BGP ermöglicht, Routing-Schleifen zu entfernen und Richtlinienentscheidungen auf der AS zu treffen.

Multiprotocol BGP (MBGP)-Erweiterungen ermöglichen BGP Unterstützung von IP-Version 6 (IPv6).MBGP definiert die Attribute MP_REACH_NLRI und MP_UNREACH_NLRI, die für die Übertragung von IPv6-Erreichbarkeitsinformationen verwendet werden. NLRI-Nachrichten (Network Layer Reachability Information) enthalten IPv6-Adress präfixe für erreichbare Routen.

BGP ermöglicht richtlinienbasiertes Routing. Sie können Routingrichtlinien verwenden, um zwischen mehreren Pfaden zu einem Ziel zu wählen und die Neuverteilung von Routinginformationen zu kontrollieren.

BGP nutzt TCP als Transportprotokoll mit Port 179 zum Herstellen von Verbindungen. Die Übertragung über ein zuverlässiges Transportprotokoll macht es BGP die Implementierung von Update-Fragmentierung, erneuter Übertragung, Anerkennung und Sequenzierung zu implementieren.

Die Junos OS Routingprotokollsoftware unterstützt Version 4 BGP 4. Diese Version von BGP zusätzliche Unterstützung für Classless-Interdomain-Routing (CIDR), wodurch das Konzept der Netzwerkklassen entfällt. Anstatt zu wissen, welche Bits einer Adresse das Netzwerk repräsentieren, können Sie mit dem ersten Oktett CIDR die Anzahl der Bits in der Netzwerkadresse explizit angeben und damit die Größe der Routingtabellen verringern. BGP Version 4 unterstützt auch die Aggregation von Routen, einschließlich der Aggregation von AS Pfaden.

In diesem Abschnitt werden die folgenden Themen erörtert:

Autonome Systeme

Ein autonomes System (AS) besteht aus Routern, die einer einzigen technischen Administration unter stehen und normalerweise ein einzelnes Interior Gateway-Protokoll und einen gemeinsamen Satz von Metriken verwenden, um Routing-Informationen innerhalb von Routern weiter zu geben. Für andere ASs bietet ein AS einen einzigen, kohärenten Interior Routing-Plan und bietet einen konsistenten Überblick darüber, welche Ziele sie erreichen können.

AS pfade und Attribute

Die Routinginformationen, die BGP Austausch von Systemen umfassen die vollständige Route zu jedem Ziel sowie zusätzliche Informationen zur Route. Die Route zu jedem Ziel wird als "AS-Pfad bezeichnet,und die zusätzlichen Routeninformationen sind in den Pfadattributen enthalten. BGP verwendet den AS und die Pfadattribute, um die Netzwerktopologie vollständig zu bestimmen. Sobald BGP Topologie erkannt und beseitigt, können Routing-Schleifen erkannt und beseitigt und zwischen Routengruppen ausgewählt werden, um administrative Einstellungen und Entscheidungen für Routing-Richtlinien durchzusetzen.

Externe und interne BGP

BGP unterstützt zwei Arten des Austauschs von Routinginformationen: Austausch zwischen verschiedenen ASs und Börsen innerhalb einer AS. Bei Verwendung unter ASs wird BGP als external BGP (EBGP) bezeichnet, BGP führen Inter-AS-Routing durch. Wenn er in einer AS Verwendet wird BGP als internal BGP (IBGP) bezeichnet, BGP Sitzungen führeneine Intra-AS-Routing. Abbildung 1 illustriert ASs, IBGP und EBGP.

Abbildung 1: ASS, EBGP und IBGPASS, EBGP und IBGP

Ein BGP-System teilt Netzwerkverfügbarkeitsinformationen mit benachbarten BGP Systemen, die als Nachbarn oder Peers bezeichnet werden.

BGP Systeme werden in Gruppen unterteilt. In einer IBGP-Gruppe befinden sich alle Peers in der Gruppe , die als interne Peersbezeichnet werden, im selben AS. Interne Peers können sich überall im lokalen Netzwerk AS müssen nicht direkt miteinander verbunden sein. Interne Gruppen verwenden Routen von einem IGP, um Weiterleitungsadressen zu lösen. Sie führen außerdem externe Routen unter allen anderen internen Routern weiter, die IBGP ausführen. So wird der nächste Hop durch Nehmen des BGP-Hops, der mit der Route empfangen wird, und es anhand der Informationen von einem der Interior Gateway-Protokolle auflöst.

In einer EBGP-Gruppe befinden sich die Peers in der Gruppe , die als externe Peersbezeichnet werden, 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 vom externen Peer und dem lokalen Router gemeinsam genutzt wird.

Mehrere BGP

Sie können mehrere Instanzen von BGP in 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 vor allem zur Layer-3-VPN-Unterstützung verwendet.

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

Anmerkung:

Wenn ein BGP Nachbar BGP an ein lokales Routinggerät sendet, muss die eingehende Schnittstelle, an der die Nachrichten empfangen werden, in der gleichen Routinginstanz konfiguriert werden, in der die Nachbarkonfiguration BGP ist. Dies gilt für Nachbarn, die einen hop entfernten oder mehrere Hops entfernt sind.

Routen, die aus dem BGP gelernt werden, werden standardmäßig instance-name.inet.0 der Tabelle hinzugefügt. Sie können Import- und Exportrichtlinien konfigurieren, um den Informationsfluss in und aus der Instanz-Routingtabelle zu steuern.

Zur Unterstützung von Layer 3-VPN konfigurieren Sie BGP am Provider Edge-Router (PE), um Routen vom Kunden-Edge-Router (CE) zu erhalten und bei Bedarf die Routen der Instanzen an den CE-Router zu senden. Sie können mehrere Instanzen von BGP verwenden, um separate Weiterleitungstabellen pro Standort zu verwalten, um den VPN-Datenverkehr auf dem PE-Router zu trennen.

Sie können Import- und Exportrichtlinien konfigurieren, die es dem Dienstanbieter ermöglichen, den Datenverkehr zum und vom Kunden zu kontrollieren und zu begrenzen.

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

BGP Routen – Übersicht

Eine BGP Route ist ein Ziel, das als PRÄFIX FÜR IP-Adressen und Informationen beschrieben wird, die den Pfad zum Ziel beschreiben.

Die folgenden Informationen beschreiben den Weg:

  • AS Pfad, eine Liste der ASS, die eine Route passiert, um den lokalen Router zu erreichen. Die erste Zahl in diesem Pfad ist die der letzten AS Pfads – der Pfad, AS am nächsten zum lokalen Router liegt. Die letzte Zahl in diesem Pfad ist AS am längsten vom lokalen Router, was im Allgemeinen der Ursprung des Pfads ist.

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

BGP-Peers routen untereinander in Nachrichten aktualisieren.

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

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

  • Lokale Routing-Informationen, BGP aufgrund lokaler Richtlinien auf Routen angewendet werden

  • Informationen, die BGP werben, BGP in Nachrichten zu aktualisieren

Für jedes Präfix in der Routingtabelle wählt der Routingprotokollprozess einen einzelnen, den aktiven Pfad aus. Wenn Sie nicht konfiguriert BGP, um mehrere Pfade zum selben Ziel ausgeschrieben zu haben, BGP nur den aktiven Pfad an.

Der BGP Router, der zuerst eine Route ankn gibt, weist ihm einen der folgenden Werte zu, um seinen 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 hat die Route ursprünglich über einen EGP gelernt (wahrscheinlich BGP).

  • 2— Der Ursprung der Route ist unbekannt.

BGP Routenauflösungsüberblick

Eine interne BGP-Route (IBGP) mit einer Next-Hop-Adresse zu einem entfernten BGP-Nachbarn (Protokoll nächsten Hop) muss den nächsten Hop mit einer anderen Route lösen müssen. BGP fügt diese Route zum RPD-Resolver-Modul für Next-Hop-Auflösung hinzu. Wenn RSVP im Netzwerk verwendet wird, wird der BGP Im nächsten Hop mithilfe der RSVP-Ingress-Route gelöst. Das Ergebnis ist der BGP, der auf einen indirekten Next Hop und den indirekten Next Hop zu einem Weiterleitungs-Next Hop führt. Der Weiterleitungs-Next-Hop wird vom RSVP-Route-Next Hop abgeleitet. In vielen Fällen gibt es zahlreiche interne BGP-Routen, die dasselbe Protokoll im nächsten Hop haben. In solchen Fällen referenzierung der BGP-Routen den gleichen indirekten Next Hop.

Vor Junos OS Veröffentlichung 17.2R1 das Resolver-Modul des Routing-Protokollprozesses (rpd) resolved routen innerhalb der IBGP-empfangenen Routen auf folgende Weise:

  1. Partielle Routenauflösung– Der Protokoll-Next Hop wird basierend auf Helper-Routen wie RSVP oder IGP gelöst. Die Metrikwerte werden von den Hilfsrouten abgeleitet, und der nächste Hop wird als Resolver-Weiterleitungs-Next-Hop bezeichnet, der von Helper-Routen übernommen wurde. Diese Kennwerte werden zur Auswahl von Routen in der Routing Information Base (RIB) verwendet, die auch als Routing-Tabelle bekannt ist.

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

Das Resolver-Modul von RPD beginnt Junos OS Release 17.2R1 und ist für einen höheren Durchsatz bei eingehendem Verarbeitungsfluss optimiert und beschleunigt die Lernrate von RIB und FIB. Durch diese Erweiterung wird die Routenauflösung wie folgt beeinflusst:

  • Die teilweisen und vollständigen Routenauflösungsmethoden werden für jede IBGP-Route ausgelöst, obwohl jede Route möglicherweise die gleichen gelösten Weiterleitungsweiterleitungs-Next-Hop- oder KRT-Weiterleitungs-Next-Hops erbt.

  • Die BGP-Pfadauswahl ist erst dann zurückgestellt, wenn die vollständige Routenauflösung für NLRI (Network Layer Reachability Information) ausgeführt wird, die von einem BGP-Nachbarn empfangen werden, die möglicherweise nach der Routenauswahl nicht die beste Route in der RIB sind.

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

  • Niedrigere Kosten für die RIB-Auflösungssuche: Die Ausgabe des gelösten Pfads wird im Resolver-Cache gespeichert, sodass die gleichen abgeleiteten Next-Hop- und Metrikwerte zu einer anderen Gruppe von Routen übernommen werden können, die dasselbe Pfadverhalten nutzen, statt einen teilweisen und vollständigen Routenauflösungsfluss zu ausführen. Dies reduziert die Kosten für die Routenauflösungssuche, da nur der am häufigsten genutzte Resolver-Status in einem Cache mit begrenzter Tiefe beibehalten wird.

  • BGP-Routenauswahloptimierung – Der Algorithmus für die BGP-Routenauswahl wird doppelt für jede empfangene IBGP-Route ausgelöst. Zunächst wird die Route in der RIB als unbrauchbar hinzugefügt, und zweitens wird die Route mit einem gelösten nächsten Hop in der RIB (nach Routenauflösung) hinzugefügt. Dadurch wird die beste Route doppelt ausgewählt. Durch die Resolver-Optimierung wird der Routenauswahlprozess im Receive-Datenfluss erst nach Erhalt der Next-Hop-Informationen vom Resolver-Modul ausgelöst.

  • Internes Caching zur Vermeidung häufiger Suchfunktion: Der Resolver-Cache verwaltet den am häufigsten genutzten Resolver-Status. Im lokalen Cache werden daher Suchfunktionen wie Next-Hop-Suche und Routensuche durchgeführt.

  • Path Equivalence Group: Wenn verschiedene Pfade denselben Weiterleitungsstatus teilen oder vom selben Protokoll nächsten Hop empfangen werden, können die Pfade einer Pfadäquivalentgruppe angehören. Mit diesem Ansatz wird die Ausführung einer vollständigen Routenauflösung für solche Pfade vermieden. Wenn für einen neuen Pfad die vollständige Routenauflösung erforderlich ist, wird er zuerst in der Datenbank der Pfadäquivalenzgruppe angezeigt, die die Ausgabe des gelösten Pfads enthält, z. B. indirekter Next Hop und Forwarding Next Hop.

BGP Nachrichtenübersicht

Alle BGP-Nachrichten haben denselben Header in fester Größe, der ein Markierungsfeld enthält, das sowohl für die Synchronisierung als auch die Authentifizierung verwendet wird, ein Längenfeld, das die Länge des Pakets angibt, und ein Typfeld, das den Nachrichtentyp angibt (z. B. Offen, Update, Benachrichtigung, Keepalive und so weiter).

In diesem Abschnitt werden die folgenden Themen erörtert:

Nachrichten öffnen

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

Die offenen Nachrichten bestehen aus BGP Header und den folgenden Feldern:

  • Version: Die aktuelle BGP-Versionsnummer ist 4.

  • Lokale AS nummer: Sie konfigurieren dies durch Angabe der autonomous-system Anweisung auf der oder der [edit routing-options][edit logical-systems logical-system-name routing-options] Hierarchieebene.

  • Hold-Time: Vorgeschlagener Hold-Time-Wert. Sie konfigurieren die lokale Hold Time mit der hold-time BGP Auszug.

  • BGP Kennung – IP-Adresse des BGP Systems. Diese Adresse wird ermittelt, wann das System startet und für jede lokale Schnittstelle und jeden BGP gleich ist. Sie können die BGP Kennung konfigurieren, indem Sie die router-id Anweisung auf der oder der [edit routing-options][edit logical-systems logical-system-name routing-options] Hierarchieebene angeben. Standardmäßig verwendet BGP DIE IP-Adresse der ersten im Router gefundenen Schnittstelle.

  • Parameter der Feldlänge und die Parameter selbst – Dies sind optionale Felder.

Nachrichten aktualisieren

BGP senden Update-Nachrichten, um Informationen zur Netzwerkverfügbarkeit eintauschen zu können. BGP-Systeme diese Informationen verwenden, um ein Diagramm zu erstellen, das die Beziehungen zwischen allen bekannten ASs beschreibt.

Die Nachrichten aktualisieren bestehen aus BGP Header und den folgenden optionalen Feldern:

  • Nicht verfehlbare Routen Länge – Länge des Feldes zurückgenommener Routen

  • Zurückgenommene Routen – IP-Adressen-Präfixe für Routen, die aus dem Service entfernt werden, da sie nicht mehr als erreichbar angesehen werden

  • Länge des Pfadattributs – Länge des Feldes der Pfadattribute; Listen Sie die Pfadattribute für eine erreichbare Route zu einem Ziel auf.

  • Pfadattribute – Eigenschaften der Routen, einschließlich des Pfadbeginns, des Multiple Exit Discriminator (MED), der Präferenz des Ursprungssystems für die Route und Informationen zu Aggregation, Communities, Konsortien und Route Reflection

  • Network Layer Reachability Information (NLRI) – IP-Adressen-Präfixe erreichbarer Routen, die in der Aktualisierungsnachricht angekündigt werden

Keepalive-Nachrichten

BGP Systeme austauschen Informationsmeldungen, um zu bestimmen, ob eine Verbindung oder ein Host ausgefallen ist oder nicht mehr verfügbar ist. Informationsmeldungen werden häufig so ausgetauscht, dass der Hold Timer nicht abläuft. Diese Nachrichten bestehen nur aus der BGP Header.

Benachrichtigungen

BGP systeme Benachrichtigungen senden, wenn eine Fehlerbedingung erkannt wird. Nachdem Die Nachricht gesendet wurde, werden BGP Sitzung und die TCP-Verbindung zwischen den systemen BGP geschlossen. Die Benachrichtigungen bestehen aus der BGP, dem Fehlercode und dem Untercode sowie aus Daten, die den Fehler beschreiben.

Nachrichten zur Routenaktualisierung

BGP-Systeme Nur dann Routenaktualisierungsmeldungen an einen Peer senden, wenn sie die Nachricht zur Routenaktualisierungsfunktion vom Peer erhalten haben. Ein BGP muss die Funktion zur Routenaktualisierung mithilfe von Werbefunktionen BGP seinen Peers werben, wenn es Nachrichten zur Routenaktualisierung erhalten möchte. Diese optionale Nachricht wird gesendet, um dynamische, eingehende, BGP Routenaktualisierungen von BGP-Peers an anforderungen oder um Aktualisierungen der ausgehenden Route an einen eingehenden BGP senden.

Nachrichten zur Routenaktualisierung bestehen aus den folgenden Feldern:

  • AFI – Address Family Identifier (16 Bit).

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

  • SAFI – Nachfolgende Address Family Identifier (8-Bit).

Wenn ein Peer ohne die Funktion zur Routenaktualisierung eine Anforderungsnachricht zur Routenaktualisierung von einem Remote-Peer empfängt, ignoriert der Empfänger die Nachricht.

Understanding BGP Update IO Thread

Die Routenverarbeitung von BGP verfügt in der Regel über mehrere Pipeline-Phasen, z. B. Aktualisierungen des Updates, Analyse der Aktualisierung, Erstellen einer Route, Auflösung des nächsten Hops, Anwenden der Exportrichtlinie einer BGP-Peergruppe, Bilden von Peer-Updates pro Peer und Senden von Updates an Peers. BGP-Aktualisierungs-IO-Threads sind für das Ende dieser BGP-Pipeline verantwortlich und müssen pro Peer-Updates für einzelne BGP-Gruppen generiert und an die Peers senden. Ein Aktualisierungs-Thread kann eine oder mehrere Benutzergruppen BGP dienen. BGP Aktualisieren von IO-Threads Konstrukt-Updates für Gruppen parallel und unabhängig von anderen Gruppen, die von anderen Update-Threads gedrängt werden. Dies kann zu einer deutlichen Konvergenzverbesserung bei einer arbeitslast großen Arbeitslast führen, die Werbung für viele Peers, die über viele Gruppen verteilt sind, umfasst. BGP Aktualisieren von IO-Threads sind auch verantwortlich für das Schreiben zu und Lesen von den TCP-Steckdosen von BGP Peers, die zuvor von BGPIO-Threads bereitgestellt wurden (daher das Suffix IO in BGP Update IO).

BGP-Update-IO-Threads können unabhängig von der RIB-Sharding-Funktion konfiguriert werden, sind jedoch für die Verwendung mit RIB-Sharding erforderlich, um eine bessere Effizienz der Prefix-Packung bei eingehenden und BGP zu erreichen. BGP splittiert die RIB in mehrere Sub-RIBs, die von separaten RPD-Threads bedient werden. Daher gehen Präfixe, die über ein einzelnes ausgehendes Update gehen konnten, auf verschiedene Shardien hinaus. Um Updates BGP mit Präfixen mit demselben ausgehenden Attribut zu erstellen, das möglicherweise zu unterschiedlichen RPD-Shard-Threads gehört, senden alle sharden Threads kompakte Ankündigungsinformationen für Präfixe, die an einen Update-Thread gesendet werden, der diese BGP-Peer-Gruppe anordnt. Dadurch kann der Update-Thread für diese BGP Peer-Gruppe Präfixe mit den gleichen Attributen packen, die möglicherweise zu unterschiedlichen Shards in der gleichen ausgehenden Updatenachricht gehören. Auf diese Weise wird die Anzahl der zu werbenden Updates minimiert und die Konvergenz somit verbessert. Aktualisieren von IO-Thread verwaltet lokale Caches von Peer-, Gruppen-, Prefix-, RIB- und RIB-Containern.

BGP-Thread für Aktualisierungen ist standardmäßig deaktiviert. Wenn Sie Update-Threading auf einer Routing-Engine konfigurieren, erzeugt RPD Update-Threads. Standardmäßig ist die Anzahl der erstellten Aktualisierungs-Threads gleich wie die Anzahl der CPU-Cores in der Routing-Engine. Update-Threading wird nur in einem 64-Bit-Routingprotokollprozess (RPD) unterstützt. Optional können Sie die Anzahl der Threads, die Sie mithilfe von Anweisungen auf set update-threading <number-of-threads> der [edit system processes routing bgp] Hierarchieebene erstellen möchten, angeben. Die Reichweite beträgt derzeit 1 bis 128.

Grundlegendes BGP Pfadauswahl

Für jedes Präfix in der Routingtabelle wählt der Routingprotokollprozess einen einzelnen besten Pfad aus. Nach der Auswahl des besten Pfads wird die Route in der Routingtabelle installiert. Der beste Pfad wird zum aktiven Pfad, wenn dasselbe Präfix nicht durch ein Protokoll mit einem niedrigeren (bevorzugten) globalen Einstellungswert, auch als administrative Entfernung bezeichnet, gelernt wird. Folgende Algorithmen zur Bestimmung der aktiven Route sind die folgenden:

  1. Stellen Sie sicher, dass der nächste Hop gelöst ist.

  2. Wählen Sie den Pfad mit dem geringsten Einstellungswert (Prozesspräferenz für Routing-Protokolle).

    Routen, die nicht für die Weiterleitung verwendet werden können (beispielsweise, weil sie durch eine Routing-Richtlinie abgelehnt wurden oder weil ein nächster Hop nicht erreichbar ist) haben die Wahl von "-1" und sind nie gewählt.

  3. Bevorzugen Sie den Pfad mit lokaler Präferenz.

    Wählen Sie für Pfade außerhalb BGP den Pfad mit dem geringsten preference2 Wert.

  4. Wenn das gesammelte 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 Systempfadwert (AS), (bei Konfiguration der Aussage wird der as-path-ignore Pfad übersprungen).

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

  6. Bevorzugen Sie die Route mit dem niedrigeren Ursprungscode.

    Routen, die aus einem IGP gelernt werden, haben einen geringeren Ursprungscode als diejenigen, die von einem Aufweg-Gateway-Protokoll (EGP) gelernt wurden. Beide verfügen über geringere Ursprungscodes als unvollständige Routen (Routen, deren Ursprung nicht bekannt ist).

  7. Bevorzugen Sie den Pfad mit der geringsten Multiple Exit Discriminator (MED)-Metrik.

    Je nachdem, ob das Nichtterministische Routing-Tabellenpfadauswahlverhalten konfiguriert ist, gibt es zwei mögliche Fälle:

    • Wenn das nichtterministische Routing-Tabellenpfadsauswahlverhalten nicht konfiguriert ist (d. h. wenn die Anweisung nicht in der BGP-Konfiguration enthalten ist), sind Pfade mit den gleichen benachbarten AS-Nummern an der Vorderseite des AS-Pfads den Pfad mit der geringsten path-selection cisco-nondeterministic MED-Kennzahl bevorzugen. Um MEDs immer zu vergleichen, ob die Peer-ASs der verglichenen Routen identisch sind, geben Sie die Erklärung path-selection always-compare-med an.

    • Wenn das nichtterministische Routingtabellenpfadauswahlverhalten konfiguriert ist (d. h. die Anweisung in der BGP-Konfiguration enthalten), bevorzugen Sie den Pfad mit der geringsten path-selection cisco-nondeterministic MED-Kennzahl.

    Bei der Ermittlung der benachbarten ASs werden Confederations nicht berücksichtigt. Eine fehlende MED-Kennzahl wird behandelt, als wenn ein MED vorhanden sei, aber "null".

    Anmerkung:

    Der MED-Vergleich funktioniert bei der Auswahl einzelner Pfade innerhalb AS (wenn die Route keinen AS umfasst), obwohl diese Nutzung ungewöhnlich ist.

    Standardmäßig werden nur MEDs von Routen, die über die gleichen autonomen Peer-Systeme (ASs) verfügen, verglichen. Sie können Optionen zur Auswahl von Routing-Tabellenpfaden konfigurieren, um unterschiedliche Verhaltensweisen zu erhalten.

  8. Bevorzugt interne Pfade, zu denen IGP und lokal generierte Routen (statisch, direkt, lokal und so weiter) gehören.

  9. Bevorzugen Sie strikt externe BGP (EBGP)-Pfade über externe Pfade, die mittels interner BGP (IBGP) Sitzungen gelernt werden.

  10. Bevorzugen den Pfad, dessen nächster Hop durch die IGP mit der geringsten Kennzahl gelöst ist.

    Anmerkung:

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

    BGP-Pfade können nicht für Pfade verwendet werden, die die gleichen MED-plus-IGP haben und sich bei den betriebskostenbasierten IGP unterscheiden. Die Auswahl des Multipath-Pfads basiert IGP der Kostenkennzahl, selbst wenn zwei Pfade die gleichen MED-plus-IGP haben.

    BGP Vergleich der IGP Metrik vor dem Vergleich der Metrik selbst rt_metric2_cmp in. So werden beispielsweise BGP Routen, die durch eine IGP gelöst werden, verworfen oder abgelehnte next-hops dieser Art RTM_TYPE_UNREACH bevorzugt. Solche Routen werden wegen inactive ihrer metric-type erklärt.

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

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

    • Beide Peers haben dieselbe Router-ID.

    • Jeder Peer ist ein Confederation-Peer.

    • Beide Pfade sind der aktuelle aktive Pfad.

  12. Bevorzugen Sie einen Primärrouter über eine Sekundärroute. Eine Hauptroute ist eine Route, die der Routing-Tabelle gehört. Eine sekundäre Route ist eine Route, die über eine Exportrichtlinie der Routingtabelle hinzugefügt wird.

  13. Bevorzugen Sie den Pfad vom Peer mit der geringsten Router-ID. Ersetzen Sie bei jedem Pfad mit einem ID-Attribut des Originators die Originator-ID im Router-ID-Vergleich.

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

  15. Den Pfad von einem Peer mit der geringsten Peer-IP-Adresse bevorzugen.

Routing-Tabellenpfadauswahl

Der kürzeste Schritt AS Pfad des Algorithmus wird standardmäßig die Länge des AS und der aktive Pfad ermittelt. Sie können eine Option konfigurieren, die es Junos OS, diesen Schritt des Algorithmus zu überspringen, indem Sie diese as-path-ignore Option auswählen.

Anmerkung:

Die Option beginnt Junos OS Release 14.1R8-, 14.2R7-, 15.1R4-, 15.1F6- und 16.1R1 und wird für as-path-ignore Routinginstanzen unterstützt.

Die Pfadauswahl des Routing-Vorgangs erfolgt, BGP dem Pfad zur Routingtabelle nicht mehr zur Entscheidung übern gehen. Zum Konfigurieren des Routing-Tabellenpfadsauswahlverhaltens müssen Sie die Aussage path-selection beinhalten:

Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.

Die Auswahl des Routing-Tabellenpfads kann wie folgt konfiguriert werden:

  • Emulieren Sie das Cisco IOS-Standardverhalten ( cisco-non-deterministic ). Bei diesem Modus werden Routen in der Reihenfolge, in der sie empfangen wurden, ausgewertet und nicht nach den benachbarten AS. Im cisco-non-deterministic Modus ist der aktive Pfad immer an erster Stelle. Alle inaktiven, aber fähigen Pfade folgen dem aktiven Pfad und werden in der Reihenfolge, in der sie empfangen wurden, beibehalten. Dabei zuerst der neueste Pfad. Nicht wettbewerbsfähige Pfade bleiben das Ende der Liste.

    Beispiel: Sie haben drei Pfad-Ankündigungen für die 192.168.1.0 /24-Route:

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

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

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

    Diese Werbung wird in schneller Folge, innerhalb einer Sekunde, in der angegebenen Reihenfolge erhalten. Pfad 3 wird kürzlich empfangen, also vergleicht das Routing-Gerät es mit Pfad 2, der nächsten aktuellen Anzeige. Die Kosten für den IBGP-Peer sind für Pfad 2 besser, sodass das Routing-Gerät Pfad 3 vom Streitsatz beseitigt. Beim Vergleich von Pfad 1 und 2 bevorzugt das Routinggerät Pfad 1, da es von einem EBGP-Peer empfangen wird. Auf diese Weise 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. Dies wird einzig und allein aufgrund der Interoperabilität bereitgestellt, damit alle Routinggeräte im Netzwerk eine konsistente Routenauswahl treffen können.

  • Vergleich von MEDs stets, ob die Peer-ASs der verglichenen Routen gleich sind ( always-compare-med ).

  • Setzen Sie die Regel um, dass der derzeit aktive Pfad bevorzugt wird, wenn beide Pfade extern sind ( external-router-id ). Gehen Sie mit dem nächsten Schritt 12 (Schritt) bei der Pfadauswahl weiter.

  • Hinzufügen der IGP-Kosten zum Next-Hop-Ziel zum MED-Wert, bevor MED-Werte zur Pfadauswahl ( ) verglichen med-plus-igp werden.

    BGP-Multipath gilt nicht für Pfade, die die gleichen MED-plus-IGP haben, sich jedoch in den IGP unterscheiden. Die Auswahl des Multipath-Pfads basiert IGP der Kostenkennzahl, selbst wenn zwei Pfade die gleichen MED-plus-IGP haben.

BGP Tabellenpfadauswahl

Es werden die folgenden Parameter für die BGP Pfadauswahl folgt:

  1. Bevorzugen Sie den größtmöglichen Wert für lokale Vorlieben.

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

  3. Bevorzugen den geringsten Ursprungswert.

  4. Bevorzugen den niedrigsten MED-Wert.

  5. Bevorzugen Sie Routen, die von einem EBGP-Peer über einen IBGP-Peer gelernt werden.

  6. Bevorzugen sie eine Ausfahrt AS.

  7. Bei EBGP-empfangenen Routen bevorzugen Sie die aktuelle aktive Route.

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

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

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

Auswirkungen der Werbung mehrerer Pfade zu einem Ziel

BGP gibt nur den aktiven Pfad an, es sei denn, Sie haben eine Konfiguration BGP mehrere Pfade zu einem Ziel ausgeschrieben.

Nehmen wir einmal, ein Routing-Gerät verfügt über vier Pfade zu einem Ziel und kann bis zu drei Pfade anzeigen ( 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 entfernt sich aus der Überlegung und es wird ein neuer bester Pfad gewählt. Dieser Vorgang wird wiederholt, bis die angegebene Anzahl von Pfaden erreicht wird.

Unterstützte Standards für BGP

Junos OS die folgenden RFCs und Internet-Entwürfe, in denen Standards für IPv4-Richtlinien (IP Version 4) festgelegt BGP.

Eine Liste der unterstützten IPv6-Standards der IP-Version 6 (IPv6) finden Sie BGP 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 Extensions 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-Routing zwischen Domänen

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

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

  • RFC 2918, Routenaktualisierungsfunktion für BGP-4

  • RFC 3065, Autonome Systemgenossenschaften für BGP

  • RFC 3107, Carrying Label-Informationen in BGP-4

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

  • RFC 3392, Funktionsanzeige mit BGP-4

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

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

  • RFC 4360, BGP erweitertes 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, Subcodes für BGP Cease Notification Message

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

  • RFC 4632, Classless Inter-Domain Routing (CIDR): Der Internetadressenzuweisungs- 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 Extensions für BGP-4

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

  • RFC 4798, Verbinden der IPv6-Inseln über IPv4-MPLS mithilfe von IPv6 Provider Edge-Routern (6PE)

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

  • RFC 4893, BGP-Unterstützung für Vier-Oktett-AS-Platz

  • RFC 5004, Vermeiden BGP des besten Pfadübergangs von einem externen zu einem anderen

  • RFC 5065, Autonome Systemgenossenschaften für BGP

  • RFC 5082, Der allgemeine TTL-Sicherheitsmechanismus (GTSM)

  • RFC 5291, Outbound-Routenfilterungsfunktion 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 Junos OS ausgeführt werden, können prefix-basierte ORF-Nachrichten erhalten.

  • RFC 5396, Textdarstellung von Autonomous System (AS)-Zahlen

  • RFC 5492, Funktionsanzeige mit BGP-4

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

  • RFC 5549, Werbung für IPv4 Netzwerkschicht Erreichbarkeitsinformationen mit einem IPv6 Next Hop

  • RFC 5575, Verbreitung von Regeln der Datenfluss-Spezifikation

  • RFC 5668, 4 Oktett AS spezielle BGP Erweiterte Community

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

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

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

  • RFC 6811, BGP Prefix Origin-Validierung

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

  • RFC 7300, Reservation der letzten autonomen Systemnummern (AS)

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

  • RFC 7854, BGP Monitoring Protocol (BMP)

  • RFC 7911, Anzeige mehrerer Pfade in BGP

  • RFC 8212, Standard External BGP (EBGP) Route Propagation Behavior ohne richtlinienkonform

    Ausnahmen:

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

  • RFC 8326, Graceful BGP Session Shutdown

  • Internet Draft draft-idr-rfc8203bis-00, BGP (läuft ab Oktober 2018)

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

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

  • Internet draft-ietf-idr-as0-06, Codifizierung der Verarbeitung von AS 0 (läuft ab Februar 2013)

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

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

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

  • Internet draft-kato-bgp-ipv6-link-local-00.txt, BGP4+ Peering mithilfe von IPv6 Link-local Address

In den folgenden RFCs und Internet-Entwürfen werden keine Standards festgelegt, sondern Informationen über BGP und verwandte Technologien zur Verfügung gestellt. Der IETF klassifiziert sie auf verschiedene Weise als "experimentelle" oder "Informational".

  • RFC 1965, Autonome Systemgenossenschaften für BGP

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

  • RFC 2270, Verwendung einer dedizierten AS für Sites, die an einen einzelnen Anbieter homed sind

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

Release-Verlaufstabelle
Release
Beschreibung
17.2R1
Das Resolver-Modul von RPD beginnt Junos OS Release 17.2R1 und ist für einen höheren Durchsatz bei eingehendem Verarbeitungsfluss optimiert und beschleunigt die Lernrate von RIB und FIB.
14.1R8
Die Option beginnt Junos OS Release 14.1R8-, 14.2R7-, 15.1R4-, 15.1F6- und 16.1R1 und wird für as-path-ignore Routinginstanzen unterstützt.