«

»

Print this Post

MPLS Headend FVRF Migration Strategy

Say you have a network that currently has an MPLS WAN from your HQ to all of your Branches. You want to migrate these MPLS connections into a DMVPN design and in doing that, you would like to move the MPLS links into a Front Door VRF. There comes a challenge with this move in regards to the routing tables and when to move the headend.

The topology used in the following demonstration is below:
Screen Shot 2017-05-17 at 5.50.47 PM

A common approach would be to migrate all of the spokes into their new VRF and then flash cut the headend into it’s VRF. However, there is an inherent risk in this approach. While you can pre-stage the DMVPN tunnels on all of the spokes the migration process would look similar to this:

Migrate MPLS connection on spoke to FVRF
Migrate MPLS BGP peering on spoke to VRF Aware
Leak VRF RIB into Global RIB on spoke
Pre-stage FVRF aware DMVPN Tunnel
Pre-stage Overlay routing protocol
Repeat for each spoke.

At this point our Spokes should be pre-staged and we will migrate the headend. Here is where the challenge comes in. If there is an issue on the headend, or the spoke configurations, we could be in a situation where all spokes are down for an extended period of time while we figure out where the issue in routing lies. In my opinion a better approach is to pre-stage and cutover the headend first. With proper planning we can migrate spokes individually, one at a time while maintaining full connectivity.

Here is our challenge scenario:

At our headend our datacenter core has an OSPF peering to our MPLS CE router. Our MPLS provider peers PE-CE with eBGP. Mutual OSPF to BGP redistribution is occurring on the CE router. We want make this CE router our DMVPN headend with EIGRP as the overlay protocol allowing summarization to the spokes for a Phase 3 DMVPN. I’ve worked out the following strategy in such a way to allow our Headend router to be cutover in a “pre-staged” DMVPN which will allow full connectivity between migrated and un migrated spokes utilizing our new Overlay routing protocol. In this strategy we maintain the headend PC-CE eBGP peering until the very end.

Since our spokes will be using either the BGP underlay peering or EIGRP overlay peering at a given time as the primary means of learning prefixes destinations redistribution will be required at the headend between BGP & OSPF, as well as EIGRP & OSPF. The following outlines the redistribution requirements.

All BGP routes will be redistributed into OSPF. This is already occurring due to the MPLS eBGP peering with the SP and OSPF being the primary infrastructure routing protocol at the headend.

EIGRP will also be redistributed into OSPF as once a spoke has been migrated to DMVPN the headend will be learning the respective spokes routes via EIGRP.

OSPF is redistributed into BGP to facilitate the headend subnets reaching non-migrated sites.

EIGRP will need to be redistributed into BGP to facilitate non-migrated sites learning prefixes of migrated sites. Since EIGRP has a more preferred AD then OSPF the headend will see migrated spokes as EIGRP routes not OSPF routes. Care will be taken to now leak the summary address(es) or the overlay tunnel address into BGP causing tunnel issues.

First we will look at the headend routing table before we stage and perform the cutover:

The first part of the strategy is going to be planning the route-map and prefix lists needed for the FVRF to Global and Global to FVRF route table leaking on the headend CE. In this case I am going to simply allow all prefixes to be leaked between to two creating a simple prefix-list and route-map configuration:

Next we will pre-stage the VRF Configuration to allow the leaks between the two routing tables as well as prestige the default route required for the FVRF. In this case, the default route will point to what is currently the eBGP neighbor. In lobbing both the rd as well as the route-targets were required for this to function properly:

Before we migrate the PE facing interface into the VRF as well as prior to migrating the eBGP peering to VRF aware lets look at the current eBGP configuration.

At this point we will add the VRF aware configuration for eBGP. This requires adding the existing neighbor underneath the address-family ipv4 vrf command. Below is the finished output of our BGP configuration at this point:

Now I am going to pre-stage the CE Tunnel interface. For simplicity in this post I am going to leave of crypto. Below is the basic DMVPN headend tunnel configuration. Notice the tunnel VRF command. This allows this tunnel interface to be pre-staged for the first spoke migration. Also take special note that at this time redirects are turned off. They will be turned on after the final spoke has been migrated:

The next step is to pre-stage the overlay routing protocol on the CE. In this case we are going to use EIGRP and summarize the address space down the tunnel. For simplicity I have left off items such as authentication that would traditionally be used in a production deployment:

Now we need to create our protection route-map for redistributing EIGRP into BGP. Afterwords we will redistribute EIGRP into both BGP and OSPF. The following prefix list denies the overlay tunnel prefix as well as the summary prefix.

Now we will redistribute EIGRP into both OSPF and BGP on the CE router. The final output is shown below:

We are now ready to migrate the CE MPLS interface into the FVRF. This will naturally cause a short outage while the new VRF aware BGP peering comes up and routes are leaked into the global routing table. After this is done however, the CE router will be able to route traffic for both migrated and non-migrated spokes. That is, MPLS native spokes and DMVPN over FVRF MPLS Spokes:

As you can see and are likely aware, once you add the interface to the VRF the IP address is removed, the tunnel interface will go down and then up, and the original BGP peering goes down. After a short time the new VRF aware BGP peering comes up.

If we now look at the routing table on the CE router we will notice that all of the routes still exist. However, the MPLS routes are now listed as being in the new VRF.

If we hop back behind the headend CE router we can see the routing table has entries for all of the MPLS spokes as O E2 routes. This confirms our VFR BGP process is redistributed properly into OSPF.

To verify full connectivity the below output shows a ping from the headend core switch to both branches. Also pings are tested between the two branches.

We are now ready to cutover our first spoke route. With the headend already migrated to an FVRF model, and the tunnel interface pre-staged along with the overlay routing and redistribution. We should be able to migrate a spoke and still maintain full connectivity to non migrated spokes. To start, we will pre-stage the VRF, Tunnel, and EIGRP on Branch 1’s spoke. Again, the VRF’s default route will point to the current eBGP peer of that spoke. Mutual redistribution will occur between OSPF and EIGRP.

Now that we are pre-staged on our Branch 1 spoke we will verify connectivity again before migration. A Ping is done from Branch 1 to Branch 2, as well as Branch 1 to the HQ.

We are not ready to move the spokes PE facing interface into the VRF. The tunnel should come up on it’s own and we should maintain full connectivity. Once done we will look at the Spoke routing table, as well as the HQ core switch to verify the routes are as expected.

The following output shows the configuration of the PE-CE interface on Branch 1 spoke as well as it’s routing table after the tunnel and EIGRP adjacency comes up:

Below is the Core Switch behind Branch 1 confirming it’s routing table has received the 10.0.0.0/8 summary route via OSPF to EIGRP redistribution:

Next we verify on both the headend core still knows about the Branch 1 subnets via the EIGRP to OSPF Redistribution.

Now we verify Branch 2 knows about the Branch 1 subnets through the existing MPLS connections and are redistributed into OSPF:

Not we will do our ping tests to verify branch to branch and branch to headend connectivity (full connectivity).

Following the same procedure we will migrate Branch 2. Utilizing pre-staging of VRF, VRF default route, EIGRP, and Tunnel Interface.

Now both branched only have a summary route via EIGRP, and their local OSPF routes. No BGP routes show up in the routing table. If we look at the headend CE we will noticed that it too, has only EIGRP and OSPF routes with the exception of the BGP underlay routes for the point-to-points between each PE and CE:

Armed with this information in mind, we are safe to remove the BGP configuration at all locations relying solely on the default routes within the FVRF and obtaining routing only from the overlay in the global RIB.

Once all of the BGP configuration is removed we will apply nhpr redirects to the headend, and nhrp shortcuts to the spokes. This will allow dynamic spoke to spoke tunnels. We will then confirm full connectivity in our new FVRF DMVPN over MPLS. The first trace will be from Branch 2 to branch 1 showing the normal path before the spoke to spoke tunnel. The second trace shows the same source destination after the spoke to spoke tunnel. This proves spoke to spoke connectivity. The last trace is from Branch 2 to the headend.

As this strategy shows. It is possible to set up an exiting MPLS WAN to allow for a slow and methodical migration of spokes as time permits. By taking care with redistribution and carefully planning and staging the headend as your first migration you allow spokes to come up and maintain migrated and non migrated spoke connectivity.

To summarize the migration strategy:
Prestage VRF on headend – this included VRF leak maps, VRF default route, and VRF aware BGP configuration
Prestage DMVPN Tunnel (minus redirects) and overlay routing protocol
Carefully plan and prestage appropriate route redistribution to facilitate full connectivity at all times
Migrate headend MPLS interface into VRF
Pre-stage Spoke with VRF, VRF default route, tunnel interface (minus shortcuts), overlay routing protocol
Pre-stage Spoke redistribution as necessary
Migrate spoke MPLS interface into VRF
Remove BGP configurations once all tunnels are up
Add NHRP shortcuts and redirects to spokes and headends respectively

Matt Ouellette is a certified information technology professional residing in Southwest Michigan. His technology findings and advice can be found on his PacketPilot blog. Mr. Ouellette spent 4 years as an I.T. Technician before stepping into a Network Engineer role at Bronson Health Group. Since completing his Associates Degree in Network Administration Matt has taken a head on approach to career enrichment through obtaining credentials such as CCNP, CCNA Voice, MCSA: Server 2008, and VCP5. This passion for continued learning allows him to deliver up to date quality technical solutions.

Permanent link to this article: http://www.packetpilot.com/mpls-headend-fvrf-migration-strategy/