Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

DMVPN to FlexVPN migration questions

Hello, if anyone has performed this migration, please share your thoughts on these points.

1. Does FlexVPN solve the latency issue experienced by spoke-to-spoke traffic (specifically, voice packets)? This is an issue with DMVPN's delay in bringing up the spoke-to-spoke IPsec negotiations and P2P tunnel.

2. Do you still need to rely on GDOI + DMVPN to address the latency issue for Spoke-to-spoke tunnels, or is IKEv2's negotiation phase fast enough for real-time/voice traffic between spokes?

3. For large-scale deployments, can you have the two Hub's in different domain ID's? If so, is it just a matter of "peering" the Hubs so traffic from a spoke in one domain/cloud simply gets rerouted over a GRE tunnel between the Hubs to reach another spoke in the other domain/cloud?

4. Is it possible for the Hubs to use redundant AAA/RADIUS servers instead of only one (as in no redundancy with using the Key Server in GetVPN)?

Many thanks.

Mike

2 REPLIES

Re: DMVPN to FlexVPN migration questions

Plese check the following link:

http://www.cisco.com/en/US/products/ps12922/products_configuration_example09186a0080c1e4e5.shtml

DMVPN to FlexVPN Soft Migration Configuration Example

Contents

Introduction

This document describes how to perform a soft migration where both Dynamic Multipoint VPN (DMVPN) and FlexVPN work on a device simultaneously without the need for a workaround and provides a configuration example.

Note: This document expands on the concepts described in the FlexVPN Migration: Hard Move from DMVPN to FlexVPN on Same Devices and FlexVPN Migration: Hard Move from DMVPN to FlexVPN on a Different Hub Cisco articles. Both of these documents describe hard migrations, which cause some disruption to traffic during migration. The limitations in these articles are due to a deficiency in Cisco IOS® software that is now rectified.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

  • DMVPN
  • FlexVPN

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco Integrated Service Router (ISR) Versions 15.3(3)M or Later
  • Cisco 1000 Series Aggregated Service Router (ASR1K) Releases 3.10 or Later

Note: Not all software and hardware supports Internet Key Exchange Version 2 (IKEv2). Refer to the Cisco Feature Navigator for information.

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. 

Background Information

One of the advantages of the newer Cisco IOS platform and software is the ability to use Next Generation Cryptography. An example is the use of Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) for encryption in IPsec, as discussed in RFC 4106. AES GCM allows much faster encryption speeds on some hardware.

Note: For additional information about the use of and migration to Next Generation Cryptography, refer to the Next Generation Encryption Cisco article.

Configure

This configuration example focuses on a migration from a DMVPN Phase 3 configuration to a FlexVPN, because both designs work similarly.


DMVPN Phase 2DMVPN Phase 3FlexVPN
TransportGRE over IPsecGRE over IPsecGRE over IPsec, VTI
NHRP UsageRegistration and ResolutionRegistration and ResolutionResolution
Next Hop from SpokeOther Spokes or HubSummary from HubSummary from Hub
NHRP Shortcut SwitchingNoYesYes (Optional)
NHRP RedirectionNoYesYes
IKE and IPsecIPsec Optional, IKEv1 TypicalIPsec Optional, IKEv1 Typical IPsec, IKEv2

Network Diagrams

This section provides both transport and overlay network diagrams.

Transport Network Diagram

The transport network used in this example includes a single hub with two spokes connected. All of the devices are connected through a network that simulates the Internet.

Overlay Network Diagram

The overlay network used in this example includes a single hub with two spokes connected. Remember that both DMVPN and FlexVPN are active simultaneously, but they use different IP address spaces.

Configurations

This configuration migrates the most popular deployment of DMVPN Phase 3 via Enhanced Interior Gateway Routing Protocol (EIGRP) to FlexVPN with Border Gateway Protocol (BGP). Cisco recommends the use of BGP with FlexVPN, because it allows deployments to scale better.

Note: The hub terminates the IKEv1 (DMVPN) and IKEv2 (FlexVPN) sessions on the same IP address. This is possible only with recent Cisco IOS releases.

Spoke Configuration

This is a very basic configuration, with two notable exceptions that allow inter-operation of both IKEv1 and IKEv2, as well as two frameworks that use Generic Routing Encapsulation (GRE) over IPsec for transport in order to coexist.

Note: The relevant changes to the Internet Security Association and Key Management Protocol (ISAKMP) and IKEv2 configuration are highlighted in bold.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 transportcrypto 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

Cisco IOS Release 15.3 allows you to tie both IKEv2 and ISAKMP profiles together in a tunnel protection configuration. Along with some internal changes to the code, this allows IKEv1 and IKEv2 to operate on the same device simultaneously.Because of the way Cisco IOS selects the profiles (IKEv1 or IKEv2) in releases earlier than 15.3, it led to some caveats, such as situations where IKEv1 is initiated to IKEv2 through the peer. The separation of IKE is now based on profile-level, not interface-level, which is achieved via the new CLI.Another upgrade in the new Cisco IOS release is the addition of the tunnel key. This is needed because both the DMVPN and FlexVPN use the same source interface and the same destination IP address. With this in place, there is no way for the GRE tunnel to know which tunnel interface is used in order to decapsulate traffic. The tunnel key allows you to differentiate tunnel0 and tunnel1 with the addition of a small (4 byte) overhead. A different key can be configured on both interfaces, but you typically only need to differentiate one tunnel. Note: The shared tunnel protection option is not required when DMVPN and FlexVPN share the same interface.Thus, the spoke routing protocol configuration is basic. EIGRP and BGP work separately. EIGRP advertises only over the tunnel interface in order to avoid peering over spoke-to-spoke tunnels, which limits scalability. BGP maintains a relationship only with the hub router (10.1.1.1) in order to advertise the local network (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

Hub Configuration

You must make similar changes on the hub-side configuration as those described in the Spoke Configuration section.Note: The relevant changes to the ISAKMP and IKEV2 configuration are highlighted in bold.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

On the hub-side, the binding between the IKE profile and the IPsec profile occurs at the profile-level, unlike spoke configuration, where this is completed via the tunnel protection command. Both approaches are viable methods to complete this binding. It is important to note that the Next Hop Resolution Protocol (NHRP) network IDs are different for DMVPN and FlexVPN in the cloud. In most cases, it is undesirable when NHRP creates a single domain over both frameworks.The tunnel key differentiates DMVPN and FlexVPN tunnels at the GRE-level in order to achieve the same goal that is mentioned in the Spoke Configuration section. The routing configuration on the hub is fairly basic. The hub device maintains two relationships with any given spoke, one that uses EIGRP and one that uses BGP. The BGP configuration uses listen-range in order to avoid a lengthy, per-spoke configuration. The summary addresses are introduced twice. The EIGRP configuration sends a summary with use of the tunnel0 configuration (IP summary-address EIGRP 100), and the BGP introduces a summary with use of the aggregate-address. The summaries are required in order to ensure that the NHRP redirection occurs, and in order to simplify the routing updates. You can send an NHRP redirect (much like an Internet Control Message Protocol (ICMP) redirect) that indicates whether a better hop exists for a given destination, which allows a spoke-to-spoke tunnel to be established. These summaries are also used in order to minimize the amount of routing updates that are sent between the hub and each spoke, which allows setups to scale better. 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

Verify

The verification for this configuration example is divided into several sections.

Pre-Migration Checks

Since both DMVPN/EIGRP and FlexVPN/BGP operate simultaneously, you must verify that the spoke maintains a relationship over IPsec with both IKEv1 and IKEv2, and that the appropriate prefixes are learned over EIGRP and BGP.  In this example, Spoke1 shows that two sessions are maintained with the hub router; one uses IKEv1/Tunnel0 and one uses IKEv2/Tunnel1.Note: Two IPsec Security Associations (SAs) (one inbound and one outbound) are maintained for each of the tunnels.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


When you check the routing protocols, you must verify that a neighborship is formed, and that the correct prefixes are learned. This is first checked with the EIGRP. Verify that the hub is visible as a neighbor, and that the 192.168.0.0/16 address (the summary) is learned from the 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

Next, verify the 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

The output shows that the hub FlexVPN IP address (10.1.1.1) is a neighbor through which the spoke receives one prefix (192.168.0.0/16). Additionally, the BGP informs the administrator that a Routing Information Base (RIB) failure occurred for the 192.168.0.0/16 prefix. This failure occurs because there is a better route for that prefix that already exists in the routing table. This route is originated by EIGRP, and can be confirmed if you check the routing table. 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

Migration

The previous section verified that both the IPsec and the routing protocols are configured and work as expected. One of the easiest ways to migrate from DMVPN to FlexVPN on the same device is to change the Administrative Distance (AD). In this example, the Internal BGP (iBGP) has an AD of 200, and the EIGRP has an AD of 90. In order for traffic to flow through the FlexVPN properly, the BGP must have a better AD. In this example, the EIGRP AD is changed to 230 and 240 for internal and external routes, respectively. This makes the BGP AD (of 200) more preferable for the 192.168.0.0/16 prefix. Another method that is used in order to acheive this is to decrease the BGP AD. However, the protocol that runs after the migration has non-default values, which can impact other parts of the deployment.In this example, the debug ip routing command is used in order to verify operation on the spoke.Note: If the information in this section is used on a production network, avoid the use of debug commands, and rely on the show commands listed in the next section. Also, the spoke EIGRP process must reestablish adjacency with the 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

There are three important actions to notice in this output:

  • The spoke notices that the AD changed, and disables the adjacency.
  • In the routing table, the EIGRP prefix is retied, and the BGP is introduced.
  • Adjacency to the hub over the EIGRP comes back online.

When you change the AD on a device, it only affects the path from the device to the other networks; it does not affect how other routers perform routing. For example, after the EIGRP distance is increased on Spoke1 (and it uses FlexVPN on the cloud in order to route traffic), the hub maintains the configured (default) ADs. This means that it uses DMVPN in order to route traffic back to Spoke1.

In certain scenarios, this can cause problems, such as when firewalls expect return traffic on the same interface. Therefore, you should change the AD on all spokes before you change it on the hub. Traffic is fully migrated by FlexVPN only once this is complete.

EIGRP-to-EIGRP Migration

A migration from DMVPN to FlexVPN that runs only EIGRP is not discussed in-depth in this document; however, it is mentioned here for completeness.

It is possible to add both DMVPN and EIGRP to the same EIGRP Autonomous System (AS) routing instance. With this in place, the routing adjacency is established over both types of clouds. This can cause load-balancing to occur, which is typically not recommended.

In order to ensure that either FlexVPN or DMVPN is chosen, an administrator can assign different Delay values on a per-interface basis. However, it is important to remember that no changes are possible on the virtual-template interfaces while corresponding virtual-access interfaces are present.

Post-Migration Checks

Similar to the process used in the Pre-Migration Checks section, the IPsec and routing protocol must be verified.

First, verify the 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

As before, two sessions are seen, both of which have two active IPsec SAs.

On the spoke, the aggregate route (192.168.0.0/16) points from the hub and is learned over 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

Similarly, the spoke LAN that is prefixed on the hub must be known via the EIGRP. In this example, the Spoke2 LAN subnet is checked:

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

In the output, the forwarding path is updated properly and points out of a virtual-access interface. 

Additional Considerations

This section describes some additional areas of importance that are relevant to this configuration example.

Existing Spoke-to-Spoke Tunnels

With a migration from EIGRP to BGP, the spoke-to-spoke tunnels are not impacted, because shortcut-switching is still in operation. Shortcut-switching on the spoke inserts a more specific NHRP route with an AD of 250.

Here is an example of such a route:

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

Communication between Migrated and Non-Migrated Spokes

If a spoke that is already on a FlexVPN/BGP wants to communicate with a device for which the migration process has not begun, the traffic always flows over the hub.

This is the process that occurs:

  1. The spoke performs a route lookup for the destination, which points through a summary route that is advertised by the hub.
  2. The packet is sent towards the hub.
  3. The hub receives the packet and performs a route lookup for the destination, which points out of another interface that is part of a different NHRP domain.

    Note: The NHRP network ID in the previous hub configuration is different for both FlexVPN and DMVPN.

Even if the NHRP network IDs are unified, a problem might occur where the migrated spoke routes objects over the FlexVPN network. This includes the directive used in order to configure shortcut switching. The non-migrated spoke attempts to run objects over the DMVPN network, with a specific goal to perform shortcut switching.

Troubleshoot

This section describes the two categories typically used in order to toubleshoot the migration.

Problems with Attempts to Establish Tunnels

Complete these steps if the IKE negotiation fails:

  1. Verify the current state with these commands:

    • show crypto isakmp sa - This command reveals the amount, source, and destination of an IKEv1 session.
    • show crypto ipsec sa - This command reveals the activity of IPsec SAs.
    • show crypto ikev2 sa - This command provides output similar to ISAKMP but is specific to IKEv2.
    • show crypto session - This command provides the summary output of the cryptographic sessions on this device.
    • show crypto socket - This command shows the status of crypto-sockets.
    • show crypto map - This command shows the mapping of IKE and IPsec profiles to the interfaces.
    • show ip nhrp - This command provides the NHRP informtion from the device. This is useful for spoke-to-spoke in FlexVPN setups, and for both spoke-to-spoke and spoke-to-hub bindings in DMVPN setups.

  2. Use these commands in order to debug the tunnel establishment:

    • debug crypto ikev2
    • debug crypto isakmp
    • debug crypto ipsec
    • debug crypto kmi

Problems with Route Propagation

Here are some useful commands that you can use in order to troubleshoot the EIGRP and topology:

  • show bgp summary - Use this command in order to verify the connected neighbors and their states.
  • show ip eigrp neighbor - Use this command in order to show the neighbors that are connected via EIGRP.
  • show bgp - Use this command in order to verify the prefixes learned over the BGP.
  • show ip eigrp topology - Use this command in order to show the prefixes learned via EIGRP.

It is important to know that a learned prefix is different than a prefix that is installed in the routing table. For more information about this, reference the Route Selection in Cisco Routers Cisco article, or the Routing TCP/IP Cisco Press book.

Known Caveats

A limitation that parallels GRE tunnel handling exists on the ASR1K. This is tracked under Cisco bug ID CSCue00443. At this time, the limitation has a scheduled fix in Cisco IOS XE Software Release 3.12.

Monitor this bug if you desire a notification once the fix becomes available.

Re: DMVPN to FlexVPN migration questions

http://www.cisco.com/c/en/us/support/docs/security/dynamic-multipoint-vpn-dmvpn/115726-flexvpn-hardmove-same-00.html

FlexVPN Migration: Hard Move from DMVPN to FlexVPN on Same Devices

Contents

Introduction

This document provides information about how to migrate from existing      DMVPN network to FlexVPN on the same devices.

Both frameworks' configurations will co-exist on the devices.

In this document only the most common scenario is shown: DMVPN using      pre-shared key for authentication and EIGRP as routing protocol.

This document demonstrates migration to BGP (recommended routing      protocol) and less desirable EIGRP.

Prerequisites

Requirements

This document assumes that the reader knows basic concepts of DMVPN and      FlexVPN.

Components Used

Note that not all software and hardware supports IKEv2. Refer to the       Cisco Feature      Navigator for information. Ideally, software versions to be used are:

  • ISR - 15.2(4)M1 or newer
  • ASR1k - 3.6.2 release 15.2(2)S2 or newer

Among the advantages of newer platform and software is the possibility      of using Next Generation Cryptography, for example, AES GCM for encryption in      IPsec. This is discussed in RFC 4106. AES GCM allows to reach much faster encryption speed on some hardware.       In order to see Cisco recommendations on using and migrating to Next      Generation Cryptography, refer to:

http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html

Conventions

Refer to

Cisco      Technical Tips Conventions

for more information on document      conventions.

Migration procedure

Currently, the recommended way to migrate from DMVPN to FlexVPN is for      the two frameworks not to operate at the same time. This limitation will be removed due to new migration features to be      introduced in the ASR 3.10 release, tracked under multiple enhancement requests      under the Cisco side, including CSCuc08066. Those features should be available      in late June, 2013. A migration where both frameworks co-exist and operate at the same time      on same devices will be referred to as soft migration, which indicates minimum      impact and smooth failover from one framework to another. A migration where both frameworks' configuration co-exist, but do not      operate at the same time is referred to as hard migration. This indicates that      a switchover from one framework to another means a lack of communication over      VPN, even if minimal.

Hard migration on same devices

In this document the migration from an existing DMVPN network to a new      FlexVPN network on same devices is discussed. This migration requires that both frameworks do not operate at the same      time on the devices, essentially requiring that DMVPN functionality is disabled      across the board before enabling FlexVPN. Until the new migration feature is available, the way to perform      migrations using same devices is to:

  1. Verify connectivity over DMVPN.
  2. Add FlexVPN configuration in place and shut down Tunnel and Virtual          template interfaces belonging to new configuration.
  3. (During a maintenance window) Shut down all DMVPN tunnel interfaces          on all spokes and hubs before moving to step 4.
  4. Unshut FlexVPN tunnel interfaces.
  5. Verify spoke to hub connectivity.
  6. Verify spoke to spoke connectivity.
  7. If verification in point 5 or 6 did not go properly revert          back to DMVPN by shutting down FlexVPN interface and un-shutting DMVPN          interfaces.
  8. Verify spoke to hub          communication.
  9. Verify spoke to spoke          communication.

Custom approach

If, due to your network or routing complexities, the approach might not      be the best idea for you, start a discussion with your Cisco representative      before migrating. The best person to discuss a custom migration process is your      System Engineer or Advanced Services Engineer.

Network topology

Transport network topology

This diagram shows a typical connections topology of hosts on the      Internet. In this document, the hub's IP address of loopback0 (172.25.1.1) is      used to terminate the IPsec session.

flexvpn-hardmove-same-01.png

Overlay network topology

This topology diagram shows two separate clouds used for overlay: DMVPN      (green connections) and FlexVPN connections.

Local Area Network prefixes are shown for corresponding sides.

The 10.1.1.0/24 subnet does not represent an actual subnet in terms of      interface addressing, but rather a chunk of IP space dedicated to FlexVPN      cloud. Rationale behind is discussed later in FlexVPN Configuration section.

flexvpn-hardmove-same-02.png

Configuration

DMVPN Configuration

This section contains basic configuration of DMVPN hub and spoke.

Pre-shared key (PSK) is used for IKEv1 authentication.

Once IPsec has been established, NHRP registration is performed from      spoke to hub, so that hub can learn the dynamically spokes' NBMA addressing.

When NHRP performs registration on spoke and hub, routing adjacancy can      establish and routes exchanged. In this example, EIGRP is used as basic routing      protocol for the overlay network.

Spoke DMVPN configuration

This is a basic example configuration of DMVPN with pre-shared key      authentication and EIGRP as routing protocol.

crypto isakmp policy 10
  encr aes
  authentication pre-share
crypto isakmp key cisco address 0.0.0.0
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
interface Tunnel0
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 protection ipsec profile DMVPN_IKEv1
router eigrp 100
 network 10.0.0.0 0.0.0.255
 network 192.168.102.0
 passive-interface default
 no passive-interface Tunnel0

Hub DMVPN configuration

In hub configuration the tunnel is sourced from loopback0 with an IP      address of 172.25.1.1.

The rest is standard deployment of DMVPN hub with EIGRP as routing      protocol.

crypto isakmp policy 10
 encr aes
 authentication pre-share
crypto isakmp key cisco 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
 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 protection ipsec profile DMVPN_IKEv1
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

FlexVPN configuration

FlexVPN is based on these same fundamental technologies:

  • IPsec: Unlike default in DMVPN, IKEv2 is used instead of IKEv1 to          negotiate IPsec SAs. IKEv2 offers improvements over IKEv1, starting with          resiliency and ending with how many messages are needed to establish a          protected data channel.
  • GRE: Unlike DMVPN, static and dynamic point to point interfaces are          used, and not only on static multipoint GRE interfaces. This configuration          allows added flexibility, especially for per-spoke/per-hub          behavior.
  • NHRP: In FlexVPN NHRP is primarily used to establish spoke to spoke          communication. Spokes do not register to hub.
  • Routing: Because spokes do not perform NHRP registration to hub, you          need to rely on other mechanisms to make sure hub and spokes can communicate          bi-directionally. Simliar to DMVPN, dynamic routing protocols can be used.          However, FlexVPN allows you to use IPsec to introduce routing information. The          default is to introduce as /32 route for the IP address on the other side of          the tunnel, which will allow spoke-to-hub direct communication.

In hard migration from DMVPN to FlexVPN the two framemworks do not work      at the same time on same devices. However, it is recommended to keep them      separate. Separate them on several levels:

  • NHRP - Use different NHRP network ID (recommended).
  • Routing - Use separate routing processes          (recommended).
  • VRF - VRF separation can allow added flexibility but will not be          discussed here (optional).

Spoke FlexVPN configuration

One of the differences in spoke configuration in FlexVPN as compared to      DMVPN, is that you have potentially two interfaces.

There is a necessary tunnel for spoke to hub communication and optional      tunnel for spoke to spoke tunnels. If you choose not to have dynamic spoke to      spoke tunneling and would rather that everything goes through hub device, you      can remove the virtual-template interface and remove NHRP shortcut switching      from the tunnel interface.

You will also notice that the static tunnel interface has an IP address      received based on negotiation. This allows the hub to provide tunnel interface      IP to spoke dynamically without the need to create static addressing in the      FlexVPN cloud.

aaa new-model
aaa authorization network default local
aaa session-id common

crypto ikev2 profile Flex_IKEv2
 match identity remote fqdn domain cisco.com
 authentication remote rsa-sig
 authentication local rsa-sig
 aaa authorization group cert list default default
 virtual-template 1
crypto ikev2 dpd 30 5 on-demand

Cisco recommends using AES GCM in hardware that supports it.

crypto ipsec transform-set IKEv2 esp-gcm
    mode transport
crypto ipsec profile default
 set ikev2-profile Flex_IKEv2
! set transform-set IKEv2
interface Tunnel1
 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
 shutdown
 tunnel source Ethernet0/0
 tunnel destination 172.25.1.1
 tunnel path-mtu-discovery
 tunnel protection ipsec profile default
interface Virtual-Template1 type tunnel
 ip unnumbered Tunnel1
 ip mtu 1400
 ip nhrp network-id 2
 ip nhrp shortcut virtual-template 1
 ip nhrp redirect
 ip tcp adjust-mss 1360
 tunnel path-mtu-discovery
 tunnel protection ipsec profile default

PKI is the recommended way of performing large scale authentication in      IKEv2.

However, you can still use pre-shared key as long as you are aware of      it's limitations.

Here is an example configuration using "cisco" as PSK:

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

FlexVPN Hub configuration

Typically a hub will only terminate dynamic spoke-to-hub tunnels. This      is why in the hub's configuration you will not find a static tunnel interface      for FlexVPN, instead a virtual-template interface is used. This will spawn a      virtual-access interface for each connection.

Note that on hub side you need to point out pool addresses to be      assigned to spokes.

Addresses from this pool will be added later on in the routing table as      /32 routes for each spoke.

aaa new-model
aaa authorization network default local
aaa session-id common
crypto ikev2 authorization policy default
 pool FlexSpokes
crypto ikev2 profile Flex_IKEv2
 match identity remote fqdn domain cisco.com
 authentication remote rsa-sig
 authentication local rsa-sig
 aaa authorization group cert list default default
 virtual-template 1
crypto ikev2 dpd 30 5 on-demand

Cisco recommends using AES GCM in hardware which supports it.

crypto ipsec transform-set IKEv2 esp-gcm
 mode transport

Note that in the configuration below the AES GCM operation has been      commented out.

crypto ipsec profile default
 set ikev2-profile Flex_IKEv2
! set transform-set IKEv2
interface Loopback0
 description DMVPN termination
 ip address 172.25.1.1 255.255.255.255
interface Loopback100
 ip address 10.1.1.1 255.255.255.255
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback100
 ip nhrp network-id 2
 ip nhrp redirect
 shutdown
 tunnel path-mtu-discovery
 tunnel protection ipsec profile default
ip local pool FlexSpokes 10.1.1.100 10.1.1.254

With authentication in IKEv2, the same principle applies on hub as on      spoke.

For scalability and flexibility, use certificates. However, you can      re-use the same configuration for PSK as on spoke.

Note: IKEv2 offers flexibility in terms of authentication. One side can          authenticate using PSK while the other RSA-SIG.

Traffic Migration

Migrating to BGP as overlay routing protocol [Recommended]

BGP is a routing protocol based on unicast exchange. Due to it's      characteristics it has been the best scaling protocol in DMVPN networks.

In this example, iBGP is used.

Spoke BGP configuration

Spoke migration consists of two parts. Enabling BGP as dynamic      routing.

router bgp 65001
 bgp log-neighbor-changes
 network 192.168.101.0
 neighbor 10.1.1.1 remote-as 65001

After the BGP neighbor comes up (see the Hub BGP configuration in this      section of migration) and new prefixes over BGP are learned, you can swing      traffic from the existing DMVPN cloud to new FlexVPN cloud.

Hub BGP configuration

On hub to avoid keeping neighborship configuration for each spoke      separately, dynamic listeners are configured.

In this setup BGP will not initiate new connections, but will accept      connection from the provided pool of IP addresses. In this case the said pool      is 10.1.1.0/24, which is all the addresses in the new FlexVPN cloud.

router bgp 65001
 network 192.168.0.0
 bgp log-neighbor-changes
 bgp listen range 10.1.1.0/24 peer-group Spokes
 aggregate-address 192.168.0.0 255.255.0.0 summary-only
 neighbor Spokes peer-group
 neighbor Spokes remote-as 65001

Migrating traffic to FlexVPN

As mentioned before migration needs to be done by shutting down DMVPN      functionality and bringing FlexVPN up.

This procedure guarantees minimum impact.

  1. On all spokes:

    interface tunnel 0
       shut
  2. On Hub:

    interface tunnel 0
      shut

    At this point make sure that there are no IKEv1 sessions established          to this hub from spokes.

    This can be verified by checking the output of the show          crypto isakmp sa command and monitoring syslog messages generated          by the crypto logging session.

    Once this has been confirmed you can proceed to bringing up FlexVPN.

  3. Continuing on hub:

    interface Virtual-template 1
     no shut
  4. On spokes:

    interface tunnel 1
       no shut

Verification Steps

IPsec stability

The best way to evaluate IPsec stability is by monitoring sylogs with      this configuration command enabled:

crypto logging session

If you see sessions going up and down, this can indicate a problem on      IKEv2/FlexVPN level that needs to be corrected before migration can begin.

BGP information populated

If IPsec is stable, make sure that the BGP table is populated with      entries from spokes (on hub) and summary from hub (on spokes).

In case of BGP, this can be viewed by performing:

show bgp 
! or
show bgp ipv4 unicast 
! or
show ip bgp summary

Example of correct information from hub:

Hub#show bgp
BGP router identifier 172.25.1.1, local AS number 65001
(...omitted...)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
*10.1.1.101 4 65001 83 82 13 0 0 01:10:46 1
*10.1.1.102 4 65001 7 7 13 0 0 00:00:44 1

You can see that hub has learned that 1 prefix from each of the spokes      and both spokes are dynamic (marked with asterisk (*) sign).

Example of similar information from spoke:

Spoke1#show ip bgp summary
BGP router identifier 192.168.101.1, local AS number 65001
(...omitted...)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.1 4 65001 11 11 6 0 0 00:03:43 1

Spoke has received one prefix from hub. In case of this setup, this      prefix should be the summary advertised on hub.

Migrating to new tunnels using EIGRP

EIGRP is a popular choice in DMVPN networks due to it's relatively      simple deployment and fast convergence.

It will, however, scale worse than BGP and does not offer many of      advanced mechanisms that can be used by BGP straight out of the box.

This next section describes one of the ways to move to FlexVPN using a      new EIGRP process.

Updated spoke configuration

In this example, a new AS is added with a separate EIGRP process.

router eigrp 200
 network 10.1.1.0 0.0.0.255
 network 192.168.101.0
 passive-interface default
 no passive-interface Tunnel1

Note: You should avoid establishing routing protocol adjacency over spoke          to spoke tunnels, thus only make interface of tunnel1 (spoke to hub) not          passive.

Updated hub configuration

Similarly on hub, DMVPN should remain the preferred way to exchange      traffic over. However, FlexVPN should advertise and learn same prefixes      already.

router eigrp 200
 network 10.1.1.0 0.0.0.255

There are two ways to provide summary back towards the spoke.

  • Redistributing a static route pointing to null0 (Preferred option).

    ip route 192.168.0.0 255.255.0.0 null 0
    ip access-list standard EIGRP_SUMMARY
     permit 192.168.0.0 0.0.255.255
    router eigrp 200
     distribute-list EIGRP_SUMMARY out Virtual-Template1
     redistribute static metric 1500 10 10 1 1500

    This option allows to have control over summary and redistribution          without touching hub's VT configuration.

  • Or, you can set up a DMVPN-style summary address on Virtual-template.          This configuration is not recommended because of internal processing and          replication of said summary to each virtual access. It is shown here for          reference:

    interface Virtual-Template1 type tunnel
     ip summary-address eigrp 200 172.16.1.0 255.255.255.0
     ip summary-address eigrp 200 192.168.0.0 255.255.0.0
     delay 2000
    

Migrating traffic to FlexVPN

Migration needs to be done by shutting down DMVPN functionality and      bringing FlexVPN up.

The following procedure guarantees minimum impact.

  1. On all spokes:

    interface tunnel 0
       shut
  2. On Hub:

    interface tunnel 0
      shut

    At this point make sure that there are no IKEv1 sessions established          to this hub from spokes.

    This can be verified by checking the output of the show          crypto isakmp sa command and monitoring syslog messages generated          by crypto logging session.

    Once this has been confirmed you can proceed to bringing up FlexVPN.

  3. Continuing on hub:

    interface Virtual-template 1
     no shut
  4. On all spokes:

    interface tunnel 1
       no shut

Verification steps

IPsec stability

As in case of BGP, you need to evaluate if IPsec is stable. The best      way to do so is by monitoring sylogs with this configuration command enabled:

crypto logging session

If you see sessions going up and down, this can indicate a problem on      IKEv2/FlexVPN level that needs to be corrected before migration can begin.

EIGRP information in topology table

Make sure that you do have your EIGRP topology table populated with      spoke LAN entries on hub and summary on spokes. This can be verified by issuing      this command on hub(s) and spoke(s).

show ip eigrp topology

Example of proper output from spoke:

Spoke1#sh 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
(...omitted as output related to DMVPN cloud ...)
EIGRP-IPv4 Topology Table for AS(200)/ID(192.168.101.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status

P 10.1.1.1/32, 1 successors, FD is 26112000
 via Rstatic (26112000/0)


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 26114560
 via 10.1.1.1 (26114560/1709056), Tunnel1


P 10.1.1.107/32, 1 successors, FD is 26112000
 via Connected, Tunnel1

You will notice that spoke knows about its LAN subnet (in italic) and      the summaries for those (in bold).

Example of proper output from hub.

Hub#sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(172.25.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status
(...omitted, related to DMVPN...) 
EIGRP-IPv4 Topology Table for AS(200)/ID(172.25.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status

P 10.1.1.1/32, 1 successors, FD is 128256
 via Connected, Loopback100


P 192.168.101.0/24, 1 successors, FD is 1561600
 via 10.1.1.107 (1561600/281600), Virtual-Access1


P 192.168.0.0/16, 1 successors, FD is 1709056
 via Rstatic (1709056/0)

P 10.1.1.107/32, 1 successors, FD is 1709056
 via Rstatic (1709056/0)


P 10.1.1.106/32, 1 successors, FD is 1709056
 via Rstatic (1709056/0)


P 0.0.0.0/0, 1 successors, FD is 1709056
 via Rstatic (1709056/0)

P 192.168.102.0/24, 1 successors, FD is 1561600
 via 10.1.1.106 (1561600/281600), Virtual-Access2

You will note that hub knows about spokes' LAN subnets (in italic), the      summary prefix it is advertising (in bold) and each spoke's      assigned IP address via negotiation.

Additional considerations

Existing spoke to spoke tunnels

Because shutting down the DMVPN tunnel interface causes NHRP entries      to be removed, existing spoke to spoke tunnels will be torn down.

Clearing NHRP entries

As mentioned before, a FlexVPN hub will not rely on the NHRP      registration process from spoke to know how to route traffic back. However,      dynamic spoke to spoke tunnels rely on NHRP entries.

In DMVPN where clearing NHRP on hub could have resulted in short-lived      connectivity problems.

In FlexVPN clearing NHRP on spokes will cause FlexVPN IPsec session,      related to spoke to spoke tunnels, to be torn down. In clearing NHRP no hub      will have an effect on FlexVPN session.

This is due to the fact that in FlexVPN, by default:

  • Spokes do not register to hubs.
  • Hubs work only as NHRP redirector and do not install NHRP          entries.
  • NHRP shortcut entries are installed on spokes for spoke-to-spoke          tunnels and are dynamic.

Known Caveats

Spoke to spoke traffic might be affected by CSCub07382.

1492
Views
0
Helpful
2
Replies
CreatePlease to create content