Fehlerbehebung: OMP Best-Path-Auswahl, Besonderheiten und typische Verwirrungen
Inhalt
Einleitung
In diesem Dokument wird beschrieben, wie Sie Fehler bei der Auswahl des OMP-besten Pfads und bei der Operation zwischen OMP, Ausgangs-Policy und Sendepfad-Limit-Funktion beheben.
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 beliebigen Router-System-IP entspricht in diesem Beispiel der Standort-ID (10.10.10.<Standort-ID>). vSmarts haben die System-IP 10.10.10.228, .229 und .230. In diesem Beispiel stehen für jeden Router zwei Transportnetze (WAN-Schnittstellen) zur Verfügung. 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, Ausgangsrichtlinie und Reihenfolge der Vorgänge für die Beschränkung des Sendepfads
Zunächst müssen Sie die Auswahl des besten Pfads, die Ausgangs-Policy und die Reihenfolge der Sendepfadlimits demonstrieren. 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 verfügt über Verbindungen 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 empfängt sein Präfix von diesen 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 Tabelle für das Overlay Management Protocol (OMP) 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
!
Sie können überprüfen, welches Präfix an welchen Peer gesendet wird. Die Route vom Standort 243 wird als Erstes betrachtet, da sie die niedrigste Originator-/Peer-Router-ID in der geordneten Liste hat. Da send-path-limit auf 1 gesetzt ist, wird nur eines der ansonsten gebundenen TLOCs für diese Route angekündigt. In diesem Beispiel wird "biz-internet" ausgewählt, da es in der aktuellen Implementierung die endgültige TLOC-ID-Bestellung erhält. Dies ist keine generische Regel für die höchste private TLOC-IP-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 12346Standort 243 erhält die nächste Route in der geordneten Liste von Standort 244, und diese Route wird ebenfalls über biz-internet angekündigt, da dieselbe endgültige TLOC-ID-Bestellung diese TLOC in diesem Fall auswählt. Standort 243 erhält aufgrund des Split Horizon keine eigene Route. Standort 247 bezieht die Route von Standort 244 aufgrund der Ausgangs-Policy.
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: Von Edge-Routern bezogene Routen 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 jetzt jedoch nur Routen von Standort 244 und nicht von Standort 245 an. 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 durch Debug-Protokolle bestätigt, die in /var/log/tmplog/vdebug gespeichert sind, wobei 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 Auswahl des besten Pfads und der Reihenfolge der Vorgänge in dieser Tabelle. Multi-Regional Fabric-Szenarien werden nicht behandelt.
| 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: bevorzugen Edge-Router-Routing gegenüber vSmart-Routing |
| 7. Bevorzugen OMP-Route mit niedrigster Ursprungsmetrik |
| 8. Bevorzugen Route empfangen von niedrigster System-IP |
| 9. Route von unterer TLOC-ID bevorzugen (TLOC-Adresse, dann Farbe, dann Kapselung) |
| 10. Richtlinie zur Kontrolle des ausgehenden Datenverkehrs |
| 11. Beschränkung des Sendepfads |
Auswahl des besten vSmart-Pfads: Von Edge-Routern bezogene Routen 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 der Region A, die Controller aus den Gruppen 1 und 2 bevorzugt. Controller aus Gruppe 3 werden als letztes Mittel für die Verbindung verwendet, wenn keiner der Controller aus den Gruppen 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 hat jetzt zwei Router mit dem Präfix 10.0.0.0/8. Jeder dieser Router hat fünf Transportnetze (WAN-Schnittstellen) mit den TLOC-Farben von privat1 bis privat5. Kanten, die dieses Präfix erzeugen, 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 -
Das Fehlerszenario sieht jetzt so aus: 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 empfangen kann?
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
- OMP-Dokumentation
- Fehlerbehebung: Instabilität der OMP-Route im Failover-Szenario
- Technischer Support und Dokumentation für Cisco Systeme
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
4.0 |
28-Apr-2026
|
Überarbeitete Texte, Grammatik, Formatierung, Links. |
3.0 |
23-Aug-2024
|
Verkürzte Einführung und korrigierter "Wille" |
2.0 |
26-Oct-2021
|
Erstveröffentlichung |
1.0 |
27-Oct-2021
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)