The previous tech tip provided insight into issues surrounding migration from a traditional VPN to an MPLS network based VPN as it relates to support for dual hybrid backbone interconnectivity during migration. Today's tip will discuss routing issues and planning for utilization of an MPLS enabled VPN.
One of the major benefits of utilizing a MPLS layer 3 VPN is that the complex routing that can be associated with large, distributed WAN environments is handled by the VPN provider. Issues surrounding split horizon, ATM and Frame virtual circuit mappings, and dynamic routing protocol neighbor establishment are practically eliminated. The only exchange of routing traffic over the WAN is between the customer CE router and the provider PE router and this is done over one IP interface (although you can have two or more for redundancy to the VPN cloud). This can certainly simplify the administration of the routing architecture over the WAN. However, the internal routing architecture and specifically the flow of traffic to the WAN from multiple entry and exit points is the responsibility of the customer and can create issues during and after the migration to the MPLS solution.
Before embarking on the path towards MPLS migration, it makes sense to optimize the internal routing environment so that when the MPLS service is brought online, there are no routing loops, sub-optimal routing paths, excessive static routes or any other routing architecture component that can cause headaches in the migration. There are several key areas of the routing architecture that need to be evaluated before migrating.
First, is the address space. Are there overlapping addresses? Are the addresses assigned in a manner that allows for aggregation and summarization? MPLS VPN's require distinct address space within a customer site.
Secondly, is there a lot of static routing in the routers? Static routing is a major flag for suboptimal routing designs. If the routing design is robust and scalable, static routing can be virtually eliminated.
Thirdly, are there multiple instances of routing protocols running on the routers? Do some have OSPF and others BGP and EIGRP? Consolidate your routed environment to one IGP and one EGP if at all possible. This will greatly reduce the administration of the routed network moving forward.
Last but not least, does the service provider support the routing protocol deployed in your environment as a viable type for exchanging routing information with the provider PE. This is important. For example, if you have OSPF and the provider only supports EIGRP or static routing, you will have to redistribute these routes into the internal IGP, which can change the routing metrics for these routes and cause traffic to take an undesirable route to a destination.
Finally, by optimizing the internal routing architecture, you can control the flow of traffic within the environment. This allows for right sizing of expensive WAN links and for proper capacity planning. In the end this could eventually save money as the network is optimized for service delivery and prepared to support distributed applications.
Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for SBC Communications. He has over 10 years of experience providing strategic, business, and technical consulting services to clients. Robbie resides in Atlanta, and is a graduate of Clemson University. His background includes positions as a Principal Architect at International Network Services, Lucent, Frontway and Callisma.
4 steps for successfully migrating from MPLS to SDWAN