Exemplo de configuração de hub duplo FlexVPN HA

Introduction

Este documento descreve como configurar um design de redundância total para escritórios remotos que se conectam a um data center via VPN baseada em IPSec sobre um meio de rede inseguro, como a Internet.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nestes componentes de tecnologia:

• Border Gateway Protocol (BGP) como o protocolo de roteamento no data center e entre spokes e hubs na sobreposição VPN.
  
  
• Bidirectional Forwarding Detection (BFD) como um mecanismo que detecta links inativos (roteador inoperante) que são executados somente dentro do data center (não nos túneis de sobreposição).
  
  
• Cisco IOS^® FlexVPN entre hubs e spokes, com recursos spoke-to-spoke ativados por meio de switching de atalho.
  
  
• Encapsulamento de roteamento genérico (GRE) entre dois hubs para permitir a comunicação spoke-to-spoke, mesmo quando os spokes estão conectados a hubs diferentes.
  
  
• Rastreamento aprimorado de objetos e rotas estáticas vinculadas aos objetos rastreados.

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. If your network is live, make sure that you understand the potential impact of any command.

Informações de Apoio

Ao projetar soluções de acesso remoto para o data center, a alta disponibilidade (HA) é frequentemente um requisito importante para aplicativos de usuário críticos.

A solução apresentada neste documento permite detecção e recuperação rápidas de cenários de falha nos quais um dos hubs de terminação de VPN fica inativo devido a problemas de recarga, atualização ou alimentação. Todos os roteadores de escritórios remotos (spokes) usam o outro hub operacional imediatamente após a detecção de tal falha.

Aqui estão as vantagens deste projeto:

• Recuperação rápida da rede a partir de um cenário de hub VPN
  
  
• Não há sincronizações com informações de estado complicadas (como Associações de Segurança IPSec (SAs), SAs de Internet Security Association and Key Management Protocol (ISAKMP) e roteamento de criptografia) entre os hubs VPN
  
  
• Nenhum problema de anti-repetição devido a atrasos na sincronização do número de sequência de Encapsulating Security Payload (ESP) com IPSec Stateful HA
  
  
• Os hubs VPN podem usar diferentes hardwares ou softwares baseados no Cisco IOS/IOS-XE
  
  
• Opções flexíveis de implementação de balanceamento de carga com o BGP como o protocolo de roteamento executado na sobreposição de VPN
  
  
• Roteamento claro e legível em todos os dispositivos sem mecanismos ocultos executados em segundo plano
  
  
• Conectividade direta spoke-to-spoke
  
  
• Todas as vantagens da FlexVPN, incluindo integração de Autenticação, Autorização e Contabilidade (AAA - Authentication, Authorization, and Accounting) e Qualidade de Serviço (QoS - Quality of Service) por túnel

Configurar

Esta seção fornece exemplos de cenários e descreve como configurar um design de redundância total para escritórios remotos que se conectam ao data center via VPN baseada em IPSec sobre um meio de rede inseguro.

Note: Use a Command Lookup Tool ( somente clientes registrados) para obter mais informações sobre os comandos usados nesta seção.

Diagrama de Rede

Esta é a topologia de rede usada neste documento:

Note: Todos os roteadores usados nessa topologia executam o Cisco IOS versão 15.2(4)M1 e o Internet Cloud usa um esquema de endereços de 172.16.0.0/24.

Cenário operacional regular

Em um cenário operacional normal, quando todos os roteadores estão ativos e operacionais, todos os roteadores spoke roteiam todo o tráfego através do hub padrão (R1-HUB1). Essa preferência de roteamento é obtida quando a preferência local de BGP padrão é definida como 200 (consulte as seções a seguir para obter detalhes). Isso pode ser ajustado com base nos requisitos de implantação, como o balanceamento de carga de tráfego.

Spoke-to-Spoke (Atalho)

Se R3-Spoke1 inicia uma conexão com R4-Spoke2, um túnel spoke-to-spoke dinâmico é criado com a configuração de switching de atalho. 

Tip: Para obter mais detalhes, consulte o guia de configuração Configuring FlexVPN Spoke to Spoke.

Se R3-Spoke1 estiver conectado apenas a R1-HUB1 e R4-Spoke2 estiver conectado apenas a R2-HUB2, uma conexão direta spoke-to-spoke ainda poderá ser obtida com o túnel GRE ponto-a-ponto executado entre os hubs. Nesse caso, o caminho de tráfego inicial entre R3-Spoke1 e R4-Spoke2 é semelhante a este:

Como o R1-Hub1 recebe o pacote na interface de acesso virtual, que tem o mesmo ID de rede do Next Hop Resolution Protocol (NHRP) que o do túnel GRE, a indicação de tráfego é enviada para o R3-Spoke1. Isso aciona a criação de túnel dinâmico spoke-to-spoke:

Tabelas de roteamento e saídas para um cenário operacional regular

Esta é a tabela de roteamento R1-HUB1 em um cenário operacional regular:

R1-HUB1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 11 subnets, 3 masks
S        10.0.0.0/8 is directly connected, Null0
C        10.0.0.0/24 is directly connected, Tunnel0
L        10.0.0.1/32 is directly connected, Tunnel0
C        10.0.1.1/32 is directly connected, Loopback0
S        10.0.1.2/32 is directly connected, Virtual-Access1
S        10.0.1.3/32 is directly connected, Virtual-Access2
B        10.0.2.1/32 [200/0] via 10.0.0.2, 00:05:40
B        10.0.2.3/32 [200/0] via 10.0.0.2, 00:05:40
B        10.0.2.4/32 [200/0] via 10.0.0.2, 00:05:40
B        10.0.5.1/32 [200/0] via 192.168.0.5, 00:05:40
B        10.0.6.1/32 [200/0] via 192.168.0.6, 00:05:40
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.0.0/24 is directly connected, Ethernet0/0
L        172.16.0.1/32 is directly connected, Ethernet0/0
S     192.168.0.0/16 is directly connected, Null0
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, Ethernet0/2
L        192.168.0.1/32 is directly connected, Ethernet0/2
B     192.168.1.0/24 [200/0] via 192.168.0.5, 00:05:40
B     192.168.3.0/24 [200/0] via 10.0.1.4, 00:05:24
B     192.168.4.0/24 [200/0] via 10.0.1.5, 00:05:33

Esta é a tabela de roteamento R3-SPOKE1 em um cenário operacional regular após a criação do túnel spoke-to-spoke com R4-SPOKE2:

R3-SPOKE1#  show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
B        10.0.0.0/8 [200/0] via 10.0.1.1, 00:06:27
H        10.0.0.1/32 is directly connected, 00:06:38, Tunnel1
S   %    10.0.1.1/32 is directly connected, Tunnel0
C        10.0.1.3/32 is directly connected, Tunnel0
H        10.0.1.4/32 is directly connected, 00:01:30, Virtual-Access1
S        10.0.2.1/32 is directly connected, Tunnel1
C        10.0.2.3/32 is directly connected, Tunnel1
H        10.0.2.4/32 [250/1] via 10.0.2.3, 00:01:30, Virtual-Access1
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.0.0/24 is directly connected, Ethernet0/0
L        172.16.0.3/32 is directly connected, Ethernet0/0
B     192.168.0.0/16 [200/0] via 10.0.1.1, 00:06:27
      192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.3.0/24 is directly connected, Ethernet0/1
L        192.168.3.3/32 is directly connected, Ethernet0/1
      192.168.4.0/32 is subnetted, 1 subnets
H        192.168.4.4 [250/1] via 10.0.1.3, 00:01:30, Virtual-Access1

Em R3-Spoke1, a tabela BGP tem duas entradas para a rede 192.168.0.0/16 com preferências locais diferentes (R1-Hub1 é o preferido):

R3-SPOKE1#show ip bgp 192.168.0.0/16
BGP routing table entry for 192.168.0.0/16, version 8
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.0.2.1 from 10.0.2.1 (10.0.2.1)
      Origin incomplete, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  Local
    10.0.1.1 from 10.0.1.1 (10.0.1.1)
      Origin incomplete, metric 0, localpref 200, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

Esta é a tabela de roteamento R5-AGGR1 em um cenário operacional regular:

R5-LAN1#show ip route
      10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
B        10.0.0.0/8 [200/0] via 192.168.0.1, 00:07:22
B        10.0.0.0/24 [200/0] via 192.168.0.1, 00:07:22
B        10.0.1.1/32 [200/0] via 192.168.0.1, 00:07:22
B        10.0.1.3/32 [200/0] via 192.168.0.1, 00:07:17
B        10.0.1.4/32 [200/0] via 192.168.0.1, 00:07:16
B        10.0.2.1/32 [200/0] via 192.168.0.2, 15:44:13
B        10.0.2.3/32 [200/0] via 192.168.0.2, 15:44:13
B        10.0.2.4/32 [200/0] via 192.168.0.2, 15:44:13
C        10.0.5.1/32 is directly connected, Loopback0
B        10.0.6.1/32 [200/0] via 192.168.0.6, 00:07:22
      172.16.0.0/24 is subnetted, 1 subnets
B        172.16.0.0 [200/0] via 192.168.0.1, 00:07:22
B     192.168.0.0/16 [200/0] via 192.168.0.1, 00:07:22
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, Ethernet0/0
L        192.168.0.5/32 is directly connected, Ethernet0/0
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, Ethernet0/1
L        192.168.1.5/32 is directly connected, Ethernet0/1
B     192.168.3.0/24 [200/0] via 10.0.1.3, 00:07:06
B     192.168.4.0/24 [200/0] via 10.0.1.4, 00:07:15

Esta é a tabela de roteamento R7-HOST em um cenário operacional regular:

R7-HOST#show ip route
S*    0.0.0.0/0 [1/0] via 192.168.1.254
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, Ethernet0/0
L        192.168.1.7/32 is directly connected, Ethernet0/0

Cenário de falha de HUB1

Este é um cenário de inatividade de R1-HUB1 (devido a ações como falta de energia ou atualização):

Neste cenário, esta sequência de eventos ocorre:

1. O BFD em R2-HUB2 e nos roteadores agregados de LAN R5-AGGR1 e R6-AGGR2 detectam o status de inatividade de R1-HUB1. Como resultado, a vizinhança do BGP cai imediatamente.
   
   
2. A detecção de objeto de trilha para R2-HUB2 que detecta a presença do loopback R1-HUB1 cai (Track 1 na configuração de exemplo).
   
   
3. Este objeto rastreado inativo aciona outra faixa para subir (NÃO lógico). Neste exemplo, o Track 2 aumenta sempre que o Track 1 cai.
   
   
4. Isso aciona uma entrada de roteamento IP estático a ser adicionada à tabela de roteamento devido a um valor inferior à distância administrativa padrão. Esta é a configuração relevante:
   
   

   ! Routes added when second HUB is down
   ip route 10.0.0.0 255.0.0.0 Null0 tag 500 track 2
   ip route 192.168.0.0 255.255.0.0 Null0 tag 500 track 2
   
   ! Default static routes are with Tag 200 and admin distance of 150
   ip route 10.0.0.0 255.0.0.0 Null0 150 tag 200
   ip route 192.168.0.0 255.255.0.0 Null0 150 tag 200

5. R2-HUB2 redistribui essas rotas estáticas com uma preferência local de BGP maior que o valor definido para R1-HUB1. Neste exemplo, uma preferência local de 500 é usada no cenário de falha, em vez do 200 definido por R1-HUB1:
   
   

   route-map LOCALPREF permit 5
    match tag 500
    set local-preference 500
   !
   route-map LOCALPREF permit 10
    match tag 200
    set local-preference 200
   !

   
   Em R3-Spoke1, você pode ver isso nas saídas de BGP. Observe que a entrada para R1 ainda existe, mas não é usada:
   
   

   R3-SPOKE1#show ip bgp 192.168.0.0/16
   BGP routing table entry for 192.168.0.0/16, version 10
   Paths: (2 available, best #1, table default)
     Not advertised to any peer
     Refresh Epoch 1
     Local
       10.0.2.1 from 10.0.2.1 (10.0.2.1)
         Origin incomplete, metric 0, localpref 500, valid, internal, best
         rx pathid: 0, tx pathid: 0x0
     Refresh Epoch 1
     Local
       10.0.1.1 from 10.0.1.1 (10.0.1.1)
         Origin incomplete, metric 0, localpref 200, valid, internal
         rx pathid: 0, tx pathid: 0

   
   
6. Nesse ponto, ambos os spokes (R3-Spoke1 e R4-Spoke2) começam a enviar tráfego para R2-HUB2. Todas essas etapas devem ocorrer em um segundo. Aqui está a tabela de roteamento no Spoke 3:
   
   

   R3-SPOKE1#show ip route
         10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
   B        10.0.0.0/8 [200/0] via 10.0.2.1, 00:00:01
   S        10.0.1.1/32 is directly connected, Tunnel0
   C        10.0.1.3/32 is directly connected, Tunnel0
   S        10.0.2.1/32 is directly connected, Tunnel1
   C        10.0.2.3/32 is directly connected, Tunnel1
         172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
   C        172.16.0.0/24 is directly connected, Ethernet0/0
   L        172.16.0.3/32 is directly connected, Ethernet0/0
   B     192.168.0.0/16 [200/0] via 10.0.2.1, 00:00:01
         192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks
   C        192.168.3.0/24 is directly connected, Ethernet0/1
   L        192.168.3.3/32 is directly connected, Ethernet0/1

7. Sessões BGP posteriores entre os spokes e R1-HUB1 ficam inoperantes e a Detecção de Peer Dead (DPD) remove os túneis IPSec terminados em R1-HUB1. No entanto, isso não afeta o encaminhamento de tráfego, já que R2-HUB2 já é usado como o gateway de terminação de túnel principal:
   
   

   R3-SPOKE1#show ip bgp 192.168.0.0/16
   BGP routing table entry for 192.168.0.0/16, version 10
   Paths: (1 available, best #1, table default)
     Not advertised to any peer
     Refresh Epoch 1
     Local
       10.0.2.1 from 10.0.2.1 (10.0.2.1)
         Origin incomplete, metric 0, localpref 500, valid, internal, best
         rx pathid: 0, tx pathid: 0x0

Configurações

Esta seção fornece configurações de exemplo para os hubs e spokes usados nesta topologia.

Configuração do R1-HUB

version 15.4
!
hostname R1-HUB1
!
aaa new-model
!
aaa authorization network default local 
!
aaa session-id common
!
! setting track timers to the lowest possible (the lower this value is
! the faster router will react
track timer ip route msec 500
!
! Monitoring of HUB2's loopback present in routing table
! If it is present it will mean that HUB2 is alive
track 1 ip route 10.0.2.1 255.255.255.255 reachability
!
! Monitoring of loopback of R5-AGGR-1
track 3 ip route 10.0.5.1 255.255.255.255 reachability
!
! Monitoring of loopback of R6-AGGR-2
track 4 ip route 10.0.6.1 255.255.255.255 reachability
!
! Track 2 should be UP only when HUB2 is not available and both AGGRE routers are up
!
track 2 list boolean and
 object 1 not
 object 3
 object 4
!         

! IKEv2 Config Exchange configuration (IP addresses for spokes are assigned from pool)
crypto ikev2 authorization policy default
 pool SPOKES
 route set interface
 route accept any tag 20
!
!
! IKEv2 profile for Spokes - Smart Defaults used
crypto ikev2 profile default
 match identity remote any
 authentication remote pre-share key cisco
 authentication local pre-share key cisco
 aaa authorization group psk list default default
 virtual-template 1   
!
interface Loopback0
 ip address 10.0.1.1 255.255.255.255
!
! GRE Tunnel configured to second HUB. It is required for spoke-to-spoke connectivity
! to work in all possible circumstances 
! no BFD echo configuration is required to avoid Traffic Indication sent by remote HUB
! (BFD echo is having the same source and destination IP address)
! 
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 ip nhrp network-id 1
 ip nhrp redirect
 bfd interval 50 min_rx 50 multiplier 3
 no bfd echo
 tunnel source Ethernet0/2
 tunnel destination 192.168.0.2
!
interface Ethernet0/0
 ip address 172.16.0.1 255.255.255.0
!
interface Ethernet0/2
 ip address 192.168.0.1 255.255.255.0
 bfd interval 50 min_rx 50 multiplier 5
!
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 ip nhrp network-id 1
 ip nhrp redirect
 tunnel protection ipsec profile default
!
! BGP Configuration
router bgp 1
 bgp log-neighbor-changes
! dynamic peer-groups are used for AGGR routers and SPOKES
 bgp listen range 192.168.0.0/24 peer-group DC
 bgp listen range 10.0.1.0/24 peer-group SPOKES
! BGP timers configured
 timers bgp 15 30
 neighbor SPOKES peer-group
 neighbor SPOKES remote-as 1
 neighbor DC peer-group
 neighbor DC remote-as 1
! Within DC BFD is used to determine neighbour status
 neighbor DC fall-over bfd
 neighbor 10.0.0.2 remote-as 1
! BFD is used to detect HUB2 status
 neighbor 10.0.0.2 fall-over bfd
 !
 address-family ipv4
  redistribute connected
! route-map which determines what should be the local-pref 
  redistribute static route-map LOCALPREF
  neighbor SPOKES activate
! to spokes only Aggregate/Summary routes are sent
  neighbor SPOKES route-map AGGR out
  neighbor DC activate
  neighbor DC route-reflector-client
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 route-reflector-client
 exit-address-family
!
ip local pool SPOKES 10.0.1.2 10.0.1.254
!
! When HUB2 goes down Static Routes with Tag 500 are added and admin distance of 1
ip route 10.0.0.0 255.0.0.0 Null0 tag 500 track 2
ip route 192.168.0.0 255.255.0.0 Null0 tag 500 track 2
! Default static routes are with Tag 200 and admin distance of 150
ip route 10.0.0.0 255.0.0.0 Null0 150 tag 200
ip route 192.168.0.0 255.255.0.0 Null0 150 tag 200
!
!
ip prefix-list AGGR seq 5 permit 192.168.0.0/16
ip prefix-list AGGR seq 10 permit 10.0.0.0/8
!
route-map AGGR permit 10
 match ip address prefix-list AGGR
!
route-map LOCALPREF permit 5
 match tag 500
 set local-preference 500
!
route-map LOCALPREF permit 10
 match tag 200
 set local-preference 200
!
route-map LOCALPREF permit 15
 match tag 20

Configuração do R2-HUB2

hostname R2-HUB2
!
aaa new-model
!
aaa authorization network default local 
!
track timer ip route msec 500
!
track 1 ip route 10.0.1.1 255.255.255.255 reachability
!
track 2 list boolean and
 object 1 not
 object 3 
 object 4
!
track 3 ip route 10.0.5.1 255.255.255.255 reachability
!
track 4 ip route 10.0.6.1 255.255.255.255 reachability
!
! 
crypto ikev2 authorization policy default
 pool SPOKES
 route set interface
 route accept any tag 20
!
!
crypto ikev2 profile default
 match identity remote any
 authentication remote pre-share key cisco
 authentication local pre-share key cisco
 aaa authorization group psk list default default
 virtual-template 1
!
!
interface Loopback0
 ip address 10.0.2.1 255.255.255.255
!
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 ip nhrp network-id 1
 ip nhrp redirect
 bfd interval 50 min_rx 50 multiplier 3
 no bfd echo
 tunnel source Ethernet0/2
 tunnel destination 192.168.0.1
!
interface Ethernet0/0
 ip address 172.16.0.2 255.255.255.0
!         
interface Ethernet0/2
 ip address 192.168.0.2 255.255.255.0
 bfd interval 50 min_rx 50 multiplier 5
!
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 ip nhrp network-id 1
 ip nhrp redirect
 tunnel protection ipsec profile default
!
router bgp 1
 bgp log-neighbor-changes
 bgp listen range 192.168.0.0/24 peer-group DC
 bgp listen range 10.0.2.0/24 peer-group SPOKES
 timers bgp 15 30
 neighbor SPOKES peer-group
 neighbor SPOKES remote-as 1
 neighbor DC peer-group
 neighbor DC remote-as 1
 neighbor DC fall-over bfd
 neighbor 10.0.0.1 remote-as 1
 neighbor 10.0.0.1 fall-over bfd
 !
 address-family ipv4
  redistribute connected
  redistribute static route-map LOCALPREF
  neighbor SPOKES activate
  neighbor SPOKES route-map AGGR out
  neighbor DC activate
  neighbor DC route-reflector-client
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 route-reflector-client
 exit-address-family
!
ip local pool SPOKES 10.0.2.2 10.0.2.254
ip forward-protocol nd
!
!
ip route 192.168.0.0 255.255.0.0 Null0 tag 500 track 2
ip route 10.0.0.0 255.0.0.0 Null0 tag 500 track 2
ip route 10.0.0.0 255.0.0.0 Null0 150 tag 200
ip route 192.168.0.0 255.255.0.0 Null0 150 tag 200
!
!
ip prefix-list AGGR seq 5 permit 192.168.0.0/16
ip prefix-list AGGR seq 10 permit 10.0.0.0/8
!
route-map AGGR permit 10
 match ip address prefix-list AGGR
!
route-map LOCALPREF permit 5
 match tag 500
 set local-preference 500
!
route-map LOCALPREF permit 10
 match tag 200
 set local-preference 100
!
route-map LOCALPREF permit 15
 match tag 20

Configuração do R3-SPOKE1

hostname R3-SPOKE1
!
aaa new-model
!
aaa authorization network default local 
!
! 
crypto ikev2 authorization policy default
 route set interface
!
!
crypto ikev2 profile default
 match identity remote any
 authentication remote pre-share key cisco
 authentication local pre-share key cisco
 dpd 10 2 on-demand
 aaa authorization group psk list default default
!
! Tunnel to the HUB1
!
interface Tunnel0
 ip address negotiated
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 2
 tunnel source Ethernet0/0
 tunnel destination 172.16.0.1
 tunnel protection ipsec profile default
!
! Tunnel to the HUB2
!
interface Tunnel1
 ip address negotiated
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 2
 tunnel source Ethernet0/0
 tunnel destination 172.16.0.2
 tunnel protection ipsec profile default
!
interface Ethernet0/0
 description INTERNET-CLOUD
 ip address 172.16.0.3 255.255.255.0
!
interface Ethernet0/1
 description LAN
 ip address 192.168.3.3 255.255.255.0
!
interface Virtual-Template2 type tunnel
 ip unnumbered Ethernet0/1
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 2
 tunnel protection ipsec profile default
!
router bgp 1
 bgp log-neighbor-changes
 timers bgp 15 30
 neighbor 10.0.1.1 remote-as 1
 neighbor 10.0.2.1 remote-as 1
 !
 address-family ipv4
  network 192.168.3.0
  neighbor 10.0.1.1 activate
  neighbor 10.0.2.1 activate
 exit-address-family

Configuração do R4-SPOKE2

hostname R4-SPOKE2
!
aaa new-model
!
aaa authorization network default local 
!
!
crypto ikev2 authorization policy default
 route set interface
!         
crypto ikev2 profile default
 match identity remote any
 authentication remote pre-share key cisco
 authentication local pre-share key cisco
 dpd 10 2 on-demand
 aaa authorization group psk list default default
!
interface Tunnel0
 ip address negotiated
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 2
 tunnel source Ethernet0/0
 tunnel destination 172.16.0.1
 tunnel protection ipsec profile default
!
interface Tunnel1
 ip address negotiated
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 2
 tunnel source Ethernet0/0
 tunnel destination 172.16.0.2
 tunnel protection ipsec profile default
!
interface Ethernet0/0
 ip address 172.16.0.4 255.255.255.0
!
interface Ethernet0/1
 ip address 192.168.4.4 255.255.255.0
!
interface Virtual-Template2 type tunnel
 ip unnumbered Ethernet0/1
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 2
 tunnel protection ipsec profile default
!
router bgp 1
 bgp log-neighbor-changes
 timers bgp 15 30
 neighbor 10.0.1.1 remote-as 1
 neighbor 10.0.2.1 remote-as 1
 !
 address-family ipv4
  network 192.168.4.0
  neighbor 10.0.1.1 activate
  neighbor 10.0.2.1 activate
 exit-address-family
! 

Configuração do R5-AGGR1

hostname R5-LAN1
!
no aaa new-model
!
!
interface Loopback0
 ip address 10.0.5.1 255.255.255.255
!
interface Ethernet0/0
 ip address 192.168.0.5 255.255.255.0
 bfd interval 50 min_rx 50 multiplier 5
!
! HSRP configuration on the LAN side
!
interface Ethernet0/1
 ip address 192.168.1.5 255.255.255.0
 standby 1 ip 192.168.1.254
!
router bgp 1
 bgp log-neighbor-changes
 neighbor 192.168.0.1 remote-as 1
 neighbor 192.168.0.1 fall-over bfd
 neighbor 192.168.0.2 remote-as 1
 neighbor 192.168.0.2 fall-over bfd
 !
 address-family ipv4
  redistribute connected
  redistribute static
  neighbor 192.168.0.1 activate
  neighbor 192.168.0.2 activate
 exit-address-family

Configuração do R6-AGGR2

hostname R6-LAN2
!
interface Loopback0
 ip address 10.0.6.1 255.255.255.255
!
interface Ethernet0/0
 ip address 192.168.0.6 255.255.255.0
 bfd interval 50 min_rx 50 multiplier 5
!
interface Ethernet0/1
 ip address 192.168.1.6 255.255.255.0
 standby 1 ip 192.168.1.254
 standby 1 priority 200
!
router bgp 1
 bgp log-neighbor-changes
 neighbor 192.168.0.1 remote-as 1
 neighbor 192.168.0.1 fall-over bfd
 neighbor 192.168.0.2 remote-as 1
 neighbor 192.168.0.2 fall-over bfd
 !
 address-family ipv4
  redistribute connected
  redistribute static
  neighbor 192.168.0.1 activate
  neighbor 192.168.0.2 activate
 exit-address-family
!

Configuração de R7-HOST (simulação de HOST nessa rede)

hostname R7-HOST
!
no aaa new-model
!
interface Ethernet0/0
 ip address 192.168.1.7 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.1.254

Notas importantes sobre a configuração

Aqui estão algumas observações importantes sobre as configurações descritas nas seções anteriores:

• O túnel GRE ponto-a-ponto entre os dois hubs é necessário para que a conectividade spoke-to-spoke funcione em todos os cenários, especificamente para incluir os cenários em que alguns dos spokes estão conectados apenas a um dos hubs e outros a outro hub.
  
  
• A configuração no bfd echo na interface de túnel GRE entre os dois hubs é necessária para evitar a indicação de tráfego que é enviada de outro hub. O eco BFD tem o mesmo endereço IP origem e destino, que é igual ao endereço IP do roteador que envia o eco BFD. Como esses pacotes são roteados de volta pelo roteador que responde, as indicações de tráfego NHRP são geradas.
  
  
• Na configuração do BGP, a filtragem de mapa de rotas que anuncia as redes em direção aos spokes não é necessária, mas torna as configurações mais ótimas, já que somente as rotas agregadas/sumarizadas são anunciadas:
  
  

  neighbor SPOKES route-map AGGR out

• Nos hubs, a configuração do mapa de rota LOCALPREF é necessária para configurar a preferência local BGP apropriada e filtra as rotas estáticas redistribuídas somente para as rotas de sumarização e modo de configuração IKEv2.
  
  
• Este design não aborda a redundância em locais remotos (spoke). Se o link da WAN no spoke ficar inoperante, a VPN também não funcionará. Adicione um segundo link ao roteador spoke ou adicione um segundo roteador spoke dentro do mesmo local para resolver esse problema.

Em resumo, o projeto de redundância apresentado neste documento pode ser tratado como uma alternativa moderna ao recurso Stateful Switchover (SSO)/Stateful. Ele é altamente flexível e pode ser ajustado para atender a seus requisitos de implantação específicos.

Verificar

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshoot

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Informações Relacionadas

• Data Sheet do Cisco IOS FlexVPN
• Configurando o spoke FlexVPN para spoke
• Suporte Técnico e Documentação - Cisco Systems