Configurar e Solucionar Problemas do FlexVPN Spoke to Spoke via EIGRP

Introdução

Este documento descreve a implantação e a solução de problemas do Cisco FlexVPN spoke-to-spoke usando IKEv2 e NHRP para túneis de criptografia de cliente direto.

Pré-requisitos

• Configuração de hub do Flex VPN e cliente do Flex VPN

Requisitos

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

• IKEv2
• VPN de rota
• Interfaces de túnel virtual (VTI)
• NHRP
• IPSec
• EIGRP
• VRF-Lite

Componentes Utilizados

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

• Cisco IOS XE 17.9.4a

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.

Escalabilidade

A FlexVPN pode ser facilmente expandida de pequenos escritórios para redes de grandes empresas. Ele pode gerenciar muitas conexões VPN sem precisar de muito trabalho extra, o que é ótimo para organizações que estão crescendo ou têm muitos usuários remotos.

Recursos Principais

• Configuração dinâmica e túneis sob demanda:
  • Interfaces de túnel virtual (VTI): O FlexVPN usa VTIs que podem ser criadas e removidas conforme necessário. Isso significa que os túneis VPN são configurados somente quando há tráfego e removidos quando não são necessários, economizando recursos e melhorando a escalabilidade.
  • Protocolos de roteamento dinâmico: Ele funciona com protocolos de roteamento como OSPF, EIGRP e BGP sobre túneis VPN. Isso mantém as informações de roteamento atualizadas automaticamente, o que é importante para redes grandes e dinâmicas.
• Flexibilidade na implantação:
  • Modelo Hub-and-Spoke: Um hub central se conecta a várias filiais. O FlexVPN simplifica a configuração dessas conexões com uma única estrutura, tornando-a ideal para redes grandes.
  • Topologias de malha completa e de malha parcial: Todos os locais podem se comunicar diretamente sem passar por um hub central, reduzindo o atraso e melhorando o desempenho.
• Alta disponibilidade e redundância:
  • Hubs redundantes: Oferece suporte a vários hubs para backup. Se um hub falhar, as filiais podem se conectar a outro hub, garantindo conectividade contínua.
  • Balanceamento de carga: Distribui conexões VPN em vários dispositivos para evitar que um único dispositivo fique sobrecarregado, o que é crucial para manter o desempenho em grandes implantações.
• Autenticação e autorização escaláveis:
  • Integração AAA: Funciona com servidores AAA, como Cisco ISE ou RADIUS, para o gerenciamento centralizado de credenciais e políticas de usuário, essenciais para o uso em larga escala.
  • PKI e certificados: Suporta Public Key Infrastructure (PKI) e certificados digitais para autenticação segura, que é mais escalável do que usar chaves pré-compartilhadas, especialmente em grandes ambientes.

Informações de Apoio

FlexVPN e NHRP

O servidor FlexVPN oferece a funcionalidade do servidor do FlexVPN. O cliente FlexVPN estabelece um túnel IPsec VPN seguro entre um cliente FlexVPN e outro servidor FlexVPN.

O NHRP é um protocolo semelhante ao Address Resolution Protocol (ARP) que alivia os problemas de rede de multiacesso sem broadcast (NBMA). Com o NHRP, as entidades NHRP conectadas a uma rede NBMA aprendem dinamicamente o endereço NBMA das outras entidades que fazem parte dessa rede, permitindo que essas entidades se comuniquem diretamente sem exigir tráfego para usar um salto intermediário.

O recurso Spoke to Spoke do FlexVPN integra NHRP e cliente FlexVPN (spoke) para estabelecer um canal de criptografia direto com outro cliente em uma rede FlexVPN existente. As conexões são criadas usando interfaces de túnel virtual (VTI), IKEv2 e NHRP, onde o NHRP é usado para resolver os clientes FlexVPN na rede.

A Cisco recomenda garantir que:

• As entradas de roteamento não são trocadas entre os spokes. Uma consideração importante, explicada posteriormente à medida que avançamos para solucionar problemas de topologia baseada em EIGRP.

• Perfis diferentes são usados para os spokes e o comando config-exchange não está configurado para os spokes.

Processo NHRP

A ilustração demonstra o fluxo de tráfego entre Spoke 1 e Spoke 2, com as redes 198.51.100.0/29/24 e 198.51.100.8/29, ambas anunciadas através do peering EIGRP diretamente para os spokes através do hub. Esta é a aparência do fluxo de tráfego quando a comunicação é estabelecida entre Spoke 1(198.51.100.0/29/24) e Spoke 2 (198.51.100.8/29).

1. O Host 1 envia o tráfego destinado ao Host 2. A pesquisa de rota no Host 1 resulta no seu encaminhamento para a interface de túnel de hub, pois o hub está anunciando essa rede via EIGRP.
2. Quando o tráfego chega ao hub, a consulta de rota final do hub confirma que a rede 198.51.100.8/29 do spoke 2 é aprendida por meio do acesso virtual do spoke 2.
3. O hub inicia o redirecionamento de NHRP, pois as interfaces de acesso virtual (spoke 1 e spoke 2) fazem parte da mesma rede NHRP com o mesmo ID de rede NHRP.
4. Ao receber o redirecionamento, Spoke1 inicia uma solicitação de resolução para a rede spoke 2 pela interface de túnel (a mesma interface pela qual recebeu o redirecionamento). Spoke 2 repete o mesmo processo para a solicitação de resolução da rede spoke 1.
5. Spoke2 recebe a solicitação de resolução na interface de túnel e recupera o número do modelo virtual conforme definido na configuração. O número do modelo virtual é usado para criar a interface de acesso virtual para estabelecer uma sessão de criptografia entre dois spokes. Quando as SAs de criptografia entre os dois spokes estiverem ativadas, ambos os spokes instalam rotas do endereço IP do próximo salto aprendidas via IPSEC após o estabelecimento de interfaces de acesso virtual.
6. Os dois spokes então continuam a verificar a acessibilidade do próximo salto antes de enviar a resposta de resolução através da recém-criada interface virtual-access para conectividade spoke-to-spoke.
7. Quando o próximo salto estiver acessível, ambos os spokes enviarão uma resposta de resolução um ao outro.
8. Ambos os spokes agora podem substituir cada endereço IP do próximo salto da rede para acesso virtual via NHO.
9. Spoke1 instala as entradas de cache necessárias para o IP do próximo salto do Spoke2 e sua rede. Spoke1 também exclui a entrada de cache temporária que aponta para o hub para resolver a rede na interface1 do túnel.
10. O mesmo passo é repetido pelo spoke 2, ele também instala entradas de cache para o IP do próximo salto do spoke 1 e sua rede avança na exclusão da entrada antiga do hub pelo túnel.
11. O NHRP adiciona rotas de atalho como a rota de substituição do próximo salto (NHO) ou a rota H (NHRP).

Configure o spoke para spoke do FlexVPN usando o EIGRP

Diagrama de topologia

Principais Considerações para a Topologia Baseada no EIGRP

Antes de prosseguir para a configuração, há alguns conceitos-chave que devemos entender:

• Para qualquer implantação do EIGRP, se os spokes estiverem recebendo uma tabela de roteamento completa de outros spokes ou apenas rotas de sumarização, uma lista de prefixos precisa ser instalada no lado do hub para atualizações de roteamento de saída para filtrar endereços IP de túnel de spokes a serem anunciados uns nos outros.

• O split horizon no EIGRP funciona de forma diferente do IBGP. O EIGRP apenas interrompe o anúncio de redes fora de uma interface na qual elas foram aprendidas. Por exemplo, o hub tem dois spokes, um conectado através de interfaces de acesso virtual 1 e o outro através de acesso virtual 2. As rotas aprendidas pelo hub via VA 1 do spoke 1 são anunciadas de volta para spoke 2 via VA 2 e vice-versa, já que VA 1 e VA 2 são interfaces diferentes. No caso do IBGP, ele não anuncia nenhuma rede aprendida de seu peer de volta para outro peer. Em um exemplo semelhante, um hub configurado com o IBGP não anuncia redes de volta que aprendeu de VA 1 para VA 2 e vice-versa.

• Esse comportamento no EIGRP cria um conflito na adjacência CEF para o endereço IP do próximo salto (um endereço IP de interface de acesso virtual para um túnel spoke-to-spoke), pois ele é aprendido primeiro via EIGRP usando uma interface de túnel de hub e depois via IPsec usando uma interface de acesso virtual. Isso causa roteamento assimétrico para o tráfego NHRP e também resulta em uma entrada NHRP duplicada na tabela NHRP e entradas NHO duplicadas na tabela de roteamento, bem como para as interfaces do próximo salto (túnel via hub) e (acesso virtual via spoke).

• O modelo virtual do lado do hub precisa ter IP de um pool diferente das interfaces de túnel de spokes, já que queremos filtrar as atualizações de saída do EIGRP para garantir que o peering do EIGRP de hub e spoke não seja afetado.

Aqui estão dois exemplos que mostram como configurar o spoke do FlexVPN usando EIGRP no servidor FlexVPN e no cliente FlexVPN. Seguimos as práticas recomendadas para segregar o tráfego subjacente e de sobreposição colocando-os em VRFs específicos. O VRF A é para a subjacência, enquanto o B é usado para a sobreposição.

Exemplo 1 - Utilizar NHO (Next-Hop-Override) para comunicação spoke-to-spoke

Servidor FlexVPN

ip local pool FLEXPOOL 192.0.2.129 192.0.2.254

crypto ikev2 authorization policy CISCO_FLEX
 pool FLEXPOOL
 def-domain cisco.com
 route set interface

crypto ikev2 proposal CISCO_PROP
 encryption aes-gcm-256
 prf sha256
 group 21

crypto ikev2 policy CISCO_POL 
 match fvrf A
 proposal CISCO_PROP

crypto ikev2 profile CISCO_IKEV2
 match fvrf A
 match identity remote fqdn domain cisco.com
 identity local fqdn hub.cisco.com
 authentication remote pre-share key cisco
 authentication local pre-share key cisco
 aaa authorization group psk list default CISCO_FLEX
 virtual-template 1

crypto ipsec transform-set CISCO_TRANSFORM esp-aes 256 esp-sha256-hmac 
 mode transport

crypto ipsec profile CISCO_PROF
 set transform-set CISCO_TRANSFORM 
 set pfs group19
 set ikev2-profile CISCO_IKEV2

interface Loopback0
 ip vrf forwarding B
 ip address 192.0.2.1 255.255.255.255

interface GigabitEthernet1
 ip vrf forwarding A
 ip address 203.0.113.2 255.255.255.252

interface Virtual-Template1 type tunnel
 ip vrf forwarding B
 ip unnumbered Loopback0
 ip nhrp network-id 1
 ip nhrp redirect
 tunnel vrf A
 tunnel protection ipsec profile CISCO_PROF

ip prefix-list CISCO_PREFIX seq 5 deny 192.0.2.128/25 le 32
ip prefix-list CISCO_PREFIX seq 6 permit 0.0.0.0/0 le 32

router eigrp B
!
address-family ipv4 unicast vrf B autonomous-system 1
!
af-interface default
hello-interval 2
hold-time 10
exit-af-interface
!
topology base
distribute-list prefix CISCO_PREFIX out 
exit-af-topology
network 192.0.2.128 0.0.0.127
network 192.0.2.1 0.0.0.0
exit-address-family

Cliente FlexVPN 1

ip host vrf A hub.cisco.com 203.0.113.2

crypto ikev2 authorization policy CISCO_FLEX
 route set interface

crypto ikev2 proposal CISCO_PROP
 encryption aes-gcm-256
 prf sha256
 group 21

crypto ikev2 policy CISCO_POL 
 match fvrf A
 proposal CISCO_PROP

crypto ikev2 client flexvpn CISCO_CLIENT
 peer 1 fqdn hub.cisco.com dynamic
 client connect Tunnel1

crypto ikev2 profile CISCO_IKEV2
 match fvrf A
 match identity remote fqdn domain cisco.com
 identity local fqdn spoke1.cisco.com
 authentication remote pre-share key cisco
 authentication local pre-share key cisco
 aaa authorization group psk list default CISCO_FLEX
 virtual-template 1

crypto ipsec transform-set CISCO_TRANSFORM esp-aes 256 esp-sha256-hmac 
 mode transport

crypto ipsec profile CISCO_PROF
 set transform-set CISCO_TRANSFORM 
 set pfs group19
 set ikev2-profile CISCO_IKEV2

interface Tunnel1
 ip vrf forwarding B
 ip address negotiated
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 1
 tunnel source GigabitEthernet1
 tunnel destination dynamic
 tunnel vrf A
 tunnel protection ipsec profile CISCO_PROF
end

interface GigabitEthernet1
 ip vrf forwarding A
 ip address 203.0.113.6 255.255.255.252

interface Loopback1
 ip vrf forwarding B
 ip address 198.51.100.1 255.255.255.248

interface Virtual-Template1 type tunnel
 ip vrf forwarding B
 ip unnumbered Tunnel1
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 1
 tunnel vrf A
 tunnel protection ipsec profile CISCO_PROF

router eigrp B
 address-family ipv4 unicast vrf B autonomous-system 1

 af-interface default
  hello-interval 2
  hold-time 10
  passive-interface
 exit-af-interface

 af-interface Tunnel1
  no passive-interface
 exit-af-interface

  topology base
  exit-af-topology
  network 198.51.100.0 0.0.0.7
  network 192.0.2.128 0.0.0.127
 exit-address-family

Cliente FlexVPN 2

ip host vrf A hub.cisco.com 203.0.113.2

crypto ikev2 authorization policy CISCO_FLEX
 route set interface

crypto ikev2 proposal CISCO_PROP
 encryption aes-gcm-256
 prf sha256
 group 21

crypto ikev2 policy CISCO_POL 
 match fvrf A
 proposal CISCO_PROP

crypto ikev2 client flexvpn CISCO_CLIENT
 peer 1 fqdn hub.cisco.com dynamic
 client connect Tunnel1

crypto ikev2 profile CISCO_IKEV2
 match fvrf A
 match identity remote fqdn domain cisco.com
 identity local fqdn spoke2.cisco.com
 authentication remote pre-share key cisco
 authentication local pre-share key cisco
 aaa authorization group psk list default CISCO_FLEX
 virtual-template 1

crypto ipsec transform-set CISCO_TRANSFORM esp-aes 256 esp-sha256-hmac 
 mode transport

crypto ipsec profile CISCO_PROF
 set transform-set CISCO_TRANSFORM 
 set pfs group19
 set ikev2-profile CISCO_IKEV2

interface Tunnel1
 ip vrf forwarding B
 ip address negotiated
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 1
 tunnel source GigabitEthernet1
 tunnel destination dynamic
 tunnel vrf A
 tunnel protection ipsec profile CISCO_PROF
end

interface GigabitEthernet1
 ip vrf forwarding A
 ip address 203.0.113.10 255.255.255.252

interface Loopback1
 ip vrf forwarding B
 ip address 198.51.100.9 255.255.255.248

interface Virtual-Template1 type tunnel
 ip vrf forwarding B
 ip unnumbered Tunnel1
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 1
 tunnel vrf A
 tunnel protection ipsec profile CISCO_PROF

router eigrp B
 address-family ipv4 unicast vrf B autonomous-system 1

 af-interface default
  hello-interval 2
  hold-time 10
  passive-interface
 exit-af-interface

 af-interface Tunnel1
  no passive-interface
 exit-af-interface

  topology base
  exit-af-topology
  network 198.51.100.8 0.0.0.7
  network 192.0.2.128 0.0.0.127
 exit-address-family

Exemplo 2 - Utilizar rotas instaladas de NHRP para comunicação spoke-to-spoke

Servidor FlexVPN

A única alteração na configuração do EIGRP é introduzir rotas de sumarização em vez da tabela de roteamento completa nos spokes. Certifique-se de desativar o modelo virtual para enviar a configuração de resumo para a topologia EIGRP. Consulte o bug da Cisco ID CSCwn84303.

router eigrp B
!
address-family ipv4 unicast vrf B autonomous-system 1
!
af-interface default
hello-interval 2
hold-time 10
exit-af-interface
!
af-interface Virtual-Template1
summary-address 198.51.100.0 255.255.255.0 <<<<<<<<<<< Summary address
exit-af-interface
!
topology base
distribute-list prefix CISCO_PREFIX out 
exit-af-topology
network 192.0.2.128 0.0.0.127
network 192.0.2.1 0.0.0.0
exit-address-family

Verificação e Troubleshooting

Exemplo 1 - Utilizar NHO (Next-Hop-Override) para comunicação spoke-to-spoke

Spoke 1 (antes da resolução e do estabelecimento de túnel do NHRP spoke to spoke)

Spoke 2 (antes da resolução e do estabelecimento de túnel do NHRP spoke to spoke)

Spoke 1 (após a resolução e o estabelecimento de túnel spoke to spoke NHRP)

Inicie o ICMP para disparar o túnel spoke-to-spoke:

Verificar atalho NHRP:

Verifique se as rotas NHO pós-criação de atalho:

Verifique os contadores NHRP:

Spoke 2 (após a resolução e o estabelecimento de túnel do NHRP spoke to spoke)

Verificar atalho NHRP:

Verifique se as rotas NHO pós-criação de atalho:

Verifique os contadores NHRP:

Aqui está uma explicação passo a passo de como um túnel spoke-to-spoke direto é estabelecido com a ajuda de depurações de um dos spokes.

• O spoke 1 iniciou o ICMP:

Spoke1#ping vrf B 198.51.100.9 source 198.51.100.1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 198.51.100.9, timeout is 2 seconds:
Packet sent with a source address of 198.51.100.1 
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 111/111/111 ms

• O hub recebeu o ICMP e iniciou o redirecionamento (indicação de tráfego) para ambos os spokes:

*Feb 3 16:15:35.280: NHRP: Receive Traffic Indication via Tunnel1 vrf: B(0x4), packet size: 104
.
*Feb 3 16:15:35.280: (M) traffic code: redirect(0)
*Feb 3 16:15:35.280: src NBMA: 203.0.113.2
*Feb 3 16:15:35.280: src protocol: 192.0.2.1, dst protocol: 198.51.100.1
.
*Feb 3 16:15:35.281: NHRP-DETAIL: NHRP traffic indication for afn 1 received on interface Tunnel1 , for vrf: B(0x4) label: 0

• Ambos os spokes acionaram uma solicitação de resolução que passou por tunnel1:

*Feb 3 16:15:35.295: NHRP: Sending NHRP Resolution Request for dest: 198.51.100.9 to nexthop: 198.51.100.9 using our src: 192.0.2.130 vrf: B(0x4)
*Feb 3 16:15:35.295: NHRP: Attempting to send packet through interface Tunnel1 via DEST dst 198.51.100.9
*Feb 3 16:15:35.295: NHRP-DETAIL: First hop route lookup for 198.51.100.9 yielded 192.0.2.1, Tunnel1
*Feb 3 16:15:35.295: NHRP: Send Resolution Request via Tunnel1 vrf: B(0x4), packet size: 72
*Feb 3 16:15:35.295: src: 192.0.2.130, dst: 198.51.100.9
.
*Feb 3 16:15:35.296: src NBMA: 203.0.113.6
*Feb 3 16:15:35.296: src protocol: 192.0.2.130, dst protocol: 198.51.100.9

• Ambos os spokes receberam uma solicitação de resolução via Tunnel1:

*Feb 3 16:15:35.392: NHRP: Receive Resolution Request via Tunnel1 vrf: B(0x4), packet size: 92
.
*Feb 3 16:15:35.392: src NBMA: 203.0.113.10
*Feb 3 16:15:35.392: src protocol: 192.0.2.129, dst protocol: 198.51.100.1
*Feb 3 16:15:35.392: (C-1) code: no error(0), flags: none
.
*Feb 3 16:15:35.392: NHRP-DETAIL: Resolution request for afn 1 received on interface Tunnel1 , for vrf: B(0x4) label: 0

• Ambos os spokes realizaram pesquisa de rota para suas redes locais 198.51.100.0/29/24 e 198.51.100.8/29:

*Feb 3 16:15:35.392: NHRP-DETAIL: Multipath IP route lookup for 198.51.100.1 in vrf: B(0x4) yielded Loopback1, pfx:198.51.100.0/29 (netid_in:1 if_in:Tunnel1)
*Feb 3 16:15:35.392: NHRP: Route lookup for destination 198.51.100.1 in vrf: B(0x4) yielded interface Loopback1, prefixlen 29
.
*Feb 3 16:15:35.392: NHRP: We are egress router. Process the NHRP Resolution Request.
.
*Feb 3 16:15:35.393: NHRP-DETAIL: Multipath IP route lookup for 198.51.100.1 in vrf: B(0x4) yielded Loopback1, pfx:198.51.100.0/29 (netid_in:1 if_in:Tunnel1)
*Feb 3 16:15:35.393: NHRP: nhrp_rtlookup for 198.51.100.1 in vrf: B(0x4) yielded interface Loopback1, prefixlen 29, label none(0)
*Feb 3 16:15:35.393: NHRP-DETAIL: netid_out 0, netid_in 1
*Feb 3 16:15:35.393: NHRP: We are egress router for target 198.51.100.1, recevied via Tunnel1 vrf: B(0x4)

• A resposta de resolução foi enfileirada e o estabelecimento de IPsec foi iniciado, pois ambos os spokes agora estão cientes dos endereços NBMA um do outro:

*Feb 3 16:15:35.393: NHRP: Checking for delayed event 192.0.2.129/198.51.100.1 on list (Tunnel1 vrf: B(0x4))
*Feb 3 16:15:35.393: NHRP: No delayed event node found.
*Feb 3 16:15:35.394: NHRP-DETAIL: Updated delayed event with ep src:203.0.113.6 dst:203.0.113.10 ivrf:B
*Feb 3 16:15:35.394: NHRP: Enqueued Delaying resolution request nbma src:203.0.113.6 nbma dst:203.0.113.10 reason:IPSEC-IFC: need to wait for IPsec SAs.
*Feb 3 16:15:35.394: NHRP: Interface: Tunnel1 configured with FlexVPN. Deferring cache creation for nhop 192.0.2.129
*Feb 3 16:15:35.406: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
*Feb 3 16:15:35.456: NHRP: Virtual-Access1: Tunnel mode changed from 
'Uninitialized tunnel mode' to 'GRE over point to point IPV4 tunnel mode'
*Feb 3 16:15:35.456: NHRP: Virtual-Access1: NHRP not enabled in delay_if_up
*Feb 3 16:15:35.511: NHRP: Registration with Tunnels Decap Module succeeded
*Feb 3 16:15:35.511: NHRP: Rejecting addr type 1
*Feb 3 16:15:35.511: NHRP: Adding all static maps to cache
*Feb 3 16:15:35.511: NHRP-DETAIL: Adding summary-prefix entry: nhrp router block not configured
*Feb 3 16:15:35.512: NHRP: 
*Feb 3 16:15:35.512: Instructing NHRP to create Virtual-Access from Virtual template 1 for interface Virtual-Access1
*Feb 3 16:15:35.537: %SYS-5-CONFIG_P: Configured programmatically by process Crypto INT from console as console
*Feb 3 16:15:35.539: NHRP-CACHE: Virtual-Access1: Cache add for target 192.0.2.130/32 vrf: B(0x4) label none next-hop 192.0.2.130
*Feb 3 16:15:35.540: 203.0.113.6 (flags:0x20)
.
*Feb 3 16:15:35.548: NHRP: Updating delayed event with destination 203.0.113.10 on interfaceTunnel1 with the new interface Virtual-Access1 
*Feb 3 16:15:35.788: NHRP: 
*Feb 3 16:15:35.788: Fetched address from underlying IKEv2 for interfaceVirtual-Access1. Pre-NATed = 203.0.113.6, Post-NATed = UNKNOWN
*Feb 3 16:15:35.788: %DMVPN-5-CRYPTO_SS: Virtual-Access1: local address : 203.0.113.6 remote address : 203.0.113.10 socket is UP

• Durante o estabelecimento de IPSEC e o processo de criação de atalhos NHRP, ambos os spokes aprenderam e instalaram uns aos outros endereços ip de túnel em sua tabela de roteamento como rota IPSEC e sondaram a acessibilidade do próximo salto:

*Feb 3 16:15:35.788: NHRP: Processing delayed event on interface Tunnel1 with NBMA 203.0.113.10
.
*Feb 3 16:15:35.789: NHRP-CACHE: Virtual-Access1: Cache add for target 192.0.2.129/32 vrf: B(0x4) label none next-hop 192.0.2.129
*Feb 3 16:15:35.789: 203.0.113.10 (flags:0x2080)
*Feb 3 16:15:35.789: NHRP-RT: Adding route entry for 192.0.2.129/32 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB
*Feb 3 16:15:35.791: NHRP-RT: Route addition to RIB Successful 
*Feb 3 16:15:35.791: NHRP-EVE: NHP-UP: 192.0.2.129, NBMA: 203.0.113.10
*Feb 3 16:15:35.791: %DMVPN-5-NHRP_NHP_UP: Virtual-Access1: Next Hop NHP : (Tunnel: 192.0.2.129 NBMA: 203.0.113.10) for (Tunnel: 192.0.2.130 NBMA: 203.0.113.6) is UP
*Feb 3 16:15:35.791: NHRP-CACHE: 
*Feb 3 16:15:35.791: Next-hop not reachable for 192.0.2.129
*Feb 3 16:15:35.791: %NHRP-5-NHOP_UNREACHABLE: Nexthop address 192.0.2.129 for 192.0.2.129/32 is not routable

• Até a conclusão da instalação do atalho e do NHO, o spoke A executou a consulta do próximo salto de endereços IP de acesso virtual do spoke B e vice-versa, mas a consulta da próxima esperança retornou "N/A rendado", devido ao qual o spoke A enviou uma indicação de erro para o spoke B confirmando que o próximo salto está inacessível. A pesquisa específica pode ser chamada de pesquisa de vários caminhos:

*Feb 3 16:15:35.791: NHRP-DETAIL: Multipath recursive nexthop lookup(if_in:, netid:1) for 192.0.2.129 in vrf: B(0x4) yielded N/A, Virtual-Access1
*Feb 3 16:15:35.791: NHRP: Sending error indication. Reason: 'Cache pak failure' LINE: 13798
*Feb 3 16:15:35.791: NHRP: Attempting to send packet through interface Virtual-Access1 via DEST dst 192.0.2.129
*Feb 3 16:15:35.791: NHRP-DETAIL: Multipath recursive nexthop lookup(if_in:, netid:1) for 192.0.2.129 in vrf: B(0x4) yielded 192.0.2.129, Virtual-Access1
*Feb 3 16:15:35.791: NHRP: Send Error Indication via Virtual-Access1 vrf: B(0x4), packet size: 132
*Feb 3 16:15:35.791: src: 192.0.2.130, dst: 192.0.2.129
.
*Feb 3 16:15:35.791: (M) error code: protocol address unreachable(6), offset: 0 
*Feb 3 16:15:35.791: src NBMA: 203.0.113.6
*Feb 3 16:15:35.791: src protocol: 192.0.2.130, dst protocol: 192.0.2.129

• Depois que o NHO foi acionado para o próximo salto e o atalho foi criado, ambos os spokes enviaram solicitações de resolução para cada uma de suas redes novamente:

*Feb 3 16:15:35.813: NHRP: No need to delay processing of resolution event nbma src:203.0.113.6 nbma dst:203.0.113.10
*Feb 3 16:15:35.813: NHRP-CACHE: Virtual-Access1: Cache update for target 192.0.2.129/32 vrf: B(0x4) label none next-hop 192.0.2.129
*Feb 3 16:15:35.813: 203.0.113.10 (flags:0x2280)
*Feb 3 16:15:35.813: NHRP-RT: Adding route entry for 192.0.2.129/32 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB
*Feb 3 16:15:35.814: NHRP-RT: Route addition to RIB Successful 
.
*Feb 3 16:15:35.841: NHRP-RT: Route entry 192.0.2.129/32 via 192.0.2.129 (Vi1) clobbered by distance
*Feb 3 16:15:35.847: NHRP-RT: Unable to stop route watch for 192.0.2.129/32 interface Virtual-Access1 . No handle
*Feb 3 16:15:35.847: NHRP-RT: Adding route entry for 192.0.2.129/32 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB
*Feb 3 16:15:35.847: NHRP-RT: Route addition failed (admin-distance) 
*Feb 3 16:15:35.847: NHRP-RT: nexthop-override added to RIB 
.
*Feb 3 16:15:37.167: NHRP: Sending NHRP Resolution Request for dest: 198.51.100.9 to nexthop: 198.51.100.9 using our src: 192.0.2.130 vrf: B(0x4)
*Feb 3 16:15:37.167: NHRP: Attempting to send packet through interface Tunnel1 via DEST dst 198.51.100.9
*Feb 3 16:15:37.167: NHRP-DETAIL: First hop route lookup for 198.51.100.9 yielded 192.0.2.1, Tunnel1
*Feb 3 16:15:37.167: NHRP: Send Resolution Request via Tunnel1 vrf: B(0x4), packet size: 72
*Feb 3 16:15:37.167: src: 192.0.2.130, dst: 198.51.100.9
.
*Feb 3 16:15:37.167: src NBMA: 203.0.113.6
*Feb 3 16:15:37.167: src protocol: 192.0.2.130, dst protocol: 198.51.100.9

• Quando ambos os spokes receberam solicitações de resolução para cada uma de suas redes, o NHO substituiu a rota EIGRP via túnel (HUB) por acesso virtual:

*Feb 3 16:30:57.768: NHRP-CACHE: Virtual-Access1: Cache add for target 198.51.100.8/29 vrf: B(0x4) label none next-hop 192.0.2.129
*Feb 3 16:30:57.768: 203.0.113.10 (flags:0x1000)
*Feb 3 16:30:57.768: NHRP-RT: Adding route entry for 198.51.100.8/29 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB
*Feb 3 16:30:57.769: NHRP-RT: Route addition failed (admin-distance) 
*Feb 3 16:30:57.769: NHRP-RT: nexthop-override added to RIB 
*Feb 3 16:30:57.769: NHRP-EVE: NHP-UP: 192.0.2.129, NBMA: 203.0.113.10
*Feb 3 16:30:57.769: %DMVPN-5-NHRP_NHP_UP: Virtual-Access1: Next Hop NHP : (Tunnel: 192.0.2.129 NBMA: 203.0.113.10) for (Tunnel: 192.0.2.130 NBMA: 203.0.113.6) is UP
*Feb 3 16:30:57.769: NHRP-CACHE: Deleting incomplete entry for 198.51.100.9/32 interface Tunnel1 vrf: B(0x4)
*Feb 3 16:30:57.769: NHRP-EVE: NHP-DOWN: 198.51.100.9, NBMA: 198.51.100.9

• Depois, ambos os spokes enviam uma resposta de resolução através da interface de acesso virtual:

*Feb 3 16:30:57.436: NHRP-CACHE: Virtual-Access1: Internal Cache add for target 198.51.100.0/29 vrf: B(0x4) label none next-hop 192.0.2.130
*Feb 3 16:30:57.436: 203.0.113.6 (flags:0x20)
*Feb 3 16:30:57.436: NHRP: Attempting to send packet through interface Virtual-Access1 via DEST dst 192.0.2.129
*Feb 3 16:30:57.436: NHRP-DETAIL: Multipath recursive nexthop lookup(if_in:, netid:1) for 192.0.2.129 in vrf: B(0x4) yielded 192.0.2.129, Virtual-Access1
*Feb 3 16:30:57.436: NHRP: Send Resolution Reply via Virtual-Access1 vrf: B(0x4), packet size: 120
*Feb 3 16:30:57.436: src: 192.0.2.130, dst: 192.0.2.129
.
*Feb 3 16:30:57.437: src NBMA: 203.0.113.10
*Feb 3 16:30:57.437: src protocol: 192.0.2.129, dst protocol: 198.51.100.1
.
*Feb 3 16:30:57.437: client NBMA: 203.0.113.6
*Feb 3 16:30:57.437: client protocol: 192.0.2.130
*Feb 3 16:30:57.437: NHRP: 144 bytes out Virtual-Access1 

Exemplo 2 - Utilizar rotas instaladas de NHRP para comunicação spoke-to-spoke

Servidor FlexVPN

Verifique a topologia EIGRP para a rota sumarizada introduzida:

Clientes FlexVPN

Verifique a presença da rota sumarizada:

Tente estabelecer um túnel spoke-to-spoke iniciando o tráfego:

Verifique novamente:

Há uma alteração muito pequena na saída de depurações para a instalação de rede de spokes, onde ela mostra a instalação bem-sucedida da rota em vez de falha de RIB e adicionando NHO:

*Feb 3 16:43:38.957: NHRP-CACHE: Virtual-Access1: Cache add for target 198.51.100.8/29 vrf: B(0x4) label none next-hop 192.0.2.131
*Feb 3 16:43:38.957: 203.0.113.10 (flags:0x1000)
*Feb 3 16:43:38.957: NHRP-RT: Adding route entry for 198.51.100.8/29 via 192.0.2.131, Virtual-Access1 vrf: B(0x4)) to RIB
*Feb 3 16:43:38.957: NHRP-RT: Route addition to RIB Successful 
*Feb 3 16:43:38.957: NHRP-EVE: NHP-UP: 192.0.2.131, NBMA: 203.0.113.10

Informações Relacionadas

• Configurando o FlexVPN spoke to spoke
• Exemplo de configuração de spoke do FlexVPN no design de hub redundante com bloco de cliente do FlexVPN