MPLS-VPNs, Internet Service Providers and IPv6
When you think about MPLS-VPN and the IPv4 or IPv6 Internet, there are two basic problems you want to solve, two important questions you need to answer.
1) How are you providing Internet Access to the MPLS-VPN customers?
2) What if your MPLS-VPN customers are Internet Service Providers who need your MPLS-VPN service to interconnect their remote sites (POP)?
Why do you have a case here? This is because MPLS-VPN, and later 6VPE which added IPv6 support in MPLS-VPN, were not designed to support the full Internet routing tables in the VPN Routing and Forwarding tables. The VRF were designed to connect private networks, not networks the size of the Internet. This is an obvious memory size and CPU resource requirements issue. How can you think a PE could manage multiple copies of the Internet Routing table (RIB) and their associated Forwarding bases (FIB)?
Let’s start with the first issue:
1) Providing Internet Access to your MPLS-VPN customers.
If a PE accommodates 20 VRF, which is a very reasonable amount, and these 20 VRF must have access to the full Internet Routing table, you cannot copy the Internet Routing Table 20 times, in each VRF. Instead, the Internet Routing Table must be stored in the PE Global Routing table. This way, all the VRF clients hosted on this PE can reach the Internet using the same routing table. Internet Access from the CE is then provided following two possible methods:
a) The most simple is for the CE to have two separate (sub-)interfaces to the PE. An interface in the VRF for VRF access. The other is connected to the Global Table space at the PE for Internet Access. Very simple as no specific feature is required. One interface is used for VRF connectivity, the other for Internet access. Sub-interfaces can be used.
b) If this is too expensive and only one interface must be used for both accesses, we must use a few static routes at the PE and the Internet Gateway. At the PE, one static route in the VRF with a next-hop in the Global Routing table to get out from the VRF to the Internet. A static route from the Global Routing table with the outgoing interface in the VRF to the CE to get back from the Internet into the VRF. At the Internet Gateway there must also be a static route for the return traffic coming back from the Internet to the VRF network.
2) The MPLS-VPN is used to interconnect Internet Service Providers customers.
The customers of the MPLS-VPN have Internet Gateways which receive the full Internet Routing tables and these tables must be announced to the customers remote sites.
In this case, the MPLS-VPN infrastructure must support Internet Service Providers customers and we must think about another design than the vanilla MPLS-VPN. What we need is a design where the ISP customers could exchange their full routing table directly among them just like VRF routes are exchanged between PEs throughout Ps in MPLS-VPN.
This is where hierarchical Carrier ‘s Carrier design comes in to play.
To achieve this result the CE, called CSC-CE which has received the the full Internet Routing Table from an Internet Gateway must be able to do the label imposition and disposition. To be able to do this the CSC-CEs must exchange labeled routes with the CSC-PEs using eBGP. Then the PE, called CSC-PE, can do the label switching without any knowledge of the Internet Routing Table exactly how P routers are doing label switching of MPLS-VPN VRF packets without any knowledge of the VRF routes in the vanilla MPLS-VPN design.
With CsC, the full Internet Routing Tables are not learned by the MPLS-VPN backbone (CSC-PE and P routers) but just exchanged thanks to a BGP session throughout the MPLS-VPN backbone. The VRF only carries the routes of the Internet Service Provider infrastructure but it doesn’t know the customer’s Internet Routing Table.
Because the pakets are received with a valid label, the CSC-PEs, and later the Ps don’t need to know the Internet Routing Table of the Customers to forward them.
All the features discussed in this post are supported by CISCO IOS for IPv4 and IPv6 running separately or concurrently in a dual-stack configuration.
Fred BOVY, CCIE #3013
Fast Lane’s Resident IPv6 Guru