MPLS technology has been around for several years, and businesses are starting to take advantage of implementations available from both domestic and global providers. Although most providers are still sticking to basics when it comes to deployment and features, it's a good idea for the engineering groups within organizations to know how they should prepare their current networks for transition. In this article, I explain the most basic MPLS implementations and show you some of the most common configurations for MPLS VPNs (L2VPN, GMPLS and VPLS are beyond the scope of this article).
Decision factors
Like any significant business decision, a number of qualifying factors usually drive a potential migration to MPLS. Several common reasons are:
- Converged services capabilities (voice, video, data).
- Any-to-any connectivity without the high cost of individual circuits.
- Advanced features for ingress and egress routing policies (load sharing, policy routing).
- Secure flexibility of adding future businesses and partners (multiple VPN support).
- Circuit consolidation (frame, T-X, ATM).
These highlight some of the most common criteria, but it is important that you know the drivers behind your company's decision to move toward an MPLS solution because some MPLS or protocol features may or may not be supported by the provider. It's also important because it can determine the overall network design moving forward.
Communication methods
Once the decision has been made to move toward an MPLS solution, the next step is designing your network to support the change and prepping your infrastructure to handle it. There are typically four ways a client can communicate with an MPLS VPN provider: BGP, OSPF, RIPv2 and static routing. Of these choices, BGP is recommended for most organizations because it provides the most flexibility and control of prefixes within the VPN. Assume for a second that BGP has been chosen for Provider Edge (PE)-to-Customer Edge (CE) communication; the next step is determining what features are actually supported on the MPLS backbone. Some routing-related questions you should ask are:
- Do you support BGP communities? If so, which ones -- and what do you do with them?
- Is there a deterministic method of route selection on your backbone?
- Do you support inbound load balancing with eiBGP?
- Do you support Outbound Route Filtering (ORF)?
You may have other questions that are unique to your environment, but keep in mind that while the technology has evolved, the bigger providers are still playing catch-up, and features may not be immediately available.
Typical configuration
When peering with an MPLS PE via BGP, the configurations are typically identical to any eBGP peering session. Here is a sample BGP configuration between 1 CE and 1 PE (use the figure below as a reference):
hostname CE1
!
router bgp 15000
bgp router-id 150.1.1.1
neighbor 135.12.1.2 remote-as 13700
neighbor 135.12.1.2 description MPLS PE Router, POS1/0
neighbor 135.12.1.2 prefix-list Backbone_Out out
neighbor 135.12.1.2 route-map LP in
neighbor 150.1.1.2 remote-as 15000
neighbor 150.1.1.2 update-source lo0
!
ip prefix-list Backbone_Out seq 20 permit 10.0.0.0/8
ip prefix-list Backbone_Out seq 25 permit 150.1.1.0/24
!
route-map LP permit 10
match as-path 1
set local-preference 150
!
ip as-path access-list 1 permit ^65145$
hostname CE2
!
router bgp 15000
bgp router-id 150.1.1.2
neighbor 135.12.1.6 remote-as 13700
neighbor 135.12.1.6 description MPLS PE Router, POS2/0
neighbor 135.12.1.6 prefix-list Backbone_Out out
neighbor 150.1.1.1 remote-as 15000
neighbor 150.1.1.1 update-source lo0
!
ip prefix-list Backbone_Out seq 20 permit 10.0.0.0/8
ip prefix-list Backbone_Out seq 25 permit 150.1.1.0/24
!
hostname CE3
!
router bgp 65145
bgp router-id 151.1.1.65
neighbor 135.50.1.2 remote-as 13700
neighbor 135.50.1.2 description MPLS PE Router, Atm1/0/0
!
These configurations will allow the main site (AS 15000) to communicate with a remote site (AS 65145) via BGP while advertising only the internal networks and the loopback interface IP space. Based on your topology and desired features, there are countless different implementations. In the next tip, I'll expand on these configurations and add some advanced protocol features for your larger and more important sites.
About the author:
Doug Downer (CCIE #9848, JNCIS #881) is a senior consultant with Callisma Inc., a wholly owned subsidiary of AT&T. Doug has more than eight years of internetworking and consulting experience for both commercial and federal businesses. His current accounts include three of the top 50 Fortune 500 companies.
This tip originally appeared on SearchNetworking.com.
