282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco athietdte cisco Dynamic Multipoint IPsec VPNs (Using Multipoint GRE/NHRP to Scale IPsec VPNs) Document ID: 41940 Updated: Jan 04, 2006 Contents Introduction Background Information The DMVPN Solution Automatic IPsec Encryption Initiation Dynamic Tunnel Creation for “Spoke-to-Hub” Links Dynamic Tunnel Creation for “Spoke-to-Spoke" Traffic ‘Supporting Dynamic Routing Protocols Cisco Express Forwarding Fast Switching for mGRE Using Dynamic Routing Over IPsec Protected VPNs Base Configuration Examples of the Routing Tables on the Hub and Spoke Routers Reducing the Hub Router Configuration Size Supporting Dynamic Addresses on Spokes Dynamic Multipoint Hub and Spoke Dynamic Multipoint IPsec VPN RIP EIGRP OSPF Initial Conditions, Conditions After a Dynamic Link Is Created Between Spoket and Spoke2 Dynamic Multipoint IPsec VPN with Dual Hubs Dual Hub - Single DMVPN Layout Initial Conditions and Changes Dual Hub - Dual DMVPN Layout Initial Conditions and Changes Conclusion Related Information Introduction This document discusses Dynamic Multipoint IPsec VPNs (DMVPN) and why a company might want to design or migrate their network to make use of this new IPsec VPN solution in Cisco |OS® Software. Background Information Companies may need to interconnect many sites to a main site, and perhaps also to each other, across the Internet while encrypting the traffic to protect it. For example, a set of retail stores that need to connect to the bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco company headquarters for inventory and ordering may also need to connect to other stores within the company to check out product availabilty. In the past, the only way to make the connection was to use a Layer-2 network such as ISDN or Frame Relay to interconnect everything. Setting up and paying for these hard-wired links for internal IP traffic can be time consuming and costly. If all of the sites (including the main site) already have relatively cheap Intemet access, then this Intemet access can also be used for internal IP communication between the stores and headquarters by using IPsec tunnels to ensure privacy and data integrity. In order for companies to build large IPsec networks interconnecting their sites across the Intemet, you need to be able to scale the IPsec network. IPsec encrypts traffic between two endpoints (peers), and the encryption is done by the two endpoints using a shared "secret". Since this secret is shared only between these two endpoints, encrypted networks are inherently a collection of point-to-point links. Because of this, IPsec is intrinsically a point-to-point tunnel network. The most feasible method to scale a large point-to-point network is to organize it into a hub-and-spoke or full (partial) mesh network. In most networks, the majority of the IP traffic is between the spokes and the hub, and very little is between the spokes, so the hub-and-spoke design is often the best choice. This design also matches with older Frame Relay networks since it was prohibitively expensive to pay for links between all sites in these networks. When using the Intemet as the interconnection between the hub and spokes, the spokes also have direct, access to each other with no additional cost, but it has been very difficult, if not impossible, to set up and/or manage a full (partial) mesh network. Full or partial mesh networks are often desirable because there can be a cost savings if spoke-to-spoke traffic can go directly through rather then via the hub. Spoke-to-spoke traffic traversing the hub uses hub resources and can incur extra delays, especially when using IPsec encryption, since the hub will need to decrypt the incoming packets from the sending spokes and then re-encrypt the traffic to send it to the receiving spoke. Another example where direct spoke-to-spoke traffic would be useful is the case where two spokes are in the same city and the hub is across the country. ‘As IPsec hub-and-spoke networks were deployed and grew in size, it became more desirable to have them route IP packets as dynamically as possible. In the older Frame Relay hub-and-spoke networks this was accomplished by running a dynamic routing protocol like OSPF or EIGRP over the Frame Relay links. This was useful for dynamically advertising the reachability of spoke networks and also to support redundancy in the IP routing network. If the network lost a hub router, a backup hub router could automatically take over to retain network connectivity to the spoke networks ‘There is a fundamental problem with IPsec tunnels and dynamic routing protocols. Dynamic routing protocols rely on using IP multicast or broadcast packets, but IPsec does not support encrypting multicast or broadcast packets. The current method for solving this problem is to use generic routing encapsulation (GRE) tunnels in combination with IPsec encryption. GRE tunnels do support transporting IP multicast and broadcast packets to the other end of the GRE tunnel ‘The GRE tunnel packet is an IP unicast packet, so the GRE packet can be encrypted using IPsec. In this scenario, GRE does the tunneling work and IPsec does the encryption part of supporting the VPN network. When GRE tunnels are configured, the IP addresses for the endpoints of the tunnel (tunnel source ..., tunnel destination ...) must be known by the other endpoint and must be routable over the intemet. This means that the hub and all of the spoke routers in this network must have static non-private IP addresses. For small site connections to the Intemet, it is typical for a spoke's extemal IP address to change each time it connects to the Intemet because their Intemet Service Provider (ISP) dynamically provides the outside interface address (via Dynamic Host Configuration Protocol (DHCP) each time the spoke comes on line (asymmetric digital subscriber line (ADSL) and Cable services). This dynamic allocation of the "outside address” of the router allows the ISP to oversubscribe the use of their Intemet address space, since not all Users will be online at the same time. It can be considerably more expensive to pay the provider to allocate a static address for the spoke router. Running a dynamic routing protocol over an IPsec VPN requires the use of GRE tunnels, but you lose the option of having spokes with dynamically allocated IP addresses on their outside physical interfaces. The above restrictions and some others are summarized in the following four points: + IPsec uses an access control list (ACL) to define what data is to be encrypted. So, each time a new (sub)network is added behind a spoke or the hub, the customer must change the ACL on both the hub and spoke routers. If the SP manages the router, then the customer must notify the SP in order to get the IPsec ACL changed so that new traffic will be encrypted ‘+ With large hub-and-spoke networks, the size of the configuration on the Hub router can become very large, to the extent that itis unusable, For example a hub router would need up to 3900 lines of configuration to support 300 spoke routers. This is large enough that it would be difficult to show the configuration and to bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 2081ssa01s ‘Dynamic Multipint Psec VPNs (Using Mulpoint GREINHRP to Scale Psec VPNs) - Cisco find the section of the configuration that is relevant to a current problem that is being debugged. Also this size configuration may be too large to fit in NVRAM and would need to be stored on Flash memory. + GRE + IPsec must know the endpoint peer address. The spokes’ IP addresses are connected directly to the Internet via their own ISP, and they are often set up so that their external interface addresses are not fixed. ‘The IP addresses can change each time the site comes online (via DHCP). + If the spokes need to directly talk with each other over the IPsec VPN, then the hub-and-spoke network must become a full mesh. Since it is not already known which spokes will need to talk directly with each other, a full mesh is required, even though each spoke may not need to talk directly with every other spoke. Also, it is not feasible to configure IPsec on a small spoke router so that it has direct connectivity with all other spoke routers in the network; thus spoke routers may need to be more powerful routers. The DMVPN Solution The DMVPN solution uses Multipoint GRE (mGRE) and Next Hop Resolution Protocol (NHRP), with IPsec and some new enhancements, to solve the above problems in a scalable manner. Automatic IPsec Encryption Initiation ‘When not using the DMVPN solution, the IPsec encryption tunnel is not initiated until there is data traffic that requires the use of this IPsec tunnel. It may take 1 to 10 seconds to complete the initiation of the IPsec tunnel and data traffic is dropped during this time. When using GRE with IPsec, the GRE tunnel configuration already includes the GRE tunnel peer (tunnel destination ...) address, which also is the IPsec peer address. Both of these addresses are preconfigured If you use Tunnel Endpoint Discovery (TED) and dynamic crypto maps on the hub router, then you can avoid having to preconfigure the IPsec peer addresses on the hub, but a TED probe and response needs to be sent and received before ISAKMP negotiation can start, This should not be necessary since, when using GRE, the peer source and destination addresses are already known. They are either in the configuration or resolved with NHRP (for multipoint GRE tunnels). With the DMVPN solution, IPsec is triggered immediately for both point-to-point and multipoint GRE tunnels Also, itis not necessary to configure any crypto ACLs, since these will be automatically derived from the GRE tunnel source and destination addresses. The following commands are used to define the IPsec encryption parameters. Notice that there is no set peer ... or match address ... commands required because this information is derived directly from the associated GRE tunnel or NHRP mappings. czypto ipsec profile set traneforn-set The following command associates a tunnel interface with the IPsec profile. interface tunnel tunnel protection ipsec profile Dynamic Tunnel Creation for “Spoke-to-Hub” Links No GRE or IPsec information about a spoke is configured on the hub router in the DMVPN network . The spoke router's GRE tunnel is configured (via NHRP commands) with information about the hub router. When the spoke router starts up, it automatically initiates the IPsec tunnel with the hub router as described above. It then uses NHRP to notify the hub router ofits current physical interface IP address. This is useful for three reasons: + If the spoke router has its physical interface IP address assigned dynamically (such as with ADSL or CableModem), then the hub router cannot be configured with this information since each time the spoke router reloads it will get a new physical interface IP address. + Configuration of the hub router is shortened and simplified since it does not need to have any GRE or IPsec information about the peer routers. All of this information is learned dynamically via NHRP. ‘+ When you add a new spoke router to the DMVPN network, you do not need to change the configuration on the hub or on any of the current spoke routers. The new spoke router is configured with the hub information, and when it starts up, it dynamically registers with the hub router. The dynamic routing protocol propagates the routing information for this spoke to the hub. The hub propagates this new routing information to the bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 35122018 ‘Dynamic Multipoint sec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco other spokes. It also propagates the routing information from the other spokes to this spoke Dynamic Tunnel Creation for “Spoke-to-Spoke” Traffic As stated earlier, currently in a mesh network, all point-to-point IPsec (or Psec+GRE) tunnels must be configured on all the routers, even if some/most of these tunnels are not running or needed at all times. With the DMVPN solution, one router is the hub, and all the other routers (spokes) are configured with tunnels to the hub. The spoke-to-hub tunnels are up continuously, and spokes do not need configuration for direct tunnels to any of the other spokes. Instead, when a spoke wants to transmit a packet to another spoke (such as the subnet behind another spoke), it uses NHRP to dynamically determine the required destination address of the target spoke. The hub router acts as the NHRP server and handles this request for the source spoke. The two spokes then dynamically create an IPsec tunnel between them (via the single mGRE interface) and data can be directly transferred. This dynamic spoke-to-spoke tunnel will be automatically tom down after a (configurable) period of inactivity. Supporting Dynamic Routing Protocols The DMVPN solution is based on GRE tunnels which support tunneling multicast/broadcast IP packets, so the DMVPN solution also supports dynamic routing protocols running over the IPsec+mGRE tunnels. Previously, NHRP required you to explicitly configure the broadcast/mutticast mapping for the tunnel destination IP addresses to support GRE tunneling of Multicast and Broadcast IP packets. For example, at the hub you would need the ip nhrp map multicast configuration line for each spoke. With the DMVPN solution, the spoke addresses are not known in advance, so this configuration is not possible. Instead, NHRP can be configured to automatically add each spoke to the multicast destination list on the hub with the ip nlirp map multicast dynamic command. With this command, when the spoke routers register their unicast NHRP mapping with the NHRP server (hub), NHRP will also create a broadcast/multicast mapping for this spoke. This eliminates the need for the spoke addresses to be known in advance, Cisco Express Forwarding Fast Switching for mGRE Currently, traffic in an mGRE interface is process-switched, resulting in poor performance. The DMVPN solution adds Cisco Express Forwarding switching for the mGRE traffic, resulting in much better performance, There are no configuration commands necessary to tum on this feature. If Cisco Express Forwarding switching is allowed on the GRE tunnel interface and the outgoing/incoming physical interfaces, then the multipoint GRE tunnel packets will be Cisco Express Forwarding-switched. Using Dynamic Routing Over IPsec Protected VPNs This section describes the current (pre-DMVPN solution) state of affairs. IPsec is implemented on Cisco routers via a set of commands that define the encryption and then a crypto map command applied on the external interface of the router. Because of this design and the fact that there is not currently a standard for using IPsec to encrypt IP multicast/broadcast packets, IP routing protocol packets cannot be “forwarded!” through the IPsec tunnel and any routing changes cannot be dynamically propagated to the other side of the IPsec tunnel. Note: All dynamic routing protocols except BGP use broadcast or multicast IP packets, GRE tunnels are used in combination with IPsec to solve this problem. GRE tunnels are implemented on Cisco routers by using a virtual tunnel interface (interface tunnel<#>). The GRE tunneling protocol is designed to handle IP mutticast/broadcast packets so a dynamic routing protocol can be “run over” a GRE tunnel, GRE tunnel packets are IP unicast packets that encapsulate the original IP multicastiunicast packet. You can then use IPsec to encrypt the GRE tunnel packet. You can also run IPsec in transport mode and save 20 bytes since GRE has already encapsulated the original data packet so you do not need IPsec to encapsulate the GRE IP packet in another IP header. When running IPsec in transport mode, there is a restriction that the IP source and destination addresses of the packet to be encrypted must match the IPsec peer addresses (the router itself). In this case, this just means that the GRE tunnel endpoint and IPsec peer addresses must be the same. This is not a problem since the same routers are both the IPsec and GRE tunnel endpoints. By combining GRE tunnels with IPsec encryption, you can use a dynamic IP routing protocol to update the routing tables on both ends of the encrypted tunnel. The IP routing table entries for the networks that were leameed through the encrypted tunnel will have the other end of the tunnel (GRE tunnel interface IP address) as the IP next hop. Thus, if the networks change on either side of the tunnel, then the other side will dynamically leam of the change and bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 4st22018 Dynamic Mulpoin Psec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco connectivity will continue without any configuration changes on the routers. Base Configuration The following is a standard point-to-point IPsec+GRE configuration. After this there is a series of configuration examples where specific features of the DMVPN solution are added in steps to show the different capabilities, of DMVPN. Each example builds on the previous examples to show how to use the DMVPN solution in increasingly complex network designs. This succession of examples can be used as a template for migrating a current IPsec+GRE VPN to a DMVPN. You can stop "the migration” at any point if that particular configuration example matches your network design requirements, IPsec + GRE Hub and Spoke (n = 1,2,3, 192,168.0.0/2 wees Pee Encrypted GRE Tunnel 10.00. ON 10.0.0.<4nt1=/30 1000.5/30 172.1701 72.16.11 172.16..1 10.0.0.2/30 T0080 10.0.0. <4n#2> 130 172.16.2.1 SPOKE1 SPORE2 SPOKE 192.168.1.0/2 192.168.2.0/2 ute 192.168..0/ @ tub Router © crypto map vpnmapl local-address Ethernet crypto map vpnmapl 10 ipsec-isakmp set peor 172.16.1.1 set traneform-set trans? match address 101 crypto map vpnmapl 20 ipsec-isakmp set peer 172.16.2.1 set transforn-set trans? match address 102 crypto map vpnnapi <10*n> ipsec-isakmp set peer 172.16..1 set transforn-set trane2 match address hipiwwu.csco,cem/clenusisupportidocssecurty-vpnipsec-negatation-ike-protoclsl¢140-cmvpn ml282015 ‘Dynamic Multipoint sec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco interface Tunnel1 bandwidth 1000 ip address 10.0.0.1 255.255.255.252 4p meu 1400 delay 1000 tunnel source Ethernet0 tunnel destination 172.16.1.1 interface Tunnel2 bandwidth 1000 ip address 10.0.0.5 255.255.255.252 4p meu 1400 delay 1000 tunnel source Ethernet0 tunnel destination 172.16.2.1 interface Tunnel bandwidth 1000 Ap address 10.0.0.<4n-3> 255.255.255.252 ap meu 1400 delay 1000 tunnel source Ethernet0 tunnel destination 172.16..1 p address 272.17.0.1 255.255.255.0 crypto map vpnmapi p address 192.168.0.1 255.255.255.0 router eigep 1 network 10.0.0.0 0.0.0.255 network 192.168.0.0 0.0.0.255 no auto-sunmary ist 101 permit gre host 172.17.0.2 host 172.16.1.1 access-list 102 permit gre host 172.17.0.1 host 172.16.2.1 access-list permit gre host 172.17.0.1 host 172.16. 2 @ spoke1 Router @ version 12.3 name Spoke] crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco47 address 0.0.0.0 crypto ipsec transform-set trans? esp-des esp-nd5-hmac mode transport crypto map vpnnap! local-addrs crypto map vpnnapi 10 ipsec-isakmp set peer 172.17.0.1 set transforn-set trans? match address 101 Etherneto bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco interface Tunnelo bandwidth 1000 ip address 10.0.0.2 255.255.255.252 ip mtu 1400 delay 1000 tunnel source Ethernet0 tunnel destination 172.17.0.1 p address 172.16.1.1 255.25 crypto map vpnmapl rface Ethernet p address 192.168.1 router eigsp 1 network 10.0.0.0 0.0.0.255 network 192.168.1.0 0,0.0.255 no auto-summary access-list 101 permit gre host 172.16.1.1 host 172.17.0 2 @ spoke2 Router @ ypto isakmp po: exyple isakmp key crypte ipsec transform-set trans? esp-des esp-na5. crypto map vpnmapi crypto map vpnmapl set peer 172.17.0 set transforn-set trans? match address 101 interface Tunneld bandwidth 1000 4p address 10.0.0.6 255.255.255.252 ip mtu 1400 delay 1000 tunnel source Etherneto tunnel destination 172.17.0.1 face Ethernet o 26.2.1 255.25 crypto map vpnmapl nett p address 192.168.2.1 255.255.255.0 router eigzp 1 network 10,0.0.0 0.0.0.255 network 192.168.2.0 0.0.0,255 no auto-summary List 101 permit gre host 172.16.2.1 host 172.17.0 bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 751282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco ® spoke Router © version 12.3 ame Spoke ypto isakmp policy 1 crypto isakmp key cisco47 address 9.0.0.0 crypto ipsec transform-set trans? esp-des esp-nd5-hmac mode transport crypto map vpnmapl local-address Ethernet crypto map vpnmapi 10 ipsec-isakmp set peer 172.17.0.1 set transform-set trans? match address 101 interface Tunnelo bandwidth 1000 ip address 10.0.0.<4n-2> 255.255.255.252 ip mtu 1400 delay 1000 tunnel source Ethernet0 tunnel destination 172.17.0.1 6 112.16..1 255.285.2 crypto map vpnmapl fe Ethernet? p address 292.168..1 255.255 router eigsp 1 network 10.0.0.0 0.0.0.255 network 192.168..0 0.0.0.255 no auto-summary access-list 101 permit gre host 172.16..1 host 172.17.0 2 In the above configuration, ACLs are used to define what traffic will be encrypted. On both the hub and spoke routers, this ACL only needs to match the GRE tunnel IP packets. No matter how the networks change at either end, the GRE IP tunnel packets will not change, so this ACL need not change, Note: When using Cisco IOS software versions prior to 12.2(13)T, you must apply the crypto map vpnmap1 Configuration command to both the GRE tunnel interfaces (Tunnel) and the physical interface (Ethemet0). With Cisco 10S version 12.2(13)T and later, you only apply the crypto map vpnmap1 configuration command to the physical interface (Ethemet0). Examples of the Routing Tables on the Hub and Spoke Routers ® Routing Table on Hub Router © 172.17.0.0/24 is subnetted, 1 subnets c 0.0 is directly connected, Eth ° 30 d, subnete c 20 connected, Tunne c 4 dy Tunnel? bp.twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml‘Dynamic Multipoint sec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco 0.9.0,<4n-4> is directly connec 192.168.0.0/24 is directly connected, Ethernet! b 192.168.1.0/24 [90/2a41600) via 10.0.0.2, 18:28:19, Tunne: D 192.168.2.0. [90/2841600) via 10.0.0.6, 2405n, Tunnel? Db 192.168..0/24 600] via 10.0.0.<4n-2>, 2d05h, Tunnel ®© Routing Table on Spoke1 Router © 172.16.0.0/24 is subnetted, 1 subnets c 12.16.1.0 is directly connected, Btherneto 0.0.0.0/30 c 10.0.0.0 d, subne tly 0.0.4 [90/284160 > 10.0.0.<4n-4> [90/2841600] via 10.0.0.1, 23:00: D 192,268.0.0/26 (90/2861600) via 10.0.0.1, 23:00:58, Tunnel 2 © 192,168.1.0/24 de directly connected, Loopback® D — 1921168.210/24 (30/3087600) via 10.0.0.1, 23:00:88, Tunne: 2 Db’ 192,168..0/24 (80/3087600] via 10.0.0-1, 23:00:88, Tuna © Routing Table on Spoke Router © 172.16.0 subsets ¢ 1 y consected, Btherneto 10,0.0.0/30 1s subnetted, subne > 0.0.0-0 (30/2841600) via 10.0.0 o1:2t, Tunneio > 20.0.0-4 (90/2841600] via 10.0.0.1; 22:01:21, Tunnel é 10.0.0.<4n-4> is directly conne tnneio D 192,168.0.0/24 [30/2841600) via 10. 2 1b > 192.168.1.0/24 {90/3097600) via 10.0.0.1, 22 0 D —192.168.2.0/24 190/30 0.0.1, 22:01:21, Tunne 10 2 t52,168..0/24 t9 divectiy connected, Echerneco This is a basic working configuration, and is used as a starting point for comparison with the more complex configurations possible using the DMVPN solution, The first change will reduce the size of the configuration on the hub router. This is not important with small numbers of spoke routers, but it does become critical when there are more than 50 to 100 spoke routers Reducing the Hub Router Configuration Size In the following example, the configuration is minimally changed on the hub router from multiple GRE point-to- point tunnel interfaces to a single GRE multipoint tunnel interface. This is a first step into the DMVPN solution. ‘There is a unique block of configuration lines on the hub router to define the crypto map characteristics for each spoke router. This piece of the configuration defines the crypto ACL and the GRE tunnel interface for that spoke router. These characteristics are mostly the same for all the spokes, except for IP addresses (set peer tunnel destination ...). Looking at the above configuration on the hub router, you see that there are at least 13 lines of configuration per spoke router; four for the crypto map, one for the crypto ACL, and eight for the GRE tunnel interface. The bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 9stss2015 ‘Dynamie Muti IPse= VPNs (Using Mulpoit GREINHRP to Scale IPsec VPNs) - Cisco total number of configuration lines, if there were 300 spoke routers, is 3900 lines. You also need 300 (/30) subnets for addressing each tunnel link. A configuration of this size is very hard to manage and even more difficult when troubleshooting the VPN network. To reduce this value, you could use dynamic crypto maps, which would reduce the above value by 1200 lines, leaving 2700 lines in a 300-spoke network, Note: When using dynamic crypto maps, the IPsec encryption tunnel must be initiated by the spoke router. You can also use ip unnumbered to reduce the number of subnets needed for the GRE tunnels, but this may make troubleshooting more difficult later. With the DMVPN solution, you can configure a single multipoint GRE tunnel interface and a single IPsec profile on the hub router to handle all spoke routers. This allows the size of the configuration on the hub router to remain a constant, no matter how many spoke routers are added to the VPN network ‘The DMVPN solution introduces the following new commands: crypto ipsec profile tunnel protection ipsec profile ip nhrp map multicast dynamic ‘The crypto ipsec profile command is used like a dynamic crypto map, and it is designed specifically for tunnel interfaces. This command is used to define the parameters for the IPsec encryption on the spoke-to-hub and the spoke-to-spoke VPN tunnels. The only parameter that is required under the profile is the transform set. The IPsec peer address and the match address ... clause for the IPsec proxy are automatically derived from the NHRP mappings for the GRE tunnel. The tunnel protection ipsec profile command is configured under the GRE tunnel interface and is sed to associate the GRE tunnel interface with the IPsec profile. In addition, the tunnel protection ipsec profile command can also be used with a point-to-point GRE tunnel. In this case it will derive the IPsec peer and proxy information from the tunnel source ... and tunnel destination ... configuration. This simplifies the configuration since the IPsec peer and the crypto ACLs are no longer needed. Note: The tunnel protection ... command specifies that the IPsec encryption will be done after the GRE encapsulation has been added to the packet. These first two new commands are similar to configuring a crypto map and assigning the crypto map to an interface using the crypto map command, The big difference is that, with the new commands, you do not need to specify the IPsec peer address or an ACL to match the packets to be encrypted. These parameters are automatically determined from the NHRP mappings for the mGRE tunnel interface. Note: When using the tunnel protection ... command on the tunnel interface, a crypto map ... command is not configured on the physical outgoing interface. ‘The last new command, ip nhrp map multicast dynamic, allows NHRP to automatically add spoke routers to the multicast NHRP mappings when these spoke routers initiate the mGRE*IPsec tunnel and register their unicast NHRP mappings. This is needed to enable dynamic routing protocols to work over the mGRE+IPsec tunnels between the hub and spokes. If this command was not available, then the hub router would need to have a separate configuration line for a multicast mapping to each spoke. Note: With this configuration, the spoke routers must initiate the mGRE+IPsec tunnel connection, since the hub router isnot configured with any information about the spokes. But, this is not a problem because with DMVPN the mGRE+IPsec tunnel is automatically initiated when the spoke router starts up, and it always stays up Note: The following example shows point-to-point GRE tunnel interfaces on the spoke routers and lines of NHRP configuration added on both the hub and spoke routers to support the mGRE tunnel on the hub router. The configuration changes are as follows. @ hub Router (ola) © czypto map vpnnapl 10 TPsec-isakmp set peer 172.16.1.1 set transform: match address 101 crypto map vpnmapl 20 IPsec-isakmp set peer 172.16.2.1 bp.tww.csco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonhiml 0st et trans?282015 ‘Dynamic Multipoint sec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco set transforn-set trans? match address 102 crypto map vpnmap! <10n> rPse: set peer 172.16..1 set transforn-set trans? match address saknp interface Tunnel1 bandwidth 1000 ip address 10.0.0.1 255.255.255.252 ip mtu 1400 delay 1000 tunnel source Ethernet0 tunnel destination 172.16.1.1 interface Tunnel2 bandwidth 1000 ip address 10.0.0.5 255.255.255.252 Ap meu 1400 delay 1000 tunnel source Ethernet0 tunnel destination 172.16.2.1 interface Tunnel bandwidth 1000 ip address 10.0.0.<4n-1> 255.255.255.252 ap meu 1400 delay 1000 tunnel source Ethernet0 tunnel destination 172.16..1 p address 172.17.0.1 25 crypto map vpnmapi access-list 101 permit gre host 172.17.0.1 host 172.16.1.1 access-list 102 permit gre host 172.17.0.1 host 172.16.2.1 access-list permit gre host 172.17.0.1 host 172.16. 2 © hub Router (new) © cxypto ipsec profile vpnprof set transforn-set trans? interface Tunnel0 2000 10.0.0.1 255.255.255.0 ip mtu 1400 Ap nhzp authentication test Ap nhep map multicast dynamic ip nhrp network-id 100000 ip nhzp holdtime 600 no ip split-horizon eigep 1 delay 1000 tunnel mode gre multipoint tunnel key 100000 tunnel protection ipsec profile vpapr bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ke-protocols/¢1940-cmvonfiml ast282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco 001 ® spoke Router (old) © ypto map vpnmapl 20 IPsec-isakap set peer 172.17.0 tranefo 5 get trans? naten address 10 nterface Tunneld bandwidth 1000 Ap address 10.0.0.<4n-2> 255.255.255.252 ip meu 1400 felay 1000 puree Ethernet? tunnel destination 172.17.0.1 interface Ethernet0 ip address 272.16..1 295.255.255.252 cxypte map vpnmapl st 192.16..1 hos ® spoke Router (new) © apt 10 TPsecvisakap r 172.17.0 transform-set trans? ss 10 maten ade neerface Tunnel0 ° Ap address 10.0.0. 255.255.255.0 ip meu 1400 Ap nhzp authentication test Ap nhzp map 10.0.0.1 172.17.0.1 ip nhrp network-id 100000 ip nhzp holdtime 300 ip ahzp nhs 10.0.0.1 100 bandwia' estination 172.17.0 ‘tunnel key 100000 nit gre host 192.16..1 On the spoke routers, the subnet mask has changed, and NHRP commands have been added under the tunnel bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaton-ike-protocls/¢1940-cmvonhiml 281282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco interface. The NHRP commands are necessary since the hub router is now using NHRP to map the spoke tunnel interface IP address to the spoke physical interface IP address Ap address 10.0.0. 255.255.255.0 ip mtu 1400 Ap nhzp authentication test Ap nhrp map 10.0.0.1 172.17.0.2 ip mhrp network-id 100000 ip nhrp holdtime 300 ip nhrp nhs 10.0.0.1 tunnel key 100000 The subnet is now /24 instead of /30, so all of the nodes are in the same subnet, instead of different subnets. The spokes still send spoke-to-spoke traffic via the hub since they are using a point-to-point GRE tunnel interface. The ip nhrp authentication ..., ip nhrp network-id ... and tunnel key ... commands are used to map the tunnel packets and the NHRP packets to the correct multipoint GRE tunnel interface and NHRP network when they are received on the hub. The ip nhrp map ... and ip nhrp nhs ... commands are used by NHRP on the spoke to advertise the spokes NHRP mapping (10.0.0. -> 172.16..1) to the hub. The 10.0,0. address is retrieved from the ip address ... command on the tunnel interface and the 172.16. .1 address is retrieved from the tunnel destination ... command on the tunnel interface. In a case where there are 300 spoke routers, this change would reduce the number of configuration lines on the hub from 3900 lines to 16 lines (a reduction of 3884 lines). The configuration on each spoke router would increase by 6 lines. Supporting Dynamic Addresses on Spokes Ona Cisco router, each IPsec peer needs to be configured with the IP address of the other IPsec peer before the IPsec tunnel can be brought up. There is a problem with doing this if a spoke router has a dynamic address on its physical interface, which is common for routers that are connected via DSL or Cable links. TED allows one IPsec peer to find another IPsec peer by sending a special Intemet Security Association and Key Management Protocol (ISAKMP) packet to the IP destination address of the original data packet that needed to be encrypted. The assumption is that this packet will traverse the intervening network along the ‘same path as taken by the IPsec tunnel packet. This packet will be picked up by the other-end IPsec peer, which will respond to the first peer. The two routers will then negotiate ISAKMP and IPsec Security Associations (SAs) and bring up the IPsec tunnel. This will only work if the data packets to be encrypted have routable IP addresses. ‘TED can be used in combination with the GRE tunnels as configured in the previous section. This has been tested and works, though there was a bug in earlier versions of Cisco IOS software where TED forced all IP traffic between the two IPsec peers to be encrypted, not just the GRE tunnel packets. The DMVPN solution provides this and additional capabilities without the hosts having to use Intemet routable IP addresses and without having to send probe and response packets. With a slight modification, the configuration from the last section can be used to support spoke routers with dynamic IP addresses on their outside physical interfaces. @ tub Router (no change) @ co ipsee profile vpnprof et trans? nterface Tunnelo bandwidth 1000 ip address 20.0.0.1 255.255.255.0 p mez 1400 p nhzp authentic: ip nhrp map mul ponarp network-id 1 Pp narp holdtime 600 lit-horizon etgrp 1 vunnel source Ethernet? tunnel mode gre multip: tunnel key 200000 bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ke-protocols/¢1940-cmvonfiml 1381282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco tunnel protect of © spoke Router (old) © 0 1Psec-isakap maten address 10 access-list 101 permit gre host 172.16..1 host 172.17.0 2 O spokecn> Router (new) 0 1Psec~isaknp set security-association level per-host naten address 10 access-list 101 permit gre any host 172.17.0 1 The functionality that is used in the new spoke configuration is as follows. ‘+ When the GRE tunnel interface comes up, it will start sending NHRP registration packets to the hub router. These NHRP registration packets will tigger IPsec to be initiated. On the spoke router, the set peer and match ip access-list commands are configured. The ACL specifies GRE as the protocol, any for the source, and the hub IP address for the destination Note: It is important to note that any is being used as the source in the ACL, and this must be the case since the IP address of the spoke router is dynamic and, therefore, not known before the physical interface is active. An IP subnet can be used for the source in the ACL if the dynamic spoke interface address will be restricted to an address within that subnet. + The set security-association level per-host command is used so that the IP source in the spokes IPsec proxy will be just the spokes current physical interface address (/32), rather than the “any” from the ACL. If the "any" from the ACL were used as the source in the IPsec proxy, it would preclude any other spoke router from also setting up an IPsec+GRE tunnel with this hub. This is because the resulting IPsec proxy on the hub would be equivalent to permit gre host 172.17.0.1 any. This would mean that all GRE tunnel packets destined to any spoke would be encrypted and sent to the first spoke that established a tunnel with the hub, since its IPsec proxy matches GRE packets for every spoke. + Once the IPsec tunnel is set up, an NHRP registration packet goes from the spoke router to the configured Next Hop Server (NHS). The NHS is the hub router of this hub-and-spoke network. The NHRP registration packet provides the information for the hub router to create an NHRP mapping for this spoke router. With this mapping, the hub router can then forward unicast IP data packets to this spoke router over the mGRE+IPsec tunnel. Also, the hub adds the spoke router to its NHRP multicast mapping list. The hub will then start sending dynamic IP routing multicast packets to the spoke (if a dynamic routing protocol is configured). The spoke will then become a routing protocol neighbor of the hub, and they will exchange routing updates. IPsec + mGRE Hub and Spoke bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml ast22018 Dynamic Mulpoin Psec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco 192.168.0.0/2 mmm [PSC° Encrypted HUB. GRE Tunnel 72.17.01 10.0.0.1/24 [Dynamic Addresses 10.00.2124 10.0.0.4/24 os SPOKE SFORE2 SPOKEen> 192, 168.1.012 192.158.2.0/2 ute 192.168. .0/ O tub Router O crypto ipsec transform-set trans? esp-des eep-mdS-hm nee Tunnelo bandwidth ip address 10.0.0.1 255.255.255.0 ipa ime 60 no ip split-horizon eigrp 1 © Etherne! ipsec prof. k 10 hipiwwu.cisco,cem/clenusisupporidocssecurty-vpripsec-negotaton-ike-protoclsl¢19¢0-cmvpn ml282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco no auto-eunnary Notice in the above hub configuration that the IP addresses of the spoke routers are not configured. The spoke’s extemal physical interface and the mapping to the spokes tunnel interface IP addresses are leamed dynamically by the hub via NHRP. This allows the spoke’s extemal physical interface IP address to be dynamically assigned. © spoket Router O on 12.3 nostname Spokel crypto isakmp policy 1 isco4? address 0.0 isakne key ransform-set trans2 esp-des hmac czypte ips node transpor! map vpnmapl lecal-address Ethernetd Psec-isaxmp map vena fer 172.17.0. curity-association level pex-host set transform-set trans? Lon maven addre nterface Tunneld bandwidth 1000 Ap address 10.0.0.2 255.255.255.0 pomty 1400 nnzp authentication test sp nazp map 10.0.0.1 172.17.0.1 Pp narp network-id 100000 delay 1000 tunnel source Ethernetd unnel destination 172.17.0.1 tunnel key 200000 Ap address dhcp hostname spoke erypte map vpnnap’ thernets 268.1.1 255.258.255.0 access-list 101 permit gre 172.16.1.0 0.0.0.255 host 172.17.0 2 © spokez Router O version 12.3 crypto isakmp policy 1 bp.twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 681‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco cation pre-share kmp key cisco: ads ee transform-set Lrans2 esp-des esp-ndS-hmac map vpnmapl loca ypto map vpnmapl 10 IPsec-isaknp set peer 172.17.0 set security-association level per-host, nterface Tunnelo bandwidth 1000 Ap address 10.0.0.3 255.255.255.0 p mts 1400 p arp authentication tes map 10.0.0.1 172.17.0.1 po narp network-ia 100000 p nhs 10.0.0.1 delay 1000 255.0 network 192.168.1.0 0.0.0 access-list 101 permit gre 172.16.2.0 0.0.0.255 host 172.17.0 1 The primary things to notice about the spoke configurations are: ‘+ The extemal physical interface (ethernet) IP address is dynamic via DHCP. ip address dhcp hostname Spoke2 + The crypto ACL (101) specifies a subnet as the source for the IPsec proxy. access-list 101 permit gre 172.16.2.0 0.0.0.255 host 172.17.0.1 + The following command in the IPsec crypto map specifies that the security association will be per host. set security-association level per-host + All of the tunnels are part of the same subnet, since all of them connect via the same multipoint GRE terface on the hub router. ip address 10,0.0.2 255.255.255.0 ‘The combination of these three commands make it unnecessary for the spoke’s extemal physical interface IP address to be configured. The IPsec proxy that is used will be host-based rather then subnet-based. ‘The configuration on the spoke routers does have the IP address of the hub router configured, since it needs to initiate the IPsec+GRE tunnel, Notice the similarity between the Spoke and Spoke2 configurations. Not only are these two similar, but all of the spoke router configurations will be similar. In most cases, all the spokes simply need unique IP addresses on their interfaces, and the rest of the their configurations will be the same, This makes it possible to configure and deploy many spoke routers quickly. ‘The NHRP data looks like the following on the hub and spoke. bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 781282015 ‘Dynamic Multipoint sec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco O tub Router O dubtshow ip ahzp 0.0.0.2/32 via Type: dynamic, 0.2, Tunneld created 01:25:18, expire 00:0 gs: authoritative Naya, 4 0.0 } Tunnel created 00:06:02, expire 00:04:03, Type: dynamic, Flags: authoritative unique registered Naya, = 10 0.0.0./32 via 10.0,0., Tunnel0 created 00:06:00, expize 00:04 type: dynamic, Flags: authoritative unique registered NEMA ad 212.16. © spoke Router O kel#she ip abrp 0.0.0.1/32 via -0.0.1, Tunneld created 4d98h Type: static, Flags: authoritative NBA address? 172.17.0.1 Dynamic Multipoint Hub and Spoke ‘The configuration on the spoke routers above does not rely on features from the DMVPN solution, so the spoke routers can run Cisco IOS software versions prior to 12.2(13)T. The configuration on the hub router does rely on DMVPN features, so it must run Cisco 10S version 12.2(13)T or later. This allows you some flexibility in deciding when you need to upgrade your spoke routers that are already deployed. If your spoke routers are also running Cisco IOS version 12.2(13)T or later, then you can simplify the spoke configuration as follows. © spokecn> Router (prior to Cisco 10S 12.2(13)T) O czypto map vpnmapl 10 IPsec-isakmp set peer 172.17.0.1 set security-association level per-host, set transform-set trane2 match addzess 102 nterface Tunnelo bandwidth 1000 Ep address 20.0.0. 400 authentication tes! map 10.0.0.1 172.17.0.1 network-id 100000 holdt ime phe 10.0. delay 100 rneto 172.17.0.1 tunnel destin tunnel key 20 interface Ethernet p address dhop hostname Spoke crypto map vpnmapi “List 101 permit gre any host 172.17.0.1 bip.twww.cisco.com/clelus/supportidocsisecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml sat282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco O spoke Router (after Cisco 10S 12.2(13)T) O czypto ipsec profile vpnprof set transforn-set trans? nterface Tunneld bandwidth 1000 ip address 20.0.0. 255.255.259.0 po mty 1400 authentication et Ep arp map 10.0.0.1 172.17.0.1 p nhrp network-id 100000 sp nazp holdtime 300 ponnrp nhs 10.0.0. delay 1000 tunnel Etherne| tunnel destination 172.17.0 tunnel key 100000 tunnel protection ipsec profile vpnprof erneto 5 dhep hostname Spoke Notice that we have done the following} L Removed the crypto map vpnmap! 10 ipsec-isakmp command and replaced it with crypto ipsec profile vpnprof. Removed the crypto map vpnmap1 command from the Ethemet0 interfaces and put the tunnel protection ipsec profile vpnprof command on the Tunnel0 interface. 3, Removed the crypto ACL, accessdist 101 permit gre any host 172.17.0.1 In this case the IPsec peer addresses and proxies are automatically derived from the tunnel source ... and tunnel destination ... configuration. The peers and proxies are as follows (as seen in the output from show crypto Ipsec sa command): al ident (addr/mask/prot/port (172.16,1.24/255 emote ident (addr/mask/prot/p (172.17,0.1/255 al crypto endpt.: 172.17.1.24, remote crypto endpt.+172.17.9 In summary, the following full configurations include all of the changes made up to this point from the Base Configuration (IPsec+GRE hub and spoke) O Hub Router O version 12.3 ypto isakmp policy 1 crypto isakmp key cisco4? address 9.0.0.0 crypto ipsec transform-set trans? esp-des esp-ndS-hm rans? bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ke-protocls/¢1940-cmvonfiml s3819252015 ‘Dynamic Multipoint sac VPNs (Using Mulipaint GREINHRP to Scale IPsec VPNs) - Cisco interface Tunnel0 bandwidth 1000 ip address 10.0.0.1 255.255.255.0 ip mtu 1490 ip nhrp authentication test ip nhrp map multicast dynamic ip nhrp network-id 100000 ip nhrp holdtime 600 no ip split-horizon eigrp 1 delay 1000 tunnel source Etherneto tunnel mode gre multipoint tunnel key 200000 tunnel prot. jon ipsec profile vpnprof rface Etherneto address 172.17.0.1 255.255.255.0 rface Ethernet? address 292.168.0.1 255.255.255.0 router eigep 1 network 10.0.0.0 0.0.0.255 network 192.168.0.0 0.0.0.255 no auto-sumnary ‘There are no changes in the hub configuration O spoke1 Router O version 12.3 name Spoke] crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0 crypto ipsec transforn-set trans? esp-des esp-nd5-hnac node transport, crypto ipsec profile vpnprof set transform-set trans? serface Tunneld bandwidth 1000) ip address 10.0.0.2 255.255.255.0 ip mtu 1490 ip nhrp authentication test Sp nhrp map 10.0.0.1 172.17.0.1 ip nhrp network-id 100000 ip nhrp holdtime 300 ip nhrp nhs 10.0,0.1 delay 1000 tunnel source Etherneto tunnel destination 172.17.0.1 tunnel key 700000 tunnel protection ipsec profile vpnprof rface Etherneto address dhcp hostname spoke2 eface Ethernet! ip addvess 192,168.1.1 255.255.255.0 bptwwn sco. comiclenusisupportidocsisectrty-vpnipsee-negotaton-ike-protocols/¢1940-emvpn ml ast282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco O spoke2 Router O fon 12.3 hostname spoke? crypto node transpe crypto ipsec profile vpnprof set transforn-set trans? bandwidth 1000 ip nhrp map 10.0.0.1 172.17.0.1 Pp nhrp network-ia 100000 delay 1 Etherneto 172.17.0 tunnel dest:nat 00 tunnel protection ipsec profile vpnprof tunnel key 200 nverface Etherneto p address dhep n name Spoke2 nverface ethernet! 92.168.2.1 25: Dynamic Multipoint IPsec VPN ‘The concepts and configuration in this section show the full capabilities of DMVPN. NHRP provides the capability for the spoke routers to dynamically lean the exterior physical interface address of the other spoke routers in the VPN network. This means that a spoke router will have enough information to dynamically build an IPsec+mGRE tunnel directly to other spoke routers. This is advantageous since, if this spoke-to-spoke data traffic was sent via the hub router, then it must be encryptedidecrypted, twice increasing the delay and the load on the hub router. In order to use this feature, the spoke routers need to be switched from point-to- point GRE (p-pGRE) to multipoint GRE (mGRE) tunnel interfaces. They also need to leam the (sub)networks that are available behind the other spokes with an IP next-hop of the tunnel IP address of the other spoke router. The spoke routers leam these (sub)networks via the dynamic IP routing protocol running over the bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 21stss2015 ‘Dynamie Muti IPse= VPNs (Using Mulpoit GREINHRP to Scale IPsec VPNs) - Cisco IPsec+mGRE tunnel with the hub. ‘The dynamic IP routing protocol running on the hub router can be configured to reflect the routes leamed from ‘one spoke back out the same interface to all of the other spokes, but the IP next-hop on these routes will usually be the hub router, not the spoke router from which the hub leamed this route. Note: The dynamic routing protocol only runs on the hub and spoke links, it does not run on the dynamic spoke-to-spoke links. The dynamic routing protocols (RIP, OSPF and EIGRP) need to be configured on the hub router to advertise the routes back out the mGRE tunnel interface and to set the IP next-hop to the originating spoke router for routes learned from one spoke when the route is advertised back out to the other spokes. The following are requirements for the routing protocol configu RIP ‘You need to tum off split horizon on the mGRE tunnel interface on the hub, otherwise RIP will not advertise routes learned via the mGRE interface back out that same interface. no ip split-horizon No other changes are necessary. RIP will automatically use the original IP next-hop on routes that it advertises back out the same interface where it learned these routes. EIGRP ‘You need to tum off split horizon on the mGRE tunnel interface on the hub, otherwise EIGRP will not advertise routes learned via the mGRE interface back out that same interface. no ip split-horizon eigrp Note: The no ip next-hop-self eigrp command will be available starting in Cisco OS release 12.3(2). For Cisco 10S releases between 12.2(13)T and 12.3(2) you must do the following: ‘+ If spoke-lo-spoke dynamic tunnels are not wanted, then the above command is not needed. + If spoke-to-spoke dynamic tunnels are wanted, then you must use process switching on the tunnel interface on the spoke routers + Otherwise, you will need to use a different routing protocol over the DMVPN. OSPF Since OSPF is a link-state routing protocol, there are not any split horizon issues. Normally for multipoint interfaces you configure the OSPF network type to be point-to-multipoint, but this would cause OSPF to add host routes to the routing table on the spoke routers. These hosts routes would cause packets destined to networks behind other spoke routers to be forwarded via the hub, rather then forwarded directly to the other spoke. To get around this problem, configure the OSPF network type to be broadcast using the command, ip ospf network broadcast ‘You also need to make sure that the hub router will be the Designated Router (DR) for the IPsectmGRE network. This is done by setting the OSPF priority to be greater than 1 on the hub and 0 on the spokes. + Hub: ip ospf priority 2 + Spoke: ip ospf priority 0 DMVPN Single Hub bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 22081282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco 192. 168.0.0/2 —_— HUI Static Dynamic 172.17.0.1 SPOKE1 — SPOKE«n> SPORE2 - 192,168. 1.0/2 192.168. .0F 192, 168.2.0/2 O tub Router O crypto isakmp policy 1 cats crypto isakme key sco47 address 0.0 cypte eransform-set rans2 esp-des esp-ndS-hm crypte ipsec profits vpnprof set transfor -set trans? p narp network-ia 100000 ip nhzp holdtine 600 ip ospf network broadcast 4p ospf priority 2 interface Etherneto p address 272.17.0.1 255.255.255.0 interface Ethernet p address 192.168.0 55.0 bp:tww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 2381282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco router ospf 1 network 10.0.0.0 0.0.0.255 area 0 network 192.168.0.0 0.0.0.255 area 0 ‘The only change in the hub configuration is that OSPF is the routing protocol instead of EIGRP. Notice that the OSPF network type is set to broadcast and the priority is set to 2. Setting the OSPF network type to broadcast will cause OSPF to install routes for networks behind the spokes routers with an IP next-hop address as the GRE tunnel address for that spoke router. O spoke1 Router O nostname Spokel crypto isakep po jent ication crypto ipsec transforn-set trans? esp-des eep-ndS-hmac node transport, cxypte ipsec profiie venprof neforn-set trans? ace Tunnel0 bandwidth 1000 p address 20.0.0.2 255.255.255.0 p mtu 1400 authentication test map multicast 172.17.0.1 map 10,0.0.1 172.17.0.1 000 network-id holdtime 300 phe 10.0.0.1 network broadcast priority 0 tunnel source Ethernetd tunnel mode gre multipoint tunnel key 200000 tunnel protection ipsec profile vpnprof face Etherneto p address dhep hostname Spokel interface Ethernet p address 292.168.1 router ospf 1 network 10.0.0.0 0.0.0.255 area 0 network 192.168.1.0 0.0.0.255 area 0 ‘The configuration on the spoke routers is now very similar to the configuration on the hub. The differences are as follows: + The OSPF priority is set to 0. The spoke routers cannot be allowed to become the DR for the mGRE nonbroadcast multiaccess (NBMA) network. Only the hub router has direct static connections to all spoke routers. The DR must have access to all members of the NBMA network. ‘= There are NHRP unicast and multicast mappings configured for the hub router. bptwwn isco. cemiclenusisupportidocs/sectrty-vpnipsee-negotaton-ike-protocols/¢1940-emvpn ml282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco Ap nhrp map multicast 172,17.0.1 Ap ahzp map 10.0.0.1 172.17.0.1 In the previous configuration, the ip nhrp map multicast ... command was not needed since the GRE tunnel was point-to-point. In that case, multicast packets will be automatically encapsulated through the tunnel to the single possible destination. This command is now needed because the spokes GRE tunnel has changed to multipoint and there is more then one possible destination. + When the spoke router comes up, it must initiate the tunnel connection with the hub, since the hub router is not configured with any information about the spoke routers, and the spoke routers may have dynamically assigned IP addresses. The spoke routers are also configured with the hub as their NHRP NHS ip hep ahs 10.0.0.1 With the above command, the spoke router will send NHRP Registration packets through the mGRE+|Psec tunnel to the hub router at regular intervals. These registration packets provide the spoke NHRP mapping information that is needed by the hub router to tunnel packets back to the spoke routers. O spoke2 Router O version 12.3 hostname Spoke? ypto isakmp policy 1 crypte isakmp key cisco47 address 0.0.0.0 0.0.0.0 crypte ipsec transform node transport ip mtu nap multicast 172.17.0.1 map 10.0.0.1 172.17.0.1 network-ia 100000 holdtime 300 phe 10.9.0.1 network broade: priority 0 delay 1000 tunnel mode gre multipoint unnel key 200000 tunnel protection ipsec profile vpnprof hep ho: Jame Spekel p address 192.168.3,1 255.255.255.0 router ospf 1 network 10.0.0.0 0.0,0.255 area 0 network 192.168.2.0 0.0.0.255 area 0 bp:twww.cisco.com/cleius/supportidocssecurty-vpnipsec-negotaon-ke-protocls/¢1940-cmvonhiml 2581282015 ‘Dynamic Multipoint Psec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco O spoke Router O ion 12.3 crypto isakmp policy 1 authentication p: ypto isakmp key ypto ipsec transform-set trans? erypte ipsec profite vpnprof set transforn-set trans? interface Tunne19 bandwidel authentication ponhrp map multicast ponhrp map 10.0.0.1 p aarp network-id holdtime 200 p nhzp nhs 10.0.0.1 Ap ospf network broadcast ip ospf priority 0 delay 1000 tunnel source Ethernet? tunnel mode gre multipoint tunnel key 200000 unnel protection ipsec profile vpnprof ace Etherneto hep ho} ame Spoke © Ethernet? ip address 292.168..1 255.255 router ospf 1 network 10.0.0.0 0.0.0.255 area 0 network 192.168..0 0.0.0.255 area 0 Notice that the configurations of all of the spoke routers are very similar. The only differences are the IP addresses on the local interfaces. This helps when deploying a large number of spoke routers. All of the spoke routers can be configured identically, and only the local IP interface addresses need to be added. At this point, take a look at the routing tables and the NHRP mapping tables on the Hub, Spoke1, and Spoke2 routers to see the initial conditions (ust after the Spoke and Spoke2 routers come up) and the conditions after Spoket and Spoke2 have created a dynamic link between them Initial Conditions O Hub Router Information O Hubtshow ip route 72.17.0.0/24 is subnetted, 1 subnets c 12.17.0.0 is directly connected, Btherneto 10.0.0.0/24 is subnetted, 1 subnets c 0.0.0.0 is directly connected, Tunnel0 bp.twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml a19252015 ‘Dynamic Multipoint sac VPNs (Using Mulipaint GREINHRP to Scale IPsec VPNs) - Cisco © 192.168.0.0/24 is directly connected, Ethernett © 192.168.1.0/24 [110/2) via 10.0.0.2, 00:19:53, Tunneld © 192.168.2.0/24 [110/2] via 10.0.0.3, 00:19:53, Tunneld Hubéshow ip nhrp 10.0.0.2/32 via 10.0.0.2, Tunnel0 created 00: 13 ‘ype: dynamic, Flags: authoritative unique registered NBMA address: 172.16.1.24 10.0.0.3/32 via 10.0.0.3, Tunnel0 created 07:1 33 ‘Type: dynamic, Flags: authoritative unique registered NBMA address: 172.16.2.75 HubYshow crypt engine connection active o0:04 25, expire 00:04: ID Interface IP-Address State Algorithm Encrypt Decr yet 204 EthernetO 172.17.0.1 set -HMAC_SHASDES_56.CB 0 0 205 EthernetO 172.17.0.1 set ~HMAC_SHAHDES_S6_cB 0 a 2628 Tunnel 10.0.0.1 set HMAC_MDS ° 40 2 2629 Tunnel 10.0.0.2 set EMAC MDS 257 0 2630 Tunnel0 —10.0.0.2 set EMAC MDS 0 42 2631 Tunnel9 —10.0.0.1 set BMAC_MDS 308 o O spoket Router Information O Spoxelfshow ip route 172.16.0.0/24 is subnetted, 1 subnete c 172.16.1.24 is directly connected, Ethernet 10.0.0.0/24 is subnetted, 1 subnets c 10.0.0.0 is directly connected, Tunneld © 192.168.0.0/24 [110/2] via 10.0.0.1, 00:32:46, Tunneld © 192.168.1.0/24 is directly connected, Ethernetl © 192.168.2.0/24 [110/2] via 10.0.0.3, 00:31:46, Tunnelo Spokel#show 4p ahzp 10.0.0.1/32 via 10.0.0.1, Tunnel created 01:42:00, never expiv: ‘Type: static, Flags: authoritative used NEMA address! 172.17.0.2 Spokeltshow exypte engine connection active =D Interface TP-Addrees State Algorithm Enerypt Decry pt 2 SchernetO 172.16.1.74 set -HMAC_SHAFDES_56_cB 0 0 2064 Tunneld ——«10.0.0.2 set HMAC MDS 0 laa 2065 Tunnel 10.0.0.2 set EMAC MDS 216 0 O spoke2 Router Information O spoke2#show ip route 172.16.0.0/24 is subnetted, 1 subnete c 172.16.2.0 is directly connected, Ethernet0 10.0.0.0/24 is subnetted, 1 subnet. 10.0.0.0 is directly connected, Tunneld 192.168.0.0/24 [110/2] via 10.0.0.1, 00:38:52, Tunnela 192.168-1.0/24 [10/2] via 10.0.0.2, 00:38:52, Tunnelo 192.168.2.0/24 is directly connected, Ethernet? Spoke2tshow ip nhzp 10.0.9.1/32 via 10.0.0.1, Tunnel0 created 01:32:10, never exp. ‘Type: static, Flags: authoritative used NBMA address! 172.17.0.1 Spoke24show erypte engine connection active bptwwn cisco. comicienusisupportidocsisectrty-vpnipsee-negotaton-ike-protocols/¢1940-emvpn ml ast282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco State Algori ypt Dec 7 sthernecO 172.16.2. set IMAC _SUA+DES_56.cB 0 2070 Tunnel 10.0.0.3 set EMAC MDS oan 2071 Tunnel 10.0.0.3 set EMAC MDS 216 o At this point we ping from 192.168. 1.2 to 192. 168.2.3. These addresses are for hosts behind the Spoke1 and Spoke? routers, respectively. The following sequence of events takes place to build the direct spoke-to-spoke mGRE+IPsec tunnel |, The Spoke1 router receives the ping packet with the destination 192.168.2.3. It looks up this destination in the routing table and finds that it needs to forward this packet out the Tunnel0 interface to the IP nexthop, 10.0.0.3. ‘The Spoket router checks the NHRP mapping table for the destination 10.0.0.3 and finds that there is not an entry. The Spoket router creates an NHRP resolution request packet and sends it to its NHS (the Hub router), 3. The Hub router checks its NHRP mapping table for the destination 10.0.0.3 and finds that it maps to the address 172.16.2.75, The Hub router creates an NHRP resolution reply packet and sends it to the Spoke’ router. }. The Spoket router receives the NHRP resolution reply, and it enters the 10.0.0.3 —>172,16,2.75 mapping in its NHRP mapping table. The addition of the NHRP mapping triggers IPsec to initiate an IPsec tunnel with the peer 172.16.2.75. 5. The Spoket router initiates ISAKMP with 172.16.2.75 and negotiates the ISAKMP and IPsec SAs. The IPsec proxy is derived from the Tunnel0 tunnel source

command and the NHRP mapping Jocal ident (addr/mask/prot/port) : (172-16.1.24/255.255.255.255/47/0) remote ident (addr/mask/prot/port) : (172.16.2.75/255.255.255,255/47/0) 5. Once the IPsec tunnel has finished being built, all further data packets to the 192.168.2.0/24 subnet are sent directly to Spoke2. '. After a packet destined to 192.168.2.3 has been forwarded to the host, this host will send a retum packet to 192.168. 1.2. When the Spoke2 router receives this packet destined to 192,168.1.2, it will look up this destination in the routing table and find that it needs to forward this packet out the Tunnel0 interface to the IP next-hop, 10.0.0.2. 3. The Spoke2 router checks the NHRP mapping table for the destination 10.0.0.2 and finds that there is not an entry. The Spoke2 router creates an NHRP resolution request packet and sends it to its NHS (the Hub router), 3. The Hub router checks its NHRP mapping table for the destination 10.0.0.2 and finds that it maps to the address 172.16.1.24, The Hub router creates an NHRP resolution reply packet and sends it to the Spoke2 router. The Spoke? router receives the NHRP resolution reply, and it enters the 10.0.0.2 —> 172,16.1.24 mapping its NHRP mapping table. The addition of the NHRP mapping triggers IPsec to initiate an IPsec tunnel with the peer 172.16.1.24, but there already is an IPsec tunnel with peer 172.16.1.24, so nothing further needs to be done. |. Spoket and Spoke2 can now forward packets directly to each other. When the NHRP mapping has not been used for forwarding packets for the holdtime, the NHRP mapping will be deleted. The deletion of the NHRP mapping entry will trigger IPsec to delete the IPsec SAs for this direct link. Conditions After a Dynamic Link Is Created Between Spoke’ and Spoke2 O spoket Router Information O Spokel4show ip ahxp 10.0.0.1/32 via 10.0.0.1, Tunnel created 02:34:16, never expire pei static, Flags: authoritative used NBMA address 0.2 0.0.0.3/32 via 10.0.0.3, Tunnel created 00:00:05, expire 00:03:35 bp.twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml ast282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco type: dynanic, rout NBMA address: 172.16.2.75 spokel¥show ezypto engine connection active =D Interface [P-Address State Algorit Pt 2 Etherneco 6.1.24 set HMAC_stia+DE ° 0 3 Etherneso 6.1.24 get HMAC SHA+DES_56_ ° 0 2064 Tunnelo 0.2 set 0 o3T5 2065 Tunnel0 0.2 set HMAC MDS a6 0 2066 Tunneld 0.2 set EMAC MDS ° 20 2067 Tunnelo 0.2 pet 9 0 O spoke2 Router Information O spoke2#shew ip ahzp 10.0.0.1/22 via 10.0.0.1, TunnelO created 02:18:25, never exp: ype: static, Flags: authoritative used NBMA address: 172.17.0. 10.0.0.2/22 via 10.0.0.2, TunnelO created 00:00:24, expire 00:04:35 ype: dynanic, Flags: BMA addzess: 172.16 Spoke2¥show crypto engine connection active rface IP-Address State Algor nerypt Decry 27 EthernetO 172.16.2.75 set -EMAC_SEAtDES 56 ° o 8 EthernetO 172.16.2.75 set. EMAC _SHASDES 56CB 0 a neld—10,0.0.3 set EMAC MDS 40 2071 tunneld —10.0.0.3 set EMAC MDS 0 2072 Tunnel0 0.0.0.3 set 1IMAC_M 1s 2073 Tunnel 10.0.0.3 set EMAC MDS 0 From the above output you can see that Spoke1 and Spoke2 have gotten NHRP mappings for each other from the Hub router, and they have built and used an mGRE+IPsec tunnel. The NHRP mappings will expire after five minutes (the current value of NHRP holdtime = 300 seconds). If the NHRP mappings are used within the last minute before expiring, then an NHRP resolution request and reply will be sent to refresh the entry before it is deleted. Otherwise, the NHRP mapping will be deleted and that will trigger IPsec to clear the IPsec SAs. Dynamic Multipoint IPsec VPN with Dual Hubs With a few additional configuration lines to the spoke routers you can set up dual (or multiple) hub routers, for redundancy. There are two ways to configure dual hub DMVPNs + Asiingle DMVPN network with each spoke using a single multipoint GRE tunnel interface and pointing to two different hubs as its Next-Hop-Server (NHS). terface. The hub routers will only have a single multipoint GRE tunnel ‘+ Dual DMVPN networks with each spoke having two GRE tunnel interfaces (either point-to-point or multipoint) and each GRE tunnel connected to a different hub router, Again, the hub routers will only have a single multipoint GRE tunnel interface The following examples will look at configuring these two different scenarios for dual hub DMVPNs. In both cases, the highlighted differences are relative to the DMVPN single hub configuration, Dual Hub - Single DMVPN Layout ‘The dual hub with a single DMVPN layout is fairly easy to set up, but it does not give you as much control ‘over the routing across the DMVPN as the dual hub with dual DMVPNs layout does. The idea in this case is to have a single DMVPN “cloud” with all hubs (two in this case) and all spokes connected to this single subnet (“cloud”). The static NHRP mappings from the spokes to the hubs define the static IPsec+mGRE links over which the dynamic routing protocol will run, The dynamic routing protocol will not run over the dynamic IPsec+mGRE links between spokes. Since the spoke routers are routing neighbors with the hub routers over the same mGRE tunnel interface, you cannot use link or interfaces differences (like metric, cost, delay, or bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml ast282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco bandwidth) to modify the dynamic routing protocol metrics to prefer one hub over the other hub when they are both up. If this preference is needed, then techniques intemal to the configuration of the routing protocol must be used. For this reason, it may be better to use EIGRP or RIP rather than OSPF for the dynamic routing protocol Note: The above issue is usually only a problem if the hub routers are co-located. When they are not co- located, normal dynamic routing will likely end up preferring the correct hub router, even if the destination network can be reached via either hub router. Dual Hub - Single DMVPN Layout 192.168.0.0/2 Static Static HUB HUB-2 vee 172.17.0.1]-——» 172.17.05 > SPOKE! Sa SPOKE SPOKE2 192.168.1.072 192.168 .0/ 192, 168.2.0/2 © tub Router © address 9.0.0.9 crypto ipse: node ransform. tran 2 esp-des eep~i crypte ipsec profile vpnprof se eet teane ans? nverface Tunnel0 bandwidth 1000 10.0.0.1 255.255.255.0 400 p authent: map mul cion test network-id 100000 holdtime 600 network broadcast priority 2 bip.twww.csco.com/cleius/supportidocsisecurty-vpnipsec-negotaton-ike-protocls/¢1940-cmvonfiml 3051282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco delay 1000 nnel mode gre multipe key 200000 tunnel protection ipsec profile vpnprof rneto p address 272.17.0.1 interface Ethernet? p address 192.168.0.1 255.255.255.0 router ospf 1 network 10.0.0.0 0.0.0.255 area 1 network 192.168.0.0 0.0.0.255 area 0 © tub2 Router O hostname lub? ceypto isaknp po cyl 2 0.0.0.0 crypto Ssakmp key cisco47 addy crypto ipsec transform-set trans: esp-des esp-nd czypte ips set traneform-set trans? interface Tunnel0 bandwidth 900 Ap address 10.0.0.2 255.255.255.0 a Ap ahep map 10.0.0.1 172.17.0.1 Ap nhzp map multicast 172.17.0.1 p nhrp map multicast dynamic 0 pomty 14 Pp narp network-Ld 100 ip nhgp holdtime 600 pnarp nhs 10.0.0. P ospf network broadcast Ap ospf priority 1 delay 1000 tunnel mode gre multip. cunnel key 100000 source Ethernet0 eunnel prot ion ipsec profile Sp address 212,17.0.9 259,259.255.0 verface Ethernet? p address 292.168.0.2 299.295.255.0 router ospf 1 network 10.0.0.0 0.0.0.255 area 1 network 192.168.0.0 0.0.0.255 area 0 bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 3st5015 ‘Dyrami Mulipie Pes VPNs (Using Mulipirt GRENHRP to Scale IPsec VPNs) - Cisco ‘The only change in the Hub1 configuration is to change OSPF to use two areas. Area 0 is used for the network behind the two hubs, and area 1 is used for the DMVPN network and networks behind the spoke routers. OSPF could use a single area, but two areas were used here to demonstrate the configuration for multiple OSPF areas. ‘The configuration for Hub2 is basically the same as the Hubt configuration with the appropriate IP address changes. The one main difference is that Hub2 is also a spoke (or client) of Hub1, making Hub1 the primary hub and Hub2 the secondary hub. This is done so that Hub2 is an OSPF neighbor with Hub1 over the mGRE tunnel. Since Hub! is the OSPF DR, it must have a direct connection with all other OSPF routers over the mGRE interface (NBMA network). Without the direct link between Hub1 and Hub2, Hub2 would not participate in the OSPF routing when Hub1 is also up. When Hub1 is down, Hub2 will be the OSPF DR for the DMVPN (NBMA network). When Hub1 comes back up, it will take over being the OSPF DR for the DMVPN. The routers behind Hub1 and Hub2 will use Hub‘ for sending packets to the spoke networks because the bandwidth for the GRE tunnel interface is set to 1000 Kb/sec versus 900 Kb/sec on Hub2. In contrast, the spoke routers will send packets for the networks behind the hub routers to both Hub1 and Hub2, since there is only a single mGRE tunnel interface on each spoke router and there will be two equal cost routes. If perpacket load balancing is being used this can cause out-of-order packets, © spoket Router O node transport ypto ipsec profile vpnprof set transforn-set trang? sface Tunnelo bandwidth 1000 0.0.11 255.255.258.9 Ap nhrp map multicast 172.17.0.1 Ap nhzp map 10.0.0.1 172.17.0.1 Ap ahzp map multicast 172.17.0.5 Ap nhzp map 10.0.0.2 172.17.0.5 p nnrp network-ia 100000 p nhzp heldtine 30 Ap nhzp nhs 10.0.0.1 4p nhzp nha 10.0.0.2 Ep ospf network broadcast Ep osp£ delay 1000 rity 0 1 Ethernet 0 tunnel mode gre multip: unnel key 100000 tunnel protection ipsec profile vpnprof Ep address dhcp hostname Spokel nverface Ethernet ip address 192.168.1.1 255 1255.0 router ospf 1 network 10.0.0.0 0.0.0.255 area 1 network 192.168.1.0 0.0.0.255 area 1 bp.twww.csco.com/clenius/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonhiml ast282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco The differences in the configuration on the spoke routers are as follows: + In the new configuration, the spoke is configured with static NHRP mappings for Hub2 and Hub? is added as a next hop server. Original Sp nhrp map multicast 172.17.0.1 Ap ahzp map 10.0.0.1 172.17.0.1 Ap ahep nha 10.0.0.1 New: 4p nhrp map multicast 172.17.0.1 Ap ahzp map 10.0.0.1 172.17.0.1 ip hp map multicast 172.17.0.5 Ap ahzp map 10.0.0.2 172.17.0.5 4p nhzp nha 10.0.0.1 4p nhrp nhs 10.0.0.2 + The OSPF areas on the spoke routers have been changed to area 1 Remember that by defining the static NHRP mapping and NHS on a spoke router for a hub, you are going to run the dynamic routing protocol over this tunnel. This defines the hub and spoke routing or neighbor network. Notice that Hub2 is a hub for all of the spokes, and it is also a spoke for Hub1. This makes it easy to design, configure, and modify muttilayer hub-and-spoke networks when you are using the DMVPN solution. © spoke2 Router O version 12.3 crypte isakmp policy 1 seation pre-sh: sco4? address 0.0.0.0 0.0.0.0 crypto isakme key ypto ipsec transform-set trans? esp-des eep-ndS~hma mode transport crypte ipsec profite vpnprof set trans? set trane2 nterface Tunneld 20.22 255.255.2 entication test ip nhzp map multicast 172.17.0.1 4p nhzp map 10.0.0.1 172.17.0.1 ip nhrp map multicast 172,17.0.5 ip nhzp map 10.0.0.2 172.17.0.5 p nip network-id 100000 sp nhzp holdtime 300 ip ahzp nhs 10.0.0.1 Ap ahep nhs 10.0.0.2 ip ospf network br p ospf priority 0 oadcast, delay 1000 tunnel mode gre multipoint tunnel key 100000 tunnel protection ipsec profile vpnprof bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonhiml 3361282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco rface Etherneto p address dhep hostname Spokel router ospf 1 network 10.0.0.0 0.0.0.255 area 0 network 192.168.2.0 0.0.0.255 area 0 © spoke Router O version 12.3 name Spoke czypte isaknp po. crypte isakmp key cisco47? address 0.0.0.0 0.0.0.0 crypto ipsec transform node transport crypto ipsec profite venprof set set trans? nverface Tunnel0 255.0 entication test ip nhzp map multicast 172.17.0.1 Ap ahep map 10.0.0.1 172.17.0.1 ip nhzp map multicast 172.17.0.5 4p ahzp map 0.0.0.2 172.17.0.5 100000 ip nap holdtime 300 ip ahzp nhs 10.0.0.1 Ap nhzp nhs 10.0.0.2 p ospf net p ospf priority network: k broadcas 1000 nnel made gre mu cunnel key interface Etherneto dress dhep hostname nett p address 192.168..1 255.255.255.0 router ospf 1 network 10.0.0.0 0.0.0.255 area 0 network 192.168..0 0.0.0.255 area 0 At this point, you can take a look at the routing tables, the NHRP mapping tables, and the IPsec connections ‘on the Hub1, Hub2, Spoke, and Spoke? routers to see the initial conditions (ust after the Spoke1 and Spoke2 routers come up). bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml9252015 ‘Dynamic Multipoint sac VPNs (Using Mulipaint GREINHRP to Scale IPsec VPNs) - Cisco Initial Conditions and Changes © tubt Router Information O Hubifshow ip route 172.17.0.0/24 is subnetted, 1 subnets c 172.17.0.0 is directly connected, Btherneto 10.0.0.0/24 is subnetted, 1 subnets c 10.0.0.0 is directly connected, Tunnel0 © 192.168.0.0/24 is directly connected, Etherneti © 192.168.1.0/24 [110/2] via 10.0.0.11, 00:02:17, Tunnelo © 192.168.2.0/24 [10/2] via 10.0.0.12, 00:02:17, Tunnei0 Hublfshow ip abrp 10.0.0.2/32 via 10.0.0.2, TunnelO created 1w3d, expire 00:03:15 ‘Type: dynanic, Flags: authoritative unique registered NBMA address: /172.17.0.5 10.0.0.11/32 via 10.0.0.11, Tunnel® created 1w3d, expire 00:03:49 ‘Type: dynamic, Flags: authoritative unique registered NBMA addzess: 172,16.1.24 10.0.0.12/32 via 10.0.0.12, Tunnel® created 1w3d, expire 00:04:06 ‘Type: dynamic, Flags: authoritative unique registered BMA address: 172.16.2.75 Hupl#show erypte engine connection active ID Interface IP-Address State Algorithm Encrypt Decr yet hernetO 172.17.0.1 set -RMAC_SHAYDES 56.CB 0 hernetO 172.17.0.1 get =EMAC_SEALDES_56_cB 0 a 6 EthernetO 172,17.0.1 set ~HMAC_SHAFDES_56_cB 0 o 3522 Tunneld —10.0.0.2 set EMAC MDS+DES 5¢.cB 0 023 2 Tunneld —10.0.0.2 set EMAC MDS+DES_56.cB 212 Tunneld 10.0.0. set HMAC_MDS+DES_56.cB 0 1 Tunneld —10.0.0.1 set EMAC_MDS+DES_56.cR 17 ° 3536 Tunneld —10.0.0.2 set EMAC_MDS+DES_56¢.cB 0 3537 Tunneld —10.0.0.2 set HMAC_MDS+DES_S6.cB 7 o 1 ®@ © tub2 Router Informal aub2¥ehow ip route 192.17.0,0/24 is subnetted, 1 subnets © 172.17.0.0 is directly connected, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets 10.0.0.0 is directly connected, Tunneld 192.168.0.0/24 is directly connected, Ethernet! 192.168-1,0/24 [10/2] via 10.0.0.11, 00:29:15, Tunne10 192,168.2.0/24 [110/2] via 10.0.0.12, 00:29:15, Tunneld Hub2#show ip abrp 10.0.0.1/32 via 10.0.0.1, Tunnel0 created Iw3d, never expire ‘ype: static, Flags: authoritative used NBMA address! 172.17.0.1 10.0,0.11/32 via 10.0,0.11, TunnelO created 1W3d, expire 00:03 ‘Type: dynamic, Flags: authoritative unique registered NBMA address: 172.16.1.24 10.0.0.12/32 via 10.0.0.12, Tunnel0 created 00:46:17, expixe 00:03:5 1 ‘ype: dynamic, Flags: authoritative unique registered NBMA address: 172.16.2.75 bptwwn cisco. comicienusisupportidocsisectrty-vpnipsee-negotaton-ike-protocols/¢1940-emvpn ml 3519252015 ‘Dynamic Multipoint sac VPNs (Using Mulipaint GREINHRP to Scale IPsec VPNs) - Cisco Hub2#show erypte engine connection active ID Interface IP-address State Algorithm Encrypt Deer yet hernetO 171.17.0.5 set =EMAC_SEALDES_56_cB 0 S EthernetO 171,17.0.5 set HMAC _SHAtDES_56_cB 0 o 6 schernetO 171.17.0.5 set HMAC SHADES 56_cB 0 ° 3520 Tunneld —«10.0.0.2 set GMAC_MDS+DES_5¢.cB 0 35 1 3521 Tunne. 10.0.0.2 set HMAC_MDS+DES_S6_cB 326 a 3522 TunnelO ——10.0.0.2 set HMAC _MDS'DES_56.cB 0 31 1 3523 Tunneld —10.0.0.2 set EMAC MDS+DES 56 cB 339 0 3524 Tunneld —«10.0.0.2 set EMAC_MDS+DES_56_cB 0 2 5 3525 Tunneld ——10.0.0.2 set HMAC _MDS+DES_56cB 22 o © spoket Router Information © Spoxelfshew ip route 192,16.0.0/24 is subnetted, 1 subnets c 172.16.1.0 is directly connected, Ethernet 10.0.0.0/24 is subnetted, 1 subnets c 10.0.0.0 is directly connected, Tunneld 0 TA 192.168.0.0/24 [110/11] via 10.0.0.1, 00:39:31, Tunnelo [110/11] via 19.0.0.2, 00:39:31, Tunneio © 192.168.1.0/24 is directly connected, Etherneti © 192.168.2.0/24 [110/2] via 10.0.0.12, 00:37:58, Tunnel0 Spoke! ¥show ip nhzp 10.0.0.1/32 via 10.0.0.1, Tunnel0 created 00:56:40, never expir ‘Type: static, Flags: authoritative used NBMA address! 172.17.0.1 10.0.0.2/32 via 10.0.0.2, TunnelO created 00:56:40, never expir ‘Type: static, Flags: authoritative used NBMA address: 172.17.0.5 Spokel4show crypto engine connection active =D Interface IP-Address State Algorithm Encrypt Decry pt hernetO 172.16.1.24 set EMAC_SEACDES_56.CB 0 o ernetO 172.16.1.24 set HMAC SHAFDES 56.CB a 2010 TunnelO —10.0.0.11 set HMAC_MDS+DES56.cB 017, 2011 Tunnel 10.0.0.22 set EMAC MDS+DES 56.cB 185 0 2012 Tunnel0 —-10.0.0,11 set EMAC MDS+DES_56.cB 0 2 2013 Tunnel 10.0.0.12 set HMACMDS+DES_56_cB 13 0 © spoke2 Router Information © Spoke24show ip route 192.16.0.0/24 is subnetted, 1 subnets c 172.16.2.0 is directly connected, Etherneto 10.0.0.0/24 is subnetted, 1 subnets c 10.0.0.0 is directly connected, Tunneto © IA 192.168.0.0/24 [110/11] via 10.0.0.1, 00:57:56, Tunnelo [110/21] via 10.0.0.2, 6, Tunne10 © 192.168.1.0/26 [110/2] via 10,0.0.11, 00:56:14, Tunnel0 © 192.168.2.0/24 is directly connected, Ethernetl Spoke2tshow ip ahzp 10.0.0.1/32 via 10.0.0.1, Tunnel created Sw6d, never expire bptwwn cisco. comicienusisupportidocsisectrty-vpnipsee-negotaton-ike-protocols/¢1940-emvpn ml‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco tatic, Flags: authoritative used address! 172.17.0 -2/32 via 10.0,0.2, Tunnel0 created 6u6d, never expire tatic, Flage: authoritative used NBMA address: 172.17.0 spoke2¥show exypto engine connection active =D Address State Algor: 12.16.2.75 set EMAC_SBA+DBS, 12.16.2.75 set HMAC _SHAIDES 56.cR 0 10.0.0.12 set o 30 10.0.0.22 set 331 9.0.0.12 set oa 0.0.0.22 236 There are a couple of interesting issues to notice about the routing tables on Hub1, Hub2, Spoket, and Spoke2: ‘+ Both hub routers have equal cost routes to the networks behind the spoke routers. Hub? 0 192,168.1.0/24 via 10.0.0 0 192.168.2.0/24 via 10.0.0 Hub2: 2 92.168.1.9/24 [10/2] via 9.1, runnelo © — 192,168.2.0/24 (2210/2) via 10.0.0.12, Tunne19 This means that Hub1 and Hub2 will advertise the same cost for the networks behind the spoke routers to the routers in the network behind the hub routers. For example, the routing table on a router, R2, that is, connected directly to the 192. 168.0.0/24 LAN would look like the following: R2: 9 A 192.168.1.0/24 [110/12] via 192.168.9. [110/22] via 192.168.0 0 © 3A 192.168.2.0/24 [110/22] via 192.168.0 (No ay ee Ween’ ‘+ The spoke routers have equal cost routes via both hub routers to the network behind the hub routers. Spoket 9 A 192.168.0.0/24 [110/11] via 10.0.0.1, 00:39:31, Tunnei0 [110/21] via 10-0.0.2, 00:39:31, Tuanelo ‘Spoke2: © «TA 192.168.0.0/24 [110/21] via 10.0.0.1, 00:57:56, Tunnel0 [110/11] via 10.0.0.2, 00:57:56, Tunnel0 If the spoke routers are doing per-packet load balancing, then you could get out-of-order packets. To avoid doing asymmetric routing or per-packet load balancing across the links to the two hubs, you need to configure the routing protocol to prefer one spoke-to-hub path in both directions. If you want Hub1 to be the primary and Hub? to be the backup, then you can set the OSPF cost on the hub tunnel interfaces to be different. Hubt nterface tunnelo bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 3st‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco Now the routes look like the following: Hubt ° 92.168.1,0/24 :00:28, Tunnelo © 192.168.2.0/24 10:28, Tunnel Hub2! ° 92.168.1,0/24 [110/21] via 10.0.0.22, 00:00:52, Tannelo © 192.168.2.0/24 [110/21] via 10 Tunnel0 Ra: 9.2, 00:01:06, Ethernet1/a/3 0.2, 00:01:06, Bthernetl/0/3 ‘The two hub routers now have different costs on the routes for the networks behind the spoke routers. This means Hub’ will be preferred for forwarding traffic to the spoke routers, as can be seen on router R2. This will take care of the asymmetric routing problem described in the first bullet above, The asymmetric routing in the other direction, as described in the second bullet above, is still there. When using OSPF as the dynamic routing protocol, you can fix this with a workaround by using the distance command under router ospf 1 on the spokes to prefer routes leamed via Hub1 over routes leamed via Hub2 Spoket: 2 0.0.0.0 2 any Now the routes look like the following: Spoke1: © 192.168.0.0/24 [110/111 via 19.0 Spoke2: ° 92.168.1,0/24 [110/11] via 19.0.0.2, 00:00:10, Tunnel0 ‘The above routing configuration will protect against asymmetric routing, while at the same time allowing failover to Hub2 if Hub goes down. It does mean that when both hubs are up, only Hubt is used. If you want to use both hubs by balancing the spokes across the hubs, with failover protection and no asymmetric routing, then the routing configuration can get complex, especially when using OSPF. For this reason, the following dual hub with dual DMVPN layout may be a better choice Dual Hub - Dual DMVPN Layout ‘The dual hub with dual DMVPN layout is slightly more difficult to set up, but it does give you better control of the routing across the DMVPN. The idea is to have a two separate DMVPN “clouds”, Each hub (two in this case) is connected to one DMVPN subnet (“cloud”) and the spokes are connected to both DMVPN subnets ("clouds"). Since the spoke routers are routing neighbors with both hub routers over the two GRE tunnel bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 381282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco interfaces, you can use interface configuration differences (such as bandwidth, cost and delay) to modify the ‘dynamic routing protocol metrics to prefer one hub over the other hub when they are both up. Note: The above issue is usually only relevant if the hub routers are codocated. When they are not co-located, normal dynamic routing will likely end up preferring the correct hub router, even if the destination network can be reached via either hub router. You can use either p-pGRE or mGRE tunnel interfaces on the spoke routers. Multiple p-pGRE interfaces on a spoke router can use the same tunnel source ... IP address, but multiple mGRE interfaces on a spoke router must have a unique tunnel source ... IP address. This is because when IPsec is initiating, the first packet is, an ISAKMP packet which needs to be associated with one of the mGRE tunnels. The ISAKMP packet only has the destination IP address (remote IPsec peer address) with which to make this association. This address is matched against the tunnel source ... address, but since both tunnels have the same tunnel source .. address, the first mGRE tunnel interface is always matched. This means that incoming multicast data packets may be associated with the wrong mGRE interface, breaking any dynamic routing protocol. GRE packets themselves do not have this problem since they have the tunnel key ... value to differentiate between the two mGRE interfaces. Starting in Cisco OS Software Releases 12.3(6) and 12.3(7)T, an additional parameter was introduced to overcome this limitation: tunnel protection....shared. The shared keyword indicates that mutiple mGRE interfaces will use the IPSec encryption with the same source IP address. If you have an earlier release you can use p-pGRE tunnels in this dual hub with dual DMVPN layout. In the p-pGRE tunnel case, both the tunnel source ... and the tunnel destination ... IP addresses can be used for matching, For this example p-pGRE tunnels will be used in this dual hub with dual DMVPN layout and not use the shared qualifier. Dual Hub - Dual DMVPN Layout 192.168.0.0/2 Static Dynamic 172.17.0.1 72.17.05 SPORE 192,168..0/ 192 168. 1.0/2 ‘SPOKE2 192.168,2.0/2 The following highlighted changes are relative to the dynamic multipoint hub and spoke configurations illustrated earlier in this document. O tubt Router O fon 12.3 hostname #ub1 crypto isakmp policy 1 bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ke-protocls/¢1940-cmvonfiml cation pre-share 3519252015 ‘Dynamic Multipoint sac VPNs (Using Mulipaint GREINHRP to Scale IPsec VPNs) - Cisco crypto isakmp key cisco4? address 0.0.0.0 0.0.0.0 crypto ipsee trangform-set trans? esp-dee esp-nas-hm node transport crypto ipsec profile vpnprof set transform-set trans? interface Tunneld bandwidth 1000 ip address 20.0.0.1 259.255. ip mtu 1400 p nhrp authentication test ip nhrp map multicast dynaric ip nhrp network-id 100000 ip nhrp holdtime 600 no ip split-horizon eigsp 1 delay 1000 tunnel source Ethernet tunnel mode gre multipoint tunnel key 100000 tunnel protection ipsec profile vpnprof interface Stherneto ip address 172.17. 1 255.255. 5.252 interface Ethernet! Sp address 192,168.0.1 255,255.255.0 router eigrp 1 network 10.0.0.0 0.0,0.255 network 192.168.0.0 0.0.0.255 no auto-sumnary © tub2 Router O version 12.3 hostname Hub2 crypto isakme policy 1 authentication pre-share crypto isakmp key cisco47 address 9.0.0.0 0.0.0.0 crypto ipsec transforn-set trans? esp-des eep-nd5-hm node transport crypto ipsec profile vpnprof set transforn-set trans? interface Tunnelo bandwidth 1000 Ap address 10.0.1.1 255.255.255.0 p mtu 1400 ip nhrp authentication test ip narp map multicast dynamic ip ahzp network-id 100001 ip nhrp holdtime 600 no ip split-horizon eigrp 1 delay 1000 tunnel source Ethernetd tunnel mode gre multipoint tunnel key 100001 bptwwn sco. comiclenusisupportidocsisectrty-vpnipsee-negotaton-ike-protocols/¢1940-cmvpn ml282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco tunnel protection ipsec profile vpnprot network 192,168.0.0 0.0.0.255 no aulo-surmary In this case, the Hub1 and Hub2 configurations are similar. The main difference is that each is the hub of a different DMVPN. Each DMVPN uses a different: + IP subnet (10.0.0.0/24, 10.0.0.1/24) + NHRP network id (100000, 100001) + Tunnel key (100000, 100001) The dynamic routing protocol has been switched from OSPF to EIGRP, since it is easier to set up and manage a NBMA network using EIGRP, as described later in this document. © spoke1 Router O ame Spokel crypte isakmp policy 1 seation pr saknp key cisco4? address 0.0.0.0 0.0.0.0 cransform-set trans2 esp-des esp-mdS-hna mode transport crypto ipsec profite vpnprof transform-set trane2 interface Tunnel0 bandwidth 1000 Ap address 10.0.0.11 255.255.255.0 p mts 1400 ip nhzp authentication test ip nhzp map 10.0.0.1 172.17.0.1 4p nhzp network-id 100000 Ep nhzp holdtime 300 ip nhzp nhs 10.0.0.1 delay tunnel source Ethernetd tunnel destination 172.17.0.1 tunnel key 100000 tunnel protection ipsec profile vpnprof interface Tunnell bandwidth 1000 ip address 10.0.1.11 255.255.255.0 sp mtu 1400 authenté: Ap ahzp map 10.0.1.1 172.17.0.5 network-id 100001 holdzime 300 4p ahep nhs 10.0.1.1 bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonhiml aust282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco delay 1000 tunnel destination 172.17.0.5 tunnel key 100001 jon ipsec profile vpnprof p address dhep hostname Spokel interface Ethernet? p address 192.168.1.1 255.255.255.0 Each of the spoke routers is configured with two p-pGRE tunnel interface, one in each of the two DMVPNs. The ip address...., ip nhrp network-id ..., tunnel key ... and tunnel destination ... values are used to differentiate between the two tunnels, The dynamic routing protocol, EIGRP, is run over both p-pGRE tunnel subnets and is used to select one p-pGRE interface (DMVPN) over the other. O spoke2 Router O crypto isakmp po authentication crypto ieakmp key ciscod crypto ipsee transforn-set node transport ypto ipsec pro: set transforn-set trans? interface Tunnel0 bandwidth 1000 ip address 10.0.0.12 255.255.255.0 pomty 1400 p nhrp authentication vest Ap nhrp map 10.0.0.1 172.17.0.1 ip nhzp network-id 100000 Ap nhzp nhs 10.0.0.1 felay 1000 pnel source Ethernetd ‘unnel destination 172.17.0.1 tunnel key 100000 jon ipsec prof tunnel prot! nterface Tunnel 2000 10.0.1.12 255.255.255.0 bands ap p mtu 1400 p nhrp authentication test ip ahzp map 10.0.1.1 172.17.0.5 Ap nhzp network-id 100001 Pp nhrp holdtime 300 4p nhzp nha 10.0.1.1 delay 1000 bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonhiml282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco tunnel destination 172.17.0.5 tunnel key 100002 tunnel protection psec prof p addzess dhep hostname spoke 68.2.1 258,255.255.0 network 10.0.0.0 0.0.0.255 network 10.0.1.0 0.0.0.255 work 192.168.2.0 0.0.0.25 no auto-sunmary O spoke Router O crypto isaknp po: cyl 047 add crypto isakmp key ¢ crypto ipsec transform-set trans? esp-des esp-mdS-hma set trans? interface Tunneld bandwidth 1000 Ap address 10.0.0. 255.255.255.0 a Ap ahep map 10.0.0.1 172.17.0.1 Ap nhzp network-id 100000 p nnep holdtime 200 ip nhrp nhs 10.0.0.1 delay 1000 tunnel destination 172.17.0.1 tunnel key 100000 cunnel protection ipse sp mtu profile vpnprot interface Tunnell bandwidth 1000 Ap address 10.0.1. 255.255.255.0 p mtu 1400 authentication test Ap nhzp map 10.0.1.1 172.17.0.5 ip nhzp network-id 100001 ime 300 Ap nhzp nhs 10.0.1.1 delay 1000 souzee Etherneto tunnel destination 172.17.0.5 tunnel key 100002 prot! ion ipsec prof. bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonhiml282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco Ep address dhep ho: name Spoke Ep address 292.168..1 255.255.258 network 10.0.0.0 0.0.0.255 network 10.0.1.0 0.0.0.255 network 192.168..0 0.0,0.255 At this point, let us take a look at the routing tables, the NHRP mapping tables, and IPsec connections on the Hub1, Hub2, Spoket and Spoke2 routers to see the initial conditions (Just after the Spoket and Spoke? routers come up). Initial Condit jons and Changes © Hubt Router information O Hubifshow ip route 72.17.0.0/30 is subnetted, 1 subnets c 12.17.0.0 is directly connected, Btherneto 10.0.0.0/24 is subnetted, 2 subnets c 0.0.0.0 is dizectly connected, Tunne10 B 0.0.1.0 (90/2611200) via 192.168.0.2, 00:00:46, ztherneti © 192.168.0.0/24 is directly connected, Ethernet! b 192.168.1.0/24 [90/2841600) via 10.9.0.11, runnelo D 192.168.2.0/24 [90/2841600] via 10.9.0.12, ‘anne 20 Hubl#show ip nhrp 0.0.0.12/32 via 10.0.0.12, TunnelO created 23:48:32, expire 00:03:50 Type: dynamic, Flags: authoritative unique registered NEMA addze: 2.16.2.75 0.0.0.11/32 via 10.0.0 unneld created 23:16:46, expire 00:04 pe: dynamic, ative un. NEMA addvess ubl#show erypto engine connection active erface State Algorithm Bnerypt ye’ 5 EthernetO 172.17.63.18 set __luac_sila+ ce ° a hernetO 10.0.0.2 set SHA+DES_56_cB 0 a 2038 Tunneld —10.0.0.2 set mps 7 59 2039 Tunnelo 0.0.0 set HMAC_MD5401 726 a 2040 Tunnelo 0.0.0 set HMAC_éDS o 5 2041 Tunnelo 0.0.0 set -MAC_MDS 36 © bub2 Router Information O jub2¥show ip route 172.17.0.0/30 is subnetted, 1 subne 72.17.0.4 is directly connected, Btherneta 10.0,0.0/24 is 10.0.0.0 (90/26: 0.0.1.0 192.168.0.0/24 is directly connected, Bthernett 392.168.1.0/24 [90/2841600] via 10.0.2.11, 00:13:24, Tunnelo 0) via 192.168.0.1, 00:12:22, ly connected, Tunneld 5 direc bp.twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml ast9252015 b 192.168.2. ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco 0/24 [90/2841 Hub2#show ip abrp 10.0.1.12/32 vil a 10.0.1.12, Type: dynamic, Flags: auth BMA address: 10.0.1.11/32 vil Type: dynamic, NEMA address: 172.16.2.75 a 10.0.1.11, ags: auth: 172.16.1.24 600] via 10.0.1.12, 00:12:11, ‘Tunneio unnel3 created 06:03:24, expire 00:04:39 joritative unique registered unnela created 23:06:47, expire 00:04:54 joritative unique registered Hub2ishew exypte engine connection active ID Interface yet 4 scherneco Etherneso 2098 Tunnelo 2099 Tunnelo 2100 Tunnelo 2201 Tunnelo IP-Addre State Algorithm 171,17.0.5 set HMAC_SHA*DES_56_cB 171.17.0.5 set AMAC_SHA-DES_56_ca 10.0.1.2 set AMAC_MDS-DES_56_cB 10.0.162 set HMAC_MDS+pES_56_cB 10.0.1.2 set AMAC_MDS-DES_5¢_ca 10.0.1.2 set AMAC_MDS-DES_s¢_c2 O spoke1 Router information O spokelfshew ip route 192.16.0.0/24 is subnetted, 1 subnets c 172.16.1.0 is directly connected, Etherneta 10.0.0.0/24 is subnetted, 1 subnets c 10.0.0.0 is directly connected, Tunneld 10.0.1.0 is ai: [90/3097600) via Spokelfshow ip ahzp 10.0.0.1/32 via 10.0,0.1, Tunnel0 created tly connected, Tunnel? DB 192.168.0.0/24 [90/2841600] via 10.0. [90/2841600) via 10.0. © 192.168.1.0/24 is directly connected, D 192.168.2.0/24 [90/3097600) via 10.0. 0. 1.1, 00:26:30, 0.1, 00:26:30, Ethernet 2.1, 00:26:29, 0.1, 00:26:28, Enerypt Dé ° 208 ‘Tunnel, ‘Tunneld ‘Tunnel ‘Tunnelo 23:25:46, never expire NBMA address: 10.0.1.1/32 via 10.0.1.1, Tunnell created 23:24:40, never expire ‘Type: stat: NBMA address: Flags: authoritative 172.17.0.2 Flags: authoritative 172.17.0.5 Spokelfshow crypto engine connection active ID Interface yet 16 Etherneto a herneco o 2118 Tunnelo 1 2119 Tunnelo 2120 Tunnel 2121 Tunnel IP-Address © State Algorithm 172.16.1.24 set AMAC_SHA-DES_56_c 172.16.1.24 set AMAC_SHA+DES_S6_cB. 10.0.0.22 set AMAC_MDS-DES_5¢_ca 10.0.0.12 set AMAC_MDS-DES_S¢_c2 10.0.1.22 set MAC_MDS+pES_86_cB 10.0.1.22 set AMAC_MDS-DES_5¢_ca © spoke2 Router Information O Spoke24show ip route 172.16.0.0/24 is subnetted, 1 subnets bptwwn cisco. comicienusisupportidocsisectrty-vpnipsee-negotaton-ike-protocols/¢1940-emvpn ml Enerypt Dec a9252015 ‘Dynamic Multipoint sac VPNs (Using Mulipaint GREINHRP to Scale IPsec VPNs) - Cisco c 172.16.2.0 is directly connected, Ethernetd 10.0.0.0/24 is subnetted, 2 subnets c 10.0.0.0 is directly connected, Tunneld c 10.0.1,0 is directly connected, Tunnel D —192.168.0.0/24 [90/2841600] via 10.0.1.1, 00:38:04, Tunnel: [90/2e41600] via 10.0.0.1, 00:38:04, Tunnelo b 192.168.1.0/24 [90/3097600) via 10.0.1.1, 00:38:02, Tunnel? 190/3097600] via 10.0.0.1, 00:38:02, Tunneld © 192.168.2.0/24 is directly connected, Ethernett spoke24show ip ahzp 10.0.0.1/32 via 10.0.0.1, TunnelO created 1d02h, never expire ‘Type: static, Flags: authoritative used NBMA address! 172.17.0.1 10.0.1.1/32 via 10.0.1.1, Tunnell created 1d02h, never expire ‘Type: static, Flags: authoritative used NBMA address: 172.17.0.5 Spoke24show crypto engine connection active ID Interface IP-Address State Algorithm Bnerypt De yet hernetO 172.16.2.75 set -AMAC_SHA-DES_s¢_c2 a 0 9 Ethernet0 172.16.2.75 set -AMAC_SHA-DES_S¢_cB 0 a 2036 Tunnel0 —-10.0.9.12 set AMAC_MDS+DES_56 ° 58 5 2037 Tunnel 10.0.0.12 set AMAC_MDS-DES_S¢ca 614 0 2038 Tunnel —-10.0.1.12 set HMAC_MDS-DES_S¢_cB 0 40 8 2039 Tunnell —-10.0.1.12 set HMAC_MDS+DES_5€.cB 424 o ‘Again, there are a couple of interesting things to notice about the routing tables on Hub1, Hub2, Spoke1, and Spoke2: + Both hub routers have equal cost routes to the networks behind the spoke routers. Hub1: b 192.168.1.0/24 [90/2841600] via 19.0.0.11, 00:00:59, Tunnel0 D 192.168.2,0/24 [90/2841600] via 10.0.0.12, 00:00:34, Tunne10 D 192.168.1.0/24 [90/2841600] via 10.0.1.11, 00:13:24, Tunnelo b 192.168.2.0/24 [90/2841600] via 19.0.1.12, 00:12:11, Tunnel0 This means that Hub1 and Hub2 will advertise the same cost for the networks behind the spoke routers to the routers in the network behind the hub routers. For example, the routing table on a router, R2, that is connected directly to the 192,168,0.0/24 LAN would look like the following: R2: D 192.168.1.0/24 [90/2867200) via 192.168.0.1, 00:51:51, Btherneti/0/3 [90/28672007 via 192.168.0.2, 00:51:51, Etherneti/0/3 D 192.168.2.0/24 (90/2867200] via 192.168.0.2, 00:52:43, Btherneti/0/3 [90/2867200) via 192.168.0.1, 00:52:43, Etherneti/0/3 + The spoke routers have equal cost routes via both hub routers to the network behind the hub routers. Spoket D 192.168.0.0/24 [90/3097600] via 10.0.1.1, 00:26:30, Tunnel? [90/3097600' via 10.0.0.1, 00:26:30, Tunnelo Spoke2: D 192.168.0.0/24 [90/3097600] via 10.0.1.1, 00:38:04, Tunnelt [90/3097600; via 10.0.0.1, 00:38:04, Tunnelo bptwwn isco. cemiclenusisupportidocs/sectrty-vpnipsee-negotaton-ike-protocols/¢1940-emvpn ml 46ss2015 ‘Dynamie Muti IPse= VPNs (Using Mulpoit GREINHRP to Scale IPsec VPNs) - Cisco If the spoke routers are doing per-packet load-balancing, then you could get out-of-order packets. To avoid doing asymmetric routing or per-packet load balancing across the links to the two hubs, you need to configure the routing protocol to prefer one spoke-to-hub path in both directions. If you want Hub1 to be the primary and Hub? to be the backup, then you can set the delay on the hub tunnel interfaces to be different. Hubt delay 1900 Hub2! nterface tunnel0 Note: In this example, 50 was added to the delay on the tunnel interface on Hub2 because it is smaller than the delay on Ethemett interface between the two hubs (100). By doing this, Hub2 will still foward packets directly to the spoke routers, but it will advertise a less desirable route than Hub1 to routers behind Hub1 and Hub2. If the delay was increased by more than 100, then Hub2 would forward packets for the spoke routers through Hub1 via the Ethemett interface, though the routers behind Hub1 and Hub2 would still correctly prefer Hub-1 for sending packets to the spoke routers. Now the routes look like the following: Hubt: D —192,168.1.0/2¢ [90/2841600] via 10.0.0.11, 00:0 D 192.168.2.0/24 (90/2841600) via 10.0.0.12, 00 Hub2: D 192.168.1.0/24 [90/7854400) via 10.9.1.11, 00 D —192.168.2.0/24 [90/2854400) via 10.0.1.12, 00:0 Ra: D —192.168.1.0/24 [90/2867200) via 192.268.0 :02:18, Bthernet1/0/3 D 192.168.2.0/26 [90/2867200) via 192.168.0.1, 00:02:18, Rtherneti/0/3 The two hub routers have different costs for the network routes behind the spoke routers, so, in this case, Hub1 will be preferred for forwarding traffic to the spoke routers, as can be seen on R2. This takes care of, issue described in the first bullet above. The issue described in the second bullet above is still there, but since you have two p-pGRE tunnel interfaces, you can set the delay ... on the tunnel interfaces separately to change the EIGRP metric for the routes learned from Hub1 versus Hub2. Spoke1: nterface tunnel0 delay 1 nterface tunnell delay 1050 Spoke2: erface tunnel0 0a verface tunnel delay 1050 Now the routes look like the following: Spoket D —192.168.0.0/2¢ [90/2841600) via 1 0.0.1, 00:15:44, Tunnelo bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml ans282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco D —192.168.2.0/24 [90/2097600) via 10.0.0.1, 00:15:44, Tunnelo Spoke2: D 192.168.0.0/24 [90/2841600) via 10.0.0.1, 00:13:54, Tunneld D 192.168 0/2 (90/3097600) via 10.0.0.1, 00:13:54, Tunneld The above routing configuration will protect against asymmetric routing, while at the same time allowing failover to Hub2 if Hub goes down, It does mean that when both hubs are up, only Hubt is used. If you want to use both hubs by balancing the spokes across the hubs, with failover protection and no asymmetric routing, then the routing configuration is more complex, but you can do it when using EIGRP. To accomplish this, set the delay ... on the tunnel interfaces of the hub routers back to being equal and then use the offset-list out command on the spoke routers to increase the EIGRP metric for routes advertised out the GRE tunnel interfaces to the backup hub. The unequal delay ... between the Tunnel0 and Tunnelt interfaces on the spoke is still used, so the spoke router will prefer its primary hub router. The changes on the spoke routers are as follows. © spoket Router O in e Tunnelo p address 10.0.0.11 255.255.255.0 ip mty 1400 nhrp map 10.0.0.1 172.17.0.1 network-id 100000 holdzime 300 ponhrp ans 10.0.0.1 delay 1000 tunnel destination 172.17,0.1 tunnel key 200000 tunnel protection ipsec profile venpr of nverface Tunnel bandwidth 1000 p address 10 p mts 1400 2172.17.09. .21 255,255.258.9 tunnel eource Ethernetd sunnel destination 172.17.0.5 tunnel key 10000 tunnel on ipsec profile venpr of offset-list 1 0 a a 0 mary bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ke-protocols/¢1940-cmvonfiml 4851282015 ‘Dynamic Multipoint Pec VPNs (Using Multipoint GREINHRP to Scale IPsac VPNs) - Cisco interface Tunneld bandwidth 1000 20.00.12 255.255.255.9 ip mtu 1400 ip nap 10.0.0.1 172.17.0.1 network-id 100000 p nhrp holdtime 300 Ep nhzp nbs 10.0.0.1 delay 1500 tunnel destination 172.17.0.1 tunnel key 200000 unnel protection ipsec profile vpnpr of nverface Tunnell ponhrp nhs 10.0.2. delay 1000 unnel eto tunnel destination 172.17.0.5 tunnel key 200001 tunnel protection ipsec profile vpnpr of offset-list 1 out 12800 Tunnell jork 10.0.0.0 0.0.0.255 network 1.0.1.0 0.0.0.255 network 192.168.2.0 distribute-list 1 out access-list 1 permit 192.168.2.0 Note: The offset value of 12800 (50256) was added to the EIGRP metric because it is smaller than 25600 (100256). This value (25600), is what is added to the EIGRP metric for routes leamed between the hub routers. By using 12800 in the offset-list command, the backup hub router will forward packets directly to the spoke routers, rather than forwarding these packets via the Ethernet to go through primary hub router for those spokes. The metric on the routes advertised by the hub routers will still be such that the correct primary hub router will be preferred, Remember that half of the spokes have Hub1 as their primary router, and the other half have Hub2 as their primary router. bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml 4351ss2015 ‘Dynamie Muti IPse= VPNs (Using Mulpoit GREINHRP to Scale IPsec VPNs) - Cisco Note: If the offset value was increased by more than 25600 (100°256), then the hubs would forward packets for half of the spoke routers through the other hub via the Ethemett interface, even though the routers behind the hubs would still prefer the correct hub for sending packets to the spoke routers. Note: The distributeist 1 out command was also added since it is possible that routes learned from one hub router via one tunnel interface on a spoke could be advertised back to the other hub via the other tunnel. The bute-list ... command ensures that the spoke router can only advertise its own routes Note: If you prefer to control the routing advertisements on the hub routers rather than on the spoke routers , then the offsetdist in and distribute-list in commands can be configured ‘on the hub routers instead of on the spokes. The access-list would list the routes from behind all spokes and the access-list would list only the routes from behind spokes where another hub router is to be the primary hub. With these changes the routes look like the following Hubt 1.0/24 [90/204 210/24 (90/28544 via 10.0.0.11, 00:1: via 10.0.0.12, 00 Hub2 > 192.168.1.0/24 [90/2854400) via 10.0.1.11, 00:09:58, Tunneld D — 192.168-2.0/24 [90/2841600) via 10.10.1.12, 00:11:11, Tunnelo Ra: > 192.168.1.0/24 [90/2867200) via 192.268.0.2, 00:13:13, Bthernett/0/3 > 192.168.2.0/24 [90/2867200} via 192.168.0-2, 00:14:25, Ethernet1/0/3 Spoket: D —192,168.0.0/24 [90/2841600) via 10.0.0.1, 00:16:12, Tunnelo Spoke2: > 192.168 0/2 [90/2841600) via 10.0.1.1, 00:18:54, Tunnel Conclusion ‘The DMVPN solution provides the following functionality to better scale large and small IPsec VPN networks. + DMVPN allows better scaling in full mesh or in partial mesh IPsec VPNs. It is especially useful when spoke-to-spoke traffic is sporadic (for example, every spoke is not constantly sending data to every other spoke). It does allow any spoke to send data directly to any other spoke, as long there is direct IP connectivity between the spokes. + DMVPN supports IPsec nodes with dynamically assigned addresses (such as Cable, ISDN, and DSL) This applies to hub-and-spoke as well as mesh networks, DMVPN can require the hub-to-spoke link to constantly be up. + DMVPN simplifies the addition of VPN nodes. When adding a new spoke router, you only have to configure the spoke router and plug it into the network (though, you may need to add ISAKMP authorization information for the new spoke on the hub). The hub will dynamically lear about the new spoke and the dynamic routing protocol will propagate the routing to the hub and all other spokes. + DMVPN reduces the size of the configuration needed on all the routers in the VPN. This is also the case for GRE IPsec hub-and-spoke-only VPN networks. + DMVPN uses GRE and, therefore, supports IP multicast and dynamic routing traffic across the VPN This means that a dynamic routing protocol can be used, and redundant “hubs” can be supported by the protocol. Multicast applications are also supported. + DMVPN supports split tunneling at the spokes. bp:twww.cisco.com/clelus/supportidocssecurty-vpnipsec-negotaon-ike-protocls/¢1940-cmvonfiml sot22018 ‘Dynamic Multipoint sec VPNs (Using Multipoint GREINHRP to Scale IPsec VPNs) - Cisco Related Information + Dynamic Multipoint VPN (DMVPN) + IPSec Support Page + Technical Support - Cisco Systems ©2015 Cisco and/or its affiliates. All rights reserved tpiwwu. cisco, cem/clenusisupportidocssecurty-vpripsec-negataton-ike-protoclsl¢1¢0-cmvpn ml ust