This posts looks more to analyze few design questions and good information on how to complete a successful DMVPN implementation, other than a focus on the configuration. And last but not least, to start a conversation and hear more about what would you do in cases like this (There are many ways to skin a cat!!)
A short background on what got me to this:
I have been most of my Professional career focused on UC and Collaboration technologies until not too long ago that I decided that I wanted to get involved with Security and Networks again. At this point my focus is to be able to maintain a good deal of knowledge on the technologies that cover all Cisco Security suite, but UC is still a great part on what I do daily at my current position.
Enough with the explanations and back to the main point.
Scenario: Requirements:
– Multi-site company needs to implement a solution that uses MPLS as their main connection to communicate between sites. They are also looking to use the Internet as a failover when MPLS fails.
– Currently when MPLS fails, they create static routes to the Firewall, to leverage Site to Site VPNS already in place
– Fail-over and Fail-back needs to happen dynamically
– Voice (My stuff), should not travel over the Internet, SRST is already in place and part of failover per site.
Scenario: The Challenges:
– DMVPN migration operations need to happen gradually, in other words sites should be migrated one by day
– All sites, or better said yet, all infrastructure uses Static Routing (dang!!)
– Remember the Voice requirement before? – well there are a handful of sites were VOICE is required to travel over the Internet Tunnel
– There are 2 Datacenters in different continents, sites from the same continent, do not or should not failover to the other datacenter (continent)
The not so pretty image of the environment playing on VIRL
DMVPN Learning Opportunities
What I discovered going over the requirements, I noticed that there are a plethora of interesting resources out there from Cisco, about how to implement a solution like this. The problem I had with this is that there is no explanation or a good document that talks about how we migrate to DMVPN without affecting other sites.
Digging on this one a bit deeper I found out that there is this concept of Route leaking, or in other words make sure you share routes from the Global routing table to the newly created FVRF.
Information on route leaking:
Easy Virtual Networks
The Great Divide
In case you are new to the VRF concepts please feel free to take a look at this
VRF Concepts and Configuration
More information on what is a FrontDoor VRF or FVRF
FrontDoor VRF or FVRF – Networking with Fish (Great Blog BTW!)
Leaking Routes VRF to Global and Global to VRF
My relevant configuration looks as follows:
vrf definition MPLS
!
address-family ipv4
route-replicate from vrf global unicast all route-map all-static **Check #2
exit-address-family
!
global-address-family ipv4
route-replicate from vrf MPLS unicast connected **Check #1
!
route-map all-static permit 10
match ip address all-static
!
ip access-list extended all-static
permit ip any any
!
interface gi0/0
vrf forwarding MPLS Check #3
ip address 12.12.12.12 255.255.255.252The reasoning behind this:
1 – Sites contain multiple Static routes directed to the PE (Provider’s Edge device) – Now, after applying the FVRF configuration to the MPLS interface, the Global Routing Table has no way to get to the PE’s IP address, replicating the Connected interfaces from the VRF to the Global Routing Table helps to solve this issue.
2 – the new VRF needs a way to send back to the Global Routing table, remember that the sites will need to communicate and your MPLS interface is now in a Routing table that does not know anything about the Global routing table. Control this one with a classic route-map, which points to an ACL, that has a Permit any at the end… as you migrate sites, just deny them on the ACL and they will not show in the FVRF routing table.
3 – Make sure you know this before you configure this one. as soon as you enter the vrf forwarding command, the IP address will be removed from the interface, which will then make you loose access.
Network environments are different, I can say this is the case for almost all networks and sites. So there are maybe cases where all this craziness is not needed, so a good discovery is necessary in order to know things that you will see along the way.
No voice over internet Tunnel
Addressing this could be easy to address by doing the following:
router eigrp 1212
network _HUB_NETWORK1
network _HUB_NETWORK2
network _HUB_NETWORK3
network _HUB_NETWORK4
network _HUB_NETWORK5
passive-interface default
no passive-interface Tunnel2100
no passive-interface Tunnel2200
distribute-list NO-VOICE-OVER-DMVPN out tunnel2200 ***
ip access-list standard NO-VOICE-OVER-DMVPN
deny _VOICENETWORK1
deny _VOICENETWORK2
deny _VOICENETWORK3
deny _VOICENETWORK4
permit any
The challenge is that this will eliminate VOICE networks to go over the Internet tunnel all the time, and to all the Spoke sites, remember we have a handful of sites that do want to failover the Voice traffic using the Internet tunnel?
Few things we can do here:
– At the SPOKES, Create an ACL that helps us matching the CUCM hosts with a deny statement and a permit all at the end
– At the SPOKES, Create a Route-map that matches the ACL and set a tag, just to identify the routes, this is optional
– At the SPOKES, Add the distribution list to the Routing Protocol incoming on the Internet tunnel
router eigrp 1212
network _SPOKE_NETWORK1
network _SPOKE_NETWORK2
network _SPOKE_NETWORK3
network _SPOKE_NETWORK4
network _SPOKE_NETWORK5
passive-interface default
no passive-interface Tunnel2100
no passive-interface Tunnel2200
distribute-list route-map NO-VOICE-OVER-DMVPN in tu2200
route-map NO-VOICE-OVER-DMVPN permit 10
match ip address NO-VOICE-OVER-DMVPN
set tag 200
ip access-list standard NO-VOICE-OVER-DMVPN
deny _VOICENETWORK1
deny _VOICENETWORK2
deny _VOICENETWORK3
deny _VOICENETWORK4
permit any
What to look forward to?
This post is to help anyone out there on how to work around some DMVPN issues that may present, in the future look forward for more interesting stuff on this topic.
I have been out of my blog and most of social media for a while, but looking to be back pretty soon with interesting stuff
About the Author:
Andres Sarmiento, CCIE # 53520 (Collaboration)
With more than 13 years of experience, Andres is specialized in the Unified Communications and Collaboration technologies. Consulted for several companies in South Florida, also Financial Institutions on behalf of Cisco Systems. Andres has been involved in high-profile implementations including Cisco technologies; such as Data Center, UC & Collaboration, Contact Center Express, Routing & Switching, Security and Hosted IPT Service provider infrastructures.
Security is a great field to be in.
indeed! – interesting stuff, but lots and lots of things 🙂