Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Configuration

Vérifier

Dépannage

Solution 1

Superposition - Cas AS 1

Superposition - Cas AS 2

Solution 2

Explication de la prévention de boucle SoO

Informations connexes

Introduction

Ce document décrit comment éviter une boucle de routage dans le fabric SD-WAN lorsque le routage BGP (Border Gateway Protocol) et le SoO (Site of Origin) sont utilisés.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- Compréhension de base du protocole OMP (Overlay Management Protocol)

- Compréhension de base du protocole BGP

- Composants SD-WAN et interaction entre eux

Composants utilisés

Pour les besoins de la démonstration, les routeurs logiciels suivants ont été utilisés :

- 3 routeurs Cisco IOS® XE CSR1000v avec la version logicielle 17.2.1v qui fonctionnent en mode contrôleur (SD-WAN)

- 2 routeurs Cisco IOS XE CSR1000v avec la version logicielle 16.7.3

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Pour les besoins de ce document, cette topologie est utilisée :

Topologie

R1 et R2 sont des routeurs Cisco IOS XE génériques (ou tout autre routeur capable d'exécuter BGPv4). cE1, cE2 et cE3 exécutent Cisco IOS XE en mode contrôleur (SD-WAN). Vous trouverez ici un résumé des paramètres site-id et system-ip attribués à chaque routeur SD-WAN :

Routeur SD-WAN

site-id

system-ip

cE1

214

192.168.30.214

cE2

215

192.168.30.215

cE3

216

192.168.30.216

Voici un ensemble d'événements qui se sont déroulés au départ :

1. R1 et R2 établissent l'appairage eBGP de manière correspondante avec cE1, cE2 et cE3. cE1 et cE2 établissent l'appairage iBGP.

2. R2 crée la route BGP 10.1.1.0/24 et l'annonce via eBGP à cE3.

3. cE3 reçoit cette route BGP côté service dans la famille d'adresses VRF 1, puis redistribue cette route dans OMP.

4. cE3 annonce la route OMP 10.1.1.0/24 à la superposition SD-WAN (les contrôleurs vSmart sont responsables de la diffusion des informations de routage via le protocole OMP vers tous les autres routeurs Edge associés à la superposition SD-WAN).

5. cE1 et cE2 reçoivent la route OMP et la redistribuent via eBGP dans VRF 1 vers R1.

Configuration

Voici la configuration appropriée de cE1. Notez que send-comminity n'est pas configuré pour le voisin 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

!

Vérifier

1. Dans l’état initial, la route est annoncée depuis cE3 et apprise par cE1 et cE2 via OMP. Les deux redistribuent la route vers BGP et s’annoncent mutuellement et vers 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'interface WAN est déconnectée ou la connectivité à la structure SD-WAN est perdue sur cE2, d'où la panne des homologues OMP (connexions vSmart). Une seule route reste acquise à partir d'iBGP :

ce2(config)#

interface GigabitEthernet 2

ce2(config-if)#

shutdown

ce2(config-if)#

tranche

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 préfère toujours la route via OMP (c'est la seule route qui reste) provenant de 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 connectivité sur l’interface WAN de cE2 est rétablie. La route est toujours préférée à partir de cE1 via iBGP en raison d'une meilleure distance administrative (AD).

ce2(config)#

interface GigabitEthernet 2

ce2(config-if)#

no shutdown

ce2(config-if)#

tranche

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 préfère toujours la route via OMP provenant de cE3. Gardez à l'esprit que cE1 redistribue OMP dans 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. Quelque chose se produit avec la connectivité cE3 à R2. Pour tester, l'interface est arrêtée et l'homologue BGP R2 est perdu :

ce3(config)#

interface GigabitEthernet 6

ce3(config-if)#

shutdown

ce3(config-if)#

engager

5. Par conséquent, la boucle de routage est formée entre cE1 et cE2 (cE2 redistribue la route depuis OMP et annonce à cE1 via BGP, cE1 redistribue BGP à OMP et annonce à 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

Dépannage

Il existe deux solutions possibles.

Solution 1

Configurez overlay-as pour OMP. Un numéro de système autonome (AS) est ensuite attribué à la superposition OMP elle-même. Exemple :

config-transaction

sdwan

omp

overlay-as 64512

exit

Par défaut, OMP est transparent pour BGP même si propagate-aspath est configuré. overlay-as est une fonctionnalité qui précède AS spécifié comme paramètre de cette commande à l'attribut BGP AS_PATH des routes exportées d'OMP vers BGP. Si vous configurez le même numéro de système autonome de superposition sur plusieurs périphériques du réseau de superposition, tous ces périphériques sont considérés comme faisant partie du même système autonome. Par conséquent, ils ne transfèrent aucune route contenant le numéro de système autonome de superposition, ce qui empêche la boucle de routage.

N'oubliez pas que overlay-as et propagate-aspath sont dépendants les uns des autres. Cette fonction est traitée en détail.

Voici deux cas qui existent :

Superposition - Cas AS 1

overlay-as configuré au niveau global sous sdwan omp section et propagate-aspath n'est pas configuré (la configuration de repos est identique à celle décrite initialement : advertise bgp est activé sous omp address-family ipv4 vrf 1 section, redistribute omp configuré sous router bgp

address-family ipv4 vrf 1

).

overlay-as 64512, configuré sur cE1/cE2 et cE3.

Topologie pour la démonstration de la superposition

Pour les besoins de la démonstration, BGP AS sur cE1, cE2 et cE3 a changé.

R1 - cE1/cE2 toujours homologue via eBGP, AS 65300 et 65401 sont utilisés respectivement.

cE3 - R2 toujours homologue via eBGP, AS 65402 et 65500 sont utilisés respectivement.

R1 envoie une route (par exemple, 192.168.41.11/32) à cE1/cE2. cE1/cE2 redistribue cette route dans OMP, sans attribut AS_PATH.

cE3 le reçoit et l'annonce dans BGP vers R2, uniquement avec son propre AS (comportement normal de eBGP).

La route route 1 sur R2 a 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 ?

Superposition - Cas AS 2

propagate-aspath configuré sous router bgp pour le VPN côté service particulier (address-family ipv4 vrf 1. Voici aussi des sous-cas.

Cas 2.1 . Avec overlay-as activé sur cE3, propagate-aspath est également activé sous router bgp 65401 address-family ipv4 vrf 1 sur cE1/cE2.

R1 envoie route route1 à cE1/cE2. cE1/cE2 redistribue cette route dans OMP avec un as-path provenant du site R1.

La route OMP sur vSmart a AS-Path : « 65300 ».

vsmart1#

show omp routes vpn 1 192.168.41.11/32 | nomore | exclusion non\ définie

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

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"

Cas 2.1.a. Avec propagate-aspath désactivé sur cE3, cE3 le reçoit en tant que route OMP et l'annonce dans BGP, ignore tout attribut as-path, superpose as, vers R2, et ajoute uniquement son propre AS BGP (comportement normal eBGP).

Route route1 sur R2 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 ?

Cas 2.1.b. Avec propagate-aspath activé sur cE3, cE3 le reçoit en tant que route OMP et l'annonce dans BGP, ajoute l'attribut as-path reçu, vers R2, puis ajoute l'AS de superposition suivi de son propre AS BGP.

Route route1 sur R2 AS-path : "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 ?

Cas 2.1.c. Avec propagate-aspath désactivé sur cE1/cE2, cE3 le reçoit en tant que route OMP sans attribut as-path et l'annonce dans BGP, vers R2, précède l'AS de superposition et ajoute uniquement son propre AS BGP.

Route route1 sur R2 AS-path : "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 ?

Cas 2.2 . Sans overlay-as configuré sur cE3, propagate-aspath est activé sous router bgp 65401 address-family ipv4 vrf 1 sur cE1/cE2.

Cas 2.2.a. Avec propagate-aspath désactivé sur cE3 uniquement, cE3 le reçoit en tant que route OMP et l'annonce dans BGP, ignorant tout attribut AS_PATH, vers R2, ajoute son propre AS BGP (comportement normal de eBGP).

Route route1 sur R2 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 ?

Cas 2.2.b. Quand propagate-aspath est activé sur cE3, cE3 le reçoit en tant que route OMP et l'annonce dans BGP, précède l'attribut AS_PATH reçu, vers R2, puis ajoute son propre AS.

Route route1 sur R2 AS-path : "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 ?

Point important :

Lorsque vous envoyez l'attribut AS-Path dans OMP, le routeur Edge n'ajoute pas son propre AS (comme démontré dans l'article vEdge Does Not Advertise Its Own AS When BGP Routes Are Advertised In OMP). Si le routeur de périphérie distant reçoit une route OMP avec son propre AS dans l'attribut AS_PATH, il n'effectue pas de détection de boucle et envoie la route avec le chemin AS reçu au routeur côté service.

Solution 2

Configurez le même site-id sur les routeurs cE1 et cE2. Bien que le vSmart annonce les routes au site avec le même ID de site que dans la route elle-même, puisque l'attribut d'origine de la route est différent, la prévention de boucle n'est pas déclenchée, mais la boucle de routage du plan de contrôle ne se forme pas car la route OMP n'est pas installée dans le RIB. Cela est dû au fait que la route OMP reste à l'état Inv, U (non valide, non résolu). Par défaut, les tunnels de plan de données ne peuvent pas être établis entre des sites qui ont le même ID de site sauf si allow-same-site-tunnels est configuré. Si la session BFD du tunnel du plan de données est à l'état down, TLOC reste non résolu. Dans cet exemple, site-id 214215 a été configuré sur les deux routeurs ce1 et ce2. La route 10.0.0.2/32 annoncée par cE2 et cE1 ne l'installe pas dans la table de routage car aucune session de plan de données n'existe entre cE1 et cE2 :

ce1#

show sdwan omp route 10.0.0.2/32 det | exc non défini

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

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" | exclusion non définie

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

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#

Vous pouvez vérifier cette commande sur le contrôleur vSmart afin de comprendre quelles routes reçoivent le préfixe particulier (voir la section « ANNONCÉ À ») :

vsmart1#

show omp routes 10.1.1.0/24 detail | nomore | exclusion non\ définie

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

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 est également préservé en tant qu'attribut de communauté étendue du site d'origine BGP (vous pouvez remarquer SoO:0:<site-id> dans les résultats précédents). Utilisé pour identifier les routes qui proviennent d'un site afin d'empêcher la nouvelle annonce de ce préfixe. Pour que cela fonctionne correctement, les routeurs doivent envoyer des communautés étendues. Configurez cE1 pour envoyer des communautés étendues au routeur cE2 :

router bgp 65401

address-family ipv4 vrf 1

neighbor 192.168.160.215 send-community both

Explication de la prévention de boucle SoO

Pour le cas où deux routeurs sur le même site sont des voisins iBGP, SD-WAN a un mécanisme de prévention de boucle intégré afin d'empêcher une boucle de routage d'OMP à BGP et de retour de BGP à OMP. Afin de démontrer cela, la topologie a été légèrement mise à jour et le même site-id 214215 a été configuré sur les deux routeurs qui exécutent BGP AS65400 (cE1/cE2). Dans cet exemple, un préfixe 10.1.1.0/24 est annoncé dans OMP à partir du site distant (cE3) et appris dans OMP au site 214215 (cE1-cE2).

Topologie pour la démonstration SoO

Afin d'accomplir la prévention des boucles, le SoO de la communauté étendue BGP est utilisé pour montrer quel site est à l'origine du préfixe. Cette communauté est ajoutée à un préfixe lorsqu'elle est redistribuée d'OMP dans BGP.

Les send-community

doit être configurée sur l'instruction neighbor dans les deux périphériques, comme illustré, pour que cette fonctionnalité fonctionne correctement.

cEdge1#

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

Commande 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 communauté étendue peut être vue avec le résultat de show bgp vpnv4 unicast vrf 1

depuis le site de publicité ou le site de réception.

Exemple :

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

Sur le routeur qui annonce le préfixe d'OMP dans BGP (cEdge1 dans cet exemple), seule la route OMP doit être présente dans le RIB.

Exemple :

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

Cependant, il peut arriver qu'une condition de concurrence se produise sur le second routeur qui reçoit le préfixe annoncé et entraîne l'installation de la route BGP dans le RIB avant l'apprentissage de la route OMP.

Sur cEdge2, la sortie de sh bpg vpnv4 unicast vrf 1 <prefix> affiche les éléments suivants :

1. Non annoncé à un homologue.

2. La communauté étendue inclut l'ID de site 214215, qui est le même site que celui sur lequel se trouve ce routeur.

Exemple :

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

Sur cEdge2, la sortie de sh ip route vrf

La présente :

1. L'indicateur « SDWAN Down » indique que ce problème provient du même site et qu'il a été détecté.

2. La distance administrative de la route est 252 (supérieure à OMP et différente de la distance administrative iBGP attendue de 200).

Exemple :

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

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 désactivé

Route metric is 1000, traffic share count is 1

AS Hops 0

MPLS label: none

Lorsqu'un routeur de site détecte qu'une route apprise BGP provient du même site-id, la route n'est pas annoncée à nouveau dans OMP.

Informations connexes

- vEdge n'annonce pas son propre AS lorsque des routes BGP sont annoncées dans OMP

- Guide de configuration du routage Cisco SD-WAN, Cisco IOS XE version 17.x - Configuration d'OMP à l'aide de l'interface CLI

- Routage IP : Guide de configuration BGP

- Configuration du routage de superposition de monodiffusion

- Référence des commandes Cisco SD-WAN - overlay-as

- Technical Support & Documentation - Cisco Systems