Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Configurazione

Verifica

Risoluzione dei problemi

Soluzione 1

Overlay-AS Caso 1

Overlay-AS Caso 2

Soluzione 2

Spiegazione della prevenzione dei loop SoO

Informazioni correlate

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. Si noti che send-comminity non è configurato per la risorsa 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 presente 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 in sdwan omp sezione e propagate-aspath non è configurato (la configurazione rest è la stessa descritta inizialmente: advertise bgp è abilitato in omp address-family ipv4 vrf 1 sezione, redistribute omp configurato in router bgp

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 configurato in router bgp per la VPN sul lato servizio specifica (address-family ipv4 vrf 1). Anche qui ci sono dei sottocasi.

Caso 2.1. Con overlay-as attivato 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 | nomo | 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 disattivato 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 as-path ricevuto, verso R2 quindi aggiunge 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 disattivato 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 configurato su cE3, propagate-aspath è abilitato nel router bgp 65401 address-family ipv4 vrf 1 su cE1/cE2.

Caso 2.2.a. Con propagate-aspath disabilitato solo su cE3, cE3 lo riceve come una 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 allow-same-site-tunnels è configurato. Se la sessione BFD del tunnel del piano dati è nello stato inattivo, il TLOC rimane non risolto. Nell'esempio riportato di seguito 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 | non fissato

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

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" | escludi non impostato

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

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

OSPF (Open Shortest Path First) send-community

per il corretto funzionamento di questa funzionalità, è necessario configurare il 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 i risultati di show bgp vpnv4 unicast vrf 1

dal sito pubblicitario o dal sito 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

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