Evite o loop de roteamento BGP-OMP na sobreposição de SD-WAN em locais de hospedagem dupla com dois roteadores

Introdução

Este documento descreve como evitar um loop de roteamento na estrutura SD-WAN quando o roteamento Border Gateway Protocol (BGP) e o Site of Origin (SoO) são usados.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Compreensão básica do Protocolo de Gerenciamento de Sobreposição (OMP - Overlay Management Protocol)
• Compreensão básica do BGP
• Componentes SD-WAN e interação entre eles

Componentes Utilizados

Para fins de demonstração, foram usados os seguintes roteadores de software:

• 3 roteadores Cisco IOS^® XE CSR1000v com Software Release 17.2.1v que são executados no modo de controlador (SD-WAN)
• 2 roteadores Cisco IOS XE CSR1000v com Software Release 16.7.3

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Para os fins deste documento, esta topologia é usada:

Topologia

R1 e R2 são roteadores genéricos Cisco IOS XE (ou qualquer outro roteador capaz de executar BGPv4). cE1, cE2 e cE3 executam o Cisco IOS XE no modo de controlador (SD-WAN). Aqui você pode encontrar um resumo dos parâmetros de identificação do local e IP do sistema atribuídos a cada roteador SD-WAN:

roteador SD-WAN	ID do site	system-ip
CE1	214	192.168.30.214
CE2	215	192.168.30.215
cE3	216	192.168.30.216

Aqui está um conjunto de eventos que ocorreram inicialmente:

1. R1 e R2 estabelecem o peering de eBGP correspondentemente com cE1, cE2 e cE3. cE1 e cE2 estabelecem o peering de iBGP.
2. R2 origina a rota BGP 10.1.1.0/24 e a anuncia via eBGP para cE3.
3. O cE3 recebe essa rota BGP no lado do serviço na família de endereços VRF 1 e depois redistribui essa rota no OMP.
4. O cE3 anuncia a rota 10.1.1.0/24 OMP para a sobreposição SD-WAN (os controladores vSmart são responsáveis pela disseminação de informações de roteamento através do protocolo OMP para todos os outros roteadores Edge unidos à sobreposição SD-WAN).
5. cE1 e cE2 recebem a rota OMP e a redistribuem via eBGP no VRF 1 para R1.

Configuração

Aqui está a configuração relevante de cE1. Observe que não send-comminity está configurado para o vizinho 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
  ! 

Verificar

1. No estado inicial, a rota é anunciada a partir de cE3 e aprendida por cE1 e cE2 através do OMP. Ambos redistribuem a rota para o BGP e anunciam um ao outro e ao 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. A interface WAN é desconectada ou a conectividade com a estrutura SD-WAN é perdida em cE2, portanto os peers OMP (conexões vSmart) ficam inoperantes. Apenas uma rota permanece aprendida do iBGP:



ce2(config)#

interface GigabitEthernet 2

ce2(config-if)#

fechamento

ce2(config-if)#

fim

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 ainda prefere a rota via OMP (essa é a única rota que resta) 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. A conectividade na interface WAN de cE2 é estabelecida novamente. A rota ainda é preferida de cE1 via iBGP devido à melhor distância administrativa (AD).



ce2(config)#

interface GigabitEthernet 2

ce2(config-if)#

no shutdown

ce2(config-if)#

fim

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 ainda prefere a rota via OMP originada por cE3. Tenha em mente que cE1 redistribui OMP no 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 acontece com a conectividade de cE3 com R2. Para testar, a interface é desativada e o peer de BGP de R2 é perdido:



ce3(config)#

interface GigabitEthernet 6

ce3(config-if)#

fechamento

ce3(config-if)#

consolidação

5. Como resultado, o loop de roteamento é formado entre cE1 e cE2 (cE2 redistribui a rota de OMP e anuncia para cE1 via BGP, cE1 redistribui BGP para OMP e anuncia para 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

Troubleshooting

Há duas soluções possíveis.

Solução 1

Configure overlay-as para OMP. Em seguida, algum número de sistema autônomo (AS) é atribuído à própria sobreposição de OMP. Por exemplo:



config-transaction
 sdwan
  omp
   overlay-as 64512
   exit

Por padrão, o OMP é transparente para o BGP, mesmo que propagate-aspath esteja configurado. overlay-as é um recurso que precede AS especificado como um parâmetro deste comando para o atributo BGP AS_PATH das rotas exportadas do OMP para o BGP. Se você configurar o mesmo número AS de sobreposição em vários dispositivos na rede de sobreposição, todos esses dispositivos serão considerados parte do mesmo AS. Como resultado, eles não encaminham nenhuma rota que contenha o número AS de sobreposição, portanto, o loop de roteamento é impedido.

Lembre-se disso overlay-as e propagate-aspath são dependentes um do outro. Esse recurso é discutido em detalhes.

Há dois casos:

Overlay-AS - Caso 1

overlay-as configurado no nível global sob sdwan omp seção e não propagate-aspath está configurado (a configuração de resto é a mesma descrita inicialmente: advertise bgp é habilitada sob omp address-family ipv4 vrf 1 seção, redistribute omp configurada sob router bgp <AS> address-family ipv4 vrf 1 seção).

overlay-as 64512, configurado em cE1/cE2 e cE3.

Topologia para demonstração de sobreposição como

Para fins de demonstração, BGP AS em cE1, cE2 e cE3 mudou.

R1 - cE1/cE2 ainda peer via eBGP, AS 65300 e 65401 são usados, respectivamente.

cE3 - R2 ainda peer via eBGP, AS 65402 e 65500 são usados, respectivamente.

R1 envia a rota (por exemplo, 192.168.41.11/32) para cE1/cE2. cE1/cE2 redistribui essa rota no OMP, sem nenhum atributo AS_PATH.

O cE3 o recebe e anuncia no BGP em direção ao R2, apenas com seu próprio AS (comportamento normal do eBGP).

A rota route1 em R2 tem 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 configurada na router bgp seção para a VPN do lado do serviço (address-family ipv4 vrf 1) específica. Aqui estão os sub-casos também.

Caso 2.1. Com overlay-as ativado em cE3, também propagate-aspath é ativado router bgp 65401 address-family ipv4 vrf 1 em cE1/cE2.

R1 envia a rota 1 para cE1/cE2. cE1/cE2 redistribui essa rota no OMP com um as-path que vem do site R1.

A rota OMP no vSmart tem AS-Path: "65300".

vsmart1#

show omp routes vpn 1 192.168.41.11/32 | nômoro | exclude not\ set

--------------------------------------------------- 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. Com propagate-aspath desativado em cE3, cE3 recebe-o como uma rota OMP e anuncia-o no BGP, ignora qualquer atributo as-path, sobrepõe-se como, em direção a R2, e adiciona apenas seu próprio AS BGP (comportamento normal do eBGP).

Route route1 no AS-path de 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. Com propagate-aspath habilitado em cE3, cE3 o recebe como uma rota OMP e o anuncia no BGP, acrescenta o atributo as-path recebido, em direção a R2, em seguida, adiciona o Overlay-AS seguido por seu próprio BGP AS.

Route route1 no AS-path de 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. Com propagate-aspath desativado em cE1/cE2, cE3 recebe-o como uma rota OMP sem nenhum atributo as-path e anuncia-o no BGP, em direção a R2, acrescenta o AS de sobreposição e adiciona apenas seu próprio AS de BGP.

Route route1 no AS-path de 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. Sem overlay-as configurado em cE3, propagate-aspath é habilitado em router bgp 65401 address-family ipv4 vrf 1 em cE1/cE2.

Caso 2.2.a. Com propagate-aspath desativado somente em cE3, cE3 recebe-o como uma rota OMP e anuncia-o no BGP, ignorando qualquer atributo AS_PATH, em direção a R2, adiciona seu próprio AS de BGP (comportamento normal do eBGP).

Route route1 no AS-path de 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 está habilitado em cE3, cE3 a recebe como uma rota OMP e a anuncia no BGP, acrescenta o atributo AS_PATH recebido, em direção a R2 e adiciona seu próprio AS.

Route route1 no AS-path de 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 ?

Ponto importante:

Quando você envia o atributo AS-Path no OMP, o roteador de borda não adiciona seu próprio AS (como demonstrado no artigo vEdge não anuncia seu próprio AS quando as rotas BGP são anunciadas no OMP). Se o roteador de borda remoto receber uma rota OMP com seu próprio AS no atributo AS_PATH, ele não executará a detecção de loop e enviará a rota com o caminho AS recebido para o roteador no lado do serviço.

Solução 2

Configure o mesmo site-id nos roteadores cE1 e cE2. Embora o vSmart anuncie rotas de volta para o site com o mesmo site-id como na própria rota, já que o atributo originador da rota é diferente, a prevenção de loop não é acionada, mas o loop de roteamento do plano de controle não se forma porque a rota OMP não está instalada na RIB. Isso ocorre porque a rota OMP permanece no estado Inv,U (Invalid,Unresolve). Por padrão, os túneis de plano de dados não podem ser estabelecidos entre locais que tenham o mesmo ID de local, a menos que allow-same-site-tunnels esteja configurado. Se a sessão BFD do túnel do plano de dados estiver no estado inativo, o TLOC permanecerá sem resolução. No exemplo aqui, site-id 214215 foi configurado nos roteadores ce1 e ce2. A rota 10.0.0.2/32 anunciada por cE2 e cE1 não a instala na tabela de roteamento porque não existem sessões de plano de dados entre cE1 e cE2:

ce1#

show sdwan omp route 10.0.0.2/32 det | exc não definido

--------------------------------------------------- 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" | exclude não definido

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

Você pode verificar esse comando no controlador vSmart para entender quais rotas recebem o prefixo específico (consulte a seção "ADVERTISED TO"):

vsmart1#

show omp routes 10.1.1.0/24 detail | nômoro | exclude not\ set

--------------------------------------------------- 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 também é preservado como atributo de comunidade estendida (SoO) de site-of-origem (você pode observar SoO:0:<site-id> nas saídas anteriores). Isso é usado para identificar rotas que se originaram de um site para que o re-anúncio desse prefixo possa ser evitado. Para que isso funcione corretamente, os roteadores devem enviar comunidades estendidas. Configure cE1 para enviar comunidades estendidas para o roteador cE2:

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

Explicação de prevenção de loop SoO

Para o caso em que dois roteadores no mesmo local são vizinhos de iBGP, a SD-WAN tem um mecanismo de prevenção de loop integrado para impedir um loop de roteamento de OMP para BGP e de volta de BGP para OMP. Para demonstrar isso, a topologia foi ligeiramente atualizada e o mesmo site-id 214215 foi configurado em ambos os roteadores que executam o BGP AS65400 (cE1/cE2). Neste exemplo, um prefixo 10.1.1.0/24 é anunciado no OMP do site remoto (cE3) e aprendido no OMP no Site 214215 (cE1-cE2).

Topologia para demonstração de SoO

Para realizar a prevenção de loop, o SoO da comunidade estendida do BGP é usado para mostrar qual site originou o prefixo. Essa comunidade é adicionada a um prefixo quando é redistribuída do OMP para o BGP.

O send-community <both|extended> comando deve ser configurado na instrução vizinha em ambos os dispositivos como mostrado, para que essa funcionalidade funcione corretamente.

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

A comunidade estendida pode ser vista com a saída de show bgp vpnv4 unicast vrf 1 <prefix> do site de publicidade ou de recepção.

Exemplo:

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

No roteador que anuncia o prefixo do OMP para o BGP (cEdge1 neste exemplo), somente a rota OMP deve estar presente no RIB.

Exemplo:

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

No entanto, pode acontecer que uma condição de corrida ocorra no segundo roteador que recebe o prefixo anunciado e faz com que a rota BGP seja instalada no RIB antes que a rota OMP seja aprendida.

No cEdge2, a saída de sh bpg vpnv4 unicast vrf 1 <prefixo> mostra:

1. Não anunciado a nenhum colega.
2. A Comunidade Estendida inclui o 214215 site-id, que é o mesmo local em que esse roteador está.

Exemplo:

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

Em cEdge2, a saída de sh ip route vrf <vrf_number> <prefix> mostra:

1. O sinalizador "SDWAN inoperante" é visto para mostrar que foi detectado que ele se originou no mesmo site.
2. A distância administrativa da rota é 252 (maior que OMP e diferente do iBGP AD 200 esperado).

Exemplo:

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 

Desativação da SDWAN

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

Quando um roteador de site detecta que uma rota BGP aprendida se origina do mesmo site-id, a rota não é anunciada de volta no OMP.

Informações Relacionadas

• O vEdge não anuncia seu próprio AS quando as rotas BGP são anunciadas no OMP
• Guia de configuração de roteamento SD-WAN da Cisco, Cisco IOS XE versão 17.x - Configurar o OMP usando CLI
• Roteamento IP: Guia de configuração do BGP
• Configurando o roteamento de sobreposição de unicast
• Referência de comandos do Cisco SD-WAN - sobreposição como
• Suporte Técnico e Documentação - Cisco Systems