Entender e solucionar problemas de controle de rota em implantações de SD-WAN de firewall seguro

Opções de download

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

Atualizado:1 de outubro de 2025

ID do documento:225111

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

Este documento descreve o controle de roteamento no BGP para VPNs baseadas em rota usando o Cisco SD-WAN no firewall seguro.

Pré-requisitos

Requisitos

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

IKEv2
VPN de rota
Interfaces de túnel virtual (VTI)
IPsec
BGP
Atributos de BGP como tags de comunidade e refletores de rota
Recurso SD-WAN em firewall seguro

Componentes Utilizados

As informações neste documento são baseadas em:

Cisco Secure Firewall Threat Defense 7.7.10
Cisco Secure Firewall Management Center 7.7.10

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 recurso

Com a nova implantação de SD-WAN para VPN baseada em rota de site a site com BGP habilitado para a sobreposição, a Cisco se concentra nos principais atributos de BGP para implementar o roteamento de sobreposição seguro e sem loops, garantindo que as redes de sobreposição e de subposição permaneçam segregadas em toda a topologia. Essa implantação também garante que nenhuma intervenção manual seja necessária para ajustar os atributos relevantes.

Cenário de implantação

Selecione uma topologia que inclua conexões iBGP e eBGP entre o HUB e o spoke. Essa abordagem oferece visibilidade máxima dos controles de roteamento implementados como parte da solução SD-WAN nos Cisco Secure Firewalls.

HUB duplo e spoke com ISP duplo

Topologia Subjacente

Underlay Topology

Topologia de sobreposição

Overlay Topology

Configuração

Como o objetivo principal deste documento é fornecer uma compreensão clara do controle de roteamento implementado como parte da implantação da SD-WAN no Secure Firewall, as etapas básicas de configuração necessárias para implantar a topologia não são revisitadas novamente. Para obter orientação detalhada sobre a configuração inicial, consulte nosso documento publicado anteriormente Configure SD-WAN for Site-to-Site VPN over Secure Firewall.

Todas as configurações na seção CLI são aplicadas por meio do assistente de configuração de SD-WAN. Nenhuma alteração ou modificação é feita separadamente à configuração BGP ou a qualquer configuração de mapa de rota.

Configuration

Verificar e solucionar problemas

A lista de comunidades é responsável por filtrar prefixos de entrada e saída. Uma explicação detalhada pode ser encontrada na seção Lista de comunidades da documentação da Cisco no Guia de configuração de dispositivos do Cisco Secure Firewall Management Center.

Configuração comum em todos os dispositivos

firepower# show running-config community-list 
community-list standard FMC_VPN_COMMUNITY_101010 permit 101010 <<<<<<<<<<
community-list standard FMC_VPN_COMMUNITY_202020 permit 202020 <<<<<<<<<<

Observe que há um único par de mapas de rota de entrada e saída por topologia, embora as configurações sejam idênticas para ambas as topologias, apenas a convenção de nomenclatura é exclusiva por topologia. Em nosso cenário, FMC_VPN_RMAP_COMMUNITY_IN_858939614 e FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 são para a topologia 1, enquanto FMC_VPN_RMAP_COMMUNITY_IN_8589942200 e FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 são para a topologia 2.

firepower# show running-config route-map

Topology 1
Inbound
route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match

set community 202020 

route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match

Outbound
route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match
set metric 1

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match
set metric 100

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 deny 100

Topology 2
Inbound
route-map FMC_VPN_RMAP_COMMUNITY_IN_8589942200 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match

set community 202020 

route-map FMC_VPN_RMAP_COMMUNITY_IN_8589942200 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match

Outbound
route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match
set metric 1

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match
set metric 100

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 deny 100

Common Across All The Hubs & Spokes Wherever Redistribution Of Inside Network Is Present

route-map FMC_VPN_CONNECTED_DIST_RMAP_101010 permit 10
match interface inside
set community 101010

A configuração de BGP através dos dispositivos na topologia é mostrada:

Spoke1 e 2 (IBGP com HUB1 e EBGP com HUB2)

firepower# show running-config router bgp 
router bgp 65500
bgp log-neighbor-changes
address-family ipv4 unicast
neighbor 198.51.100.1 remote-as 65500 <<<<< tunnel from spokes to HUB 1 via ISP1
neighbor 198.51.100.1 activate
neighbor 198.51.100.1 send-community
neighbor 198.51.100.1 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 in
neighbor 198.51.100.1 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 out
neighbor 198.51.100.2 remote-as 65510 <<<<< tunnel from spokes to HUB 2 via ISP1
neighbor 198.51.100.2 ebgp-multihop 2
neighbor 198.51.100.2 activate
neighbor 198.51.100.2 send-community
neighbor 198.51.100.2 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 in
neighbor 198.51.100.2 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 out
neighbor 198.51.100.3 remote-as 65500 <<<<< tunnel from spokes to HUB 1 via ISP2
neighbor 198.51.100.3 activate
neighbor 198.51.100.3 send-community
neighbor 198.51.100.3 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589942200 in
neighbor 198.51.100.3 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 out
neighbor 198.51.100.4 remote-as 65510 <<<<< tunnel from spokes to HUB 2 via ISP2
neighbor 198.51.100.4 ebgp-multihop 2
neighbor 198.51.100.4 activate
neighbor 198.51.100.4 send-community
neighbor 198.51.100.4 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589942200 in
neighbor 198.51.100.4 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 out
redistribute connected route-map FMC_VPN_CONNECTED_DIST_RMAP_101010 <<<<<<< route-map to redistribute inside network into BGP
maximum-paths 8
maximum-paths ibgp 8
no auto-summary
no synchronization
exit-address-family

HUB1 (Correspondência IBGP com os Spokes)

firepower# show running-config router bgp 
router bgp 65500
bgp log-neighbor-changes
address-family ipv4 unicast
neighbor 198.51.100.10 remote-as 65500 <<<<< tunnel from HUB 1 to Spoke 1 via ISP 1
neighbor 198.51.100.10 activate
neighbor 198.51.100.10 send-community
neighbor 198.51.100.10 route-reflector-client
neighbor 198.51.100.10 next-hop-self
neighbor 198.51.100.10 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 in
neighbor 198.51.100.10 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 out
neighbor 198.51.100.11 remote-as 65500 <<<<< tunnel from HUB 1 to Spoke 2 via ISP 1
neighbor 198.51.100.11 activate
neighbor 198.51.100.11 send-community
neighbor 198.51.100.11 route-reflector-client
neighbor 198.51.100.11 next-hop-self
neighbor 198.51.100.11 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 in
neighbor 198.51.100.11 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 out
neighbor 198.51.100.70 remote-as 65500 <<<<< tunnel from HUB 1 to Spoke 1 via ISP 2
neighbor 198.51.100.70 activate
neighbor 198.51.100.70 send-community
neighbor 198.51.100.70 route-reflector-client
neighbor 198.51.100.70 next-hop-self
neighbor 198.51.100.70 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589942200 in
neighbor 198.51.100.70 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 out
neighbor 198.51.100.71 remote-as 65500 <<<<< tunnel from HUB 1 to Spoke 2 via ISP 2
neighbor 198.51.100.71 activate
neighbor 198.51.100.71 send-community
neighbor 198.51.100.71 route-reflector-client
neighbor 198.51.100.71 next-hop-self
neighbor 198.51.100.71 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589942200 in
neighbor 198.51.100.71 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 out
no auto-summary
no synchronization
exit-address-family

HUB2 (Correspondência EBGP com os Spokes)

firepower# show running-config router bgp 
router bgp 65510
bgp log-neighbor-changes
address-family ipv4 unicast
neighbor 198.51.100.40 remote-as 65500 <<<<< tunnel from HUB 2 to Spoke 1 via ISP 1
neighbor 198.51.100.40 ebgp-multihop 2
neighbor 198.51.100.40 activate
neighbor 198.51.100.40 send-community
neighbor 198.51.100.40 next-hop-self
neighbor 198.51.100.40 as-override
neighbor 198.51.100.40 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 in
neighbor 198.51.100.40 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 out
neighbor 198.51.100.41 remote-as 65500 <<<<< tunnel from HUB 2 to Spoke 2 via ISP 1
neighbor 198.51.100.41 ebgp-multihop 2
neighbor 198.51.100.41 activate
neighbor 198.51.100.41 send-community
neighbor 198.51.100.41 next-hop-self
neighbor 198.51.100.41 as-override
neighbor 198.51.100.41 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 in
neighbor 198.51.100.41 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 out
neighbor 198.51.100.100 remote-as 65500 <<<<< tunnel from HUB 2 to Spoke 1 via ISP 2
neighbor 198.51.100.100 ebgp-multihop 2
neighbor 198.51.100.100 activate
neighbor 198.51.100.100 send-community
neighbor 198.51.100.100 next-hop-self
neighbor 198.51.100.100 as-override
neighbor 198.51.100.100 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589942200 in
neighbor 198.51.100.100 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 out
neighbor 198.51.100.101 remote-as 65500 <<<<< tunnel from HUB 2 to Spoke 2 via ISP 2
neighbor 198.51.100.101 ebgp-multihop 2
neighbor 198.51.100.101 activate
neighbor 198.51.100.101 send-community
neighbor 198.51.100.101 next-hop-self
neighbor 198.51.100.101 as-override
neighbor 198.51.100.101 route-map FMC_VPN_RMAP_COMMUNITY_IN_8589942200 in
neighbor 198.51.100.101 route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 out
no auto-summary
no synchronization
exit-address-family

Topologia de roteamento

Routing Topology

O spoke anuncia sua rede interna, 192.0.2.8/29, no BGP com uma marca de comunidade específica de 101010, conforme configurado no mapa de rota FMC_VPN_CONNECTED_DIST_RMAP_101010.

Spoke1

Spoke1# show bgp community 101010 exact-match <<<< to verify the exact network redistributed into BGP

BGP table version is 4, local router ID is 203.0.113.35
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
*> 192.0.2.8/29     0.0.0.0              0         32768  ? <<<<<<<<<<< local inside network

O spoke modifica o valor da métrica para sua rede interna, 192.0.2.8/29, e o anuncia aos hubs, conforme configurado nos mapas de rota FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 e FMC_VPN_RMAP_COMMUNITY_OUT_858994200.

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match
set metric 1

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match
set metric 100

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 deny 100

O HUB1 aprende a rede Spoke 1 192.0.2.8/29 com a marca de comunidade 101010 e altera a marca de comunidade para 202020, preservando a métrica antes de encaminhá-la para outros spokes, conforme definido nos mapas de rota configurados.

HUB1

Route-Map for ISP1 DVTI
Inbound
route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match
set community 202020

route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match

Outbound
route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match
set metric 1
set ip next-hop 198.51.100.1 <<<<<<<<<< only next-hop is changed in ISP2 tunnel route-map with ISP2 DVTI IP

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match
set metric 100
set ip next-hop 198.51.100.1 <<<<<<<<<< only next-hop is changed in ISP2 tunnel route-map with ISP2 DVTI IP

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 deny 100

Route-Map for ISP2 DVTI
Inbound
route-map FMC_VPN_RMAP_COMMUNITY_IN_8589942200 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match
set community 202020

route-map FMC_VPN_RMAP_COMMUNITY_IN_8589942200 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match

Outbound
route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match
set metric 1
set ip next-hop 198.51.100.3 <<<<<<<<<< only next-hop is changed in ISP2 tunnel route-map with ISP2 DVTI IP

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match
set metric 100
set ip next-hop 198.51.100.3 <<<<<<<<<< only next-hop is changed in ISP2 tunnel route-map with ISP2 DVTI IP

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589942200 deny 100

HUB1# show bgp community 202020 exact-match <<<< this will confirm if received prefixes have community tags flipped

BGP table version is 5, local router ID is 198.51.100.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
* i192.0.2.8/29     198.51.100.70        1    100      0  ?
*>i                 198.51.100.10        1    100      0  ?
* i192.0.2.16/29    198.51.100.71        1    100      0  ?
*>i                 198.51.100.11        1    100      0  ?

HUB1# show bgp 192.0.2.8 <<<< this will display available paths in BGP for the network

BGP routing table entry for 192.0.2.8/29, version 4
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
              1          2
  Local, (Received from a RR-client)
    198.51.100.70 from 198.51.100.70 (203.0.113.35) <<<<< spoke 1 ISP 2 tunnel to HUB 1
      Origin incomplete, metric 1, localpref 100, valid, internal
      Community: 202020
  Local, (Received from a RR-client)
    198.51.100.10 from 198.51.100.10 (203.0.113.35) <<<<< spoke 1 ISP 1 tunnel to HUB 1
      Origin incomplete, metric 1, localpref 100, valid, internal, best
      Community: 202020 <<<<< community updated as per the route-map configured on spoke side

HUB1# show route 192.0.2.8

Routing entry for 192.0.2.8 255.255.255.248
  Known via "bgp 65500", distance 200, metric 1, type internal
  Last update from 198.51.100.10 0:09:18 ago
  Routing Descriptor Blocks:
  * 198.51.100.10, from 198.51.100.10, 0:09:18 ago
      Route metric is 1, traffic share count is 1
      AS Hops 0
      MPLS label: no label string provided

HUB1# show bgp ipv4 unicast neighbors 198.51.100.10 routes <<<<<< to check specific prefixes learnt via ISP1 spoke1 tunnel

BGP table version is 5, local router ID is 198.51.100.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
*>i192.0.2.8/29     198.51.100.10        1    100      0  ? <<< preferred route

Total number of prefixes 1

HUB1# show bgp ipv4 unicast neighbors 198.51.100.70 routes <<<<<< to check specific prefixes learnt via ISP2 spoke1 tunnel

BGP table version is 5, local router ID is 198.51.100.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
* i192.0.2.8/29     198.51.100.70        1    100      0  ?

Total number of prefixes 1

O HUB2 também aprende a rede Spoke 1 192.0.2.8/29 com a marca de comunidade 101010 e altera a marca de comunidade para 202020 e atualizar a métrica para 100 antes de encaminhá-la para outros spokes, conforme especificado nos mapas de rota configurados. Essa alteração de métrica entra em vigor devido ao peering eBGP. Isso ocorre porque o MED (Multi-Exit Discriminator) é um atributo BGP opcional, não transitivo usado para influenciar o tráfego de entrada, sugerindo um ponto de entrada preferido em um AS. O MED geralmente não é propagado entre peers iBGP dentro do mesmo AS e, em vez disso, anunciado para peers BGP externos (eBGP) em sistemas autônomos diferentes.

HUB2

HUB2# show bgp community 202020 exact-match <<<< this will confirm if receieved prefixes have community tags flipped

BGP table version is 5, local router ID is 198.51.100.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
*  192.0.2.8/29     198.51.100.1       100             0  65500 ? <<<<<< advertised back by spoke 2 ISP1 to HUB2 previously learnt via HUB1 iBGP
*                   198.51.100.1       100             0  65500 ? <<<<<< advertised back by spoke 2 ISP2 to HUB2 previously learnt via HUB1 iBGP
*                   198.51.100.100       1             0  65500 ? <<<<<< advertised by spoke 2 ISP tunnel
*>                  198.51.100.40        1             0  65500 ? <<<<<< advertised and preferred by spoke 1 ISP 1 tunnel
*  192.0.2.16/29    198.51.100.1       100             0  65500 ?
*                   198.51.100.1       100             0  65500 ?
*                   198.51.100.101       1             0  65500 ?
*>                  198.51.100.41        1             0  65500 ?

HUB2# show bgp 192.0.2.8 <<<< this will display available paths in BGP for the network

BGP routing table entry for 192.0.2.8/29, version 4
Paths: (4 available, best #4, table default)
  Advertised to update-groups:
              1          2
  65500 
    198.51.100.1 (inaccessible) from 198.51.100.41 (203.0.113.36) <<<<<< advertised back by spoke 2 ISP1 to HUB2 previously learnt via HUB1 iBGP
      Origin incomplete, metric 100, localpref 100, valid, external
      Community: 202020
  65500 
    198.51.100.1 (inaccessible) from 198.51.100.101 (203.0.113.36) <<<<<< advertised back by spoke 2 ISP2 to HUB2 previously learnt via HUB1 iBGP
      Origin incomplete, metric 100, localpref 100, valid, external
      Community: 202020
  65500 
    198.51.100.100 from 198.51.100.100 (203.0.113.35) <<<<<< advertised by spoke 1 ISP 2 tunnel
      Origin incomplete, metric 1, localpref 100, valid, external
      Community: 202020
  65500 
    198.51.100.40 from 198.51.100.40 (203.0.113.35) <<<<<< advertised and preferred by spoke 1 ISP 1 tunnel
      Origin incomplete, metric 1, localpref 100, valid, external, best
      Community: 202020

HUB2# show bgp ipv4 unicast neighbors 198.51.100.40 routes <<<<<< to check specific prefixes learnt via ISP1 spoke1 tunnel

BGP table version is 5, local router ID is 198.51.100.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path 
*> 192.0.2.8/29     198.51.100.40        1             0  65500 ? <<<< preferred
*  192.0.2.16/29    198.51.100.1       100             0  65500 ?

Total number of prefixes 2

HUB2# show bgp ipv4 unicast neighbors 198.51.100.41 routes <<<<<< to check specific prefixes learnt via ISP1 spoke2 tunnel

BGP table version is 5, local router ID is 198.51.100.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
*  192.0.2.8/29     198.51.100.1       100             0  65500 ? <<<<<<
*> 192.0.2.16/29    198.51.100.41        1             0  65500 ?

Total number of prefixes 2

HUB2# show bgp ipv4 unicast neighbors 198.51.100.100 routes <<<<<< to check specific prefixes learnt via ISP2 spoke1 tunnel

BGP table version is 5, local router ID is 198.51.100.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
*  192.0.2.8/29     198.51.100.100       1             0  65500 ? <<<<<<
*  192.0.2.16/29    198.51.100.1       100             0  65500 ?

Total number of prefixes 2

HUB2# show bgp ipv4 unicast neighbors 198.51.100.101 routes <<<<<< to check specific prefixes learnt via ISP2 spoke2 tunnel

BGP table version is 5, local router ID is 198.51.100.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
*  192.0.2.8/29     198.51.100.1       100             0  65500 ? <<<<<<
*  192.0.2.16/29    198.51.100.101       1             0  65500 ?

Total number of prefixes 2

Spoke 2 recebe a rede Spoke 1 192.0.2.8/29 dos túneis ISP1 e ISP2 HUB1 com métrica 1, enquanto recebe a mesma rede dos túneis ISP1 HUB2 e ISP2 HUB2 com um próximo salto atualizado de HUB1.

Spoke 2

Spoke2# show bgp community 202020 exact-match <<<< this will confirm if receieved prefixes have community tags flipped

BGP table version is 8, local router ID is 203.0.113.36
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
*mi192.0.2.8/29     198.51.100.3         1    100      0  ?
*>i                 198.51.100.1         1    100      0  ? <<<< HUB1 ISP1 route preferred
*                   198.51.100.2       100             0  65510 65510 ?
*                   198.51.100.4       100             0  65510 65510 ?
*  192.0.2.16/29    198.51.100.4       100             0  65510 65510 ?
*                   198.51.100.2       100             0  65510 65510 ?

route-map FMC_VPN_RMAP_COMMUNITY_IN_8589939614 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match

set community 202020

route-map FMC_VPN_RMAP_COMMUNITY_IN_8589956263 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match

O spoke 2 também anuncia redes aprendidas do HUB1 de volta para o HUB2, conforme definido pelo mapa de rota de saída configurado, com a métrica atualizada.

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 permit 10
match community FMC_VPN_COMMUNITY_101010 exact-match
set metric 1

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 permit 20
match community FMC_VPN_COMMUNITY_202020 exact-match
set metric 100 <<<<<

route-map FMC_VPN_RMAP_COMMUNITY_OUT_8589939614 deny 100

Spoke2# show bgp ipv4 unicast neighbors 198.51.100.2 advertised-routes <<<<< to check specific prefixes advertised via ISP1 HUB2 tunnel back to HUB2

BGP table version is 8, local router ID is 203.0.113.36
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
*>i192.0.2.8/29     198.51.100.1         1    100      0  ? <<<<<<<
*> 192.0.2.16/29    0.0.0.0              0         32768  ?

Total number of prefixes 2

Spoke2# show bgp ipv4 unicast neighbors 198.51.100.4 advertised-routes <<<<< to check specific prefixes advertised via ISP2 HUB2 tunnel back to HUB2

BGP table version is 8, local router ID is 203.0.113.36
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
*>i192.0.2.8/29     198.51.100.1         1    100      0  ? <<<<<<<
*> 192.0.2.16/29    0.0.0.0              0         32768  ?

Total number of prefixes 2

Conclusão

A finalidade deste documento é fornecer um passo a passo da implantação de roteamento de back-end, com foco nos controles de roteamento implementados dentro do BGP para garantir tanto a contingência quanto a redundância.

Em resumo, o spoke 2, assim como qualquer outro spokes na topologia, usa a mesma abordagem ao anunciar suas redes no domínio BGP. O controle de roteamento mais importante nesse cenário é a filtragem de lista de comunidade, que garante que somente as redes dentro dessa topologia sejam anunciadas a outros peers, evitando a propagação de rede não intencional.

Além disso, o atributo MED Multi-exit Discriminator é usado para influenciar a seleção de rotas para peers eBGP, garantindo que as rotas aprendidas através do peer iBGP configurado como o HUB primário tenham preferência sobre os prefixos aprendidos do HUB secundário através do eBGP.

Ao fazer ajustes de topologia, como configurar o iBGP para o HUB secundário, você pode eliminar a necessidade de manipulação MED e mapas de rota de entrada que invertam as tags de comunidade antes de anunciar a mesma rede para outros spokes.

Informações Relacionadas

Para obter assistência adicional, entre em contato com o TAC. É necessário um contrato de suporte válido:Cisco Worldwide Support Contacts.
Você também pode visitar a Cisco VPN Community para obter informações adicionais e discussões sobre tendências.

Histórico de revisões

Revisão	Data de publicação	Comentários
1.0	01-Oct-2025	Versão inicial

Colaborado por engenheiros da Cisco

Daniyal Akhtar
Engenheiro de consultoria técnica

Este documento lhe foi útil?

Feedback

Contate a Cisco

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