Evite el loop de ruteo BGP-OMP en la superposición SD-WAN en sitios doblemente conectados con dos routers

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