Guest

Cisco FlexVPN

FlexVPN Migration: Hard Move from DMVPN to FlexVPN on a Different Hub

Cisco - FlexVPN Migration: Hard Move from DMVPN to FlexVPN on a Different Hub

Document ID: 115727

Updated: Jan 09, 2013

Contributed by Marcin Latosie, Cisco TAC Engineer.

   Print

Introduction

This document describes how to migrate from a Dynamic Multipoint VPN (DMVPN) network to FlexVPN on different hub devices.

Note: Both framework configurations can coexist on the devices.

In this document, only the most common scenario is shown: DMVPN using pre-shared key for authentication and Enhanced Interior Gateway Routing Protocol (EIGRP) as routing protocol. In this document, migration to Border Gateway Protocol (BGP) (recommended routing protocol) and EIGRP (less desirable) is demonstrated.

Prerequisites

Requirements

This document assumes the reader is familiar with basic concepts of DMVPN and FlexVPN.

Components Used

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

  • ISR - 15.2(4)M1 or newer

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

Note: Not all software and hardware supports IKEv2. Refer to the Cisco Feature Navigator for information.

Among the advantages of newer platform and software is the possibility of using Next Generation Cryptography, for example, AES GCM for encryption in IPsec, as 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 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 is going to be removed due to new migration features to be introduced in the ASR 3.10 release, tracked under multilple enhancement requests under the Cisco side, including CSCuc08066 (registered customers only) . Those features should be available in late June 2013.

A migration where both frameworks co-exist and operate at the same time on the same devices will be referred to as soft migration, indicating 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 will mean lack of communication over VPN, even if minimal.

Hard migration between two different hubs

In this document migration from existing DMVPN hub to a new FlexVPN hub is discussed.

This migration allows inter-communication between spokes migrated already to FlexVPN, and those still running on DMVPN and can be performed in multiple phases, on each spoke separately.

Provided that routing information is properly populated, communication between migrated and non-migrated spokes should remain possible. However, added additional latency can be observed because migrated and non-migrated spokes will not build spoke to spoke tunnels between each other.

At the same time, migrated spokes should be able to establish direct spoke to spoke tunnels between themselves. The same applies to non-migrated spokes.

Until this new migration feature is available, the way to perform migrations using a different hub from DMVPN and FlexVPN is to:

  1. Verify connectivity over DMVPN.

  2. Add FlexVPN configuration in place and shut down the tunnel belonging to new configuration.

  3. (During a maintenance window) On each spoke, one by one, shut down DMVPN tunnel.

  4. On same spoke as in step 3, un-shut FlexVPN tunnel interfaces.

  5. Verify spoke to hub connectivity.

  6. Verify spoke to spoke connectivity within FlexVPN.

  7. Verify spoke to spoke connectivity with DMVPN from Flex.

  8. Repeat steps 3-7 for each spoke separately.

  9. If verification in steps 5, 6 or 7 did not go properly revert back to DMVPN by shutting down FlexVPN interface and un-shutting DMVPN interfaces.

  10. Verify spoke to hub communication over backed up DMVPN.

  11. Verify spoke to spoke communication over backed up DMVPN.

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 typical connections topology of hosts on the internet. The hub's IP address of loopback0 (172.25.1.1) is used to terminate DMVPN IPsec session. The IP on new hub (172.25.2.1) is used for FlexVPN.

You will also notice a link between the two hubs. This link is crucial to allow connectivity between FlexVPN and DMVPN clouds during migration.

It will allow spokes already migrated to FlexVPN to communicate with DMVPN networks and vice versa.

flexvpn-hard-hub-01.png

Overlay network topology

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

Local Area Network prefixes are shown for corresponding sites.

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

flexvpn-hard-hub-02.png

Configuration

DMVPN configuration

This section contains basic configuration of DMVPN hub and spoke.

As you can see, pre-shared key (PSK) is used for IKEv1 authentication.

Once IPsec has been established, NHRP registration from spoke to hub is performed so that hub can learn 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

Here you can find 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 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 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 multpoint 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. Similar 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 frameworks do not work at the same time on the 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 neccessary 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.2.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.

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 that 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.2.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
 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.

Inter-hub BGP connection

You need to make sure that hubs know where particular prefixes are located.

This becomes increasingly important as we migrated some spokes to FlexVPN while some other spokes remain on DMVPN.

Inter-hub BGP connection based on, DMVPN hub configuration.

router bgp 65001
 network 192.168.0.0
 neighbor 192.168.0.2 remote-as 65001

Traffic migration

Migrating to BGP as overlay routing protocol (Recommended)

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

FlexVPN Hub; Full BGP configuration

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

In this setup BGP will not initiiate 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.

Two things to note:

  1. FlexVPN hub will advertise specific prefixes DMVPN hub, thus the unsupress map.

  2. Either advertise FlexVPN subnet of 10.1.1.0/24 into the routing table, or make sure that DMVPN hub sees FlexVPN hub as the next hop.

This document shows the latter approach.

access-list 1 permit any
route-map ALL permit 10
 match ip address 1route-map SET_NEXT_HOP permit 10
 set ip next-hop 192.168.0.2
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 neighbor 192.168.0.1 remote-as 65001
 neighbor 192.168.0.1 route-reflector-client
 neighbor 192.168.0.1 unsuppress-map ALL
 neighbor 192.168.0.1 route-map SET_NEXT_HOP out

DMVPN Hub; Full BGP and EIGRP configuration

The configuration on DMVPN hub is basic because it will only receive specific prefixes from FlexVPN hub and advertise prefixes it has learned from EIGRP.

router bgp 65001
 bgp log-neighbor-changes
 redistribute eigrp 100
 neighbor 192.168.0.2 remote-as 65001

Migrating traffic to BGP/FlexVPN

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

The following procedure guarantees minimum impact:

  1. On each spoke, separately:

    interface tunnel 0
       shut

    At this point make sure there are no IKEv1 sessions established to this spoke.

    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.

  2. On same spoke:

    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 with these commands:

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

Here is an example of correct information from FlexVPN hub:

BGP router identifier 172.25.2.1, local AS number 65001
(...omitted...)Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
*10.1.1.100 4 65001 112 123 16 0 0 01:35:58 1
192.168.0.1 4 65001 97 99 16 0 0 01:24:12 4

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

You can also see that a total of four prefixes from inter-hub connection is received.

Example of similar information from spoke:

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 120 109 57 0 0 01:33:23 2

Spoke has received two prefixes from hub. In case of this setup, one prefix should be the summary advertised on FlexVPN hub. The other is DMVPN 10.0.0.0/24 network redistributed on DMVPN spoke into BGP.

Migrating to new tunnels using EIGRP

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

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

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

Updated spoke configuration

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. Therefore, only make the interface of tunnel1 (spoke to hub) not passive.

Updated FlexVPN hub configuration

Similarly, for the FlexVPN hub, prepare the routing protocol in the appopriate AS matching one configured on spokes.

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 route 10.1.1.0 255.255.255.0 null 0ip prefix-list
     EIGRP_SUMMARY_ONLY seq 5 permit 192.168.0.0/16
    ip prefix-list EIGRP_SUMMARY_ONLY seq 10 permit 10.1.1.0/24
    route-map EIGRP_SUMMARY permit 20
     match ip address prefix-list EIGRP_SUMMARY_ONLY  
    
    router eigrp 200
     distribute-list route-map EIGRP_SUMMARY out Virtual-Template1
     redistribute static metric 1500 10 10 1 1500 route-map EIGRP_SUMMARY

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

    This is important because hub's VT configuration cannot be modified if there is active virtual access associated with it.

  • 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 192.168.0.0 255.255.0.0
    

    Another aspect to be accounted for is the inter-hub routing exchange.

    This can be done by redistributing EIGRP instances to iBGP.

DMVPN hub - updated BGP configuration

The configuration remains basic. You need to redistribute specific prefixes from EIGRP to BGP.

router bgp 65001
 redistribute eigrp 100
 neighbor 192.168.0.2 remote-as 65001 

FlexVPN hub - updated BGP configuration

Similar to DMVPN hub, in FlexVPN you need to redistribute new EIGRP process' prefixes to BGP.

router bgp 65001
 redistribute eigrp 200
 redistribute static
 neighbor 192.168.0.1 remote-as 65001

Migrating traffic to FlexVPN

Migrating traffic to FlexVPN As discussed before, migration needs to be done by shutting down DMVPN functionality and bringing FlexVPN up on each spoke, one at a time.

This procedure guarantees minimum impact:

  1. On each spoke, separately:

    interface tunnel 0
       shut

    At this point make sure there are no IKEv1 sessions established on this spoke.

    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.

  2. On same spoke:

    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

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 [AS_NUMBER] topology

This is an example of output from spoke:

Spoke1#show ip eigrp 200 topology 
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)
 via 10.1.1.1 (26240000/128256), Tunnel1
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/2562560), Tunnel1
P 10.1.1.100/32, 1 successors, FD is 26112000
 via Connected, Tunnel1
P 10.1.1.0/24, 1 successors, FD is 26114560
 via 10.1.1.1 (26114560/2562560), Tunnel1

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

This is an example of output from hub:

hub2# show ip eigrp 200 topology 
EIGRP-IPv4 Topology Table for AS(200)/ID(172.25.2.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, Loopback200
P 192.168.101.0/24, 1 successors, FD is 26905600
 via 10.1.1.100 (26905600/281600), Virtual-Access1
P 192.168.0.0/16, 1 successors, FD is 2562560
 via Rstatic (2562560/0)
P 10.1.1.0/24, 1 successors, FD is 2562560
 via Rstatic (2562560/0)

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 down 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 NHRP registration process from spoke to know how to route traffic back. However, dynamic spoke to spoke tunnels rely on NHRP entries.

In DMVPN, clearing NHRP on hub can result in short-lived connectivity problems.

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

This is because 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.

Related Information

Updated: Jan 09, 2013
Document ID: 115727