Fehlerbehebung: OMP - Besonderheiten und typische Verwirrungen bei der Auswahl der besten Pfade
Download-Optionen
-
ePub (93.2 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Inklusive Sprache
In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Informationen zu dieser Übersetzung
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Inhalt
Einleitung
Dieses Dokument beschreibt ein typisches Missverständnis bei der Auswahl des besten Pfades (OMP) und der Reihenfolge des Betriebs zwischen der OMP-Auswahl des besten Pfades, der Ausgangs-Policy und der Funktion zur Beschränkung des Sendepfads.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse der SDWAN-Lösung (Software Defined Wide Area Network) von Cisco verfügen.
Verwendete Komponenten
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Für diese Demonstration wurden im Labor drei vSmart Controller und drei Cisco IOS® XE-Router mit den Standort-IDs 243, 244 und 245 eingerichtet, die dasselbe 172.16.1.0/24-Präfix ankündigen. An das Overlay sind auch einige andere Router angeschlossen (z. B. mit Standort-ID 204). Das letzte Oktett einer Router-System-IP entspricht in diesem Beispiel der Standort-ID (10.10.10.<Standort-ID>). vSmarts verfügen über system-ip 10.10.10.228, .229 und .230. In diesem Beispiel stehen für jeden Router zwei Transportnetze (WAN-Schnittstellen) zur Verfügung, daher zwei Transport Locators (TLOCs) mit den Farben private1 und biz-internet. Auf private1 hat der Circuit-Router eine zugewiesene IP-Adresse in der Form 192.168.9.x und auf biz-internet hat er 192.168.10.x, wobei x eine Standort-ID ist.
Die Szenarien wurden mit vSmarts mit den Softwareversionen 20.4.1 und 20.6.1 getestet.
Auswahl des besten Pfades, Ausgangs-Policy und Reihenfolge der Sendepfadbegrenzungen
Zunächst müssen Sie die beste Pfadauswahl, die beste Ausgangs-Policy und die beste send-path-limit Reihenfolge der Abläufe zeigen. Router mit der Standort-ID 247 müssen ein Präfix von Routern mit der Standort-ID 244 oder 245 erhalten, jedoch nicht von 243.
Hier ist die Politik, dies zu erreichen als Referenz:
policy
lists
site-list site_247
site-id 247
!
site-list sites_244_245
site-id 244
site-id 245
!
prefix-list ENK_PL
ip-prefix 172.16.1.0/24
!
!
control-policy send_2_247
sequence 10
match route
prefix-list ENK_PL
site-list sites_244_245
!
action accept
!
!
sequence 20
match route
prefix-list ENK_PL
!
action reject
!
!
default-action accept
!
!
apply-policy
site-list site_247
control-policy send_2_247 out
!
!Ein vSmart2 bietet Konnektivität zu zwei anderen vSmarts (Standort-ID 1) und Edge-Routern mit Standort-ID 243, 244 und 247. Standort 245 ist mit einem anderen vSmart-Controller verbunden, und vSmart2 erhält sein Präfix von diesem indirekt über andere vSmart(s).
vsmart2# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
------------------------------------------------------------------------------------------
10.10.10.204 vedge 1 1 204 up 2:20:18:10 14/0/7
10.10.10.228 vsmart 1 1 1 up 2:20:18:06 247/0/9
10.10.10.230 vsmart 1 1 1 up 2:20:17:07 256/0/15
10.10.10.243 vedge 1 1 243 up 2:20:18:10 8/0/7
10.10.10.244 vedge 1 1 244 up 0:13:24:59 10/0/6
10.10.10.247 vedge 1 1 247 up 2:20:18:10 0/0/8
In der OMP-Tabelle können Sie feststellen, dass die Route von zwei anderen vSmart-Controllern sowie direkt von den Standorten 243 und 244 empfangen wird:
vsmart2# show omp routes 172.16.1.0/24
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA -> On-demand inactive
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1 172.16.1.0/24 10.10.10.228 409 1001 C,R installed 10.10.10.243 public-internet ipsec -
10.10.10.230 7187 1002 C,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.243 69 1001 C,R installed 10.10.10.243 public-internet ipsec -
10.10.10.243 81 1001 C,R installed 10.10.10.243 private1 ipsec -
10.10.10.244 68 1002 C,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.244 81 1002 C,R installed 10.10.10.244 private1 ipsec -send-path-limit - in dieser Demonstration auf 1 eingestellt ist:
vsmart2# show running-config omp
omp
no shutdown
send-path-limit 1
no graceful-restart
!
Hinweis: Von allen Multi-Pfaden mit gleichen Kosten für ein gegebenes Präfix, die als bestmögliche Pfade ausgewählt und von der ausgehenden (Egress-)Richtlinie akzeptiert werden, maximal die Anzahl der Pfade, die in der angegebenen "Send-Path-Limit" angegeben sind.
Sie können überprüfen, welches Präfix an welchen Peer gesendet wird. Die vom Standort 243 stammende Route hat die niedrigste Originator-System-IP in der OMP-Routenliste. Da send-path-limit der Wert auf 1 festgelegt ist, stammt die einzige Route, die den Routern mit der Standort-ID 204 und 244 sowie zwei anderen vSmart-Controllern (10.10.10.228, .230) angekündigt wurde, aus der biz-internet-TLOC, da sie eine höchste private IP-Adresse (der Schnittstelle zugewiesene Adresse):
vsmart2# show omp tlocs ip 10.10.10.243 received | b PUBLIC
ADDRESS PSEUDO PUBLIC PRIVATE
FAMILY TLOC IP COLOR ENCAP FROM PEER STATUS KEY PUBLIC IP PORT PRIVATE IP PORT
------------------------------------------------------------------------------------------------------------------------
ipv4 10.10.10.243 biz-internet ipsec 10.10.10.228 C,R 1 192.168.10.243 12346 192.168.10.243 12346
10.10.10.230 C,R 1 192.168.10.243 12346 192.168.10.243 12346
10.10.10.243 C,I,R 1 192.168.10.243 12346 192.168.10.243 12346
10.10.10.243 private1 ipsec 10.10.10.228 C,R 1 192.168.9.243 12346 192.168.9.243 12346
10.10.10.230 C,R 1 192.168.9.243 12346 192.168.9.243 12346
10.10.10.243 C,I,R 1 192.168.9.243 12346 192.168.9.243 12346Die Standort-ID 243 erhält die nächste Route aus der Liste (von Standort 244) und wird ebenfalls über die Biz-Internet-Farbe angezeigt, da sie die höchste private TLOC-IP-Adresse aufweist. Standort 243 erhält aufgrund der Split-Horizon-Regel keine eigene Route, obwohl er die niedrigste System-IP hat. Standort 247 erhält die Route von Standort 244 aufgrund der Egress-Richtlinie ebenfalls.
vsmart2# show omp routes 172.16.1.0/24 detail | nomore | exclude not\ set | b ADVERTISED | include peer\|originator\|tloc
peer 10.10.10.204
originator 10.10.10.243
tloc 10.10.10.243, biz-internet, ipsec
peer 10.10.10.228
originator 10.10.10.243
tloc 10.10.10.243, biz-internet, ipsec
peer 10.10.10.230
originator 10.10.10.243
tloc 10.10.10.243, biz-internet, ipsec
peer 10.10.10.243
originator 10.10.10.244
tloc 10.10.10.244, biz-internet, ipsec
peer 10.10.10.244
originator 10.10.10.243
tloc 10.10.10.243, biz-internet, ipsec
peer 10.10.10.247
originator 10.10.10.244
tloc 10.10.10.244, biz-internet, ipsec
Auswahl des besten vSmart-Pfads: Routen am Edge-Router im Vergleich zu Routen, die über andere vSmarts empfangen wurden Fall 1
Um diese Demonstration fortzusetzen, erhöhen Sie sie, send-path-limit und stellen Sie sie auf 16 ein, aktivieren Sie sie, debug omp policy prefix 172.16.1.0/24 level highund beobachten Sie die Ergebnisse. vSmart2 empfängt jetzt auch eine Route von Standort-ID 245 über vSmart1 mit System-ip (10.10.10.228 und vSmart3 mit 10.10.10.230).
vsmart2# show omp routes 172.16.1.0/24
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA -> On-demand inactive
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1 172.16.1.0/24 10.10.10.228 10146 1001 C,R installed 10.10.10.243 public-internet ipsec -
10.10.10.228 10448 1001 C,R installed 10.10.10.243 private1 ipsec -
10.10.10.228 10449 1002 C,R installed 10.10.10.245 biz-internet ipsec -
10.10.10.228 10450 1002 C,R installed 10.10.10.245 private1 ipsec -
10.10.10.230 10252 1002 C,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.230 10577 1002 C,R installed 10.10.10.244 private1 ipsec -
10.10.10.230 10578 1002 C,R installed 10.10.10.245 biz-internet ipsec -
10.10.10.230 10579 1002 C,R installed 10.10.10.245 private1 ipsec -
10.10.10.243 69 1001 C,R installed 10.10.10.243 public-internet ipsec -
10.10.10.243 81 1001 C,R installed 10.10.10.243 private1 ipsec -
10.10.10.244 68 1002 C,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.244 81 1002 C,R installed 10.10.10.244 private1 ipsec -vSmart2 kündigt jedoch nur Routen von Standort 244 und nicht mehr von Standort 245 an, und zwar jetzt von Standort 247. Dies ist eine typische Verwechslungsquelle, da Routen, die direkt von Edge-Routern empfangen werden, gegenüber Routen bevorzugt werden, die über vSmarts empfangen und nicht an einen Edge-Router weitergegeben und nicht an einen Edge-Router gesendet werden. Dies gilt jedoch nur, wenn vSmart einen OMP-Routing-Tabelleneintrag für dasselbe Präfix von einem anderen vSmart gefunden hat, mit dem der Edge-Router bereits verbunden ist:
vsmart2# show omp routes 172.16.1.0/24 detail | nomore | exclude not\ set | b ADVERTISED | include peer\|originator
peer 10.10.10.204
originator 10.10.10.244
originator 10.10.10.244
originator 10.10.10.243
originator 10.10.10.243
peer 10.10.10.228
originator 10.10.10.244
originator 10.10.10.244
originator 10.10.10.243
originator 10.10.10.243
peer 10.10.10.230
originator 10.10.10.244
originator 10.10.10.244
originator 10.10.10.243
originator 10.10.10.243
peer 10.10.10.243
originator 10.10.10.244
originator 10.10.10.244
peer 10.10.10.244
originator 10.10.10.243
originator 10.10.10.243
peer 10.10.10.247
originator 10.10.10.244
originator 10.10.10.244
Dies wird auch aus Debug-Protokollen bestätigt, die in gespeichert sind, in /var/log/tmplog/vdebug denen der Grund für die Unterdrückung als vSmart Connectivityangesehen wird.
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.243 Path: 69 suppressed due to - Policy Rejection
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.243 Path: 81 suppressed due to - Policy Rejection
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.228 Path: 11005 suppressed due to - vSmart Connectivity
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.228 Path: 11006 suppressed due to - vSmart Connectivity
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.228 Path: 11007 suppressed due to - vSmart Connectivity
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.228 Path: 11008 suppressed due to - vSmart Connectivity
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.230 Path: 11186 suppressed due to - vSmart Connectivity
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.230 Path: 11187 suppressed due to - vSmart Connectivity
Bedenken Sie gleichzeitig, dass der Standort 247 beide Routen dennoch empfängt, da er standardmäßig mit zwei vSmart-Controllern (max-control-connections 2) verbunden ist und vSmart3 ihm beide Routen ankündigt, da die Ausgangspunkte direkt mit ihm verbunden sind:
Site-247#show sdwan omp routes 172.16.1.0/24 | begin PATH
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1 172.16.1.0/24 10.10.10.229 13 1002 C,I,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.229 14 1002 C,I,R installed 10.10.10.244 private1 ipsec -
10.10.10.230 13 1002 C,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.230 14 1002 C,R installed 10.10.10.244 private1 ipsec -
10.10.10.230 61 1002 C,I,R installed 10.10.10.245 biz-internet ipsec -
10.10.10.230 62 1002 C,I,R installed 10.10.10.245 private1 ipsec -vsmart3# show omp routes 172.16.1.0/24 detail | nomore | exclude not\ set | b ADVERTISED | include peer\|originator | b "peer 10.10.10.247"
peer 10.10.10.247
originator 10.10.10.244
originator 10.10.10.244
originator 10.10.10.245
originator 10.10.10.245Eine Zusammenfassung der besten Pfadauswahl und der Reihenfolge der Vorgänge in dieser Tabelle.
| 1. Nicht veraltete Route über veraltete Route bevorzugen |
| 2. Auflösbarkeit der Route Next-Hop-TLOC ist erreichbar (BFD-Sitzung auf Datenebene ist hier vorhanden) |
| 3. Bevorzugen Sie die höchste Routenpräferenz |
| 4. Bevorzugen die höchste TLOC-Präferenz |
| 5. Bevorzugen Sie den besten Ursprungscode (Verbunden, Statisch, eBGP, EIGRP Intern, OSPF Intra, OSPF Inter, OSPF Extern, EIGRP Extern iBGP, Unbekannt/Unset) |
| 6. Routenquellenpräferenz. Bei vSmart: Routing am Edge über Router statt Routing über vSmart bevorzugen |
| 7. Bevorzugen OMP-Route mit niedrigster Ursprungsmetrik |
| 8. Bevorzugen Route empfangen von niedrigster System-IP |
| 9. Bevorzugen Sie die Route von der höchsten privaten TLOC-IP-Adresse, die von derselben Standort-ID stammt. |
| 10. Richtlinie zur Kontrolle des ausgehenden Datenverkehrs |
| 11. Beschränkung des Sendepfads |
Auswahl des besten vSmart-Pfads: Routen am Edge-Router im Vergleich zu Routen, die über andere vSmarts empfangen wurden Fall 2
Dieses Verhalten zeigt sich in Szenarien mit doppeltem Ausfall, bei denen die Controller-Affinitätskonfiguration und die ausgehende (Egress-)Richtlinienkonfiguration bestimmte Routen von einigen Quellen auf der Grundlage bestimmter Kriterien von anderen unterscheiden, wie dies bei der Richtlinie in den vorherigen Szenarien der Fall war. Zur Demonstration in diesem Abschnitt müssen Sie die Routenskalierung im Vergleich zu den vorherigen Szenarien erhöhen, damit mehr Standorte mit unterschiedlichen Standort-IDs verwendet werden. Betrachten Sie eine typische Bereitstellung mit drei vSmart Controllern und drei geografischen Regionen, wie in der Demonstration im vorherigen Abschnitt gezeigt. Mithilfe der Affinität wird jeder vSmart der entsprechenden Gruppe 1, 2 oder 3 zugewiesen. max-control-connections wird auf den Standardwert 2 gesetzt. vSmarts 1 und 2 werden für Router aus der Region A bevorzugt. In der Region B sind vSmart 2 und 3 bevorzugt. Für eine Region werden C vSmart 3 und C vSmart 1 bevorzugt.
Nachfolgend finden Sie ein Konfigurationsbeispiel für die Zuweisung eines vSmart Controllers zu Gruppe 1:
system
controller-group-id 1
!
Außerdem ein Beispiel für eine Konfiguration für den Router aus Region A, bei der Controller aus den Gruppen 1 und 2 bevorzugt werden. Controller aus Gruppe 3 werden als letzte Möglichkeit für die Verbindung verwendet, wenn keiner der Controller aus Gruppe 1 und 2 verfügbar ist, da standardmäßig der Wert 2 festgelegt max-control-connections ist:
system
controller-group-list 1 2 3
!
Das gleiche Ergebnis kann mit der anderen Konfiguration erzielt werden:
vpn 0
interface ge0/0
tunnel-interface
exclude-controller-group-list 3
!
!
!
max-control-connections wird in dieser Demonstration ebenfalls auf den Standardwert 2 gesetzt. send-path-limit Auf allen Routern und Controllern auf den Wert 16 gesetzt.
Jede Region verfügt über zwei Router, deren Präfix 10.0.0.0/8 lautet. Jeder dieser Router verfügt über fünf Transportnetze (WAN-Schnittstellen) mit TLOC-Farben von private1 bis private5. Die diesem Präfix zugrunde liegenden cEdges werden den Regionen zugewiesen, wie in dieser Tabelle dargestellt. Außerdem wird die neue System-IP-Adressierung beschrieben.
| Hostname/System-IP |
vSmart1 |
vSmart2 |
vSmart3 |
|
| 169.254.206.4 |
169.254.206.5 |
169.254.206.6 |
||
| cEdge 1 |
169.254.206.11 |
Region A |
Region A |
|
| cEdge 2 |
169.254.206.12 |
Region A |
Region A |
|
| cEdge 3 |
169.254.206.13 |
Region B |
Region B |
|
| cEdge4 |
169.254.206.14 |
Region B |
Region B |
|
| cEdge5 |
169.254.206.15 |
Region C |
Region C |
|
| cEdge 6 |
169.254.206.16 |
Region C |
Region C |
|
Aufgrund dieser Konfiguration und Skalierung erhält jeder vSmart-Controller 20 Pfade von direkt verbundenen Routern (4 Router x 5 TLOCs) und zusätzlich 20 Pfade von jedem vSmart. Insgesamt werden unter normalen Bedingungen 60 Pfade für das angegebene Präfix 10.0.0.0/8 in der OMP-Tabelle jedes vSmart-Controllers angegeben. Einige unwichtige Spalten wurden aus Gründen der Kürze aus der Ausgabe von show omp route 10.0.0.0/8 vSmart1 entfernt.
FROM PEER STATUS TLOC IP COLOR PREFERENCE
------------------------------------------------------------------
169.254.206.5 C,R 169.254.206.11 private1 -
169.254.206.5 C,R 169.254.206.11 private2 -
169.254.206.5 C,R 169.254.206.11 private3 -
169.254.206.5 C,R 169.254.206.11 private4 -
169.254.206.5 C,R 169.254.206.11 private5 -
169.254.206.5 C,R 169.254.206.12 private1 -
169.254.206.5 C,R 169.254.206.12 private2 -
169.254.206.5 C,R 169.254.206.12 private3 -
169.254.206.5 C,R 169.254.206.12 private4 -
169.254.206.5 C,R 169.254.206.12 private5 -
169.254.206.5 C,R 169.254.206.13 private1 -
169.254.206.5 C,R 169.254.206.13 private2 -
169.254.206.5 C,R 169.254.206.13 private3 -
169.254.206.5 C,R 169.254.206.13 private4 -
169.254.206.5 C,R 169.254.206.13 private5 -
169.254.206.5 C,R 169.254.206.14 private1 -
169.254.206.5 C,R 169.254.206.14 private2 -
169.254.206.5 C,R 169.254.206.14 private3 -
169.254.206.5 C,R 169.254.206.14 private4 -
169.254.206.5 C,R 169.254.206.14 private5 -
169.254.206.6 C,R 169.254.206.13 private1 -
169.254.206.6 C,R 169.254.206.13 private2 -
169.254.206.6 C,R 169.254.206.13 private3 -
169.254.206.6 C,R 169.254.206.13 private4 -
169.254.206.6 C,R 169.254.206.13 private5 -
169.254.206.6 C,R 169.254.206.14 private1 -
169.254.206.6 C,R 169.254.206.14 private2 -
169.254.206.6 C,R 169.254.206.14 private3 -
169.254.206.6 C,R 169.254.206.14 private4 -
169.254.206.6 C,R 169.254.206.14 private5 -
169.254.206.6 C,R 169.254.206.15 private1 -
169.254.206.6 C,R 169.254.206.15 private2 -
169.254.206.6 C,R 169.254.206.15 private3 -
169.254.206.6 C,R 169.254.206.15 private4 -
169.254.206.6 C,R 169.254.206.15 private5 -
169.254.206.6 C,R 169.254.206.16 private1 -
169.254.206.6 C,R 169.254.206.16 private2 -
169.254.206.6 C,R 169.254.206.16 private3 -
169.254.206.6 C,R 169.254.206.16 private4 -
169.254.206.6 C,R 169.254.206.16 private5 -
169.254.206.11 C,R 169.254.206.11 private1 -
169.254.206.11 C,R 169.254.206.11 private2 -
169.254.206.11 C,R 169.254.206.11 private3 -
169.254.206.11 C,R 169.254.206.11 private4 -
169.254.206.11 C,R 169.254.206.11 private5 -
169.254.206.12 C,R 169.254.206.12 private1 -
169.254.206.12 C,R 169.254.206.12 private2 -
169.254.206.12 C,R 169.254.206.12 private3 -
169.254.206.12 C,R 169.254.206.12 private4 -
169.254.206.12 C,R 169.254.206.12 private5 -
169.254.206.15 C,R 169.254.206.15 private1 -
169.254.206.15 C,R 169.254.206.15 private2 -
169.254.206.15 C,R 169.254.206.15 private3 -
169.254.206.15 C,R 169.254.206.15 private4 -
169.254.206.15 C,R 169.254.206.15 private5 -
169.254.206.16 C,R 169.254.206.16 private1 -
169.254.206.16 C,R 169.254.206.16 private2 -
169.254.206.16 C,R 169.254.206.16 private3 -
169.254.206.16 C,R 169.254.206.16 private4 -
169.254.206.16 C,R 169.254.206.16 private5 -
Lassen Sie uns nun ein Fehlerszenario diskutieren. Einige Spoke-Router mit der Standort-ID 20, die zu Region A gehören, können aus irgendeinem Grund keine Verbindung zu beiden Controllern herstellen und sind nur mit einem Controller vSmart3 verbunden, der als letztes Mittel vSmart für diese Region ist.
Site-20# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
------------------------------------------------------------------------------------------
169.254.206.6 vsmart 1 1 1 up 0:00:26:31 10/4/0
Wenn keine Kontrollrichtlinie konfiguriert ist, kann dies zu suboptimalem Routing für Standort 20 aus Region A führen, da vSmart3 gemäß dem Algorithmus zur Auswahl des besten Pfads zuerst Routen ankündigt, die von Edge-Routern empfangen wurden. Sie sind bevorzugter als native Routen zu Region A, die über die vSmart-Controller vSmart1 und vSmart2 empfangen werden:
vsmart3# show omp routes 10.0.0.0/8 advertised detail | nomore | b ADVERTISED | i originator\|peer\|\ tloc | b “peer 192.168.206.20”
peer 192.168.206.20
originator 169.254.206.14
tloc 169.254.206.14, private2, ipsec
originator 169.254.206.14
tloc 169.254.206.14, private1, ipsec
originator 169.254.206.14
tloc 169.254.206.14, private3, ipsec
originator 169.254.206.14
tloc 169.254.206.14, private4, ipsec
originator 169.254.206.14
tloc 169.254.206.14, private5, ipsec
originator 169.254.206.15
tloc 169.254.206.15, private5, ipsec
originator 169.254.206.15
tloc 169.254.206.15, private2, ipsec
originator 169.254.206.15
tloc 169.254.206.15, private1, ipsec
originator 169.254.206.15
tloc 169.254.206.15, private3, ipsec
originator 169.254.206.15
tloc 169.254.206.15, private4, ipsec
originator 169.254.206.13
tloc 169.254.206.13, private5, ipsec
originator 169.254.206.13
tloc 169.254.206.13, private4, ipsec
originator 169.254.206.13
tloc 169.254.206.13, private3, ipsec
originator 169.254.206.13
tloc 169.254.206.13, private1, ipsec
originator 169.254.206.13
tloc 169.254.206.13, private2, ipsec
originator 169.254.206.16
tloc 169.254.206.16, private1, ipsec
Um ein suboptimales Routing zu vermeiden, muss vSmart zulassen, dass Stationen nur Routen von den Routern in derselben Region empfangen können. Das folgende Beispiel zeigt eine Kontrollrichtlinie, mit der dieses Ergebnis erzielt werden kann:
policy
lists
site-list hubs_A
site-id 11
site-id 12
!
site-list hubs_B
site-id 13
site-id 14
!
site-list hubs_C
site-id 15
site-id 16
!
site-list spokes_A
site-id 20
!
site-list spokes_B
site-id 21
!
site-list spokes_C
site-id 10
!
!
control-policy region_A
sequence 10
match route
site-list hubs_A
!
action accept
!
!
sequence 20
match route
!
action reject
!
!
default-action accept
!
control-policy region_B
sequence 10
match route
site-list hubs_B
!
action accept
!
!
sequence 20
match route
!
action reject
!
!
default-action accept
!
control-policy region_C
sequence 10
match route
site-list hubs_C
!
action accept
!
!
sequence 20
match route
!
action reject
!
!
default-action accept
!
!
apply-policy
site-list spokes_A
control-policy region_A out
!
site-list spokes_B
control-policy region_B out
!
site-list spokes_C
control-policy region_C out
!
!
Aus dem vorherigen Szenario wissen Sie jedoch, dass Routen am Edge den Routen vorgezogen werden, die über vSmart-Controller empfangen werden. Bedeutet es, dass Site-20 unter den derzeitigen Bedingungen keine Routen erhalten wird?
Hier ist noch ein weiteres wichtiges Konzept, das häufig übersehen wird. Routen von cEdge1 und cEdge2 (system-ip 169.254.206.11 und 169.254.206.12) werden jedoch in der vSmart3 OMP-Tabelle beibehalten, auch wenn sie weniger bevorzugt sind und dennoch als C ("ausgewählt") gekennzeichnet sind. Alle Schritte im Best-Path-Auswahlalgorithmus ab Schritt 8 (einschließlich) betrachteter Tie-Breaker und Routen werden nicht aus der OMP-Tabelle entfernt, sondern nach der beschriebenen Präferenz für den Zweck der konsequenten Verarbeitung durch Egress-Control-Policies und -send-path-limitLimitation sortiert.
Da vSmart3 keinen OMP-Routing-Tabelleneintrag für das Refix 10.0.0.0/8 von einem anderen vSmart finden kann, mit dem der Edge-Router bereits verbunden ist (Site-20 nur mit vSmart3 verbunden), werden Routen von Standort 11 und Standort 12 (cEdge1 und cEdge2 entsprechend) an den Standort-20-Router angekündigt:
vsmart3# show omp routes 10.0.0.0/8 advertised detail | nomore | b ADVERTISED | i originator\|peer\|\ tloc | b “peer 192.168.206.20”
peer 192.168.206.20
originator 169.254.206.11
tloc 169.254.206.11, private1, ipsec
originator 169.254.206.11
tloc 169.254.206.11, private2, ipsec
originator 169.254.206.11
tloc 169.254.206.11, private3, ipsec
originator 169.254.206.11
tloc 169.254.206.11, private4, ipsec
originator 169.254.206.11
tloc 169.254.206.11, private5, ipsec
originator 169.254.206.12
tloc 169.254.206.12, private1, ipsec
originator 169.254.206.12
tloc 169.254.206.12, private2, ipsec
originator 169.254.206.12
tloc 169.254.206.12, private3, ipsec
originator 169.254.206.12
tloc 169.254.206.12, private4, ipsec
originator 169.254.206.12
tloc 169.254.206.12, private5, ipsec
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
26-Oct-2021 |
Erstveröffentlichung |
1.0 |
27-Oct-2021 |
Erstveröffentlichung |
Beigetragen von
- Eugene KhabarovCisco Engineering
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)