Unterschiede zwischen as-OVERRIDE und ALLOWAS-IN

Einführung

ALLOWAS-IN und as-OVERRIDE sind zwei ähnliche Funktionen, die in einem Szenario verwendet werden können, in dem ein as X (z. B. Anbieter) über mehrere Standorte / PoPs mit einem anderen as Y (z. B. Transitbetreiber / Backbone-MPLS) verbunden ist,. Um beide Funktionen besser zu verstehen, ist es angebracht zu analysieren, wie die Steuerung von Schleifen im BGP-Protokoll (RFC 4271) funktioniert.

Die BGP-Protokollspezifikation bietet mehrere Mechanismen zur Steuerung und Verhinderung von Schleifen. In einem iBGP-Szenario (d. H. BGP-Sitzungen innerhalb einer same AS) ist die Split-Horizon-Regel beispielsweise einer der Schleifensteuerungs- und Verhinderungsmechanismen, der verhindert, dass von einem iBGP-Nachbarn (A) an den iBGP-Nachbarn (B) angekündigte Präfixe von (B) an einen dritten iBGP-Nachbarn (C) erneut angekündigt werden. Es gibt mehrere mögliche Lösungen, um diese Regel zu “entspannen” (die Verwendung von Routenreflektoren ist beispielsweise eine davon), aber sie werden in diesem Artikel nicht diskutiert.

bereits in eBGP-Szenarien (d. h. BGP-Sitzungen zwischen verschiedenen Aces) ist der einfachste Regelungs- und Präventionsmechanismus die Analyse des Attributs as_path. Wenn der eBGP-Peer (A) seine eigene ASN im Attribut as_path des / der vom eBGP-Peer (B) angekündigten Präfixes (s) findet (und umgekehrt), verwirft der Router das Präfix, um eine mögliche Routingschleife zu vermeiden. ALLOWAS – IN und as-OVERRIDE sind zwei ähnliche Lösungen, die in diesem Fall verwendet werden können, und von diesem Punkt an werden wir detailliert beschreiben, in welchen Situationen wir die eine oder andere verwenden können.

ALLOWAS-IN

Betrachten Sie das Szenario in Abbildung 1, in dem AS 20 (Provider) as 10 (Upstream) Transit Client ist. Topologien dieser Art können mit einer gewissen Häufigkeit auftreten, z. B. bei Internetanbietern, die keine physische Verbindung zwischen ihren IP-PoPs haben und IP-Transit von einem vorgelagerten Anbieter erwerben müssen, um ihren Abonnenten in jedem PoP / Ort Internetzugang bereitzustellen.

Abbildung 1: Client (AS 20) verbunden mit ISP / UPSTREAM (as 10) in zwei PoPs an verschiedenen Orten.

In diesem Szenario kündigt R2 das Präfix 10.0.0.0/24 für Upstream an, und der as_path dieses Präfixes wird auf dem Upstream-Router wie folgt angezeigt:

R1_Upstream#sh ip bgp 10.0.0.0/24 Network Next Hop Metric LocPrf Weight Path*> 10.0.0.0/24 100.64.0.2 100 20 i

nach dem “normalen” Betrieb des BGP-Protokolls (dh Ignorieren von Filtern, Routingrichtlinien usw.).), wird das as_path-Attribut des Präfixes auf R1 geändert, bevor es gegenüber seinen Peers erneut angekündigt wird. Die “neue” as-PATH-Liste des Präfixes sieht ungefähr so aus:

AS_PATH: 10 20 i

Wenn jedoch die BGP-Aktualisierungsnachricht mit dem Präfix 10.0.0.0 / 24 R3 erreicht, verwirft R3 dieses Update, da es das Vorhandensein einer eigenen ASN (in diesem Fall 20) im Attribut as_path dieses Präfixes bemerkt. Eine ähnliche Warnung ist im R3-Routerprotokoll (Cisco IOS-Plattform, Debug-Modus) zu sehen:

Hier kommt ALLOWAS-IN ins Spiel, um diese Einschränkung zu lockern. ALLOWAS-IN wird auf dem Router des Anbieters konfiguriert, in diesem Fall R3. Der Effekt ist, dass BGP einfach das mögliche Vorhandensein eines eigenen AS im as_path von Präfixen akzeptiert, die von Upstream empfangen werden.

auf den meisten Plattformen (Cisco, Juniper, etc.) ALLOWAS-IN erfordert einen Parameter, der die maximale Anzahl von Vorkommen einer eigenen ASN im Attribut as_path ist, das den empfangenen Präfixen zugeordnet ist. Zum Beispiel in Cisco IOS, wenn wir das Auftreten von bis zu 2-fache seiner eigenen ASN erlauben wollen, in Route Updates über Peer eBGP 1.1.1.1 (R1_Upstream) Die Konfiguration ist wie folgt:

R3# conf tR3# (config) router bgp 20R3# (config-router) neighbor 1.1.1.1 allowas-in 2

Im obigen Beispiel führen wir die Konfiguration so durch, dass wir Präfixe lernen können, die höchstens 2 Vorkommen einer eigenen ASN im Feld as-PATH enthalten, wenn sie vom Nachbarn 1.1.1.1 abweichen, was dem Szenario des zuvor veröffentlichten Diagramms entsprechen würde. Es ist wichtig zu beachten, dass ALLOWAS-IN auf allen Client-Routern konfiguriert werden muss, auf denen die BGP-Schleifensteuerungsregel gelockert werden soll!

Schauen wir uns ein vollständigeres Beispiel an (und mit aktiviertem Debug-Modus auf der Cisco IOS-Plattform). Im Terminal ist es möglich, die BGP-Aktualisierungsnachricht, die die Datenstruktur enthält, die Informationen über das Präfix und die Subnetzmaske enthält, ziemlich deutlich zu sehen (Network Layer Reachability Information – NLRI). Im Folgenden kann festgestellt werden, dass der Router das Vorhandensein von AS 20 im Attribut as_path des von r1_upstream (Nachbar 1.1.1.1) angekündigten Präfixes 10.0.0.0/ 24 erkannt, das Präfix jedoch in der Weiterleitungstabelle (FIB) installiert hat, da die durch die Konfiguration “allowas-in” für Nachbar 1.1.1.1 auferlegte Einschränkung gelockert wurde:

AS-OVERRIDE

Wie bereits erwähnt, ist die as-OVERRIDE-Funktionalität in Bezug auf das gewünschte Ziel, die BGP-Protokollschleifensteuerung zu entspannen, der ALLOWAS-IN sehr ähnlich. Der große Unterschied zwischen den beiden besteht jedoch darin, dass das Attribut as_path des Präfixes geändert wird, indem das Vorhandensein der “ursächlichen” ASN der Schleife durch die ASN der Schleife selbst ersetzt wird. Infolgedessen wird AS-OVERRIDE immer auf der Upstream-Seite (Dienstanbieter) konfiguriert, während die gesamte zulässige Konfiguration auf der Clientseite durchgeführt wird.

Es ist auch erwähnenswert, dass die Verwendung von as-OVERRIDE im Allgemeinen mit Layer-3-VPN-Szenarien (L3VPN) in einem verwalteten MPLS-Netzwerk verbunden ist. In diesem Szenario verfügt der Kunde über mehrere Standorte und verwendet BGP als Routingprotokoll zwischen seinem vorgelagerten CE (Customer Edge) und PE (Provider Edge). In diesem Fall wird as-OVERRIDE auf PE-Routern angewendet, und der Effekt besteht darin, dass die CE-ASN durch die PE-ASN ersetzt wird, bevor die Präfixe den anderen PE im MPLS-Netzwerk erneut mitgeteilt werden.

Im obigen Diagramm würde der CE/R3 Router das Präfix 10.0.0.0 / 24 mit dem as-PATH Attribut “20 10” erhalten und dann würde ich den ankündigung aufgrund des bereits zuvor diskutierten Mechanismus zur Verhinderung von BGP-Schleifen. Wenn jedoch die as-OVERRIDE-Konfiguration auf PE1 durchgeführt wird, erhält der CE / R3-Router das Präfix 10.0.0.0 / 24 mit dem as-path-Attribut “10 10” und das Präfix wird daher auf der FIB installiert. Es ist äußerst wichtig darauf hinzuweisen, dass AS-OVERRIDE auf allen PE-Routern konfiguriert werden muss, um die Erreichbarkeit von Client-Präfixen innerhalb von L3VPN sicherzustellen!

aus operativer Sicht ist die as-OVERRIDE-Konfiguration bei den meisten aktuellen routers.As ein Beispiel, schauen wir uns die Konfiguration auf Cisco IOS für das obige Szenario an:

Die as-OVERRIDE-Konfiguration wird in der BGP-Sitzung zwischen PE und CE zurückgesetzt. Im Folgenden wird es möglich sein, die Präfixe zu überprüfen, die von den CE-Routern dieses VPNs stammen oder angekündigt wurdenv4 enthält nur die ASN des PE (Upstream) im Attribut AS_PATH:

Die Verwendung von as-OVERRIDE muss gut durchdacht und geplant sein, um Probleme oder Inkonsistenzen bei der Weiterleitung von Paketen zu vermeiden, schließlich entspannen wir uns Ein Hilfsmechanismus zur Vermeidung dieser Probleme ist die Verwendung der BGP Extended Community “Site of Origin – SoO”, um die IP-Präfixe zu identifizieren, die jede VPN-Client-Site über L3VPN an andere CES weitergibt. In diesem Artikel werden wir dieses Thema jedoch nicht diskutieren und es ist ein zusätzliches Forschungsthema für den Leser.

Autoren: Daniel Damitoe Humberto Galiza

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.