BGP – Übersicht

In diesem Abschnitt werden die folgenden Themen behandelt:

• Autonome Systeme
• AS-Pfade und -Attribute
• Externes und internes BGP
• Mehrere BGP-Instanzen
• Protokolldatenverkehr für Schnittstellen in einer Sicherheitszone zulassen

Externes und internes BGP

BGP unterstützt zwei Arten des Austauschs von Routing-Informationen: Austausch zwischen verschiedenen AS und Austausch innerhalb eines einzelnen AS. Bei Verwendung unter AS wird BGP als externes BGP (EBGP) bezeichnet, und BGP-Sitzungen führen ein Inter-AS-Routing durch. Bei Verwendung in einem AS wird BGP als internes BGP (IBGP) bezeichnet, und BGP-Sitzungen führen ein AS-internes Routing durch. veranschaulicht ASs, IBGP und EBGP.Abbildung 1

Abbildung 1: ASs, EBGP und IBGP

Ein BGP-System teilt Informationen zur Netzwerkerreichbarkeit mit benachbarten BGP-Systemen, die als Nachbarn oder Peers bezeichnet werden.

BGP-Systeme sind in Gruppen angeordnet. In einer IBGP-Gruppe befinden sich alle Peers in der Gruppe – so genannte interne Peers – in derselben AS. Interne Peers können sich überall im lokalen AS befinden und müssen nicht direkt miteinander verbunden sein. Interne Gruppen verwenden Routen von einer IGP, um Weiterleitungsadressen aufzulösen. Sie verteilen auch externe Routen an alle anderen internen Router, auf denen IBGP ausgeführt wird, und berechnen den nächsten Hop, indem sie den nächsten BGP-Hop, der mit der Route empfangen wird, mithilfe von Informationen aus einem der internen Gateway-Protokolle auflösen.

In einer EBGP-Gruppe befinden sich die Peers in der Gruppe – sogenannte externe Peers – 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.

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

Die folgenden Informationen beschreiben den Pfad:

• AS-Pfad, bei dem es sich um eine Liste der Nummern der ASs handelt, die eine Route durchläuft, um den lokalen Router zu erreichen. Die erste Zahl im Pfad ist die des letzten AS im Pfad – der AS, der dem lokalen Router am nächsten ist. Die letzte Zahl im Pfad ist der AS, der am weitesten vom lokalen Router entfernt ist, der in der Regel der Ursprung des Pfads ist.

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

BGP-Peers kündigen sich gegenseitig Routen in Aktualisierungsnachrichten an.

BGP speichert seine Routen in der Routing-Tabelle von Junos OS ().inet.0 In der Routing-Tabelle werden die folgenden Informationen zu BGP-Routen gespeichert:

• Routinginformationen aus Updatenachrichten, die von Peers empfangen wurden

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

• Informationen, die BGP BGP-Peers in Aktualisierungsmeldungen ankündigt

Für jedes Präfix in der Routing-Tabelle wählt der Routing-Protokollprozess einen einzigen besten Pfad aus, den so genannten aktiven Pfad. Sofern Sie BGP nicht so konfigurieren, dass mehrere Pfade zum gleichen Ziel angekündigt werden, kündigt BGP nur den aktiven Pfad an.

Der BGP-Router, der eine Route zuerst ankündigt, weist ihr einen der folgenden Werte zu, um ihren Ursprung zu identifizieren. Bei der Routenauswahl wird der niedrigste Ursprungswert bevorzugt.

• 0– Der Router hat die Route ursprünglich über ein IGP (OSPF, IS-IS oder eine statische Route) gelernt.

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

• 2—Der Ursprung der Route ist unbekannt.

Bei einer internen BGP-Route (IBGP) mit einer Next-Hop-Adresse zu einem Remote-BGP-Nachbarn (Protokoll nächster Hop) muss der nächste Hop über eine andere Route aufgelöst werden. BGP fügt diese Route dem rpd-Resolver-Modul hinzu, um die Auflösung des nächsten Hops zu ermöglichen. Wenn RSVP im Netzwerk verwendet wird, wird der nächste BGP-Hop mithilfe der RSVP-Eingangsroute aufgelöst. Dies führt dazu, dass die BGP-Route auf einen indirekten nächsten Hop und der indirekte nächste Hop auf einen weiterleitenden nächsten Hop verweist. Der Weiterleitungs-Next-Hop wird vom nächsten Hop der RSVP-Route abgeleitet. Es gibt häufig eine große Anzahl interner BGP-Routen, die dasselbe Protokoll für den nächsten Hop haben, und in solchen Fällen würde der Satz von BGP-Routen auf denselben indirekten nächsten Hop verweisen.

Vor Junos OS Version 17.2R1 löste das Resolver-Modul des Routing-Protokoll-Prozesses (RPD) Routen innerhalb des IBGP auf folgende Weise auf:

1. Partial Route Resolution: Der nächste Hop des Protokolls wird basierend auf Hilfsrouten wie RSVP- oder IGP-Routen aufgelöst. Die Metrikwerte werden von den Hilfsrouten abgeleitet, und der nächste Hop wird als Resolver bezeichnet, der den nächsten Hop weiterleitet und von Hilfsrouten geerbt wurde. Diese Metrikwerte werden für die Auswahl von Routen in der Routing-Informationsbasis (RIB) verwendet, die auch als Routing-Tabelle bezeichnet wird.

2. Vollständige Routenauflösung: Der letzte nächste Hop wird abgeleitet und basierend auf der Weiterleitungsexportrichtlinie als Kernel-Routing-Tabelle (KRT) bezeichnet, die den nächsten Hop weiterleitet.

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

• Die Methoden zur Auflösung der partiellen und vollständigen Route werden für jede IBGP-Route ausgelöst, obwohl jede Route die gleichen aufgelösten nächsten Hops für die Weiterleitung oder die nächste KRT-Weiterleitung erben kann.

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

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

• Niedrigere Suchkosten für die RIB-Auflösung: Die Ausgabe des aufgelösten Pfads wird in einem Resolver-Cache gespeichert, sodass dieselben abgeleiteten Werte für den nächsten Hop und die gleichen Metrikwerte an einen anderen Satz von Routen mit demselben Pfadverhalten vererbt werden können, anstatt sowohl einen teilweisen als auch einen vollständigen Routenauflösungsfluss durchzuführen. Dadurch werden die Kosten für die Suche nach der Routenauflösung reduziert, da nur der häufigste Resolverstatus in einem Cache mit begrenzter Tiefe beibehalten wird.

• BGP-Routenauswahloptimierung – Der BGP-Routenauswahlalgorithmus wird für jede empfangene IBGP-Route zweimal ausgelöst – erstens, während die Route im RIB mit dem nächsten Hop als unbrauchbar hinzugefügt wird, und zweitens, während die Route mit einem aufgelösten nächsten Hop im RIB hinzugefügt wird (nach der Routenauflösung). Dies führt dazu, dass die beste Route zweimal ausgewählt wird. Bei der Resolver-Optimierung wird der Routenauswahlprozess im Empfangsfluss erst ausgelöst, nachdem die Next-Hop-Informationen vom Resolver-Modul abgerufen wurden.

• Internes Caching zur Vermeidung häufiger Lookups: Der Resolver-Cache behält den Status des häufigsten Resolvers bei, sodass die Lookup-Funktionen, wie z. B. die Suche nach dem nächsten Hop und die Routensuche, über den lokalen Cache ausgeführt werden.

• Pfadäquivalenzgruppe: Wenn verschiedene Pfade denselben Weiterleitungsstatus aufweisen oder vom nächsten Hop desselben Protokolls empfangen werden, können die Pfade zu einer Pfadäquivalenzgruppe gehören. Dieser Ansatz vermeidet die Notwendigkeit, für solche Pfade eine vollständige Routenauflösung durchzuführen. Wenn für einen neuen Pfad eine vollständige Routenauflösung erforderlich ist, wird er zunächst in der Datenbank der Pfadäquivalenzgruppe gesucht, die die aufgelöste Pfadausgabe enthält, z. B. indirekter nächster Hop und Weiterleitung des nächsten Hops.

In diesem Abschnitt werden die folgenden Themen behandelt:

• Offene Nachrichten
• Nachrichten aktualisieren
• Keepalive-Nachrichten
• Benachrichtigungen
• Route-Refresh-Meldungen

Die BGP-Routenverarbeitung umfasst in der Regel mehrere Pipeline-Phasen, z. B. das Empfangen von Updates, das Parsen von Updates, das Erstellen von Routen, das Auflösen des nächsten Hops, das Anwenden der Exportrichtlinie einer BGP-Peer-Gruppe, das Erstellen von Updates pro Peer und das Senden von Updates an Peers.

BGP-RIB-Sharding teilt ein einheitliches BGP-RIB in mehrere Sub-RIBs auf, und jedes Sub-RIB verarbeitet eine Teilmenge von BGP-Routen. Ein separater RPD-Thread, der als BGP-Shard-Thread bezeichnet wird, bedient jedes untergeordnete RIB von, um Parallelität zu erreichen. BGP-Shard-Threads sind für alle Phasen der BGP-Routenverarbeitungspipeline verantwortlich, mit Ausnahme der Bildung von Updates pro Peer und des Sendens von Updates an Peers. BGP-Shard-Threads empfangen die Updates, die von Peers von den BGP-Update-E/A-Threads gesendet werden, wobei die BGP-Update-E/A-Threads die Präfixe in den Updates hashen, und senden die Updates basierend auf der Hashberechnung an die entsprechenden BGP-Shard-Threads. Der BGP-Shard-Thread verarbeitet die Konfiguration auf die gleiche Weise wie der RPD-Hauptthread, erstellt Peers, Gruppen und Routing-Tabellen und verwendet die Konfigurationsinformationen für die BGP-Routenverarbeitung.

BGP-Update-E/A-Threads sind für das Ende dieser BGP-Pipeline verantwortlich, d. h. das Generieren von Updates pro Peer für einzelne BGP-Gruppen und das Senden dieser Updates an die Peers. Ein Update-Thread kann eine oder mehrere BGP-Gruppen bedienen. BGP-Update-E/A-Threads erstellen Updates für Gruppen parallel und unabhängig von anderen Gruppen, die von anderen Update-Threads bedient werden. Dies kann eine erhebliche Konvergenzverbesserung bei einer schreibintensiven Workload bieten, die Werbung an viele Peers erfordert, die über viele Gruppen verteilt sind. BGP-Update-IO-Threads sind auch für das Schreiben und Lesen in die TCP-Sockets der BGP-Peers verantwortlich, was zuvor von BGPIO-Threads bereitgestellt wurde (daher das Suffix IO in BGP Update IO).

BGP-Update-E/A-Threads können unabhängig von der RIB-Sharding-Funktion konfiguriert werden, müssen jedoch zwingend mit RIB-Sharding verwendet werden, um eine bessere Effizienz beim Präfixpacken in ausgehenden BGP-Aktualisierungsnachrichten zu erreichen. BGP-Sharding teilt das RIB in mehrere Sub-RIBs auf, die von separaten RPD-Threads bedient werden. Daher landen Präfixe, die in ein einzelnes ausgehendes Update hätten aufgenommen werden können, in verschiedenen Shards. Um BGP-Updates mit Präfixen mit demselben ausgehenden Attribut erstellen zu können, die zu verschiedenen RPD-Shard-Threads gehören können, senden alle Shard-Threads kompakte Ankündigungsinformationen für Präfixe, die an einen Update-Thread angekündigt werden sollen, der diese BGP-Peergruppe bedient. Auf diese Weise kann der Update-Thread, der diese BGP-Peer-Gruppe bedient, Präfixe mit denselben Attributen packen, die möglicherweise zu verschiedenen Shards in derselben ausgehenden Update-Nachricht gehören. Dies minimiert die Anzahl der anzukündigenden Updates und trägt so zur Verbesserung der Konvergenz bei. Der Update IO-Thread verwaltet lokale Caches von Peer-, Gruppen-, Präfix-, TSI- und RIB-Containern.

BGP-Update-Thread und BGP-RIB-Sharding sind standardmäßig deaktiviert. Wenn Sie Update-Threading und Rib-Sharding in einer Routing-Engine konfigurieren, erstellt RPD Update-Threads. Standardmäßig entspricht die Anzahl der erstellten Update-Threads und Shard-Threads der Anzahl der CPU-Kerne der Routing-Engine. Updatethreading wird nur für einen 64-Bit-Routing-Protokollprozess (RPD) unterstützt. Optional können Sie die Anzahl der Threads angeben, die Sie erstellen möchten, indem Sie and-Anweisungen auf Hierarchieebene verwenden.set update-threading <number-of-threads>set rib-sharding <number-of-threads>[edit system processes routing bgp] Für BGP-Update-Threads liegt der Bereich derzeit zwischen 1 und 128 und für BGP-RIB-Sharding zwischen 1 und 31.

Wenn Sie NSR für die Funktionen BGP RIB Sharding und BGP Update IO konfigurieren, erstellt der Backup-RPD die gleiche Anzahl von BGP-Shard- und BGP-Update-E/A-Threads in der Backup-Routing-Engine. Die Backup-RPD-BGP-Update-E/A-Threads lesen das replizierte BGP-Update, andere von den Peers empfangene Nachrichten sowie das replizierte BGP-Update und andere an die Peers gesendete Nachrichten. Basierend auf dem Hashing von Präfixen senden die Backup-RPD-BGP-Update-IO-Threads diese BGP-Nachrichten an den entsprechenden BGP-Shard und die RPD-Hauptthreads. Der BGP-Shard und die RPD-Hauptthreads in der Backup-RPD erstellen den Status der empfangenen und angekündigten Route mithilfe 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.

Für jedes Präfix in der Routing-Tabelle wählt der Routing-Protokollprozess einen einzigen besten Pfad aus. Nachdem der beste Pfad ausgewählt wurde, wird die Route in der Routing-Tabelle installiert. Der beste Pfad wird zur aktiven Route, wenn derselbe Präfix nicht von einem Protokoll mit einem niedrigeren (bevorzugteren) globalen Präferenzwert gelernt wird, der auch als administrative Distanz bezeichnet wird. Der Algorithmus zur Bestimmung der aktiven Route lautet wie folgt:

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

2. Wählen Sie den Pfad mit dem niedrigsten Präferenzwert (Routing-Protokoll-Prozesspräferenz).

   Routen, die nicht für die Weiterleitung verwendet werden können (z. B. weil sie von der Routingrichtlinie abgelehnt wurden oder weil auf einen nächsten Hop nicht zugegriffen werden kann), haben eine Präferenz von –1 und werden nie ausgewählt.

3. Bevorzugen Sie den Pfad mit höherer lokaler Präferenz.

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

4. Wenn das AIGP-Attribut (Accumulated Interior Gateway Protocol) aktiviert ist, fügen Sie die IGP-Metrik hinzu, und bevorzugen Sie den Pfad mit dem niedrigeren AIGP-Attribut.

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

   Ein Konföderationssegment (Sequenz oder Satz) hat eine Pfadlänge von 0. Eine AS-Menge hat eine Pfadlänge von 1.

6. Bevorzugen Sie die Route mit dem niedrigeren Ursprungscode.

   Routen, die von einem IGP gelernt wurden, haben einen niedrigeren Ursprungscode als solche, die von einem Exterior Gateway Protocol (EGP) gelernt wurden, und beide haben niedrigere Ursprungscodes als unvollständige Routen (Routen, deren Ursprung unbekannt ist).

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

   Je nachdem, ob das Auswahlverhalten für den Pfad der nicht deterministischen Routingtabelle konfiguriert ist, gibt es zwei mögliche Fälle:

   • Wenn das nicht deterministische Verhalten bei der Auswahl des Routing-Tabellenpfads nicht konfiguriert ist (d. h., wenn die Anweisung nicht in der BGP-Konfiguration enthalten ist), bevorzugen Sie für Pfade mit denselben benachbarten AS-Nummern am Anfang des AS-Pfads den Pfad mit der niedrigsten MED-Metrik.path-selection cisco-nondeterministic Um MEDs immer unabhängig davon zu vergleichen, ob die Peer-ASs der verglichenen Routen identisch sind, fügen Sie die Anweisung ein.path-selection always-compare-med

   • Wenn ein nicht deterministisches Verhalten bei der Auswahl des Routing-Tabellenpfads konfiguriert ist (d. h., die Anweisung ist in der BGP-Konfiguration enthalten), bevorzugen Sie den Pfad mit der niedrigsten MED-Metrik.path-selection cisco-nondeterministic

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

   HINWEIS:

   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 ungewöhnlich ist.

   Standardmäßig werden nur die MEDs von Routen verglichen, die über dieselben Peer Autonomous Systems (ASs) verfügen. Sie können Optionen für die Auswahl des Routing-Tabellenpfads konfigurieren, um unterschiedliche Verhaltensweisen zu erzielen.

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

9. Bevorzugen Sie ausschließlich externe BGP-Pfade (EBGP) gegenüber externen Pfaden, die durch interne BGP-Sitzungen (IBGP) erlernt wurden.

10. Bevorzugen Sie den Pfad, dessen nächster Hop über die IGP-Route mit der niedrigsten Metrik aufgelöst wird. BGP-Routen, die über IGP aufgelöst werden, werden gegenüber nicht erreichbaren oder abgelehnten Routen bevorzugt.

    HINWEIS:

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

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

11. Wenn beide Pfade extern sind, bevorzugen Sie den ältesten Pfad, also den Pfad, der zuerst gelernt wurde. Dies geschieht, um das Flapping von Routen zu minimieren. Diese Regel wird nicht verwendet, wenn eine der folgenden Bedingungen erfüllt ist:

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

    • Beide Peers haben dieselbe Router-ID.

    • Bei beiden Peers handelt es sich um Konföderationspeers.

    • Keiner der beiden Pfade ist der aktuell aktive Pfad.

12. Bevorzugen Sie eine primäre Route gegenüber einer sekundären Route. Eine primäre Route ist eine Route, die zur Routing-Tabelle gehört. Eine sekundäre Route ist eine Route, die der Routingtabelle über eine Exportrichtlinie hinzugefügt wird.

13. Bevorzugen Sie den Pfad vom Peer mit der niedrigsten Router-ID. Ersetzen Sie für jeden Pfad mit einem Absender-ID-Attribut die Router-ID während des Router-ID-Vergleichs durch die Absender-ID.

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

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

• Auswahl des Routing-Tabellenpfads
• Auswahl des BGP-Tabellenpfads
• Auswirkungen der Werbung für mehrere Pfade zu einem Ziel

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 BGP-Standards der IP-Version 6 (IPv6) 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-Community-Attribut

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

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

• RFC 2439, BGP-Klappendämpfung

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

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

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

• RFC 2918, Routenaktualisierungsfunktion für BGP-4

• RFC 3065, Autonomous System Confederations for BGP (Autonome Systemkonföderationen für BGP)

• RFC 3107, Carrying Label Information in BGP-4

• RFC 3345, Border Gateway Protocol (BGP) Persistente Route-Oszillationsbedingung

• RFC 3392, Ankündigung zu 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-Routenreflexion: Eine Alternative zu Full Mesh Internal BGP (IBGP)

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

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

• RFC 4632, Classless Inter-Domain Routing (CIDR): Der Zuweisungs- und Aggregationsplan für Internetadressen

• RFC 4684, Constrained Route Distribution 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, Multiprotokoll-Erweiterungen für BGP-4

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

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

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

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

• RFC 5004, Vermeiden Sie BGP-Übergänge mit dem besten Pfad von einem externen zu einem anderen

• RFC 5065, Autonomous System Confederations für BGP

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

• RFC 5291, Filterfunktion für ausgehende Routen für BGP-4 (teilweise Unterstützung)

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

  Geräte mit Junos OS können präfixbasierte ORF-Nachrichten empfangen.

• RFC 5396, Textuelle Darstellung von AS-Nummern (Autonomous System)

• RFC 5492, Ankündigung zu Funktionen mit BGP-4

• RFC 5512, Der BGP Encapsulation Subsequent Address Family Identifier (SAFI) und das BGP Tunnel Encapsulation Attribute

• RFC 5549, Ankündigung von IPv4-Informationen zur Erreichbarkeit der Netzwerkschicht mit einem IPv6 Next Hop

• RFC 5575, Verbreitung von Ablaufspezifikationsregeln

• RFC 5668, 4-Oktett-AS-spezifische BGP-Extended Community

• RFC 6286, Autonomous-systemwide Unique BGP Identifier for BGP-4 – vollständig konform

• RFC 6368, Internes BGP als Anbieter-/Kunden-Edge-Protokoll für BGP/MPLS-IP Virtual Private Networks (VPNs)

• RFC 6810, Das Resource Public Key Infrastructure (RPKI)-to-Router-Protokoll

• RFC 6811, Ursprungsvalidierung von BGP-Präfixen

• RFC 6996, Reservierung für autonome Systeme (AS) für den privaten Gebrauch

• RFC 7300, Reservierung der letzten AS-Nummern (Autonomous System)

• RFC 7611, BGP ACCEPT_OWN Community-Attribut

  Wir unterstützen den RFC, indem wir es Juniper Routern ermöglichen, Routen zu akzeptieren, die von einem Routenreflektor mit dem Community-Wert empfangen werden.accept-own

• RFC 7752, North-bound-Verteilung von Link-State- und Traffic Engineering (TE)-Informationen mithilfe von BGP

• RFC 7854, BGP-Überwachungsprotokoll (BMP)

• RFC 7911, Ankündigung mehrerer Pfade in BGP

• RFC 8212, Default External BGP (EBGP) Route Propagation Behavior without Policies – vollständig konform

  Ausnahmen:

  Die Verhaltensweisen in RFC 8212 sind standardmäßig nicht implementiert, um eine Unterbrechung der bestehenden Kundenkonfiguration zu vermeiden. Das Standardverhalten wird weiterhin beibehalten, um alle Routen in Bezug auf EBGP-Peers zu akzeptieren und anzukündigen.

• RFC 8326, Ordnungsgemäßes Herunterfahren der BGP-Sitzung

• RFC 9069, Unterstützung für lokale RIB im BGP Monitoring Protocol (BMP)

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

• Internet-Entwurf draft-ietf-grow-bmp-adj-rib-out-01, Unterstützung für Adj-RIB-Out im BGP Monitoring Protocol (BMP) ( läuft am 3. September 2018 ab)

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

• Internet-Entwurf draft-ietf-idr-as0-06, Kodifizierung der AS-0-Verarbeitung (gültig bis Februar 2013)

• Internet-Entwurf draft-ietf-idr-link-bandwidth-06.txt, BGP Link Bandwidth Extended Community (gültig bis Juli 2013)

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

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

• Internet-Entwurf draft-kato-bgp-ipv6-link-local-00.txt, BGP4+-Peering mit IPv6 Link-Local Address

Die folgenden RFCs und Internet-Entwürfe definieren keine Standards, sondern geben Auskunft über BGP und verwandte Technologien. Die IETF klassifiziert sie unterschiedlich als "experimentell" oder "informativ".

• RFC 1965, Autonomous System Confederations for BGP (Autonome Systemkonföderationen für BGP)

• RFC 1966, BGP Route Reflection – Eine Alternative zu vollmaschigem IBGP

• RFC 2270, Verwendung eines dedizierten AS für Standorte, die von einem einzigen Anbieter verwaltet werden

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