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.
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.
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.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software e hardware:
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.
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:
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
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 |