L3 VPNs - Multiprotocol BGP

A look at some of the issues involved with multiprotocol BGP and how to solve them.

The previous tip provided an overview of Layer 3 (L3) VPNs. This tip will review the technical aspects of how MPLS utilizes multiprotocol BGP to propagate VPN routing information between PE routers and allows for overlapping address space between customer VPN.

BGP allows routers to exchange IP reachability information. BGP is classified as an exterior gateway protocol (EGP) and first became a standard in 1989 (RFC 1105). The current BGPv4 standard (RFC 1771) was published in 1994. Within an MPLS network the PE routers form a mesh of peering relationships that allows the PE routers to exchange routing information contained in the virtual routing fields that represent customer VPNs. Each PE advertises the routes in its routing tables to all the other PE routers. Without any filtering or routing policies in place the PE routers would each contain routes to all customer networks connected to the service provider cloud. However, there are two issues with this scenario.

The first is that all PEs do not need all routes. The PEs only need the routes to other PEs that have customers attached. For instance if a provider's network has 20 PE routers and a customer is only connected to two of the PE routers, it is not necessary for the rest of the routers to have reachability information to those routes.

The second issue is that the customer networks are not required to have public address space. The customers can utilize their private RFC 1918 address space. This requires the MPLS cloud to be able to distinguish between overlapping address space. For instance a provider may have a PE router in San Francisco that has customer routes that utilize the 10.1.0.0/16 address space and another PE in Atlanta that has a customer with the exact same address space. If the PEs both advertised the exact route to the other PE peer routers, there would be duplicate address space in the BGP forwarding tables (remember the customer routes are maintained in a VRF, which is separate from the BGP routing table). In order to overcome these issues the PE routers utilize multiprotocol BGP to carry VPN-IPv4 routes.

A VPN-IPv4 route is a 96 bit, globally unique prefix that carries a route distinguisher. A route distinguisher is a 64 bit prefix that is appended to the 32 bit IPv4 address space that is advertised to the PE by the CE routers. A route distinguisher is configured for each VRF in the PE. The route distinguisher does not provide any information regarding the origin of the route or the VPNs to which the route is to be distributed. The route distinguisher allows the creation of distinct routes to overlapping address space. Using the example above, the PE router can append a unique route distinguisher to each of the 10.1.0.0/16 address spaces thereby creating unique IPv4 addresses for those customer routes. The PE routers then advertise the VPN-IPv4 routes to the other PEs within the network. This does not solve the first issue of all PEs not needing all routes. In order to overcome this issue, BGP installs additional route attributes to the BGP update to the other PE peers. The route attributes are called extended BGP community attributes and consist of a route target and a route origin. The route target identifies the set of routes that the PE needs to advertise to other PE's that have the same customer connection and the route origin identifies the originating site. The route origin is optional but the route target is advertised to every router that has a forwarding table associated with that particular customer VPN. If a router does not have a VRF associated with the target VPN, the route is not in the PEs per site forwarding table. This allows the PEs to only maintain routes to customers who have VPNs attached to that PE.

The creation of a unique VPN-IPv4 address space, route targets and route distinguishers are extensions of the BGP protocol. These attributes and the propagation of the unique address spaces define multi-protocol BGP. The next tip will discuss how you can utilize these attributes as well as the route origin to build full and partial mesh VPNs as well as hub and spoke VPNs.


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 May 2004

Dig deeper on VPN setup and configuration

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchNetworking

SearchUnifiedCommunications

SearchTelecom

SearchSDN

Close