Resolver Loop de Roteamento BGP-OMP quando o Roteamento BGP e SoO Forem Usados

Opções de download

PDF (655.1 KB)
Ver no Adobe Reader em vários dispositivos
ePub (500.5 KB)
Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
Mobi (Kindle) (307.8 KB)
Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos

Atualizado:17 de maio de 2024

ID do documento:215992

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Informações de Apoio

Configuração

Verificar

Troubleshooting

Solução 1

Overlay-AS - Caso 1

Overlay-AS - Caso 2

Solução 2

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

Informações Relacionadas

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

As informações neste documento são baseadas nestas versões de software e hardware:

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 para demonstração 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:

R1 e R2 estabelecem o peering de eBGP correspondentemente com cE1, cE2 e cE3. cE1 e cE2 estabelecem o peering de iBGP.
R2 origina a rota BGP 10.1.1.0/24 e a anuncia via eBGP para cE3.
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.
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).
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)#
shutdown
ce2(config-if)#
end
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 still prefers the route via OMP (this is the only route that remains) originated by 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)#
end
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)#
shutdown
ce3(config-if)#
commit

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.

Existem 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 | nomore | 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.

Roteie route1 no AS-path de R2: 6540264512.

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.

Roteie route1 no AS-path de R2: 6540265300.

R2#

sh ip bgp | i 192.168.41.11/32

 *> 192.168.41.11/32 192.168.60.216 1000 0 65402 65300 ?

 
       
       Observação: quando você envia o atributo AS-Path para o 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 not set

--------------------------------------------------- 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 not set

--------------------------------------------------- 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 | nomore | 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 Isso também é preservado como atributo de comunidade estendida de site de origem (SoO) do BGP (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:

 Não anunciado a nenhum colega.
 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:

 O sinalizador "SDWAN inoperante" é visto para mostrar que foi detectado que ele se originou no mesmo site.
 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 

SDWAN Down
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 downloads da Cisco

Histórico de revisões

Revisão	Data de publicação	Comentários
5.0	17-May-2024	Recertificação
4.0	10-Nov-2022	Versão inicial
3.0	16-Aug-2022	A seção "Explicação de prevenção de loop SoO" foi adicionada.
2.0	04-Nov-2021	Solução 2 atualizada na seção Solução de problemas.
1.0	01-Sep-2020	Versão inicial

Colaboração de

Eugene Khabarov
Engenheiro de escalonamento de SD-WAN da Cisco
Andy Rook
Líder técnico em engenharia de entrega ao cliente da Cisco

Este documento lhe foi útil?

Feedback

Contate a Cisco

Abrir um caso de suporte
(É necessário um Contrato de Serviço da Cisco)

Este documento se refere a estes produtos

SD-WAN

Resolver Loop de Roteamento BGP-OMP quando o Roteamento BGP e SoO Forem Usados

Opções de download

Linguagem imparcial

Sobre esta tradução

Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Informações de Apoio

Configuração

Verificar

Troubleshooting

Solução 1

Overlay-AS - Caso 1

Overlay-AS - Caso 2

Solução 2

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

Informações Relacionadas

Histórico de revisões

Colaboração de

Este documento lhe foi útil?

Contate a Cisco

Este documento se refere a estes produtos

`Verificar`

`Troubleshooting`

`Solução 1`

`Overlay-AS - Caso 1`

`Overlay-AS - Caso 2`

`Solução 2`

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

`Informações Relacionadas`