Vermeidung von BGP-OMP-Routing-Schleifen im SD-WAN-Overlay an Dual-Homed-Standorten mit zwei Routern

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

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, dass nicht für den Nachbarn 192.168.160.215 konfiguriert send-comminity ist:

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)#

end

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)#

end

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

Standardmäßig ist OMP für BGP transparent, selbst wenn es konfiguriert propagate-aspath ist. overlay-as ist eine Funktion, die AS, das als Parameter dieses Befehls angegeben wurde, dem BGP AS_PATH-Attribut von Routen, die von OMP nach BGP exportiert wurden, voranstellt. 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 voneinander abhängig propagate-aspath 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 (Rest-Konfiguration ist die gleiche wie anfänglich beschrieben: advertise bgp wird unter omp address-family ipv4 vrf 1 Abschnitt aktiviert, redistribute omp konfiguriert unter router bgp <AS> 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, um router bgp Abschnitt für das jeweilige serviceseitige VPN (address-family ipv4 vrf 1) hinzuzufügen. Hier sind auch Unterfälle.

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

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 | Nomen | nicht\ gesetzt ausschließen

--------------------------------------------------- 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. Wenn cE3 auf cE3 propagate-aspath deaktiviert ist, empfängt cE3 die Nachricht als OMP-Route und kündigt sie dem BGP an, ignoriert alle As-Path-Attribute und überlagert diese in Richtung 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. Wenn auf cE3 propagate-aspath aktiviert, empfängt cE3 die Nachricht als OMP-Route und kündigt sie dem BGP an, gibt das empfangene As-Path-Attribut an R2 weiter und 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 Wenn cE3 auf cE1/cE2 propagate-aspath deaktiviert ist, empfängt es diese als OMP-Route ohne "as-path"-Attribut und kündigt sie 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 auf cE3 overlay-as konfiguriert, propagate-aspath ist diese Funktion unter Router bgp 65401 address-family ipv4 vrf 1 auf cE1/cE2 aktiviert.

Fall 2.2.a. Wenn cE3 nur auf cE3 propagate-aspath deaktiviert ist, 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. Wenn auf cE3 aktiviert propagate-aspath ist, empfängt cE3 die Nachricht als OMP-Route und kündigt sie dem BGP an, gibt das empfangene AS_PATH-Attribut an R2 weiter und 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 Tunnel für die Datenebene eingerichtet werden, es sei denn, sie allow-same-site-tunnels sind konfiguriert. Wenn sich die BFD-Sitzung des Datenebenentunnels im inaktiven Zustand befindet, bleibt die TLOC-Lösung weiterhin bestehen. In diesem Beispiel 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 | exc nicht eingestellt

--------------------------------------------------- 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 | Nomen | nicht\ gesetzt ausschließen

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

Der send-community <both|extended> Befehl muss für die Neighbor-Anweisung auf beiden Geräten wie dargestellt 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 kann mit der Ausgabe show bgp vpnv4 unicast vrf 1 <prefix> von entweder der Werbe-oder Empfänger-Website zu sehen.

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 werden in der Ausgabe von folgende sh ip route vrf <vrf_number> <prefix> angezeigt:

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