Evitare il loop di routing BGP-OMP nella sovrapposizione SD-WAN sui siti dual-homed con due router

Introduzione

Questo documento descrive come evitare un loop di routing nella struttura SD-WAN quando vengono usati il routing Border Gateway Protocol (BGP) e il sito di origine (SoO).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Conoscenze base di OMP (Overlay Management Protocol)
• Conoscenze base di BGP
• Componenti SD-WAN e interazione tra di essi

Componenti usati

Ai fini della dimostrazione, sono stati utilizzati i seguenti router software:

• 3 router Cisco IOS^® XE CSR1000v con software versione 17.2.1v in modalità controller (SD-WAN)
• 2 router Cisco IOS XE CSR1000v con software versione 16.7.3

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Ai fini del presente documento, viene utilizzata la seguente topologia:

Topologia

R1 e R2 sono router Cisco IOS XE generici (o qualsiasi altro router in grado di eseguire BGPv4). cE1, cE2 e cE3 eseguono Cisco IOS XE in modalità controller (SD-WAN). Qui è possibile trovare un riepilogo dei parametri site-id e system-ip assegnati a ciascun router SD-WAN:

Router SD-WAN	id-sito	ip-sistema
cE1	214	192.168.30.214
cE2	215	192.168.30.215
cE3	216	192.168.30.216

Di seguito una serie di eventi che hanno avuto luogo all'inizio:

1. R1 e R2 stabiliscono il peering eBGP in modo corrispondente con cE1, cE2 e cE3. cE1 e cE2 stabiliscono il peering iBGP.
2. R2 crea la route BGP 10.1.1.0/24 e la annuncia tramite eBGP a cE3.
3. cE3 riceve questa route BGP sul lato servizio nella famiglia di indirizzi VRF 1 e la ridistribuisce in OMP.
4. cE3 annuncia il percorso OMP 10.1.1.0/24 alla sovrimpressione SD-WAN (i controller vSmart sono responsabili del routing della diffusione delle informazioni tramite il protocollo OMP a tutti gli altri router Edge uniti alla sovrimpressione SD-WAN).
5. cE1 e cE2 ricevono la route OMP e la ridistribuiscono tramite eBGP in VRF da 1 a R1.

Configurazione

Ecco la configurazione appropriata di cE1. Notare che non send-comminity è configurato per il router adiacente 192.168.160.215:

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
  ! 

Verifica

1. Nello stato iniziale, il percorso viene annunciato da cE3 e appreso da cE1 e cE2 tramite OMP. Entrambi ridistribuiscono la route a BGP e si annunciano l'uno all'altro e a R1:



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. L'interfaccia WAN è disconnessa o la connettività al fabric SD-WAN è interrotta su cE2, quindi i peer OMP (connessioni vSmart) non funzionano. Da iBGP rimane un'unica route:



ce2(config)#

interfaccia Gigabit Ethernet 2

ce2(config-if)#

shutdown

ce2(config-if)#

fine

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 preferisce ancora la route tramite OMP (è l'unica che rimane) originata da 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. La connettività sull'interfaccia WAN di cE2 viene stabilita di nuovo. Il percorso è ancora preferito da cE1 tramite iBGP a causa della migliore distanza amministrativa (AD).



ce2(config)#

interfaccia Gigabit Ethernet 2

ce2(config-if)#

nessuna chiusura

ce2(config-if)#

fine

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 preferisce ancora il percorso tramite OMP creato da cE3. Tenere presente che cE1 ridistribuisce OMP in BGP:

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. Succede qualcosa con la connettività cE3 a R2. Per eseguire il test, l'interfaccia viene chiusa e il peer R2 BGP viene perso:



ce3(config)#

interfaccia Gigabit Ethernet 6

ce3(config-if)#

shutdown

ce3(config-if)#

eseguire

5. Di conseguenza, il ciclo di routing si forma tra cE1 e cE2 (cE2 ridistribuisce la rotta da OMP e annuncia a cE1 tramite BGP, cE1 ridistribuisce BGP a OMP e annuncia a cE2):



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

Risoluzione dei problemi

Ci sono due possibili soluzioni.

Soluzione 1

Configurare overlay-as per OMP. Quindi, un numero di sistema autonomo (AS) viene assegnato alla sovrapposizione OMP stessa. Ad esempio:



config-transaction
 sdwan
  omp
   overlay-as 64512
   exit

Per impostazione predefinita, OMP è trasparente per BGP anche se propagate-aspath è configurato. overlay-as È una funzionalità che precede AS specificato come parametro di questo comando all'attributo BGP AS_PATH delle route esportate da OMP a BGP. Se si configura lo stesso numero AS sovrapposto su più dispositivi nella rete sovrapposta, tutti questi dispositivi sono considerati parte dello stesso AS. Di conseguenza, non inoltrano alcun percorso contenente il numero AS di sovrapposizione, quindi il ciclo di routing non viene consentito.

Tenete a mente che overlay-as e propagate-aspath sono dipendenti l'uno dall'altro. Questa funzione viene descritta in dettaglio.

Esistono due casi:

Overlay-AS Caso 1

overlay-as configurato a livello globale nella sdwan omp sezione e non propagate-aspath configurato (la configurazione rest è la stessa descritta inizialmente: advertise bgp è abilitato nella omp address-family ipv4 vrf 1 sezione, redistribute omp configurato nella router bgp <AS> address-family ipv4 vrf 1 sezione).

overlay-as 64512, configurato su cE1/cE2 e cE3.

Topologia per la dimostrazione di overlay-as

A scopo dimostrativo, BGP AS su cE1, cE2 e cE3 è stato modificato.

R1 - cE1/cE2 ancora peer tramite eBGP, in quanto vengono utilizzati rispettivamente 65300 e 65401.

cE3 - R2 ancora peer tramite eBGP, in quanto vengono utilizzati rispettivamente 65402 e 65500.

R1 invia la route (ad esempio, 192.168.41.11/32) a cE1/cE2. cE1/cE2 ridistribuisce la route in OMP, senza alcun attributo AS_PATH.

cE3 lo riceve e lo pubblicizza in BGP verso R2, solo con il proprio AS (comportamento normale di eBGP).

La route route1 su R2 ha 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 Caso 2

propagate-aspath configurata nella router bgp sezione per la VPN del lato servizio (address-family ipv4 vrf 1Service Side VPN) specifica. Anche qui ci sono dei sottocasi.

Caso 2.1. Con overlay-as abilitato su cE3, propagate-aspath è abilitato anche in router bgp 65401 address-family ipv4 vrf 1 su cE1/cE2.

R1 invia la route route1 a cE1/cE2. cE1/cE2 ridistribuisce la route in OMP con un AS-path proveniente dal sito R1.

Il percorso OMP su vSmart ha AS-Path: "65300".

vsmart1#

show omp route vpn 1 192.168.41.11/32 | nomore | escludi non\ impostato

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

Caso 2.1.a. Con propagate-aspath disabilitato su cE3, cE3 lo riceve come route OMP e lo annuncia in BGP, ignora qualsiasi attributo as-path, si sovrappone a R2 e aggiunge solo il proprio BGP AS (normale comportamento eBGP).

Route route1 su percorso AS R2: "65402".

R2#

sh ip bgp | i 192.168.41.11/32

 *> 192.168.41.11/32 192.168.60.216 1000 0 65402 ?

Caso 2.1.b. Con propagate-aspath abilitato su cE3, cE3 lo riceve come una route OMP e lo annuncia in BGP, precede l'attributo received come-path, in R2 aggiunge quindi Overlay-AS seguito dal proprio BGP AS.

Route route1 su percorso AS R2: "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 ?

Caso 2.1.c. Con propagate-aspath disabilitato su cE1/cE2, cE3 lo riceve come route OMP senza alcun attributo as-path e lo annuncia in BGP, verso R2, precede Overlay-AS e aggiunge solo il proprio BGP AS.

Route route1 su percorso AS R2: "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 ?

Caso 2.2. Senza overlay-as configurarlo su cE3, propagate-aspath viene abilitato nella famiglia di indirizzi ipv4 vrf 1 del router bgp 65401 su cE1/cE2.

Caso 2.2.a. Con propagate-aspath disabilitato solo su cE3, cE3 lo riceve come route OMP e lo annuncia in BGP, ignorando qualsiasi attributo AS_PATH, verso R2, aggiunge il proprio BGP AS (normale comportamento eBGP).

Route route1 su percorso AS R2: "65402".

R2#

sh ip bgp | i 192.168.41.11/32

 *> 192.168.41.11/32 192.168.60.216 1000 0 65402 ?

Caso 2.2.b. Quando propagate-aspath è abilitato su cE3, cE3 lo riceve come route OMP e lo annuncia in BGP, precede l'attributo AS_PATH ricevuto, verso R2, quindi aggiunge il proprio AS.

Route route1 su percorso AS R2: "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 ?

Punto importante:

Quando si invia l'attributo AS-Path in OMP, il router perimetrale non aggiunge il proprio AS (come mostrato nell'articolo vEdge non annuncia il proprio AS quando le route BGP vengono annunciate in OMP). Se il router perimetrale remoto riceve una route OMP con il proprio AS nell'attributo AS_PATH, non esegue il rilevamento del loop e invia la route con il percorso AS ricevuto al router sul lato servizio.

Soluzione 2

Configurare lo stesso id-sito sui router cE1 e cE2. Sebbene vSmart annunci le route verso il sito con lo stesso ID sito della route stessa, poiché l'attributo originator della route è diverso, la prevenzione dei loop non viene attivata, ma il loop di routing del control plane non si forma perché la route OMP non è installata nella RIB. Ciò si verifica perché la route OMP rimane nello stato Inv,U (Non valido, Non risolto). Per impostazione predefinita, non è possibile stabilire tunnel del piano dati tra siti con lo stesso ID sito a meno che non allow-same-site-tunnels sia configurato. Se la sessione BFD del tunnel del piano dati è nello stato inattivo, il TLOC rimane non risolto. Nell'esempio, questo router site-id 214215 è stato configurato su entrambi i router ce1 e ce2. Il router 10.0.0.2/32 annunciato da cE2 e cE1 non lo installa nella tabella di routing perché non esistono sessioni del piano dati tra cE1 e cE2:

ce1#

show sdwan omp route 10.0.0.2/32 det | exc non impostato

--------------------------------------------------- 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" | esclusione non impostata

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

È possibile controllare questo comando sul controller vSmart per capire quali route ricevono il prefisso specifico (vedere la sezione "ADVERTISED TO"):

vsmart1#

mostra dettagli route omp 10.1.1.0/24 | nomore | escludi non\ impostato

--------------------------------------------------- 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 viene inoltre mantenuto come attributo della community esteso del sito di origine BGP (SoO:0:<site-id> negli output precedenti). Utilizzato per identificare le route originate da un sito in modo da impedire la ripubblicazione del prefisso. Per il corretto funzionamento di questa funzionalità, i router devono inviare community estese. Configurare cE1 per inviare le community estese al router cE2:

router bgp 65401 address-family ipv4 vrf 1 neighbor 192.168.160.215 send-community both 

Spiegazione della Prevenzione del Loop SoO

Nel caso in cui due router nello stesso sito siano vicini iBGP, SD-WAN ha un meccanismo di prevenzione dei loop integrato per prevenire un loop di routing da OMP a BGP e viceversa. Per dimostrarlo, la topologia è stata leggermente aggiornata e lo stesso ID sito 214215 è stato configurato su entrambi i router con BGP AS65400 (cE1/cE2). In questo esempio, un prefisso 10.1.1.0/24 viene pubblicizzato in OMP dal sito remoto (cE3) e appreso in OMP al sito 214215 (cE1-cE2).

Topologia per la dimostrazione dell'SoO

Al fine di realizzare la prevenzione dei loop, il SoO della community estesa BGP viene usato per mostrare quale sito ha originato il prefisso. Questa community viene aggiunta a un prefisso quando viene ridistribuita da OMP in BGP.

Per il corretto funzionamento di questa funzionalità, è necessario configurare il send-community <both|extended> comando sull'istruzione neighbor in entrambi i dispositivi, come mostrato di seguito.

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

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

La comunità estesa può essere vista con l'output di show bgp vpnv4 unicast vrf 1 <prefix> dal sito pubblicitario o di ricezione.

Esempio:

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

Sul router che annuncia il prefisso da OMP in BGP (cEdge1 nell'esempio), deve essere presente solo la route OMP nel RIB.

Esempio:

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

Tuttavia, può accadere che si verifichi una race condition sul secondo router che riceve il prefisso annunciato e provoca l'installazione della route BGP nel RIB prima che il router OMP venga appreso.

Su cEdge2, l'output di sh bpg vpnv4 unicast vrf 1 <prefix> visualizza quanto segue:

1. Non annunciato ad alcun peer.
2. Extended Community include il sito con ID 214215, che corrisponde al sito su cui si trova il router.

Esempio:

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

Su cEdge2, l'output di sh ip route vrf <vrf_number> <prefix> mostra quanto segue:

1. La bandierina "SDWAN Down" indica che la connessione è stata rilevata come proveniente dallo stesso sito.
2. La distanza amministrativa della rotta è 252 (superiore a OMP e diversa da quella prevista per iBGP AD 200).

Esempio:

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

distanza 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 non disponibile

 
Route metric is 1000, traffic share count is 1
AS Hops 0
MPLS label: none

Quando un router di sito rileva che una route individuata da BGP ha lo stesso ID sito, non viene annunciata di nuovo in OMP.

Informazioni correlate

• vEdge non annuncia il proprio come quando le route BGP vengono annunciate in OMP
• Guida alla configurazione del routing Cisco SD-WAN, Cisco IOS XE release 17.x - Configurazione di OMP tramite CLI
• Instradamento IP: Guida alla configurazione BGP
• Configurazione di Unicast Overlay Routing
• Guida di riferimento ai comandi di Cisco SD-WAN - overlay-as
• Documentazione e supporto tecnico – Cisco Systems