Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

Configuración

Verificación

Troubleshoot

Solución 1

Caso 1 de Overlay-AS

Caso AS de superposición 2

Solución 2

Explicación de la Prevención de Bucles SoO

Información Relacionada

Introducción

Este documento describe cómo evitar un loop de ruteo en el entramado SD-WAN cuando se utiliza el ruteo del Protocolo de gateway fronterizo (BGP) y el Sitio de origen (SoO).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

- Comprensión básica de Overlay Management Protocol (OMP)

- Comprensión básica de BGP

- Componentes SD-WAN e interacción entre ellos

Componentes Utilizados

Para la demostración, se utilizaron estos routers de software:

- 3 routers Cisco IOS® XE CSR1000v con versión de software 17.2.1v que se ejecutan en modo de controlador (SD-WAN)

- 2 routers Cisco IOS XE CSR1000v con versión de software 16.7.3

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

A los efectos de este documento, se utiliza esta topología:

Topología

R1 y R2 son routers genéricos Cisco IOS XE (o cualquier otro router capaz de ejecutar BGPv4). cE1, cE2 y cE3 ejecutan Cisco IOS XE en modo de controlador (SD-WAN). Aquí puede encontrar un resumen de los parámetros site-id y system-ip asignados a cada router SD-WAN:

Router SD-WAN

id del sitio

system-ip

cE1

214

192.168.30.214

cE2

215

192.168.30.215

cE3

216

192.168.30.216

A continuación se muestra un conjunto de eventos que tuvieron lugar inicialmente:

1. R1 y R2 establecen el peering eBGP en correspondencia con cE1, cE2 y cE3. cE1 y cE2 establecen el peering iBGP.

2. R2 origina la ruta BGP 10.1.1.0/24 y la anuncia vía eBGP a cE3.

3. cE3 recibe esta ruta BGP en el lado del servicio en la familia de direcciones VRF 1 y luego redistribuye esta ruta en OMP.

4. cE3 anuncia la ruta OMP 10.1.1.0/24 a la superposición SD-WAN (los controladores vSmart son responsables de la difusión de la información de routing a través del protocolo OMP a todos los demás routers Edge unidos a la superposición SD-WAN).

5. cE1 y cE2 reciben la ruta OMP y la redistribuyen nuevamente a través de eBGP en VRF 1 a R1.

Configuración

Esta es la configuración relevante de cE1. Observe que no send-comminity está configurado para el vecino 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

!

Verificación

1. En el estado inicial, la ruta se anuncia desde cE3 y se aprende por cE1 y cE2 a través de OMP. Ambos redistribuyen la ruta a BGP y se anuncian entre sí y 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. La interfaz WAN se desconecta o se pierde la conectividad con el fabric SD-WAN en cE2, por lo que los pares OMP (conexiones vSmart) dejan de funcionar. Solo queda una ruta aprendida de iBGP:

ce2(config)#

interface GigabitEthernet 2

ce2(config-if)#

apagado

ce2(config-if)#

Finalizar

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 sigue prefiriendo la ruta a través de OMP (esta es la única ruta que queda) originada por 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 conectividad en la interfaz WAN de cE2 se establece de nuevo. La ruta se sigue prefiriendo desde cE1 a través de iBGP debido a una mejor distancia administrativa (AD).

ce2(config)#

interface GigabitEthernet 2

ce2(config-if)#

no shutdown

ce2(config-if)#

Finalizar

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 sigue prefiriendo la ruta a través de OMP originada por cE3. Tenga en cuenta que cE1 redistribuye OMP en 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. Algo sucede con la conectividad cE3 a R2. Para realizar la prueba, la interfaz se apaga y se pierde el par BGP R2:

ce3(config)#

interface GigabitEthernet 6

ce3(config-if)#

apagado

ce3(config-if)#

commit

5. Como resultado, el loop de ruteo se forma entre cE1 y cE2 (cE2 redistribuye la ruta de OMP y anuncia a cE1 a través de BGP, cE1 redistribuye BGP a OMP y anuncia 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

Troubleshoot

Hay dos soluciones posibles.

Solución 1

Configure overlay-as para OMP. Luego, se asigna algún número de sistema autónomo (AS) a la superposición de OMP. Por ejemplo:

config-transaction

sdwan

omp

overlay-as 64512

exit

De forma predeterminada, OMP es transparente para BGP incluso si propagate-aspath está configurado. overlay-as es una función que antepone AS especificado como parámetro de este comando al atributo AS_PATH de BGP de las rutas exportadas de OMP a BGP. Si configura el mismo número AS de superposición en varios dispositivos de la red de superposición, todos estos dispositivos se consideran parte del mismo AS. Como resultado, no reenvían ninguna ruta que contenga el número AS de superposición, por lo que se impide el loop de ruteo.

Tenga en cuenta que overlay-as y propagate-aspath dependen el uno del otro. Esta función se analiza en detalle.

Aquí hay dos casos que existen:

Caso 1 de Overlay-AS

overlay-as configurado en el nivel global en la sdwan omp sección y no propagate-aspath está configurado (la configuración rest es la misma que la descrita inicialmente: advertise bgp está habilitada en la omp address-family ipv4 vrf 1 sección, redistribute omp configurada en la router bgp <AS> address-family ipv4 vrf 1 sección).

overlay-as 64512, configurado en cE1/cE2 y cE3.

Topología para la demostración de superposición

A efectos de demostración, BGP AS en cE1, cE2 y cE3 cambió.

R1 - cE1/cE2 aún igual a través de eBGP, AS 65300 y 65401 se utilizan respectivamente.

cE3 - R2 todavía peer vía eBGP, AS 65402 y 65500 se utilizan respectivamente.

R1 envía la ruta (por ejemplo, 192.168.41.11/32) a cE1/cE2. cE1/cE2 redistribuye esta ruta en OMP, sin ningún atributo AS_PATH.

cE3 lo recibe y lo anuncia en BGP hacia R2, solamente con su propio AS (comportamiento normal de eBGP).

La ruta route1 en R2 tiene 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 ?

Caso AS de superposición 2

propagate-aspath configurado en la router bgp sección para la VPN del lado del servicio (address-family ipv4 vrf 1) en particular. Aquí hay sub-casos también.

Caso 2.1. Con overlay-as activado en cE3, también propagate-aspath está activado router bgp 65401 address-family ipv4 vrf 1 en cE1/cE2.

R1 envía la ruta1 a cE1/cE2. cE1/cE2 redistribuye esta ruta en OMP con una ruta as que proviene del sitio R1.

La ruta OMP en vSmart tiene AS-Path: "65300".

vsmart1#

show omp routes vpn 1 192.168.41.11/32 | no más | excluir no\ establecido

--------------------------------------------------- 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 inhabilitado en cE3, cE3 lo recibe como una ruta OMP y lo anuncia en BGP, ignora cualquier atributo as-path, se superpone como, hacia R2, y agrega solamente su propio AS BGP (comportamiento eBGP normal).

Ruta ruta1 en 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 ?

Caso 2.1.b. Con propagate-aspath habilitado en cE3, cE3 lo recibe como una ruta OMP y lo anuncia en BGP, antepone el atributo recibido as-path, hacia R2 y luego agrega el Overlay-AS seguido por su propio AS BGP.

Route route1 en 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 ?

Caso 2.1.c. Con propagate-aspath inhabilitado en cE1/cE2, cE3 lo recibe como una ruta OMP sin ningún atributo as-path y lo anuncia en BGP, hacia R2, antepone Overlay-AS y agrega solamente su propio AS BGP.

Route route1 en 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 ?

Caso 2.2. Sin overlay-as configuración en cE3, propagate-aspath se habilita en router bgp 65401 address-family ipv4 vrf 1 en cE1/cE2.

Caso 2.2.a. Con propagate-aspath inhabilitado en cE3 solamente, cE3 lo recibe como una ruta OMP y lo anuncia en BGP, ignorando cualquier atributo AS_PATH, hacia R2, agrega su propio AS BGP (comportamiento eBGP normal).

Ruta ruta1 en 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 ?

Caso 2.2.b. Cuando propagate-aspath está habilitado en cE3, cE3 lo recibe como una ruta OMP y lo anuncia en BGP, antepone el atributo AS_PATH recibido, hacia R2 y luego agrega su propio AS.

Ruta ruta1 en 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 ?

Punto importante:

Cuando envía el atributo AS-Path a OMP, el router de borde no agrega su propio AS (como se muestra en el artículo vEdge Does Not Advertise Its Own AS When BGP Routes Are Advertised Into OMP). Si el router periférico remoto recibe una ruta OMP con su propio AS en el atributo AS_PATH, no realiza la detección de loop y envía la ruta con el trayecto AS recibido al router en el lado del servicio.

Solución 2

Configure el mismo site-id en los routers cE1 y cE2. Aunque vSmart anuncia las rutas de vuelta al sitio con el mismo id de sitio que en la ruta en sí, dado que el atributo de originador de la ruta es diferente, no se activa la prevención de bucles, pero no se forma el bucle de routing del plano de control porque la ruta OMP no está instalada en el RIB. Esto se debe a que la ruta OMP permanece en el estado Inv,U (No válido,Sin resolver). De forma predeterminada, los túneles del plano de datos no se pueden establecer entre sitios que tengan el mismo id de sitio a menos que allow-same-site-tunnels se configure. Si la sesión BFD del túnel del plano de datos se encuentra en el estado inactivo, TLOC permanece sin resolver. En este ejemplo, site-id 214215 se configuró en ambos routers ce1 y ce2. La ruta 10.0.0.2/32 anunciada por cE2 y cE1 no la instala en la tabla de ruteo porque no existen sesiones de plano de datos entre cE1 y cE2:

ce1#

show sdwan omp route 10.0.0.2/32 det | exc no establecido

--------------------------------------------------- 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" | excluir no establecido

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

Puede verificar este comando en el controlador vSmart para comprender qué rutas reciben el prefijo específico (consulte la sección "ADVERTISED TO"):

vsmart1#

show omp routes 10.1.1.0/24 detail | no más | excluir no\ establecido

--------------------------------------------------- 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 también se conserva como atributo de comunidad ampliada del sitio de origen BGP (SoO) (puede observar SoO:0:<site-id> en los resultados anteriores). Esto se utiliza para identificar las rutas que se han originado desde un sitio para evitar que se vuelva a anunciar ese prefijo. Para que esto funcione correctamente, los routers deben enviar comunidades extendidas. Configure cE1 para enviar comunidades extendidas al router cE2:

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

Explicación de la Prevención de Bucles SoO

En el caso de que dos routers en el mismo sitio sean vecinos iBGP, SD-WAN tiene un mecanismo de prevención de loops integrado para evitar un loop de ruteo de OMP a BGP y de vuelta de BGP a OMP. Para demostrar esto, la topología se actualizó ligeramente y se configuró el mismo id de sitio 214215 en ambos routers que ejecutan BGP AS65400 (cE1/cE2). En este ejemplo, se anuncia un prefijo 10.1.1.0/24 en OMP desde el sitio remoto (cE3) y se aprende en OMP en el sitio 214215 (cE1-cE2).

Topología para la demostración de SoO

Para lograr la prevención de loops, el SoO de la comunidad ampliada BGP se utiliza para mostrar qué sitio originó el prefijo. Esta comunidad se agrega a un prefijo cuando se redistribuye de OMP a BGP.

El send-community <both|extended> comando se debe configurar en la instrucción neighbor en ambos dispositivos, como se muestra, para que esta funcionalidad funcione correctamente.

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 comunidad ampliada se puede ver con el resultado de show bgp vpnv4 unicast vrf 1 <prefix> desde el sitio de publicidad o de recepción.

Ejemplo:

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

En el router que anuncia el prefijo de OMP en BGP (cEdge1 en este ejemplo), sólo la ruta OMP debe estar presente en el RIB.

Ejemplo:

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

Sin embargo, puede ocurrir que una condición de carrera ocurra en el segundo router que recibe el prefijo anunciado y hace que la ruta BGP se instale en el RIB antes de que se aprenda la ruta OMP.

En cEdge2, la salida de sh bpg vpnv4 unicast vrf 1 <prefix> muestra lo siguiente:

1. No se anuncia a ningún par.

2. La comunidad ampliada incluye el id de sitio 214215, que es el mismo sitio en el que se encuentra este router.

Ejemplo:

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

En cEdge2, el resultado de sh ip route vrf <vrf_number> <prefix> muestra lo siguiente:

1. Se observa que el indicador "SDWAN inactivo" indica que se ha detectado que se ha originado en el mismo sitio.

2. La distancia administrativa de la ruta es 252 (mayor que OMP y diferente de la esperada AD 200 de iBGP).

Ejemplo:

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 inactivo

Route metric is 1000, traffic share count is 1

AS Hops 0

MPLS label: none

Cuando un router de sitio detecta que una ruta aprendida BGP se origina desde el mismo id de sitio, la ruta no se anuncia nuevamente en OMP.

Información Relacionada

- vEdge no anuncia su propio AS cuando las rutas BGP se anuncian en OMP

- Guía de Configuración de Ruteo SD-WAN de Cisco, Cisco IOS XE Release 17.x - Configuración de OMP con CLI

- Guía de Configuración de IP Routing: BGP

- Configuración de Unicast Overlay Routing

- Referencia de Comandos de Cisco SD-WAN - overlay-as

- Soporte Técnico y Documentación - Cisco Systems