Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Informações de Apoio

Configuração

Verificar

Troubleshoot

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

Introduction

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.

Prerequisites

Requirements

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. 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 send-comminity não 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 para o outro e para 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

Troubleshoot

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 está configurado. overlay-as é um recurso que precede AS especificado como um parâmetro desse comando para o atributo AS_PATH de BGP das rotas exportadas de OMP para 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.

Tenha em mente que overlay-as e propagate-aspath são dependentes uns dos outros. Esse recurso é discutido em detalhes.

Há dois casos:

Overlay-AS - Caso 1

overlay-as configurados a nível global sob sdwan omp seção e propagate-aspath não está configurado (a configuração restante é a mesma descrita inicialmente: advertise bgp está habilitado em omp address-family ipv4 vrf 1 seção, redistribute omp configurado em router bgp

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 configurado em router bgp para a VPN do lado do serviço em particular (address-family ipv4 vrf 1). Aqui estão os sub-casos também.

Caso 2.1. Com overlay-as ativado em cE3, propagate-aspath também está habilitado em 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 não\ definido

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

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, o cE3 o recebe como uma rota OMP e o anuncia no BGP, ignora qualquer atributo as-path, sobrepõe as, em direção a R2 e adiciona apenas 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.1.b. Com propagate-aspath ativado em cE3, o cE3 o recebe como uma rota OMP e o anuncia no BGP, acrescenta o atributo as-path recebido, em direção ao R2 e 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 desabilitado em cE1/cE2, cE3 o recebe como uma rota OMP sem nenhum atributo as-path e o anuncia no BGP, em direção a R2, acrescenta o Overlay-AS e adiciona apenas seu próprio AS do 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 está ativado no roteador bgp 65401 address-family ipv4 vrf 1 em cE1/cE2.

Caso 2.2.a. Com propagate-aspath desativado apenas em cE3, o cE3 o recebe como uma rota OMP e o anuncia 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 estiver habilitado em cE3, cE3 a receberá como uma rota OMP e a anunciará no BGP, anexará o atributo AS_PATH recebido, em direção a R2 e adicionará 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 está 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" | excluir 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 não\ definido

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

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

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

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

No cEdge2, a saída de sh ip route vrf

mostra o seguinte:

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