Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Informações de Apoio

Configurar

Diagramas de rede

Diagrama da rede de transporte

Diagrama de sobreposição de rede

Configurações

Configuração de Spoke

Configuração do hub

Verificar

Verificações de pré-migração

Migração

Migração do EIGRP para EIGRP

Verificações pós-migração

Considerações adicionais

Túneis spoke-to-spoke existentes

Comunicação entre spokes migrados e não migrados

Troubleshoot

Problemas com tentativas de estabelecer túneis

Problemas com Propagação de Rota

Caveats conhecidos

Introduction

Este documento descreve como executar uma migração de software na qual tanto a VPN multiponto dinâmica (DMVPN) como a FlexVPN funcionam em um dispositivo simultaneamente sem a necessidade de uma solução alternativa e fornece um exemplo de configuração.

Note: Este documento expande os conceitos descritos na Migração do FlexVPN: Transferência forçada de DMVPN para FlexVPN nos mesmos dispositivos e migração de FlexVPN: Transferência forçada de DMVPN para FlexVPN em artigos diferentes de hub da Cisco. Esses dois documentos descrevem migrações difíceis, que causam alguma interrupção no tráfego durante a migração. As limitações nesses artigos se devem a uma deficiência no software Cisco IOS® que agora é corrigida.

Prerequisites

Requirements

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

- DMVPN

- FlexVPN

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

- Cisco Integrated Service Router (ISR) versões 15.3(3)M ou posterior

- Cisco 1000 Series Aggregated Service Router (ASR1K) versões 3.10 ou posterior

Note: Nem todos os softwares e hardwares suportam o Internet Key Exchange Versão 2 (IKEv2). Consulte o Cisco Feature Navigator para obter informações.

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

Uma das vantagens da plataforma e do software Cisco IOS mais novos é a capacidade de usar a criptografia de última geração. Um exemplo é o uso do AES (Advanced Encryption Standard, Padrão de Criptografia Avançada) no GCM (Galois/Counter Mode) para criptografia no IPsec, conforme discutido no RFC 4106. O AES GCM permite velocidades de criptografia muito mais rápidas em algum hardware.

Note: Para obter informações adicionais sobre o uso e a migração para a criptografia de próxima geração, consulte o artigo da Cisco Next Generation Encryption.

Configurar

Este exemplo de configuração concentra-se em uma migração de uma configuração da fase 3 do DMVPN para um FlexVPN, porque ambos os designs funcionam da mesma forma.

Fase 2 do DMVPN

Fase 3 do DMVPN

FlexVPN

Transporte

GRE sobre IPsec

GRE sobre IPsec

GRE sobre IPsec, VTI

Uso de NHRP

Registro e resolução

Registro e resolução

Resolução

Próximo salto do Spoke

Outros Spokes ou Hub

Resumo do hub

Resumo do hub

Switching de atalho NHRP

No

Yes

Sim (opcional)

Redirecionamento de NHRP

No

Yes

Yes

IKE e IPsec

IPsec opcional, IKEv1 típico

IPsec opcional, IKEv1 típico

IPsec, IKEv2

Diagramas de rede

Esta seção fornece diagramas de rede de transporte e sobreposição.

Diagrama da rede de transporte

A rede de transporte usada neste exemplo inclui um único hub com dois spokes conectados. Todos os dispositivos são conectados através de uma rede que simula a Internet.

Diagrama de sobreposição de rede

A rede de sobreposição usada neste exemplo inclui um único hub com dois spokes conectados. Lembre-se de que o DMVPN e o FlexVPN estão ativos simultaneamente, mas usam espaços de endereços IP diferentes.

Configurações

Essa configuração migra a implantação mais popular da fase 3 do DMVPN via Enhanced Interior Gateway Routing Protocol (EIGRP) para o FlexVPN com Border Gateway Protocol (BGP). A Cisco recomenda o uso do BGP com FlexVPN, pois permite que as implantações escalem melhor.

Note: O hub termina as sessões de IKEv1 (DMVPN) e IKEv2 (FlexVPN) no mesmo endereço IP. Isso só é possível com versões recentes do Cisco IOS.

Configuração de Spoke

Essa é uma configuração muito básica, com duas exceções notáveis que permitem a interoperação de IKEv1 e IKEv2, bem como duas estruturas que usam o Generic Routing Encapsulation (GRE) sobre IPsec para transporte a fim de coexistir.

Note: As alterações relevantes na configuração da Internet Security Association and Key Management Protocol (ISAKMP) e IKEv2 estão destacadas em negrito.

crypto keyring DMVPN_IKEv1

pre-shared-key address 0.0.0.0 0.0.0.0 key cisco

crypto logging session

crypto ikev2 keyring Flex_key

peer Spokes

address 0.0.0.0 0.0.0.0

pre-shared-key local cisco

pre-shared-key remote cisco

crypto ikev2 profile Flex_IKEv2

match identity remote address 0.0.0.0

authentication remote pre-share

authentication local pre-share

keyring local Flex_key

aaa authorization group psk list default default

virtual-template 1

crypto ikev2 dpd 30 5 on-demand

crypto isakmp policy 10

encr aes

authentication pre-share

crypto isakmp keepalive 30 5

crypto isakmp profile DMVPN_IKEv1

keyring DMVPN_IKEv1

match identity address 0.0.0.0

crypto ipsec transform-set IKEv1 esp-aes esp-sha-hmac

mode transport

crypto ipsec profile DMVPN_IKEv1

set transform-set IKEv1

set isakmp-profile DMVPN_IKEv1

crypto ipsec profile default

set ikev2-profile Flex_IKEv2

interface Tunnel0

desciption DMVPN tunnel

ip address 10.0.0.101 255.255.255.0

no ip redirects

ip mtu 1400

ip nhrp map 10.0.0.1 172.25.1.1

ip nhrp map multicast 172.25.1.1

ip nhrp network-id 1

ip nhrp holdtime 900

ip nhrp nhs 10.0.0.1

ip nhrp shortcut

ip tcp adjust-mss 1360

tunnel source Ethernet0/0

tunnel mode gre multipoint

tunnel key 0

tunnel protection ipsec profile DMVPN_IKEv1 isakmp-profile DMVPN_IKEv1

interface Tunnel1

description FlexVPN spoke-to-hub tunnel

ip address negotiated

ip mtu 1400

ip nhrp network-id 2

ip nhrp shortcut virtual-template 1

ip nhrp redirect

ip tcp adjust-mss 1360

tunnel source Ethernet0/0

tunnel destination 172.25.1.1

tunnel protection ipsec profile default ikev2-profile Flex_IKEv2

interface Virtual-Template1 type tunnel

description FlexVPN spoke-to-spoke

ip unnumbered Ethernet1/0

ip mtu 1400

ip nhrp network-id 2

ip nhrp shortcut virtual-template 1

ip nhrp redirect

ip tcp adjust-mss 1360

tunnel protection ipsec profile default ikev2-profile Flex_IKEv2

O Cisco IOS versão 15.3 permite que você vincule os perfis IKEv2 e ISAKMP em uma configuração de proteção de túnel. Juntamente com algumas alterações internas ao código, isso permite que IKEv1 e IKEv2 operem no mesmo dispositivo simultaneamente.

Por causa da maneira como o Cisco IOS seleciona os perfis (IKEv1 ou IKEv2) em versões anteriores à 15.3, ele levou a algumas advertências, como situações em que IKEv1 é iniciado para IKEv2 através do peer. A separação da IKE agora se baseia no nível do perfil, não no nível da interface, o que é obtido através da nova CLI.

Outra atualização na nova versão do Cisco IOS é a adição da chave do túnel. Isso é necessário porque o DMVPN e o FlexVPN usam a mesma interface de origem e o mesmo endereço IP de destino. Com isso em vigor, não há como o túnel GRE saber qual interface de túnel é usada para desencapsular o tráfego. A chave de túnel permite diferenciar tunnel0 e tunnel1 com a adição de uma pequena sobrecarga (4 bytes). Uma chave diferente pode ser configurada em ambas as interfaces, mas você normalmente só precisa diferenciar um túnel.

Note: A opção de proteção de túnel compartilhado não é necessária quando DMVPN e FlexVPN compartilham a mesma interface.

Assim, a configuração do protocolo de roteamento de spoke é básica. O EIGRP e o BGP funcionam separadamente. O EIGRP anuncia somente sobre a interface do túnel para evitar peering sobre túneis spoke-to-spoke, o que limita a escalabilidade. O BGP mantém uma relação somente com o roteador do hub (10.1.1.1) para anunciar a rede local (192.168.101.0/24).

router eigrp 100

network 10.0.0.0 0.0.0.255

network 192.168.101.0

passive-interface default

no passive-interface Tunnel0

router bgp 65001

bgp log-neighbor-changes

network 192.168.101.0

neighbor 10.1.1.1 remote-as 65001

Configuração do hub

Você deve fazer alterações semelhantes na configuração do lado do hub às descritas na seção Configuração de Spoke.

Note: As alterações relevantes na configuração de ISAKMP e IKEV2 estão destacadas em negrito.

crypto ikev2 authorization policy default

pool FlexSpokes

route set interface

crypto ikev2 keyring Flex_key

peer Spokes

address 0.0.0.0 0.0.0.0

pre-shared-key local cisco

pre-shared-key remote cisco

crypto ikev2 profile Flex_IKEv2

match identity remote address 0.0.0.0

authentication remote pre-share

authentication local pre-share

keyring local Flex_key

aaa authorization group psk list default default

virtual-template 1

crypto ikev2 dpd 30 5 on-demand

crypto isakmp policy 10

encr aes

authentication pre-share

crypto isakmp key cisco address 0.0.0.0

crypto ipsec profile DMVPN_IKEv1

set transform-set IKEv1

crypto ipsec profile default

set ikev2-profile Flex_IKEv2

interface Tunnel0

ip address 10.0.0.1 255.255.255.0

no ip redirects

ip mtu 1400

ip nhrp map multicast dynamic

ip nhrp network-id 1

ip nhrp holdtime 900

ip nhrp server-only

ip nhrp redirect

ip summary-address eigrp 100 192.168.0.0 255.255.0.0

ip tcp adjust-mss 1360

tunnel source Loopback0

tunnel mode gre multipoint

tunnel key 0

tunnel protection ipsec profile DMVPN_IKEv1

interface Virtual-Template1 type tunnel

ip unnumbered Loopback100

ip mtu 1400

ip nhrp network-id 2

ip tcp adjust-mss 1360

tunnel protection ipsec profile default

No lado do hub, a associação entre o perfil IKE e o perfil IPsec ocorre no nível do perfil, ao contrário da configuração do spoke, onde isso é concluído através do comando tunnel protection. Ambas as abordagens são métodos viáveis para concluir esta ligação.

É importante observar que as IDs de rede do Next Hop Resolution Protocol (NHRP) são diferentes para DMVPN e FlexVPN na nuvem. Na maioria dos casos, é indesejável quando o NHRP cria um único domínio sobre ambas as estruturas.

A chave do túnel diferencia os túneis DMVPN e FlexVPN no nível de GRE para alcançar o mesmo objetivo mencionado na seção Configuração de Spoke.

A configuração de roteamento no hub é bastante básica. O dispositivo de hub mantém duas relações com qualquer spoke dado, uma que usa EIGRP e outra que usa BGP. A configuração do BGP usa o intervalo de escuta para evitar uma configuração longa por raio.

Os endereços de resumo são apresentados duas vezes. A configuração do EIGRP envia um resumo com o uso da configuração tunnel0 (IP summary-address EIGRP 100), e o BGP introduz um resumo com o uso do aggregate-address. Os resumos são necessários para garantir que o redirecionamento de NHRP ocorra e para simplificar as atualizações de roteamento. Você pode enviar um redirecionamento de NHRP (como um redirecionamento de Internet Control Message Protocol (ICMP)) que indica se existe um salto melhor para um determinado destino, o que permite que um túnel spoke-to-spoke seja estabelecido. Esses resumos também são usados para minimizar a quantidade de atualizações de roteamento enviadas entre o hub e cada spoke, o que permite que as configurações sejam dimensionadas melhor.

router eigrp 100

network 10.0.0.0 0.0.0.255

network 192.168.0.0 0.0.255.255

passive-interface default

no passive-interface Tunnel0

router bgp 65001

bgp log-neighbor-changes

bgp listen range 10.1.1.0/24 peer-group Spokes

network 192.168.0.0

aggregate-address 192.168.0.0 255.255.0.0 summary-only

neighbor Spokes peer-group

neighbor Spokes remote-as 65001

Verificar

A verificação deste exemplo de configuração é dividida em várias seções.

Verificações de pré-migração

Como tanto DMVPN/EIGRP quanto FlexVPN/BGP operam simultaneamente, você deve verificar se o spoke mantém uma relação sobre IPsec com IKEv1 e IKEv2, e se os prefixos apropriados são aprendidos sobre EIGRP e BGP.

Neste exemplo, Spoke1 mostra que duas sessões são mantidas com o roteador de hub; um usa IKEv1/Tunnel0 e outro usa IKEv2/Tunnel1.

Note: Duas SAs (Associações de Segurança IPsec) (uma entrada e uma saída) são mantidas para cada um dos túneis.

Spoke1#show cry sess

Crypto session current status

Interface: Tunnel0

Profile: DMVPN_IKEv1

Session status: UP-ACTIVE

Peer: 172.25.1.1 port 500

Session ID: 0

IKEv1 SA: local 172.16.1.2/500 remote 172.25.1.1/500 Active

IPSEC FLOW: permit 47 host 172.16.1.2 host 172.25.1.1

Active SAs: 2, origin: crypto map

Interface: Tunnel1

Profile: Flex_IKEv2

Session status: UP-ACTIVE

Peer: 172.25.1.1 port 500

Session ID: 1

IKEv2 SA: local 172.16.1.2/500 remote 172.25.1.1/500 Active

IPSEC FLOW: permit 47 host 172.16.1.2 host 172.25.1.1

Active SAs: 2, origin: crypto map

Ao verificar os protocolos de roteamento, você deve verificar se uma vizinhança é formada e se os prefixos corretos são aprendidos. Isso é primeiro verificado com o EIGRP. Verifique se o hub está visível como um vizinho e se o endereço 192.168.0.0/16 (o resumo) é aprendido do hub:

Spoke1#show ip eigrp neighbors

EIGRP-IPv4 Neighbors for AS(100)

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

0 10.0.0.1 Tu0 10 00:04:02 7 1398 0 13

Spoke1#show ip eigrp topology

EIGRP-IPv4 Topology Table for AS(100)/ID(192.168.101.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 192.168.101.0/24, 1 successors, FD is 281600

via Connected, Ethernet1/0

P 192.168.0.0/16, 1 successors, FD is 26880000

via 10.0.0.1 (26880000/256), Tunnel0

P 10.0.0.0/24, 1 successors, FD is 26880000

via Connected, Tunnel0

Em seguida, verifique o BGP:

Spoke1#show bgp summary

(...)

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.1.1.1 4 65001 13 11 3 0 0 00:06:56 1

Spoke1#show bgp

BGP table version is 3, local router ID is 192.168.101.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

r>i 192.168.0.0/16 10.1.1.1 0 100 0 i

*> 192.168.101.0 0.0.0.0 0 32768 i

A saída mostra que o endereço IP FlexVPN do hub (10.1.1.1) é um vizinho através do qual o spoke recebe um prefixo (192.168.0.0/16). Além disso, o BGP informa ao administrador que ocorreu uma falha de Routing Information Base (RIB) para o prefixo 192.168.0.0/16. Essa falha ocorre porque há uma rota melhor para esse prefixo que já existe na tabela de roteamento. Essa rota é originada pelo EIGRP e pode ser confirmada se você verificar a tabela de roteamento.

Spoke1#show ip route 192.168.0.0 255.255.0.0

Routing entry for 192.168.0.0/16, supernet

Known via "eigrp 100", distance 90, metric 26880000, type internal

Redistributing via eigrp 100

Last update from 10.0.0.1 on Tunnel0, 00:10:07 ago

Routing Descriptor Blocks:

* 10.0.0.1, from 10.0.0.1, 00:10:07 ago, via Tunnel0

Route metric is 26880000, traffic share count is 1

Total delay is 50000 microseconds, minimum bandwidth is 100 Kbit

Reliability 255/255, minimum MTU 1400 bytes

Loading 1/255, Hops 1

Migração

A seção anterior verificou se o IPsec e os protocolos de roteamento estão configurados e funcionam conforme esperado. Uma das maneiras mais fáceis de migrar de DMVPN para FlexVPN no mesmo dispositivo é alterar a distância administrativa (AD). Neste exemplo, o BGP interno (iBGP) tem um AD de 200, e o EIGRP tem um AD de 90.

Para que o tráfego flua pelo FlexVPN corretamente, o BGP deve ter um AD melhor. Neste exemplo, o AD do EIGRP é alterado para 230 e 240 para rotas internas e externas, respectivamente. Isso torna o BGP AD (de 200) mais preferível para o prefixo 192.168.0.0/16.

Outro método usado para alcançar isso é diminuir o AD BGP. No entanto, o protocolo executado após a migração tem valores não padrão, o que pode afetar outras partes da implantação.

Neste exemplo, o comando debug ip routing é usado para verificar a operação no spoke.

Note: Se as informações nesta seção forem usadas em uma rede de produção, evite o uso de comandos debug e confie nos comandos show listados na próxima seção. Além disso, o processo EIGRP de spoke deve restabelecer a adjacência com o hub.

Spoke1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Spoke1(config)#router eigrp 100

Spoke1(config-router)# distance eigrp 230 240

Spoke1(config-router)#^Z

Spoke1#

*Oct 9 12:12:34.207: %SYS-5-CONFIG_I: Configured from console by console

*Oct 9 12:12:43.648: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.0.1

(Tunnel0) is down: route configuration changed

*Oct 9 12:12:43.648: RT: delete route to 192.168.0.0 via 10.0.0.1,

eigrp metric [90/26880000]

*Oct 9 12:12:43.648: RT: no routes to 192.168.0.0, delayed flush

*Oct 9 12:12:43.648: RT: delete network route to 192.168.0.0/16

*Oct 9 12:12:43.650: RT: updating bgp 192.168.0.0/16 (0x0) :

via 10.1.1.1

*Oct 9 12:12:43.650: RT: add 192.168.0.0/16 via 10.1.1.1, bgp metric [200/0]

Spoke1#

*Oct 9 12:12:45.750: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.0.1

(Tunnel0) is up: new adjacency

Há três ações importantes a serem observadas nesta saída:

- O spoke percebe que o AD mudou e desabilita a adjacência.

- Na tabela de roteamento, o prefixo do EIGRP é desativado e o BGP é apresentado.

- A adjacência ao hub através do EIGRP volta a estar online.

Quando você altera o AD em um dispositivo, ele afeta apenas o caminho do dispositivo para as outras redes; não afeta a forma como outros roteadores executam o roteamento. Por exemplo, depois que a distância EIGRP é aumentada em Spoke1 (e usa FlexVPN na nuvem para rotear o tráfego), o hub mantém os ADs configurados (padrão). Isso significa que ele usa DMVPN para rotear o tráfego de volta para Spoke1.

Em determinados cenários, isso pode causar problemas, como quando os firewalls esperam tráfego de retorno na mesma interface. Portanto, você deve alterar o AD em todos os spokes antes de alterá-lo no hub. O tráfego é totalmente migrado pelo FlexVPN somente quando isso estiver concluído.

Migração do EIGRP para EIGRP

Uma migração de DMVPN para FlexVPN que executa somente o EIGRP não é discutida em profundidade neste documento; no entanto, é aqui mencionada para ser completa.

É possível adicionar DMVPN e EIGRP à mesma instância de roteamento EIGRP Autonomous System (AS). Com isso em vigor, a adjacência de roteamento é estabelecida em ambos os tipos de nuvens. Isso pode fazer com que ocorra o balanceamento de carga, o que geralmente não é recomendado.

Para garantir que FlexVPN ou DMVPN seja escolhido, um administrador pode atribuir diferentes valores de atraso por interface. No entanto, é importante lembrar que nenhuma alteração é possível nas interfaces de modelo virtual enquanto as interfaces de acesso virtual correspondentes estão presentes.

Verificações pós-migração

Semelhante ao processo usado na seção Verificações de Pré-Migração, o IPsec e o protocolo de roteamento devem ser verificados.

Primeiro, verifique o IPsec:

Spoke1#show crypto session

Crypto session current status

Interface: Tunnel0

Profile: DMVPN_IKEv1

Session status: UP-ACTIVE

Peer: 172.25.1.1 port 500

Session ID: 0

IKEv1 SA: local 172.16.1.2/500 remote 172.25.1.1/500 Active

IPSEC FLOW: permit 47 host 172.16.1.2 host 172.25.1.1

Active SAs: 2, origin: crypto map

Interface: Tunnel1

Profile: Flex_IKEv2

Session status: UP-ACTIVE

Peer: 172.25.1.1 port 500

Session ID: 1

IKEv2 SA: local 172.16.1.2/500 remote 172.25.1.1/500 Active

IPSEC FLOW: permit 47 host 172.16.1.2 host 172.25.1.1

Active SAs: 2, origin: crypto map

Como antes, duas sessões são vistas, ambas com duas SAs IPsec ativas.

No spoke, a rota agregada (192.168.0.0/16) aponta do hub e é aprendida sobre o BGP.

Spoke1#show ip route 192.168.0.0 255.255.0.0

Routing entry for 192.168.0.0/16, supernet

Known via "bgp 65001", distance 200, metric 0, type internal

Last update from 10.1.1.1 00:14:07 ago

Routing Descriptor Blocks:

* 10.1.1.1, from 10.1.1.1, 00:14:07 ago

Route metric is 0, traffic share count is 1

AS Hops 0

MPLS label: none

Da mesma forma, a LAN de raio prefixada no hub deve ser conhecida através do EIGRP. Neste exemplo, a sub-rede de LAN Spoke2 é verificada:

Hub#show ip route 192.168.102.0 255.255.255.0

Routing entry for 192.168.102.0/24

Known via "bgp 65001", distance 200, metric 0, type internal

Last update from 10.1.1.106 00:04:35 ago

Routing Descriptor Blocks:

* 10.1.1.106, from 10.1.1.106, 00:04:35 ago

Route metric is 0, traffic share count is 1

AS Hops 0

MPLS label: none

Hub#show ip cef 192.168.102.100

192.168.102.0/24

nexthop 10.1.1.106 Virtual-Access2

Na saída, o caminho de encaminhamento é atualizado corretamente e aponta para fora de uma interface de acesso virtual.

Considerações adicionais

Esta seção descreve algumas áreas adicionais importantes que são relevantes para este exemplo de configuração.

Túneis spoke-to-spoke existentes

Com uma migração do EIGRP para o BGP, os túneis spoke-to-spoke não são afetados, porque a comutação de atalhos ainda está em operação. A comutação de atalho no spoke insere uma rota NHRP mais específica com um AD de 250.

Aqui está um exemplo dessa rota:

Spoke1#show ip route 192.168.102.100

Routing entry for 192.168.102.0/24

Known via "nhrp", distance 250, metric 1

Last update from 10.1.1.106 on Virtual-Access1, 00:00:42 ago

Routing Descriptor Blocks:

* 10.1.1.106, from 10.1.1.106, 00:00:42 ago, via Virtual-Access1

Route metric is 1, traffic share count is 1

Comunicação entre spokes migrados e não migrados

Se um spoke que já está em um FlexVPN/BGP deseja se comunicar com um dispositivo para o qual o processo de migração não foi iniciado, o tráfego sempre flui sobre o hub.

Esse é o processo que ocorre:

1. O spoke executa uma pesquisa de rota para o destino, que aponta através de uma rota sumarizada anunciada pelo hub.

2. O pacote é enviado para o hub.

3. O hub recebe o pacote e executa uma pesquisa de rota para o destino, que aponta para outra interface que faz parte de um domínio NHRP diferente.

Note: O ID da rede NHRP na configuração de hub anterior é diferente para FlexVPN e DMVPN.

Mesmo que as IDs de rede NHRP sejam unificadas, pode ocorrer um problema em que os objetos de rotas de spoke migradas pela rede FlexVPN. Isso inclui a diretiva usada para configurar a comutação de atalhos. O spoke não migrado tenta executar objetos na rede DMVPN, com um objetivo específico de executar a comutação de atalhos.

Troubleshoot

Esta seção descreve as duas categorias tipicamente usadas para solucionar problemas da migração.

Problemas com tentativas de estabelecer túneis

Conclua estes passos se a negociação IKE falhar:

1. Verifique o estado atual com estes comandos:

- show crypto isakmp sa - Este comando revela a quantidade, a origem e o destino de uma sessão IKEv1.

- show crypto ipsec sa - Este comando revela a atividade de SAs IPsec.
Note: Ao contrário do IKEv1, nesta saída o valor do grupo Diffie-Hellman (DH) do Perfect Forward Secsecret (PFS) aparece como PFS (Y/N): N, grupo DH: nenhuma durante a primeira negociação de túnel; no entanto, depois que uma chave de rechaveamento ocorre, os valores corretos são exibidos. Isso não é um bug, mesmo que o comportamento seja descrito em CSCug67056. A diferença entre IKEv1 e IKEv2 é que neste último caso, as SAs filho são criadas como parte da troca AUTH. O Grupo DH configurado no mapa de criptografia é usado somente durante uma chave de rechaveamento. Por esta razão, você vê PFS (S/N): N, grupo DH: nenhuma até a primeira chave. Com o IKEv1, você vê um comportamento diferente porque a criação do SA filho ocorre durante o Modo Rápido, e a mensagem CREATE_CHILD_SA tem provisões para a transferência do payload do Key Exchange que especifica os parâmetros DH para derivar um novo segredo compartilhado.

- show crypto ikev2 sa - Este comando fornece uma saída semelhante a ISAKMP, mas é específico para IKEv2.

- show crypto session - Este comando fornece a saída de resumo das sessões criptográficas neste dispositivo.

- show crypto socket - Este comando mostra o status de crypto-sockets.

- show crypto map - Este comando mostra o mapeamento dos perfis IKE e IPsec para as interfaces.

- show ip nhrp - Este comando fornece as informações de NHRP do dispositivo. Isso é útil para conexões spoke-to-spoke em configurações de FlexVPN e para conexões spoke-to-spoke e spoke-to-hub em configurações de DMVPN.

2. Use estes comandos para depurar o estabelecimento do túnel:

- debug crypto ikev2

- debug crypto isakmp

- debug crypto ipsec

- debug crypto kmi

Problemas com Propagação de Rota

Aqui estão alguns comandos úteis que você pode usar para solucionar problemas do EIGRP e da topologia:

- show bgp summary - Use este comando para verificar os vizinhos conectados e seus estados.

- show ip eigrp neighbor - Use este comando para mostrar os vizinhos conectados via EIGRP.

- show bgp - Use este comando para verificar os prefixos aprendidos sobre o BGP.

- show ip eigrp topology - Use este comando para mostrar os prefixos aprendidos via EIGRP.

É importante saber que um prefixo aprendido é diferente de um prefixo instalado na tabela de roteamento. Para obter mais informações sobre isso, consulte o artigo Seleção de rota nos Cisco Routers Cisco ou o manual Routing TCP/IP Cisco Press.

Caveats conhecidos

Uma limitação de que o tratamento de túnel GRE paralela existe no ASR1K. Isso é controlado na ID de bug da Cisco CSCue00443. No momento, a limitação tem uma correção programada no Cisco IOS XE Software Release 3.12.

Monitore esse bug se desejar uma notificação assim que a correção estiver disponível.