Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Konfiguration

Überprüfung

Fehlerbehebung

Lösung 1

Overlay-AS Fall 1

Overlay-AS, Fall 2

Lösung 2

SoO - Erklärung zur Vermeidung von Schleifen

Zugehörige Informationen

Einleitung

In diesem Dokument wird beschrieben, wie eine Routing-Schleife in der SD-WAN-Fabric vermieden werden kann, wenn Border Gateway Protocol (BGP)-Routing und SoO (Site of Origin) verwendet werden.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

- Grundlegendes Verständnis des Overlay Management Protocol (OMP)

- Grundlegendes Verständnis des BGP

- SD-WAN-Komponenten und deren Interaktion

Verwendete Komponenten

Für die Demonstration wurden folgende Software-Router verwendet:

- 3 Cisco IOS® XE CSR1000v Router mit Softwareversion 17.2.1v, die im Controller-Modus (SD-WAN) ausgeführt werden

- 2 Cisco IOS XE CSR1000v Router mit Softwareversion 16.7.3

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 verstehen.

Hintergrundinformationen

Für dieses Dokument wird diese Topologie verwendet:

Topologie

R1 und R2 sind generische Cisco IOS XE-Router (oder andere Router, die BGPv4 ausführen können). cE1, cE2 und cE3 führen Cisco IOS XE im Controller (SD-WAN)-Modus aus. Hier finden Sie eine Zusammenfassung der zugewiesenen Standort-ID- und System-IP-Parameter für jeden SD-WAN-Router:

SD-WAN-Router

Standort-ID

System-IP

cE1

214

192.168.30.214

cE2

215

192.168.30.215

cE3

216

192.168.30.216

Hier eine Reihe von Ereignissen, die ursprünglich stattgefunden haben:

1. R1 und R2 stellen eBGP-Peering entsprechend mit cE1, cE2 und cE3 her. cE1 und cE2 stellen iBGP-Peering her.

2. R2 generiert die BGP-Route 10.1.1.0/24 und kündigt sie per eBGP an cE3 an.

3. cE3 empfängt diese BGP-Route serviceseitig in der VRF-1-Adressfamilie und verteilt sie dann auf OMP.

4. cE3 kündigt dem SD-WAN-Overlay die OMP-Route 10.1.1.0/24 an (vSmart-Controller sind für das Routing der Informationsverbreitung über das OMP-Protokoll zu allen anderen Edge-Routern verantwortlich, die dem SD-WAN-Overlay angehören).

5. cE1 und cE2 empfangen die OMP-Route und verteilen sie über eBGP in VRF 1 an R1 zurück.

Konfiguration

Nachfolgend finden Sie die relevante Konfiguration von cE1. Beachten Sie, send-comminity ist nicht für den Nachbarn 192.168.160.215 konfiguriert:

router bgp 65401

bgp log-neighbor-changes

distance bgp 20 200 20

!

address-family ipv4 vrf 1

redistribute omp

propagate-aspath

neighbor 192.168.140.10 remote-as 65300

neighbor 192.168.140.10 activate

neighbor 192.168.140.10 send-community both

neighbor 192.168.160.215 remote-as 65400

neighbor 192.168.160.215 activate

exit-address-family

!

sdwan

omp

no shutdown

send-path-limit  4

ecmp-limit       4

graceful-restart

no as-dot-notation

timers

holdtime               60

advertisement-interval 1

graceful-restart-timer 43200

eor-timer              300

exit

address-family ipv4 vrf 1

advertise bgp

!

address-family ipv4

advertise connected

advertise static

!

address-family ipv6

advertise connected

advertise static

cE2:

router bgp 65401

bgp log-neighbor-changes

distance bgp 20 200 20

!

address-family ipv4 vrf 1

redistribute omp

propagate-aspath

neighbor 192.168.150.10 remote-as 65300

neighbor 192.168.150.10 activate

neighbor 192.168.150.10 send-community both

neighbor 192.168.160.214 remote-as 65401

neighbor 192.168.160.214 activate

neighbor 192.168.160.214 send-community both

exit-address-family

!

sdwan

omp

no shutdown

send-path-limit  4

ecmp-limit       4

graceful-restart

no as-dot-notation

timers

holdtime               60

advertisement-interval 1

graceful-restart-timer 43200

eor-timer              300

exit

address-family ipv4 vrf 1

advertise bgp

!

address-family ipv4

advertise connected

advertise static

!

address-family ipv6

advertise connected

advertise static

cE3:

router bgp 65401

bgp log-neighbor-changes

timers bgp 5 15

!

address-family ipv4 vrf 1

redistribute omp

propagate-aspath

neighbor 192.168.60.11 remote-as 65500

neighbor 192.168.60.11 activate

exit-address-family

!

sdwan

omp

no shutdown

send-path-limit  4

ecmp-limit       4

graceful-restart

no as-dot-notation

timers

holdtime               60

advertisement-interval 1

graceful-restart-timer 43200

eor-timer              300

exit

address-family ipv4 vrf 1

advertise bgp

!

address-family ipv4

advertise connected

advertise static

!

address-family ipv6

advertise connected

advertise static

!

Überprüfung

1. Im Ausgangszustand wird die Route von cE3 angekündigt und von cE1 und cE2 über OMP gelernt. Beide verteilen die Route an das BGP und geben die Route untereinander und an R1 bekannt:

cE1#

show bgp vpnv4 unicast vrf 1.10.1.1.1/24

BGP routing table entry for 1:1:10.1.1.1/24, version 342041

Paths: (2 available, best #2, table 1)

Advertised to update-groups:

4          5

Refresh Epoch 1

65500

192.168.160.215 (via vrf 1) from 192.168.160.215 (192.168.109.215)

Origin incomplete, metric 1000, localpref 50, valid, internal

Extended Community: SoO:0:215 RT:1:1

rx pathid: 0, tx pathid: 0

Updated on Aug 21 2020 11:23:32 GMT

Refresh Epoch 1

65500

192.168.30.216 (via default) from 0.0.0.0 (192.168.109.214)

Origin incomplete, metric 1000, localpref 50, valid, sourced, best

Extended Community: SoO:0:214 RT:1:1

rx pathid: 0, tx pathid: 0x0

Updated on Aug 21 2020 11:23:32 GMT

cE2#

show bgp vpnv4 unicast vrf 1.10.1.1.1/24

BGP routing table entry for 1:1:10.1.1.1/24, version 327810

Paths: (2 available, best #2, table 1)

Advertised to update-groups:

5          6

Refresh Epoch 1

65500

192.168.160.214 (via vrf 1) from 192.168.160.214 (192.168.109.214)

Origin incomplete, metric 1000, localpref 50, valid, internal

Extended Community: RT:1:1

rx pathid: 0, tx pathid: 0

Updated on Aug 21 2020 11:23:32 GMT

Refresh Epoch 1

65500

192.168.30.216 (via default) from 0.0.0.0 (192.168.109.215)

Origin incomplete, metric 1000, localpref 50, valid, sourced, best

Extended Community: SoO:0:215 RT:1:1

rx pathid: 0, tx pathid: 0x0

Updated on Aug 21 2020 11:23:32 GMT

2. Die WAN-Schnittstelle ist nicht verbunden, oder die Verbindung zur SD-WAN-Fabric ist auf cE2 unterbrochen, wodurch die OMP-Peers (vSmart-Verbindungen) ausfallen. Vom iBGP wurde nur eine Route übernommen:

ce2(config)#

interface GigabitEthernet 2

ce2(config-if)#

herunterfahren

ce2(config-if)#

Ende

Uncommitted changes found, commit them? [yes/no/CANCEL] yes

Commit complete.

ce2#

show bgp vpnv4 unicast vrf 1.10.1.1.1/24

BGP routing table entry for 1:1:10.1.1.1/24, version 345276

Paths: (1 available, best #1, table 1)

Advertised to update-groups:

6

Refresh Epoch 1

65500

192.168.160.214 (via vrf 1) from 192.168.160.214 (192.168.109.214)

Origin incomplete, metric 1000, localpref 50, valid, internal, best

Extended Community: RT:1:1

rx pathid: 0, tx pathid: 0x0

Updated on Aug 21 2020 11:23:32 GMT

cE1 bevorzugt weiterhin die Route über OMP (dies ist die einzige verbleibende Route), die von cE3 ausgeht:

ce1#

show bgp vpnv4 unicast vrf 1.10.1.1.1/24

BGP routing table entry for 1:1:10.1.1.1/24, version 342041

Paths: (1 available, best #1, table 1)

Advertised to update-groups:

4          5

Refresh Epoch 1

65500

192.168.30.216 (via default) from 0.0.0.0 (192.168.109.214)

Origin incomplete, metric 1000, localpref 50, valid, sourced, best

Extended Community: SoO:0:214 RT:1:1

rx pathid: 0, tx pathid: 0x0

Updated on Aug 21 2020 11:23:32 GMT

3. Die Verbindung an der WAN-Schnittstelle von cE2 wird wieder hergestellt. Aufgrund der besseren administrativen Distanz (AD) wird die Route von cE1 über iBGP weiterhin bevorzugt.

ce2(config)#

interface GigabitEthernet 2

ce2(config-if)#

Kein Herunterfahren

ce2(config-if)#

Ende

Uncommitted changes found, commit them? [yes/no/CANCEL] yes

Commit complete.

ce2#

show bgp vpnv4 unicast vrf 1.10.1.1.1/24

BGP routing table entry for 1:1:10.1.1.1/24, version 345276

Paths: (1 available, best #1, table 1)

Advertised to update-groups:

6

Refresh Epoch 1

65500

192.168.160.214 (via vrf 1) from 192.168.160.214 (192.168.109.214)

Origin incomplete, metric 1000, localpref 50, valid, internal, best

Extended Community: RT:1:1

rx pathid: 0, tx pathid: 0x0

Updated on Aug 21 2020 11:23:32 GMT

cE1 bevorzugt weiterhin die Route über OMP, die von cE3 generiert wird. Beachten Sie, dass cE1 OMP in BGP umverteilt:

ce1#

show bgp vpnv4 unicast vrf 1.10.1.1.1/24

BGP routing table entry for 1:1:10.1.1.1/24, version 569358

Paths: (1 available, best #1, table 1)

Advertised to update-groups:

4          5

Refresh Epoch 1

65500

192.168.30.216 (via default) from 0.0.0.0 (192.168.109.214)

Origin incomplete, metric 1000, localpref 50, valid, sourced, best

Extended Community: SoO:0:214 RT:1:1

rx pathid: 0, tx pathid: 0x0

Updated on Aug 21 2020 15:13:09 GMT

4. Etwas passiert mit der cE3-Verbindung zu R2. Zum Testen wird die Schnittstelle heruntergefahren, und der R2-BGP-Peer geht verloren:

ce3(config)#

interface GigabitEthernet 6

ce3(config-if)#

herunterfahren

ce3(config-if)#

verpflichten

5. Daraus ergibt sich die Routing-Schleife zwischen cE1 und cE2 (cE2 verteilt die Route von OMP und kündigt cE1 via BGP an, cE1 verteilt BGP an OMP und kündigt cE2 an):

ce1#

show bgp vpnv4 unicast vrf 1.10.1.1.1/24

BGP routing table entry for 1:1:10.1.1.1/24, version 732548

Paths: (1 available, best #1, table 1)

Advertised to update-groups:

5

Refresh Epoch 1

65500

192.168.160.215 (via vrf 1) from 192.168.160.215 (192.168.109.215)

Origin incomplete, metric 1000, localpref 50, valid, internal, best

Extended Community: SoO:0:215 RT:1:1

rx pathid: 0, tx pathid: 0x0

Updated on Aug 21 2020 15:38:47 GMT

ce2#

show bgp vpnv4 unicast vrf 1.10.1.1.1/24

BGP routing table entry for 1:1:10.1.1.1/24, version 639650

Paths: (1 available, best #1, table 1)

Advertised to update-groups:

5          6

Refresh Epoch 1

65500

192.168.30.214 (via default) from 0.0.0.0 (192.168.109.215)

Origin incomplete, metric 1000, localpref 50, valid, sourced, best

Extended Community: SoO:0:215 RT:1:1

rx pathid: 1, tx pathid: 0x0

Updated on Aug 21 2020 15:38:47 GMT

Fehlerbehebung

Es gibt zwei mögliche Lösungen.

Lösung 1

Konfigurieren Sie Overlay-as für OMP. Anschließend wird dem OMP-Overlay selbst eine AS-Nummer (Autonomous System) zugewiesen. Beispiele:

config-transaction

sdwan

omp

overlay-as 64512

exit

OMP ist standardmäßig transparent für BGP, auch wenn propagate-aspath ist konfiguriert. overlay-as ist eine Funktion, die AS, das als Parameter dieses Befehls angegeben wurde, dem BGP AS_PATH-Attribut von Routen vorstellt, die von OMP nach BGP exportiert wurden. Wenn Sie dieselbe Overlay-AS-Nummer auf mehreren Geräten im Overlay-Netzwerk konfigurieren, werden alle diese Geräte als Teil desselben AS betrachtet. Daher leiten sie keine Routen weiter, die die Overlay-AS-Nummer enthalten, und verhindern so die Routing-Schleife.

Beachten Sie, dass overlay-as und propagate-aspath voneinander abhängig sind. Diese Funktion wird ausführlich behandelt.

Es gibt zwei Fälle:

Overlay-AS Fall 1

overlay-as konfiguriert auf globaler Ebene unter sdwan omp Abschnitt und propagate-aspath ist nicht konfiguriert (Restkonfiguration ist identisch mit der anfänglichen: advertise bgp ist aktiviert unter omp address-family ipv4 vrf 1 Abschnitt, redistribute omp konfiguriert unter router bgp

address-family ipv4 vrf 1

Abschnitt).

overlay-as 64512, konfiguriert auf cE1/cE2 und cE3.

Topologie für Overlay-als Demo

Zu Demonstrationszwecken haben sich die BGP-AS für cE1, cE2 und cE3 geändert.

R1 - cE1/cE2 wird weiterhin als Peer über eBGP, AS 65300 bzw. 65401 verwendet.

cE3 - R2-Peer über eBGP, AS 65402 bzw. 65500.

R1 sendet die Route (z. B. 192.168.41.11/32) an cE1/cE2. cE1/cE2 verteilt diese Route ohne ein AS_PATH-Attribut in OMP um.

cE3 empfängt die Nachricht und kündigt sie dem R2 gegenüber im BGP an, allerdings nur mit eigenem AS (normales eBGP-Verhalten).

Route1 auf R2 hat AS_PATH: "65402".

R2#

sh ip bgp | i 192.168.41.11/32

*>   192.168.41.11/32 192.168.60.216        1000             0 65402 ?

Overlay-AS, Fall 2

propagate-aspath konfiguriert unter router bgp Abschnitt für das jeweilige serviceseitige VPN (address-family ipv4 vrf 1). Hier sind auch Unterfälle.

Fall 2.1: Mit overlay-as aktiviert auf cE3, propagate-aspath ist auch aktiviert unter router bgp 65401 address-family ipv4 vrf 1 auf cE1/cE2.

R1 sendet Route1 an cE1/cE2. cE1/cE2 verteilt diese Route in OMP mit einem As-Pfad, der vom R1-Standort kommt.

Die OMP-Route in vSmart hat den AS-Pfad "65300".

vsmart1#

show omp routen vpn 1 192.168.41.11/32 | nomore | Ausschließen nicht\ gesetzt

---------------------------------------------------

omp route entries for vpn 1 route 192.168.41.11/32

---------------------------------------------------

RECEIVED FROM:

peer            192.168.30.214

path-id         81

label           1001

status          C,R

Attributes:

originator       192.168.30.214

type             installed

tloc             192.168.30.214, biz-internet, ipsec

overlay-id        1

site-id          25

origin-proto     eBGP

origin-metric    0

as-path          "65300"

RECEIVED FROM:

peer            192.168.30.215

path-id         68

label           1002

status          C,R

Attributes:

originator       192.168.30.215

type             installed

tloc             192.168.30.215, biz-internet, ipsec

overlay-id        1

site-id          25

origin-proto     eBGP

origin-metric    0

as-path          "65300"

Fall 2.1.a. Mit propagate-aspath cE3 auf cE3 deaktiviert, empfängt cE3 es als OMP-Route und kündigt es dem BGP an, ignoriert alle As-Path-Attribute, überlagert sich mit R2 und fügt nur sein eigenes BGP AS hinzu (normales eBGP-Verhalten).

Route1 auf R2 AS-Pfad: "65402".

R2#

sh ip bgp | i 192.168.41.11/32

*>   192.168.41.11/32 192.168.60.216        1000             0 65402 ?

Fall 2.1.b. Mit propagate-aspath aktiviert auf cE3, empfängt cE3 es als OMP-Route und kündigt es dem BGP an, gibt das empfangene As-Path-Attribut vor, R2 fügt dann das Overlay-AS hinzu, gefolgt von seinem eigenen BGP-AS.

Route1 auf R2 AS-Pfad: "65402 64512 65300".

R2#

sh ip bgp | i 192.168.41.11/32

*>   192.168.41.11/32 192.168.60.216        1000             0 65402 64512 65300 ?

Fall 2.1.c Mit propagate-aspath cE3, das auf cE1/cE2 deaktiviert ist, empfängt es als OMP-Route ohne "as-path"-Attribut und kündigt es dem BGP gegenüber R2 an, stellt dem Overlay-AS vor und fügt nur sein eigenes BGP-AS hinzu.

Route1 auf R2 AS-Pfad: "65402 64512".

R2#

sh ip bgp | i 192.168.41.11/32

*>   192.168.41.11/32 192.168.60.216        1000             0 65402 64512 ?

Fall 2.2: Ohne overlay-as konfiguriert auf cE3, propagate-aspath ist unter Router bgp 65401 address-family ipv4 vrf 1 auf cE1/cE2 aktiviert.

Fall 2.2.a. Mit propagate-aspath Nur auf cE3 deaktiviert, empfängt cE3 es als OMP-Route und kündigt es dem BGP an. Dabei ignoriert cE3 jedes AS_PATH-Attribut gegenüber R2 und fügt sein eigenes BGP AS (normales eBGP-Verhalten) hinzu.

Route1 auf R2 AS-Pfad: "65402".

R2#

sh ip bgp | i 192.168.41.11/32

*>   192.168.41.11/32 192.168.60.216        1000             0 65402 ?

Fall 2.2.b. Wann propagate-aspath ist auf cE3 aktiviert, cE3 empfängt es als OMP-Route und kündigt es dem BGP an, stellt dem empfangenen AS_PATH-Attribut ein, R2 fügt dann sein eigenes AS hinzu.

Route1 auf R2 AS-Pfad: "65402", "65300".

R2#

sh ip bgp | i 192.168.41.11/32

*>   192.168.41.11/32 192.168.60.216        1000             0 65402 65300 ?

Wichtiger Punkt:

Wenn Sie das AS-Path-Attribut in OMP senden, fügt der Edge-Router kein eigenes AS hinzu (wie im Artikel vEdge kündigt sein eigenes AS nicht an, wenn BGP-Routen in OMP angekündigt werden). Wenn der Remote-Edge-Router eine OMP-Route mit eigenem AS im AS_PATH-Attribut empfängt, führt er keine Schleifenerkennung durch und sendet die Route mit dem empfangenen AS-Pfad an den Router auf der Serviceseite.

Lösung 2

Konfigurieren Sie dieselbe Standort-ID auf den Routern cE1 und cE2. Obwohl vSmart Routen mit derselben Standort-ID wie in der Route selbst an den Standort zurückmeldet, wird aufgrund des unterschiedlichen Originator-Attributs der Route keine Schleifenvermeidung ausgelöst, aber die Routingschleife auf der Kontrollebene wird nicht gebildet, da die OMP-Route nicht in der RIB installiert ist. Dies liegt daran, dass die OMP-Route im Status Inv,U (Ungültig,Unaufgelöst) verbleibt. Standardmäßig können zwischen Standorten mit derselben Standort-ID keine Datenebenentunnel eingerichtet werden, es sei denn, allow-same-site-tunnels ist konfiguriert. Wenn sich die BFD-Sitzung des Datenebenentunnels im inaktiven Zustand befindet, bleibt die TLOC-Lösung weiterhin bestehen. Im Beispiel hier site-id 214215 wurde auf beiden Routern ce1 und ce2 konfiguriert. Die von cE2 und cE1 angekündigte Route 10.0.0.2/32 installiert sie nicht in der Routing-Tabelle, da zwischen cE1 und cE2 keine Datenebenensitzungen bestehen:

ce1#

show sdwan omp route 10.0.0.2/32 det | exkl. nicht festgelegt

---------------------------------------------------

omp route entries for vpn 3 route 10.0.0.2/32

---------------------------------------------------

RECEIVED FROM:

peer            192.168.30.113

path-id         3

label           1004

status          Inv,U

Attributes:

originator       192.168.30.215

type             installed

tloc             192.168.30.215, mpls, ipsec

overlay-id        1

site-id          214215

origin-proto     connected

origin-metric    0

RECEIVED FROM:

peer            192.168.30.113

path-id         4

label           1004

status          Inv,U

loss-reason     tloc-id

lost-to-peer    192.168.30.113

lost-to-path-id 3

Attributes:

originator       192.168.30.215

type             installed

tloc             192.168.30.215, biz-internet, ipsec

overlay-id        1

site-id          214215

origin-proto     connected

origin-metric    0

ce1#

show sdwan omp tlocs "ip 192.168.30.215" | Ausschließen nicht festgelegt

---------------------------------------------------

tloc entries for 192.168.30.215

mpls

ipsec

---------------------------------------------------

RECEIVED FROM:

peer            192.168.30.113

status          C,I,R

Attributes:

attribute-type    installed

encap-proto       0

encap-spi         256

encap-auth        sha1-hmac,ah-sha1-hmac

encap-encrypt     aes256

public-ip         192.168.110.215

public-port       12347

private-ip        192.168.110.215

private-port      12347

public-ip         ::

public-port       0

private-ip        ::

private-port      0

bfd-status        down

site-id           214215

preference        0

weight            1

version           3

gen-id             0x80000026

carrier           default

restrict          0

groups            [ 0 ]

bandwidth         0

qos-group         default-group

---------------------------------------------------

tloc entries for 192.168.30.215

biz-internet

ipsec

---------------------------------------------------

RECEIVED FROM:

peer            192.168.30.113

status          C,I,R

Attributes:

attribute-type    installed

encap-proto       0

encap-spi         256

encap-auth        sha1-hmac,ah-sha1-hmac

encap-encrypt     aes256

public-ip         192.168.109.215

public-port       12347

private-ip        192.168.109.215

private-port      12347

public-ip         ::

public-port       0

private-ip        ::

private-port      0

bfd-status        down

site-id           214215

preference        0

weight            1

version           3

gen-id             0x80000026

carrier           default

restrict          0

groups            [ 0 ]

bandwidth         0

qos-group         default-group

ce1#

Sie können diesen Befehl auf dem vSmart-Controller überprüfen, um zu ermitteln, welche Routen das jeweilige Präfix erhalten (siehe Abschnitt "ANGEKÜNDIGT AN"):

vsmart1#

omp routen 10.1.1.0/24 detail anzeigen | nomore | Ausschließen nicht\ gesetzt

---------------------------------------------------

omp route entries for vpn 1 route 10.1.1.0/24

---------------------------------------------------

RECEIVED FROM:

peer            192.168.30.216

path-id         68

label           1002

status          C,R

Attributes:

originator       192.168.30.216

type             installed

tloc             192.168.30.216, biz-internet, ipsec

overlay-id        1

site-id          216

origin-proto     eBGP

origin-metric    0

as-path          65500

ADVERTISED TO:

peer    192.168.30.214

Attributes:

originator       192.168.30.216

label            1002

path-id          5525

tloc             192.168.30.216, biz-internet, ipsec

site-id          216

overlay-id        1

origin-proto     eBGP

origin-metric    0

as-path          65500

ADVERTISED TO:

peer    192.168.30.215

Attributes:

originator       192.168.30.216

label            1002

path-id          5287

tloc             192.168.30.216, biz-internet, ipsec

site-id          216

overlay-id        1

origin-proto     eBGP

origin-metric    0

as-path          65500

site-id wird auch als erweitertes BGP Site-of-Origin (SoO)-Community-Attribut beibehalten (Sie können SoO:0:<Standort-ID> in den vorherigen Ausgaben bemerken). Diese wird verwendet, um Routen zu identifizieren, die von einem Standort stammen, sodass die erneute Ankündigung dieses Präfix zurück verhindert werden kann. Damit dies ordnungsgemäß funktioniert, müssen Router erweiterte Communitys senden. Konfigurieren Sie cE1 so, dass erweiterte Communities an den Router cE2 gesendet werden:

router bgp 65401

address-family ipv4 vrf 1

neighbor 192.168.160.215 send-community both

SoO - Erklärung zur Vermeidung von Schleifen

Für den Fall, dass zwei Router am selben Standort iBGP-Nachbarn sind, verfügt SD-WAN über einen integrierten Loop-Prevention-Mechanismus, um eine Routing-Loop von OMP zu BGP und zurück von BGP zu OMP zu verhindern. Um dies zu demonstrieren, wurde die Topologie leicht aktualisiert und auf beiden Routern, auf denen BGP AS65400 ausgeführt wird (cE1/cE2), dieselbe Standort-ID 214215 konfiguriert. In diesem Beispiel wird ein 10.1.1.0/24-Präfix in OMP vom Remote-Standort (cE3) angekündigt und in OMP am Standort 214215 (cE1-cE2) gelernt.

Topologie für SoO-Demonstration

Um eine Schleifenvermeidung zu erreichen, wird der SoO der erweiterten BGP-Community verwendet, um anzuzeigen, von welchem Standort das Präfix stammt. Diese Community wird einem Präfix hinzugefügt, wenn sie von OMP in BGP neu verteilt wird.

Die Fehlermeldung send-community

-Befehl auf beiden Geräten für die Neighbor-Anweisung konfiguriert werden, damit diese Funktion ordnungsgemäß funktioniert.

cEdge1#

show run | Sek. Router-BGP

router bgp 65400

bgp log-neighbor-changes

!

address-family ipv4 vrf 1

redistribute omp

neighbor 192.168.160.215 remote-as 65400

neighbor 192.168.160.215 activate

neighbor 192.168.160.215 send-community both

exit-address-family

cEdge2#

show run | Sek. Router-BGP

router bgp 65400

bgp log-neighbor-changes

!

address-family ipv4 vrf 1

neighbor 192.168.160.214 remote-as 65400

neighbor 192.168.160.214 activate

neighbor 192.168.160.214 send-community both

exit-address-family

Die erweiterte Community wird angezeigt durch die Ausgabe von show bgp vpnv4 unicast vrf 1

entweder von der Werbe- oder der empfangenden Website.

Beispiel:

cEdge1#

show bgp vpnv4 unicast vrf 1 10.1.1.1

BGP routing table entry for 1:10:10.1.1.1/24, version 4

Paths: (1 available, best #1, table 1)

Advertised to update-groups:

1

Refresh Epoch 1

Local

192.168.30.215 (via default) from 0.0.0.0 (192.168.109.215)

Origin incomplete, metric 1000, localpref 50, valid, sourced, best

Extended Community: SoO:0:214215 RT:1:1

rx pathid: 0, tx pathid: 0x0

Updated on Jul 5 2152 23:30:55 UTC

Auf dem Router, der das Präfix von OMP an BGP weitergibt (in diesem Beispiel cEdge1), muss nur die OMP-Route in der RIB vorhanden sein.

Beispiel:

cEdge1#

show ip route vrf 1 10.1.1.1

Routing Table: 1

Routing entry for 10.1.1.1/32

Known via "omp", distance 251, metric 0, type omp

Redistributing via bgp 65400

Advertised by bgp 65400

Last update from 192.168.30.215 on Sdwan-system-intf, 15:59:54 ago

Routing Descriptor Blocks:

* 192.168.30.215 (default), from 192.168.30.215, 15:59:54 ago, via Sdwan-system-intf

Route metric is 0, traffic share count is 1

Es kann jedoch vorkommen, dass auf dem zweiten Router eine Race Condition auftritt, die das angekündigte Präfix empfängt und bewirkt, dass die BGP-Route in der RIB installiert wird, bevor die OMP-Route gelernt wird.

Auf cEdge2 zeigt die Ausgabe von sh bpg vpnv4 unicast vrf 1 <prefix> Folgendes an:

1. Wird keinem Peer angekündigt.

2. Die erweiterte Community enthält die Standort-ID 214215, die mit dem Standort übereinstimmt, an dem sich dieser Router befindet.

Beispiel:

cEdge2#

show bgp vpnv4 unicast vrf 1 10.1.1.1

BGP routing table entry for 1:1:10.1.1.1/24, version 32

Paths: (1 available, best #1, table 1)

Not advertised to any peer

Refresh Epoch 1

Local

192.168.160.214 (via vrf 1) from 192.168.160.214 (192.168.54.11)

Origin incomplete, metric 1000, localpref 50, valid, internal, best

Extended Community:

SoO:0:214215

RT:65512:10

rx pathid: 0, tx pathid: 0x0

Updated on Jul 6 2152 17:26:19 UTC

Auf cEdge2 wird die Ausgabe von sh ip route vrf

zeigt diese:

1. Das Flag "SDWAN Down" zeigt an, dass dies vom selben Standort stammt.

2. Die administrative Distanz der Route beträgt 252 (höher als OMP und anders als der erwartete iBGP AD 200).

Beispiel:

cEdge2#

show ip route vrf 1 10.1.1.1

Routing Table: 1

Routing entry for 10.1.1.0/24

Known via "bgp 65400",

Entfernung 252

, metric 1000, type internal

Redistributing via omp

Last update from 192.168.160.214 00:15:13 ago

Routing Descriptor Blocks:

* 192.168.160.214, from 192.168.160.214, 00:15:13 ago

opaque_ptr 0x7F9DD0B86818

SDWAN ausgefallen

Route metric is 1000, traffic share count is 1

AS Hops 0

MPLS label: none

Wenn ein Standort-Router erkennt, dass eine vom BGP bezogene Route von derselben Standort-ID stammt, wird die Route nicht zurück an OMP gemeldet.

Zugehörige Informationen

- vEdge kündigt nicht seine eigenen an, als wenn BGP-Routen in OMP angekündigt werden

- Cisco SD-WAN Routing Configuration Guide, Cisco IOS XE Version 17.x - Konfigurieren von OMP über CLI

- IP-Routing: BGP-Konfigurationsleitfaden

- Konfigurieren von Unicast-Overlay-Routing

- Cisco SD-WAN-Befehlsreferenz - Overlay-AS

- Technischer Support und Dokumentation für Cisco Systeme