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).
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.
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 184.108.40.206 neighbor 220.127.116.11 remote-as 13700 neighbor 18.104.22.168 description MPLS PE Router, POS1/0 neighbor 22.214.171.124 prefix-list Backbone_Out out neighbor 126.96.36.199 route-map LP in neighbor 188.8.131.52 remote-as 15000 neighbor 184.108.40.206 update-source lo0 ! ip prefix-list Backbone_Out seq 20 permit 10.0.0.0/8 ip prefix-list Backbone_Out seq 25 permit 220.127.116.11/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 18.104.22.168 neighbor 22.214.171.124 remote-as 13700 neighbor 126.96.36.199 description MPLS PE Router, POS2/0 neighbor 188.8.131.52 prefix-list Backbone_Out out neighbor 184.108.40.206 remote-as 15000 neighbor 220.127.116.11 update-source lo0 ! ip prefix-list Backbone_Out seq 20 permit 10.0.0.0/8 ip prefix-list Backbone_Out seq 25 permit 18.104.22.168/24 ! hostname CE3 ! router bgp 65145 bgp router-id 22.214.171.124 neighbor 126.96.36.199 remote-as 13700 neighbor 188.8.131.52 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.
This was first published in September 2006