Auflösen von BGP-OMP-Routing-Schleifen bei Verwendung von BGP-Routing und so weiter

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

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• 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:

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

Hier ist 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)#
shutdown
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 still prefers the route via OMP (this is the only route that remains) originated by cE3:

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)#
no shutdown
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. Bei der cE3-Verbindung mit R2 geschieht etwas. Zum Testen wird die Schnittstelle heruntergefahren, und der R2-BGP-Peer geht verloren:

ce3(config)#
interface GigabitEthernet 6
ce3(config-if)#
shutdown
ce3(config-if)#
commit

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 für BGP standardmäßig 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 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 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 identisch mit der anfänglichen Beschreibung: advertise bgp wird unter "omp address-family ipv4 vrf 1Abschnitt" aktiviert, redistribute omp unter "router bgp address-family ipv4 vrf 1Abschnitt" konfiguriert).

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 per eBGP, AS 6530 und 65401 verwendet.

cE3 - R2 weiterhin Peer über eBGP, AS 65402 und 65500 werden jeweils verwendet.

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. Bei overlay-as aktivierter Funktion für cE3 propagate-aspath ist dies auch unter router bgp 65401 address-family ipv4 vrf 1 für cE1/cE2 möglich.

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

OMP-Route in vSmart hat AS-Pfad: 65300.

vsmart1#

show omp routes vpn 1 192.168.41.11/32 | nomore | exclude not\ set

---------------------------------------------------
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 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. Bei propagate-aspath Aktivierung auf cE3 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 gefolgt von seinem eigenen BGP-AS hinzu.

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 cE3 die Nachricht 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: 6540264512.

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 Konfiguration für cE3 ist propagate-aspath dieser 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. Dabei wird dem empfangenen AS_PATH-Attribut R2 vorangestellt und dann sein eigenes AS hinzugefügt.

Route1 auf R2 AS-Pfad: 6540265300.

R2#

sh ip bgp | i 192.168.41.11/32

 *>   192.168.41.11/32 192.168.60.216        1000             0 65402 65300 ?

Anmerkung: 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 ankündigt, wird keine Schleifenvermeidung ausgelöst, da das Ausgangsattribut der Route unterschiedlich ist. Die Routingschleife auf der Kontrollebene bildet sich jedoch nicht, 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. Im vorliegenden 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 not set

---------------------------------------------------
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" | exclude not set

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

show omp routes 10.1.1.0/24 detail | nomore | exclude not\ set

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

Dassite-id bleibt auch als erweitertes BGP Site-of-Origin (SoO)-Community-Attribut erhalten (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 Befehl muss für die Neighbor-Anweisung auf beiden Geräten wie dargestellt konfiguriert werden, damit diese Funktion ordnungsgemäß funktioniert.

cEdge1#

show run | sec 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

cEdge 2#

show run | sec 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 von angezeigt werden, entweder von der Werbe- show bgp vpnv4 unicast vrf 1 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

cEdge 2#

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 zeigt die Ausgabe von sh ip route vrf Folgendes an:

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

cEdge 2#

show ip route vrf 1 10.1.1.1
Routing Table: 1
Routing entry for 10.1.1.0/24
Known via "bgp 65400",

distance 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 Down
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
• Cisco SD-WAN-Befehlsreferenz - Overlay-AS
• Technischer Support und Downloads von Cisco