DMVPN - Rig In a Box (RiB) Solution
I have a customer who has multiple remote sites that require Internet connectivity. The current solution is very hands on in that someone must re-IP devices as they are moved site to site.
This was a perfect opportunity to introduce DMVPN to this customer. The proposed DMVPN Solution for remote site connectivity is a multi-facet DMVPN configuration that utilizes multiple ISP connections, VRF Lite, and Zone Based Firewall technologies.
It is always my goal when developing a design strategy for a customer to stick to the basics, to provide a solution that not only provides scalability but one that is manageable. I always point out a familiar line from an architecture design book:
"Think of the 2:00AM test, if you were awakened in the middle of the night because of a network problem and had to figure out the traffic flows in your network while you were half asleep, could you do it?"
So many Engineers fall into the pattern of designing and configuring networks to their current skill level instead of designing the network based on the business requirements (I am no exception). Overly complex designs that are hard to manage are quite common in the wild, it should be the goal of every Network Engineer to keep the design as simple as possible.
Multi-Facet DMVPN Solution
Unlike your typical DMVPN where perhaps a remote site needs access to the Corporate HQ and should be able to share network resources. My client is looking for their remote sites to simply gain Internet access through the Hub site. In talking with the customer and getting an idea for the potential growth of the solution it was determined that the local Internet circuit should be upgraded to support the upcoming site additions. The circuit was upgraded to a 300Mb/300Mb connection.
It was now time to begin designing the solution to later demonstrate it as a Proof of Concept (PoC). If the customer signs off on the PoC, we simply take the configurations and migrate them to live hardware.
DMVPN Proof of Concept
The overall goal is to provide a remote site (Spoke) Internet connectivity via the corporate HQ (Hub) site. Resources at the spoke site will be VoIP external (Internet SIP Provider) and internal intercom service. The topology for this design is quite simple and is highly modular.
Again, simplicity and a comprehensive approach is my preference and I like to separate my drawings into Layer 3 and Layer 2. I do this as I want to create a drawing so any Engineer walking through the door can quickly wrap their head around the design and begin troubleshooting etc.
While typical DMVPN configurations are relatively straightforward, I went through various designs before settling on the following
Hub - This router also serves as my customers MPLS router so I wanted to completely segment the DMVPN configuration from the current production services provided by this router. How do we do that? Hmmm, oh yes...VRF : )
My previous background and experience has been more involved in switching and various security related avenues (ASA, L2L and SSL VPN's) so while I am fully aware of VRF and what it provides, this was a perfect opportunity for me to implement it and let it work it's magic. Exciting stuff!
Spoke - Multiple ISP connections, should primary fail we need to provide not only failover to a secondary connection but provide failover in a timely manner so that we experience as little downtime as possible, I aimed for anywhere between 15-30 seconds. Our end users are utilizing Citrix and VoIP and with Voice involved, failover must be relatively fast. Voice will be provided by leveraging a Internet SIP provider. I will not go into the CME configuration here, perhaps another time.
Hub Configuration
The Hub configuration is typical DMVPN but of course with the implementation of a VRF, we must ensure our configuration is VRF aware.
1. We first start by creating our VRF, give the VRF a name and create your route distinguisher and ensure CEF is enabled
HQ-RTR (config) # ip vrf DMVPN
HQ-RTR (config-vrf) # rd 1:1
HQ-RTR (config-vrf) # ip cef
2. Configure crypto keyring, ISAKMP policy and profile, again these must be VRF aware and are configured using the following commands:
HQ-RTR (config) # pre-shared key address 0.0.0.0 0.0.0.0 key Cisco123
HQ-RTR (config) # crypto isakmp policy 10
HQ-RTR (config-isakmp) # hash md5
HQ-RTR (config-isakmp) # authentication pre-share
HQ-RTR (config-isakmp) # exit
HQ-RTR (config) # crypto isakmp keepalive 10
HQ-RTR (config) # crypto isakmp profile RiB
HQ-RTR (config-isa-profile) # keyring RiB
HQ-RTR (config-isa-profile) # match identity address 0.0.0.0 0.0.0.0 DMVPN
3. Now configure the IPsec transform-set and IPsec profile:
HQ-RTR (config) # crypto ipsec transform-set strong esp-3des esp-md5-hmac
HQ-RTR (cfg-crypto-trans) # mode transport
HQ-RTR (config) # crypto ipsec profile DMVPN
HQ-RTR (ipsec-profile) # set security-association lifetime seconds 120
HQ-RTR (ipsec-profile) #set transform-set strong
HQ-RTR (ipsec-profile) #set isakmp-profile RiB
That concludes the configuration of our VRF, our crypto and IPsec arguements. Now we need to configure the public facing interface, VTI's, NAT, and create our dynamic routing process to complete the Hub configuration.
I requested a public IP from the customers applicable range, as an example let's use 200.1.1.1/24. Let's apply this to our available interface on the router.
1. Apply public IP to interface and provide a description
HQ-RTR (config) # interface GigabitEthernet0/3
HQ-RTR (config-if) # ip address 200.1.1.1 255.255.255.0
HQ-RTR (config-if) # description DMVPN Internet Connection
2. We will need to provide a means for traffic to reach the Internet via the G0/3 interface, in order for this to happen we will need to NAT/PAT, let's create an ACL to identify which traffic should be PAT'd then create our NAT pool, again we must make our NAT statement VRF aware:
HQ-RTR (config-if) # access-list 1 permit 10.0.0.0 0.255.255.255
HQ-RTR (config) # ip nat pool PAT 200.1.1.1 200.1.1.1 prefix-length 24
HQ-RTR (config) # ip nat inside source list 1 interface GigabitEthernet0/3 vrf DMVPN overload
3. Let's apply NAT to our G0/3 interface
HQ-RTR (config) # interface GigabitEthernet0/3
HQ-RTR (config-if) # ip nat outside
1. Create the VTI's (Virtual Tunnel Interfaces) and assign an IP address in a range that will provide for growth, I have chosen consecutive /24 networks for this purpose
HQ-RTR (config) # interface Tunnel 1
HQ-RTR (config-if) # ip address 10.0.1.1 255.255.255.0
HQ-RTR (config-if) # no ip redirects
HQ-RTR (config-if) # ip mtu 1400
HQ-RTR (config-if) # no ip next-hop-self eigrp 100
HQ-RTR (config-if) # ip nat inside
HQ-RTR (config-if) # ip nhrp authentication Cisco
HQ-RTR (config-if) # ip nhrp map multicast dynamic
HQ-RTR (config-if) # ip nhrp network-id 1
HQ-RTR (config-if) # ip virtual-reassembly in
HQ-RTR (config-if) # no ip split-horizon eigrp 100
HQ-RTR (config-if) # tunnel source GigabitEthernet0/3HQ-RTR (config-if) # tunnel mode gre multipoint
HQ-RTR (config-if) # tunnel key 1111
HQ-RTR (config-if) # tunnel vrf DMVPN
HQ-RTR (config-if) # tunnel protection ipsec profile DMVPN shared
HQ-RTR (config) # interface Tunnel 2
HQ-RTR (config-if) # ip address 10.0.2.1 255.255.255.0
HQ-RTR (config-if) # no ip redirects
HQ-RTR (config-if) # ip mtu 1400
HQ-RTR (config-if) # no ip next-hop-self eigrp 200
HQ-RTR (config-if) # ip nat inside
HQ-RTR (config-if) # ip nhrp authentication Cisco
HQ-RTR (config-if) # ip nhrp map multicast dynamic
HQ-RTR (config-if) # ip nhrp network-id 2
HQ-RTR (config-if) # ip virtual-reassembly in
HQ-RTR (config-if) # no ip split-horizon eigrp 200
HQ-RTR (config-if) # tunnel source GigabitEthernet0/3HQ-RTR (config-if) # tunnel mode gre multipoint
HQ-RTR (config-if) # tunnel key 2222
HQ-RTR (config-if) # tunnel vrf DMVPN
HQ-RTR (config-if) # tunnel protection ipsec profile DMVPN shared
Let's configure the EIGRP processes now, one for each connection that will be on the spoke side:
1. Let's now create the EIGRP routing processes and again, we must make the routing process aware of our VRF, thus making the autonomous system part of our VRF:
HQ-RTR (config) # router eigrp 100
HQ-RTR (config-router) # address-family ipv4 vrf DMVPN autonomous-system 100
HQ-RTR (config-router-af) # redistribute static
HQ-RTR (config-router-af) # network 10.0.1.1 0.0.0.0HQ-RTR (config-router-af) # passive-interface default
HQ-RTR (config-router-af) # no passive-interface Tunnel 1
HQ-RTR (config-router-af) # exit
HQ-RTR (config) # router eigrp 200
HQ-RTR (config-router) # address-family ipv4 vrf DMVPN autonomous-system 200
HQ-RTR (config-router-af) # redistribute static
HQ-RTR (config-router-af) # network 10.0.2.1 0.0.0.0HQ-RTR (config-router-af) # passive-interface default
HQ-RTR (config-router-af) # no passive-interface Tunnel 2
HQ-RTR (config-router-af) # exit
2. We have to ensure we have a default route for our new public facing interface (G0/3) and of course once again it must be VRF aware:
HQ-RTR (config) # ip route vrf DMVPN 0.0.0.0 0.0.0.0 200.1.1.2
3. Let's take a quick look at our vrf routing table, is our default route in the routing table?
HQ-RTR # sh ip route vrf DMVPN
Routing Table: DMVPN
Codes: L - local, C - connected, S -
static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
S*
0.0.0.0/0 [1/0] via 200.1.1.2
10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C
10.0.1.0/24 is directly connected, Tunnel1
L 10.0.1.1/32 is directly connected,
Tunnel1
C
10.0.2.0/24 is directly connected, Tunnel2
L
10.0.2.1/32 is directly connected, Tunnel2
200.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 200.1.1.0/24 is directly connected, GigabitEthernet0/3
L 200.1.1.1/32 is directly connected, GigabitEthernet0/3
4. One last thing and I have mentioned it over and over during the configurations above, are all of our interfaces VRF aware? Have we assigned interfaces to the VRF? We must configure VRF forwarding on our VTI's and Public Facing interface. Let's do that and finalize the configuration of our Hub router:
HQ-RTR (config) # interface GigabitEthernet0/3
HQ-RTR (config-if) # ip vrf forwarding DMVPN
HQ-RTR (config) # interface Tunnel 1
HQ-RTR (config-if) # ip vrf forwarding DMVPN
HQ-RTR (config) # interface Tunnel 1
HQ-RTR (config-if) # ip vrf forwarding DMVPN
5. That now completes the configuration on the Hub router!
Now it is time to configure the Spoke router....
Spoke Configuration
As I mentioned before, this spoke design went through various iterations, remember that failover timers need to be tweaked in order to provide for quick failover to the secondary Internet connection. I initially went with the Primary Internet up with the Secondary being down, I configured IP SLA to help track connectivity, used a floating static route then leveraged EEM to bring the secondary up and shut the other VTI down. Once both connections were up at the same time, loads of errors and failover was far from fast.
I decided once again to leverage VRF, but in particular this is a FVRF configuration in that we leave the VTI's in the global routing table and the only interface that is a member of the VRF is the secondary internet interface. This way were are using the VRF to negotiate IPsec, we then leverage the global routing table for dynamic routing across the tunnel/s. Both interfaces are up at the same time, I can then control routing by placing a higher delay metric on the secondary VTI.
Let's get started:
1. Again we start by creating a VRF, give the VRF a name and create a route distinguisher. Enable CEF if it is not already enabled
Spoke-RTR (config) # ip vrf RigSecondary
Spoke-RTR (config) # crypto keyring RiB vrf RigSecondary
**Note: This solution utilizes a head-end router (1900) that will provide DHCP addresses to each RiB. This is why we see a typical RFC1918 address on the primary outside interface.**
1. We plug the sites internet connection into port G0/0 and receive an IP address via DHCP, same for the Secondary interface which will receive a public IP address for the ISP, this is a Satellite connection, let's use 140.1.1.2/24 as a reference for this connection.
2. Now let's create our NAT statements for our outside interfaces, let's use route maps for this
3. Let's apply NAT to our interfaces
4. Now let's create our VTI's, again we are using IP addresses from the same /24 network on the Hub (10.0.1.0/24 and 10.0.2.0/24).
Spoke-RTR (config-if) # tunnel key 1111
Spoke-RTR (config-if) # tunnel protection ipsec profile DMVPN
Since we are leveraging a FVRF configuration, the secondary tunnel will have a few slight differences in the configuration, this way the tunnel endpoint is negotiated via the VRF which is based on the "tunnel vrf" command. Otherwise, the endpoint negotiation would take place via the global routing table and for this design, this is something we do not want to occur.
Spoke-RTR (config-if) # tunnel key 2222
Spoke-RTR (config-if) # tunnel vrf RigSecondary
Spoke-RTR (config-if) # tunnel protection ipsec profile DMVPN
It is now time to configure our EIGRP processes, one for each public interface
1. Let's create the EIGRP routing processes and again, we have multiple network segments that we need to advertise:
Spoke-RTR (config-router-af) # no passive-interface Tunnel 1
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.10
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.20
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.30
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.99
Spoke-RTR (config-router-af) # exit
Spoke-RTR (config-router-af) # passive-interface default
Spoke-RTR (config-router-af) # no passive-interface Tunnel 2
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.10
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.20
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.30
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.99
Spoke-RTR (config-router-af) # exit
Unlike with the Hub router, we do not need a static route to be configured. If you will remember from the configuration of the hub we are redistributing a static route down to the spoke, this way the spoke will receive a default route via EIGRP for each active connection.
In order to ensure the Primary connection is the chosen path, let's set a delay metric on the secondary tunnel interface
Let's now verify EIGRP, we should have a default route in our global routing table via Tunnel 1 to the Hub router
Spoke-RTR# sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 10.0.1.1 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/26880256] via 10.0.1.1, 04:43:45, Tunnel1 <----- Default Route via EIGRP
10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks
C 10.0.1.0/24 is directly connected, Tunnel1
L 10.0.1.2/32 is directly connected, Tunnel1
C 10.0.2.0/24 is directly connected, Tunnel2
L 10.0.2.2/32 is directly connected, Tunnel2
C 10.175.0.0/16 is directly connected, GigabitEthernet0/0
L 10.175.1.253/32 is directly connected, GigabitEthernet0/0
C 10.250.1.0/24 is directly connected, GigabitEthernet0/1.10
L 10.250.1.254/32 is directly connected, GigabitEthernet0/1.10
C 10.250.2.0/24 is directly connected, GigabitEthernet0/1.20
L 10.250.2.254/32 is directly connected, GigabitEthernet0/1.20
C 10.250.3.0/24 is directly connected, GigabitEthernet0/1.30
L 10.250.3.254/32 is directly connected, GigabitEthernet0/1.30
C 10.250.99.0/24 is directly connected, GigabitEthernet0/1.99
L 10.250.99.254/32 is directly connected, GigabitEthernet0/1.99
Now let's verify connectivity to the Internet from the Spoke-RTR
Spoke-RTR# traceroute 4.2.2.2
Type escape sequence to abort.
Tracing the route to 4.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.1.1 44 msec 44 msec 56 msec <------traffic has traversed the tunnel
2 x.x.x.x 48 msec 44 msec 40 msec
3 x.x.x.x 44 msec 48 msec 44 msec
4 x.x.x.x 80 msec *
x.x.x.x 48 msec
5 x.x.x.x 52 msec * *
6
Spoke-RTR# ping 4.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/77/80 ms
Another command to verify DMVPN connectivity that is useful is "sh dmvpn", and "sh crypto session"
Spoke-RTR#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel1, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 200.1.1.1 10.0.1.1 UP 05:00:23 S
Interface: Tunnel2, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 200.1.1.1 10.0.2.1 UP 05:00:18 S
Spoke-RTR#sh crypto session Spoke Configuration
As I mentioned before, this spoke design went through various iterations, remember that failover timers need to be tweaked in order to provide for quick failover to the secondary Internet connection. I initially went with the Primary Internet up with the Secondary being down, I configured IP SLA to help track connectivity, used a floating static route then leveraged EEM to bring the secondary up and shut the other VTI down. Once both connections were up at the same time, loads of errors and failover was far from fast.
I decided once again to leverage VRF, but in particular this is a FVRF configuration in that we leave the VTI's in the global routing table and the only interface that is a member of the VRF is the secondary internet interface. This way were are using the VRF to negotiate IPsec, we then leverage the global routing table for dynamic routing across the tunnel/s. Both interfaces are up at the same time, I can then control routing by placing a higher delay metric on the secondary VTI.
Let's get started:
1. Again we start by creating a VRF, give the VRF a name and create a route distinguisher. Enable CEF if it is not already enabled
Spoke-RTR (config) # ip vrf RigSecondary
Spoke-RTR (config-vrf) # rd 1:1
Spoke-RTR (config-vrf) # ip cef
2. Configure crypto keyring, and ISAKMP policy, again let's make sure the keyring is VRF aware:
Spoke-RTR (config) # pre-shared key address 0.0.0.0 0.0.0.0 key Cisco123
Spoke-RTR (config) # crypto isakmp policy 10
Spoke-RTR (config-isakmp) # hash md5
Spoke-RTR (config-isakmp) # authentication pre-share
Spoke-RTR (config-isakmp) # exit
Spoke-RTR (config) # crypto isakmp keepalive 10
3. Now configure the IPsec transform-set and IPsec profile:
Spoke-RTR (config) # crypto ipsec transform-set strong esp-3des esp-md5-hmac
Spoke-RTR (cfg-crypto-trans) # mode transport
Spoke-RTR (config) # crypto ipsec profile DMVPN
Spoke-RTR (ipsec-profile) # set security-association lifetime seconds 120
Spoke-RTR (ipsec-profile) #set transform-set strong
1. We plug the sites internet connection into port G0/0 and receive an IP address via DHCP, same for the Secondary interface which will receive a public IP address for the ISP, this is a Satellite connection, let's use 140.1.1.2/24 as a reference for this connection.
Spoke-RTR (config) # sh interface GigabitEthernet0/3
!
interface GigabitEthernet0/0
ip dhcp client default-router distance 1
ip address dhcp
Spoke-RTR (config) # sh ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.175.1.253 YES DHCP up up
interface GigabitEthernet0/0
ip dhcp client default-router distance 1
ip address dhcp
Spoke-RTR (config) # sh ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.175.1.253 YES DHCP up up
Spoke-RTR (config) # sh interface GigabitEthernet0/1.98
!
interface GigabitEthernet0/1.98
ip dhcp client default-router distance 1
ip address dhcp
Spoke-RTR (config) # sh ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/1.98 140.1.1.2 YES DHCP up up
interface GigabitEthernet0/1.98
ip dhcp client default-router distance 1
ip address dhcp
Spoke-RTR (config) # sh ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/1.98 140.1.1.2 YES DHCP up up
2. Now let's create our NAT statements for our outside interfaces, let's use route maps for this
Spoke-RTR (config-if) # route-map InternetPRI permit 10
Spoke-RTR (config-route-map) # match interface GigabitEthernet0/0
Spoke-RTR (config-if) # route-map InternetSEC permit 10
Spoke-RTR (config-route-map) # match interface GigabitEthernet0/1.98
Spoke-RTR (config) # ip nat inside source route-map InternetPRI interface G0/0 overload
Spoke-RTR (config) # ip nat inside source route-map InternetSEC interface G0/1.98 overload
Spoke-RTR (config) # ip nat inside source route-map InternetPRI interface G0/0 overload
Spoke-RTR (config) # ip nat inside source route-map InternetSEC interface G0/1.98 overload
3. Let's apply NAT to our interfaces
Spoke-RTR (config) # interface GigabitEthernet0/0
Spoke-RTR (config-if) # ip nat outside
Spoke-RTR (config) # interface GigabitEthernet0/1.98
Spoke-RTR (config-if) # ip nat outside
4. Now let's create our VTI's, again we are using IP addresses from the same /24 network on the Hub (10.0.1.0/24 and 10.0.2.0/24).
Spoke-RTR (config) # interface Tunnel 1
Spoke-RTR (config-if) # ip address 10.0.1.2 255.255.255.0
Spoke-RTR (config-if) # no ip redirects
Spoke-RTR (config-if) # ip mtu 1400
Spoke-RTR (config-if) # ip nat inside
Spoke-RTR (config-if) # ip nhrp authentication Cisco
Spoke-RTR (config-if) # ip nhrp map multicast dynamic
Spoke-RTR (config-if) # ip nhrp map multicast dynamic
Spoke-RTR (config-if) # ip nhrp map 10.0.1.1 200.1.1.1
Spoke-RTR (config-if) # ip nhrp map multicast 200.1.1.1
Spoke-RTR (config-if) # ip nhrp map multicast 200.1.1.1
Spoke-RTR (config-if) # ip nhrp network-id 1
Spoke-RTR (config-if) # ip virtual-reassembly in
Spoke-RTR (config-if) # tunnel source GigabitEthernet0/0
Spoke-RTR (config-if) # tunnel mode gre multipointSpoke-RTR (config-if) # tunnel key 1111
Spoke-RTR (config-if) # tunnel protection ipsec profile DMVPN
Since we are leveraging a FVRF configuration, the secondary tunnel will have a few slight differences in the configuration, this way the tunnel endpoint is negotiated via the VRF which is based on the "tunnel vrf" command. Otherwise, the endpoint negotiation would take place via the global routing table and for this design, this is something we do not want to occur.
Spoke-RTR (config) # interface Tunnel 2
Spoke-RTR (config-if) # ip address 10.0.2.2 255.255.255.0
Spoke-RTR (config-if) # no ip redirects
Spoke-RTR (config-if) # ip mtu 1400
Spoke-RTR (config-if) # ip nat inside
Spoke-RTR (config-if) # ip nhrp authentication Cisco
Spoke-RTR (config-if) # ip nhrp map multicast dynamic
Spoke-RTR (config-if) # ip nhrp map multicast dynamic
Spoke-RTR (config-if) # ip nhrp map 10.0.2.1 200.1.1.1
Spoke-RTR (config-if) # ip nhrp map multicast 200.1.1.1
Spoke-RTR (config-if) # ip nhrp map multicast 200.1.1.1
Spoke-RTR (config-if) # ip nhrp network-id 2
Spoke-RTR (config-if) # ip virtual-reassembly in
Spoke-RTR (config-if) # tunnel source GigabitEthernet0/1.98
Spoke-RTR (config-if) # tunnel mode gre multipointSpoke-RTR (config-if) # tunnel key 2222
Spoke-RTR (config-if) # tunnel vrf RigSecondary
Spoke-RTR (config-if) # tunnel protection ipsec profile DMVPN
It is now time to configure our EIGRP processes, one for each public interface
1. Let's create the EIGRP routing processes and again, we have multiple network segments that we need to advertise:
Spoke-RTR (config) # router eigrp 100
Spoke-RTR (config-router-af) # network 10.0.1.2 0.0.0.0
Spoke-RTR (config-router-af) # network 10.250.0.0 0.0.255.255
Spoke-RTR (config-router-af) # passive-interface defaultSpoke-RTR (config-router-af) # network 10.250.0.0 0.0.255.255
Spoke-RTR (config-router-af) # no passive-interface Tunnel 1
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.10
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.20
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.30
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.99
Spoke-RTR (config-router-af) # exit
Spoke-RTR (config) # router eigrp 200
Spoke-RTR (config-router-af) # network 10.0.2.2 0.0.0.0
Spoke-RTR (config-router-af) # network 10.250.0.0 0.0.255.255Spoke-RTR (config-router-af) # passive-interface default
Spoke-RTR (config-router-af) # no passive-interface Tunnel 2
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.10
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.20
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.30
Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.99
Spoke-RTR (config-router-af) # exit
Unlike with the Hub router, we do not need a static route to be configured. If you will remember from the configuration of the hub we are redistributing a static route down to the spoke, this way the spoke will receive a default route via EIGRP for each active connection.
In order to ensure the Primary connection is the chosen path, let's set a delay metric on the secondary tunnel interface
Spoke-RTR (config) # interface Tunnel 2
Spoke-RTR (config-if) # delay 100000
Let's now verify EIGRP, we should have a default route in our global routing table via Tunnel 1 to the Hub router
Spoke-RTR# sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 10.0.1.1 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/26880256] via 10.0.1.1, 04:43:45, Tunnel1 <----- Default Route via EIGRP
10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks
C 10.0.1.0/24 is directly connected, Tunnel1
L 10.0.1.2/32 is directly connected, Tunnel1
C 10.0.2.0/24 is directly connected, Tunnel2
L 10.0.2.2/32 is directly connected, Tunnel2
C 10.175.0.0/16 is directly connected, GigabitEthernet0/0
L 10.175.1.253/32 is directly connected, GigabitEthernet0/0
C 10.250.1.0/24 is directly connected, GigabitEthernet0/1.10
L 10.250.1.254/32 is directly connected, GigabitEthernet0/1.10
C 10.250.2.0/24 is directly connected, GigabitEthernet0/1.20
L 10.250.2.254/32 is directly connected, GigabitEthernet0/1.20
C 10.250.3.0/24 is directly connected, GigabitEthernet0/1.30
L 10.250.3.254/32 is directly connected, GigabitEthernet0/1.30
C 10.250.99.0/24 is directly connected, GigabitEthernet0/1.99
L 10.250.99.254/32 is directly connected, GigabitEthernet0/1.99
Now let's verify connectivity to the Internet from the Spoke-RTR
Spoke-RTR# traceroute 4.2.2.2
Type escape sequence to abort.
Tracing the route to 4.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.1.1 44 msec 44 msec 56 msec <------traffic has traversed the tunnel
2 x.x.x.x 48 msec 44 msec 40 msec
3 x.x.x.x 44 msec 48 msec 44 msec
4 x.x.x.x 80 msec *
x.x.x.x 48 msec
5 x.x.x.x 52 msec * *
6
Spoke-RTR# ping 4.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/77/80 ms
Another command to verify DMVPN connectivity that is useful is "sh dmvpn", and "sh crypto session"
Spoke-RTR#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel1, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 200.1.1.1 10.0.1.1 UP 05:00:23 S
Interface: Tunnel2, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 200.1.1.1 10.0.2.1 UP 05:00:18 S
Crypto session current status
Interface: Tunnel1
Session status: UP-ACTIVE
Peer: 200.1.1.1 port 4500
IKEv1 SA: local 10.175.1.253/4500 remote 200.1.1.1/4500 Active
IPSEC FLOW: permit 47 host 10.175.1.253 host 200.1.1.1
Active SAs: 2, origin: crypto map
Interface: Tunnel2
Session status: UP-ACTIVE
Peer: 200.1.1.1 port 500
IKEv1 SA: local 140.1.1.2/500 remote 200.1.1.1/500 Active
IPSEC FLOW: permit 47 host 140.1.1.2 host 200.1.1.1
Active SAs: 2, origin: crypto map
Failover to Secondary
Of course we need to verify failover, let's create a failover scenario. I will shutdown the Tunnel 1 interface on the Hub and monitor the Spoke
Spoke-RTR#
*Jan 14 02:51:15.938: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.1.1 (Tunnel1) is down: holding time expired
We have lost adjacency via Tunnel 1 as shown above, let's now look at the routing table, we should have a new default route via EIGRP
Spoke-RTR#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 10.0.2.1 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/51200256] via 10.0.2.1, 00:03:03, Tunnel2 <----- Default Route via EIGRP
10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks
C 10.0.1.0/24 is directly connected, Tunnel1
L 10.0.1.2/32 is directly connected, Tunnel1
C 10.0.2.0/24 is directly connected, Tunnel2
L 10.0.2.2/32 is directly connected, Tunnel2
C 10.175.0.0/16 is directly connected, GigabitEthernet0/0
L 10.175.1.253/32 is directly connected, GigabitEthernet0/0
C 10.250.1.0/24 is directly connected, GigabitEthernet0/1.10
L 10.250.1.254/32 is directly connected, GigabitEthernet0/1.10
C 10.250.2.0/24 is directly connected, GigabitEthernet0/1.20
L 10.250.2.254/32 is directly connected, GigabitEthernet0/1.20
C 10.250.3.0/24 is directly connected, GigabitEthernet0/1.30
L 10.250.3.254/32 is directly connected, GigabitEthernet0/1.30
C 10.250.99.0/24 is directly connected, GigabitEthernet0/1.99
L 10.250.99.254/32 is directly connected, GigabitEthernet0/1.99
Is traffic routing via Tunnel 2?
Spoke-RTR#traceroute 4.2.2.2
Type escape sequence to abort.
Tracing the route to 4.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.2.1 688 msec 708 msec 720 msec <----- Traffic has traversed Tunnel 2
2 x.x.x.x 732 msec 700 msec 720 msec
3 x.x.x.x 720 msec 720 msec 760 mse
Time to bring the primary back online
Spoke-RTR#
*Jan 14 03:02:13.945: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.1.1 (Tunnel1) is up: new adjacency
The routing table is again routing traffic out Tunnel 1
Spoke-RTR#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 10.0.1.1 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/26880256] via 10.0.1.1, 00:00:26, Tunnel1 <---- Primary route restored
10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks
C 10.0.1.0/24 is directly connected, Tunnel1
L 10.0.1.2/32 is directly connected, Tunnel1
C 10.0.2.0/24 is directly connected, Tunnel2
L 10.0.2.2/32 is directly connected, Tunnel2
C 10.175.0.0/16 is directly connected, GigabitEthernet0/0
L 10.175.1.253/32 is directly connected, GigabitEthernet0/0
C 10.250.1.0/24 is directly connected, GigabitEthernet0/1.10
L 10.250.1.254/32 is directly connected, GigabitEthernet0/1.10
C 10.250.2.0/24 is directly connected, GigabitEthernet0/1.20
L 10.250.2.254/32 is directly connected, GigabitEthernet0/1.20
C 10.250.3.0/24 is directly connected, GigabitEthernet0/1.30
L 10.250.3.254/32 is directly connected, GigabitEthernet0/1.30
C 10.250.99.0/24 is directly connected, GigabitEthernet0/1.99
L 10.250.99.254/32 is directly connected, GigabitEthernet0/1.99
That concludes the configuration and testing of this DMVPN solution. I learned a lot during the implementation of this and am satisfied with the results.
ZBFW Configuration (Zone Based Firewall)
I will cover ZBFW in a separate blog, however I did utilize ZBFW for the Spoke router, the configuration is rather straight forward and is as follows
class-map type inspect match-any
trust-to-untrust
match protocol tcp
match protocol udp
match protocol icmp
class-map type inspect match-all
vpn-to-trust
match access-group 100
class-map type inspect match-any
untrust-to-trust-icmp
match protocol icmp
class-map type inspect match-any
untrust-to-trust-ssh
match protocol ssh
!
policy-map type inspect
trust-to-untrust-policy-map
class type inspect trust-to-untrust
inspect
class class-default
drop
policy-map type inspect
untrust-to-trust-policy-map
class type inspect untrust-to-trust-ssh
inspect
class type inspect untrust-to-trust-icmp
inspect
class type inspect vpn-to-trust
inspect
class class-default
drop
!
zone security trust
zone security untrust
zone-pair security trust-to-untrust source
trust destination untrust
service-policy type inspect
trust-to-untrust-policy-map
zone-pair security untrust-to-trust source
untrust destination trust
service-policy type inspect
untrust-to-trust-policy-mapEach interface must now be assigned to a zone, either trust or untrust. Outside interfaces will be assigned the untrust zone, while all internal LAN interfaces and VTI's will be assigned to the trust zone. The commands are
zone-member security trust
zone-member security untrust
I also have configured a L2L VPN on the spoke, that is what the class-map "vpn-to-trust" references but I will not delve into that topic here.
I will soon be implementing a secondary Hub, check back in the near future. As I begin to work on that solution I will post my thoughts here.
Until then, Happy Routing!
Comments
Post a Comment