Interprovider/Inter-AS MPLS

Interprovider/Inter-AS MPLS

In my last article I discussed the issues and roadblocks to interconnecting one provider's MPLS cloud to another's to provide a customer VPN endpoints on each cloud. The issues focused on management and SLA adherence rather than the technical aspects of interconnection. Unlike most service delivery issues, the problem here isn't the technology itself but the delivery of the service over the technology. The technology for interconnecting provider backbones to support VPN across multiple clouds is supported via Interprovider or Inter-autonomous System support.

Interprovider support allows VPNs to span multiple service provider backbones. The providers are able to do this by exchanging IPv4 address reachability information in the form of VPN-IPv4 addresses. The VPN-IPv4 routing information is exchanged via RBGP between the providers Autonomous System Border Routers (ASBR's). Once the VPN-IPv4 routes have been handed off to each autonomous system, the routing information is propagated via an interior gateway routing protocol such as OSPF or IS-IS. The EBGP border routers are used primarily to distribute the routes between the autonomous systems. In addition, the EBGP border routers handle the distribution of the label switching information associated with each route. The border router will rewrite the next hop and the MPLS label associated with each route that it receives

    Requires Free Membership to View

    SearchEnterpriseWAN.com members gain immediate and unlimited access to breaking industry news, best practices for designing and managing Wide Area Networks, WAN Security, and more -- all at no cost. Join me on SearchEnterpriseWAN.com today!

    Kate Gerwig, Editorial Director

    By submitting your registration information to SearchEnterpriseWAN.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchEnterpriseWAN.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

from the alternate autonomous system.

Let's assume we have two providers, P1 and P2 that have a customer with sites on each backbone CE1 and CE2 (C1). CE1 wants to advertise a route to CE2 and vice versa. The two providers are interconnected via ASBR1 and ASBR2 respectively.

CE1-PE1-ASBR1-ASBR2-PE2-CE2

NOTE, there may be any number of MPLS P routers between the PE routers and the ASBR routers.

Below is an example of how the routes and labels are advertised between the autonomous systems. For this example I will display CE1 on the P1 backbone to CE2 on the P2 backbone.

Provider 1 Route Advertisement
CE1-PE1 – Advertise 10.10.10.0 (normal advertisement via IGP), next hop CE interface

PE1-ASBR1 – Advertise 10.10.10.0 as VPN-IPV4 with label of 10, next hop PE1

ASBR1-ASBR2 – Advertise 10.10.10.0 as VPN-IPV4 with label of 20, next hop ASBR1

ASBR2 – PE2 - Advertise 10.10.10.0 as VPN-IPV4 with label of 30, next hop ASBR2

PE2 – CE2 - Advertise 10.10.10.0 to CE2 with next hop of PE2

So in this case CE2 will see the next hop to 10.10.10.0 as PE2
PE2 will see the next hop to 10.10.10.0 as ASBR2, this is regardless of how many P routers are between PE2 and ASBR2. PE2 uses label switching to forward traffic to ASBR2.
ASBR2 sees the next hop to 10.10.10.0 as ASBR1
ASBR1 sees the next hop to 10.10.10.0 as PE1
PE1 sees the next hop as CE1

In essence the ASBR routers act as gateways of last resorts for all of the routes requiring reachability within the other autonomous systems. Any traffic on the provider 1 backbone that is destined to provider 2 will be forwarded to the ASBR1 router as it has all of the provider 2 routes in its routing table and has performed label binding to ensure that the labeled packets are forwarded properly.

As can be seen from this example, it is not that hard to set up the network to exchange VPN routing information between autonomous systems. The difficult part is the actual enforcement and adherence to SLAs and QoS parameters that can be offered across the two backbones.


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.


This was first published in February 2005

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.