DMVPN Hub and Spoke with EIGRP routing

In this minilab (microlab) I'll pick up where we left on the DMVPN Hub and Spoke minilab. We'll be adding EIGRP routing to the configuration so the private networks become reachable.
Here's a breakdown of the tasks necessary to configure DMVPN in each router:

1. Configure the EIGRP routing process on the spokes
2. Configure the EIGRP routing process on the HUB

1-Configuring EIGRP on the spokes

2-Configuring EIGRP on the hub

Now lets look at the routing tables on the hub:

Looking good.. now let's look at the spokes:

We're not receiving the routes for the other spokes, to receive these routes we need to disable split-horizon on the tunnel interface of the hub:

Another look at the spoke's routing tables:

Better.. we're now getting the route for the other spokes, but with this routing table will force the traffic between the private networks of the two spokes to go through the hub, to fix this we must issue the no ip next-hop-self command for the eigrp process on the tunnel interface of the hub:

Another look at the spoke's routing tables:

Finally we have the routes for the other spoke's private networks with the next hop at the other spoke's tunnel interface.


And we're done!!

DMVPN Hub and Spoke

Here´s a simple lab to set up a DMVPN scenario, we have two spokes (R2 and R3) and one hub (R1). R4 is simply there to simulate a "network" cloud". We will be using DMVPN phase 2 to permit the dynamic creation of spoke to spoke tunnels. Here's our topology:

In this the goal is to set up DMVPN. To simulate private networks we'll set up loopback interface's on each of the routers (R1 through R3) with addresses in the format 11.11.11.11, 22.22.22.22, etc.
Begin by setting up basic connectivity, R4 interface's should be the default gateway for other routers.


Here's a breakdown of the tasks necessary to configure DMVPN in each router:

1. Configure ISAKMP policy and keys
2. Configure IPsec transform-set and profile
3. Configure the tunnel interface:



1. IP address
2. Tunnel source, mode and key
3. NHRP authentication, mappings, network-id
4. Tunnel protection



4. Test!

We'll begin with the DMVPN configuration without EIGRP, and then add EIGRP routing over the tunnel. I'll be posting the configs for the hub and one of the spokes (R2), the other spoke's configuration is identical.

1-ISAKMP

Hub and Spoke:

2-IPsec

Hub and Spoke:

So far the only thing that you don't have in a simple ipsec tunnel is the ipsec profile.

3-Tunnel interface

3.1 and 3.2- IP, tunnel mode and source  

Hub and Spoke:

On the spoke the ip address should be 10.0.0.2 instead of 10.0.0.1. By not using a tunnel destination and defining the tunnel mode as gre multipoint on the spoke router we are implicitly using DMVPN Phase 2, whereas if we used a tunnel destination on the spoke we would be using DMVPN Phase 1, thus making all spoke-to-spoke traffic traverse the hub router.

3.3-NHRP

Hub:

Spoke:

And finally the configurations differ, on the spoke router we manually map the ip of tunnel interface of R1 to the physical interface of R1, and map multicast traffic to be directed to R1's physical interface, and define our next hop server as R1's tunnel interface.

On the hub side we simply say that multicast mapping is dynamic.

3.4-Tunnel protection

Hub and Spoke:

When you apply the tunnel protection command ISAKMP should become ON (if you weren't allready using it for something else).

4-Test!

You should see the nhrp mappings on the spoke and hub (show ip nhrp) and the DMVPN peers (show dmvpn), to make sure everything is working ping R1's tunnel interface from R2:

Bringing up R3 and configuring it identically, you should be able to ping it from the other spoke, and you should see that the two spokes form an adjacency ( sh adjacency detail ).

And we're done, on my next post we'll add routing and more to this scenario.

IPsec VTI

IPsec virtual tunnel interfaces provide a routable interface to terminate IPsec tunnels, also allowing the encryption of multicast traffic. One of the main advantages of using IPsec VTI interfaces is that you don't need to statically map the IPsec session to a particular interface (no crypto map is required), thus allowing the encrypted traffic to be sent and received through any physical interface. Another adavange is that there is no need to configure symmetrical ACLs on the end points of the IPsec tunnel to define "interesting" traffic, in IPsec VTI the routing engine is used as a trigger mechanism.


In this minilab we'll configure a static VTI tunnel between two routers, R1 and R3. I'll show the configuration steps on R1, the config on R3 is symmetrical.

Here's a breakdown of the tasks we have to do in order to acomplish this (basic connectivity is assumed to be configured):

1-Define ISAKMP policy and pre-shared key.

2-Define the IPsec transform-set

3-Create an IPsec profile

4-Create the tunnel interface and configure it accordingly

5-Test!

1-ISAKMP
R1(config)#crypto isakmp key 0 key address 23.23.23.3
R1(config)#crypto  isakmp policy 10
R1(config-isakmp)#group 2
R1(config-isakmp)#lifetime 3600
R1(config-isakmp)#encryption des
R1(config-isakmp)#hash md5
R1(config-isakmp)#authentication pre-share


2-IPsec transform set
R1(config)#crypto ipsec transform-set SET esp-des esp-sha-hmac
R1(cfg-crypto-trans)#mode transport


3-IPsec profile
R1(config)#crypto ipsec profile VTI
R1(ipsec-profile)#set transform-set SET


4-Tunnel interface
R1(config)#int tunnel 0
R1(config-if)#ip address 13.13.13.1 255.255.255.0
R1(config-if)#tunnel source fastEthernet 1/0
R1(config-if)#tunnel destination 23.23.23.3
R1(config-if)#tunnel mode ipsec ipv4
R1(config-if)#tunnel protection ipsec profile VTI


5-Route
R1(config)#ip route 3.3.3.0 255.255.255.0 tunnel 0


6-Test

R1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

Notice there's no need to define the source of the ping, as would be in a classic IPsec tunnel where only the traffic between the private networks.

GRE over IPsec between two routers

Here´s a simple lab to set up a LAN-to-LAN IPsec tunnel. The "LANs" we'll be connecting are two loopback interfaces on R1 and R3, 1.1.1.1/24 and 3.3.3.3/24. Here's our topology:

For this lab we'll be running EIGRP on routers 1 and 3 with AS 13. The GRE tunnel will be established between two loopbacks in R1 and R3, with addresses 1.1.1.1 and 3.3.3.3.
We'll create one more loopback in each of the routers R1 and R3 to simulate local networks routed via GRE, the addresses for these will be 11.11.11.0/24 in R1 and 33.33.33.0/24 in R3.


If we wanted to be able to use the GRE tunnel without IPsec we would need R2 to have routes to these loopbacks, in this case we won't do that so the GRE tunnel will only work once the IPsec tunnel is established.



Here's a breakdown of the tasks we have to do in order to acomplish this:
1-Create the loopbacks and get basic connectivity
2-Create the GRE tunnel
3-Setup EIGRP
4-Define ISAKMP policy and pre-shared key.
5-Define the IPsec transform-set
6-Create an ACL for our "interesting" traffic.
7-Create a crypto map
8-Apply the crypto map to an interface.
9-Test!

1-Basic connectivity
R1 and R3 should have a default route with next hop in R2, don't create any routes in R2 it will only know directly connected networks. From R1 you should be able to ping 23.23.23.3 but not 3.3.3.3


2-GRE tunnel
R1(config)#interface tunnel 1
R1(config-if)#ip address 13.13.13.1 255.255.255.0
R1(config-if)#tunnel source loopback 0
R1(config-if)#tunnel destination 3.3.3.3


3-EIGRP
R1(config)#router eigrp 13
R1(config-router)#network 1.1.1.0 0.0.0.255
R1(config-router)#network 13.13.13.0 0.0.0.255
R1(config-router)#network 11.11.11.0 0.0.0.255


4-ISAKMP
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#encryption des
R1(config-isakmp)#lifetime 3600
R1(config-isakmp)#group 2
R1(config-isakmp)#hash md5
!
R1(config)#crypto isakmp key 0 key address 23.23.23.3


5-IPsec
R1(config)#crypto ipsec transform-set SET esp-3des ah-sha-hmac
R1(cfg-crypto-trans)#mode tunnel


6-ACL
R1(config)#ip access-list extended 103
R1(config-ext-nacl)#10 permit gre host 1.1.1.1 host 3.3.3.3


7-Crypto map
R1(config)#crypto map MAP 10 ipsec-isakmp
R1(config-crypto-map)#set transform-set SET
R1(config-crypto-map)#set peer 23.23.23.3
R1(config-crypto-map)#match address 103


8-Apply the crypto map to the interface
R1(config)#int fa1/0
R1(config-if)#crypto map MAP


9-Test the configuration!
When you apply the crypto map to both routers you should see an EIGRP adjacency being formed, all good so far, but after a while you should see flapping on the Tunnel interface:
*Feb  2 15:32:29.163: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 13: Neighbor 13.13.13.3 (Tunnel1) is up: new adjacency
*Feb  2 15:32:38.023: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Feb  2 15:32:39.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Feb  2 15:32:39.063: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 13: Neighbor 13.13.13.3 (Tunnel1) is down: interface down
*Feb  2 15:33:39.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
*Feb  2 15:33:41.699: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 13: Neighbor 13.13.13.3 (Tunnel1) is up: new adjacency
*Feb  2 15:33:48.023: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Feb  2 15:33:49.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Feb  2 15:33:49.063: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 13: Neighbor 13.13.13.3 (Tunnel1) is down: interface down

This behaviour is caused by EIGRP route pointing the tunnel's network to be reachable with the Tunnel interface as the next hop for that network, so whenever the router tries to send a packet to tunnel termination on the other router this happens:
The packet is queued in the output queue of the tunnel interface
The tunnel interface adds a GRE header to the packet and queues the packet to the transport protocol destined to the destination address of the tunnel interface.
IP looks up the route to the destination address and learns that it is through the tunnel interface, which returns the packet to Step 1 above; hence, there is a recursive routing loop.
(taken from  http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094690.shtml )
In this configuration there are two ways to solve this problem, one is to remove the loopbacks that are forming the tunnel from the eigrp routing process.The other solution is to manually add a more specific static route for the tunnel destination, with the next hop on our outbound interface (where we have the crypto map applied). So add it in:
R1(config)#ip route 3.3.3.3 255.255.255.255 FastEthernet 1/0
Now the router should have stopped the recursive routing, and you should get a stable tunnel, hte routing table should look something like this:
Gateway of last resort is 12.12.12.2 to network 0.0.0.0

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback0
     33.0.0.0/24 is subnetted, 1 subnets
D       33.33.33.0 [90/297372416] via 13.13.13.3, 00:02:43, Tunnel1
     3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S       3.3.3.3/32 is directly connected, FastEthernet1/0
D       3.3.3.0/24 [90/297372416] via 13.13.13.3, 00:02:43, Tunnel1
     11.0.0.0/24 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, Loopback1
     12.0.0.0/24 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, FastEthernet1/0
     13.0.0.0/24 is subnetted, 1 subnets
C       13.13.13.0 is directly connected, Tunnel1
S*   0.0.0.0/0 [1/0] via 12.12.12.2

And we're done, you should have connectivity between the local networks.

Basic LAN to LAN IPsec tunnel between two routers

Here´s a simple lab to set up a LAN-to-LAN IPsec tunnel. The "LANs" we'll be connecting are two loopback interfaces on R1 and R3, 1.1.1.1/24 and 3.3.3.3/24. Here's our topology:

Here's a breakdown of the tasks we have to do in order to acomplish this:
1-Define ISAKMP policy and pre-shared key.
2-Define the IPsec transform-set
3-Create an ACL for our "interesting" traffic.
4-Create a crypto map
5-Apply the crypto map to an interface.
6-Test!

When configuring IPsec it´s a good idea to create the configuration in notepad, so you can then copy and paste into the devices as required. The configuration steps below are for R1, for R3 they are exactly the same except for the peer address and the ACL will be an exact mirror of the one on R1. The commands are entered in config mode.

1-ISAKMP policy
crypto isakmp key 0 key address 23.23.23.3

crypto isakmp policy 10
authentication pre-share
encryption des
hash sha
group 2
lifetime 3600

2-IPsec transform set
crypto ipsec transform-set TS esp-seal esp-sha-hmac
mode tunnel

3-ACL
access-list 103 permit ip 1.1.1.0 0.0.0.255 3.3.3.0  0.0.0.255

4-Crypto map
crypto map CMAP 10 ipsec-isakmp
set transform-set TS
set peer 23.23.23.3
match address 103

5-Apply crypto map
R1(config)#int FastEthernet 1/0R1(config-if)#crypto map CMAP

6-Test the configuration!
To establish IPsec tunnel there must be interesting traffic, in this case we'll ping from 1.1.1.1 to 3.3.3.3, i'll have R3 with isakmp and IPsec debugging. The result should look like this in R1:

R1#ping 3.3.3.3 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 92/100/108 ms


In R3 you should see the negotiation and the SAs being created.