Can an enterprise itself use MPLS VPN and still transit a commercial MPLS VPN service? Can a transit provider use MPLS VPN to connect ISP sites that might themselves use MPLS VPN? In other words, is it possible to have a hierarchy of VPN services? The answer is yes, and two solutions are presented here. Each uses MPLS in the core network. We have retained their original service provider context during discussion, but the solutions can beand have beenused in any large network that requires some form of hierarchical transport of labeled packets. Do all transport providers have to use MPLS if their customers decide to? Obviously not. It is possible to tunnel labeled packets across an IP core using the MPLS over GRE or MPLS over L2TPv3 encapsulation discussed previously in this chapter. In fact, tunneling is probably the easiest solution, and we recommend that enterprise network administrators use that approach unless valid reasons encourage the use of one of the following solutions. Some examples will be given in Chapter 7. Carrier Supporting CarrierCarrier supporting carrier (CsC) is a two-layer IP VPN solution designed to allow a backbone carrier to use MPLS VPN (or L2TPv3) to carry traffic belonging to customers' carriers that use MPLS VPNs. Before looking at the solution, it is a good idea to understand the problem being solved. An MPLS PE router holds all the routes of all the sites to which it connects. In a normal scenario, although this number can be large, the expectation is that an individual VPN would require at most hundreds or perhaps thousands of entries in a VRF. However, if the customer is itself an ISP, carrying routes belonging to their customers, the potential exists to require the backbone PE to carry an impossibly large number of routes. The CsC solution addresses this issue. CsC is based on the observation that the label switched domain of an MPLS VPN network (that is, the backbone network) only needs routing information to reach provider (P) routersthe customer routing domain is invisible to the core. In a CsC scenario, the ISP needs to share the global routing table with the backbone carrier only. The CsC backbone routers (labeled CSC-PE1, CSC-P, and CSC-PE2 in Figure 5-13) carry the next-hop routes for the ISP carrier networks so that an LSP exists between ISP sites. Note that the next-hop routes should not be aggregated because that would break the end-to-end LSP. Figure 5-13. CsC TopologyFigure 5-13 shows the CsC topology. The major differences between CsC and a standard MPLS VPN solution are as follows:
Figure 5-13 shows CsC data-plane operation, specifically the label stack of a packet as it traverses the ISP and backbone carrier networks:
Figure 5-13 also illustrates the control-plane operation:
The rest of the label-exchange operation is the same. CSC-CE2 and CSC-PE2 are eBGP or LDP routing peers. CSC-CE2 announces itself as the next-hop address for the 11.2.0.0/24 network to CSC-PE2, which will store them in the ISP VRF. CSC-PE2 announces the 11.2.0.0 prefixes (as VPNv4 addresses) to CSC-PE1 using iBGP. CSC-PE1 in turn announces the prefixes (and label) to CSC-CE1 for 11.2.0.0 using eBGP (or LDP). CSC-CE1 redistributes the 11.2.0.0/24 routing information into its IGP so that it can be learned by all the other P routers in the ISP1 network. After the protocols converge on the ISP network, an LSP is available from PE1 to PE2 for their iBGP session to carry 10.2.0.0 prefix information and in turn allow CE1 to send traffic to CE2. To summarize, the CSC-CE is a LSR on the ISP network and exchanges routes and labels with other LSRs in the ISP core. CSC-CE also exchanges routes and labels with CSC-PE, which is part of to the backbone provider. Because the CSC-CE only needs routing and label information to reach other ISP core routers, the CSC-PE only has to carry this information in its VRF tables. MPLS runs on the CSC-CE and CSC-PE link. The data-plane operation explanation above described how labels are pushed or popped on packets as they cross different parts of the ISP and backbone provider's network. Figure 5-14 shows the final label stack of the packet at is leaves CSC-PE1. Figure 5-14. CsC Label Stack
Inter-Autonomous System RoutingCsC is suitable for transport carriers but might be overkill for two providers who peer to allow reachability to each other's customers across their core networks. Inter-autonomous system routing for MPLS VPN is a solution that allows two autonomous systems to exchange routing information. There is a clear analogy with standard BGP exchanges between service providers. Figure 5-15 shows the inter-autonomous system solution topology. In each area, an Autonomous System Boundary Router (ASBR) router has an eBGP relationship with a peer in the other autonomous system and an iBGP session with the PE routers in its own area. The ASBR learns VPNv4 prefixes from iBGP and exports this information in eBGP. For the next hop to be visible within an autonomous system, the ASBR announces itself as the next hop. The ASBR also generates VPN route identifier labels for all the prefixes that it learns from iBGP peers. These labels are sent using eBGP to the next ASBR. There is no LDP session between ASBR devices. Figure 5-15. Inter-Autonomous System TopologyBecause the ASBR is also an iBGP peer (that is, a PE), it will take routes learned through eBGP and announce them to all the PEs in its autonomous system. While doing so, it announces itself as the next-hop routerin standard MPLS VPN fashionand creates new labels for the prefixes. PEs will install routes into VRFs by applying standard RT values matching. The forwarding plane in each autonomous system is identical to standard MPLS VPNs. ASBR2 appears as a PE within its autonomous system, so the IGP label is removed by the penultimate hop. ASBR2 looks up the label in its LFIB and finds a new label and next hop: ASBR1. It forwards the packet to ASBR1, which performs a similar LFIB lookup and this time finds the next hop to be PE1 with yet another VPN label. ASBR1 then does a second lookup to find the IGP label needed to reach PE1 and forwards the packet. Note that although there are new labels on each network segment, the VPNv4 addresses are global across both autonomous systems. The RD value appended at a PE in AS1 is accepted by another PE in AS2. Inter-Autonomous System Connectivity SummaryIn this section, we looked at two different solutions to connect MPLS VPNs. The first, CsC, involved a hierarchical topology with a Tier 2 service provider that uses MPLS to provide VPN service to its customers, connecting across a Tier 1 backbone provider that also uses MPLS VPN for its customers. Compared to a standard RFC 2547 network, the main differences in a CsC network is that the CsC-CE and CsC-PEs exchange labels and routes, and there are three labels on packets crossing the backbone network. The second solution, inter-autonomous systems, is simpler and involves two ASBR routers from different ISPs establishing a peering relationship using eBGP. VPNv4 addresses and VPN labels are exchanged from one inter-autonomous system PE to another and are used in the data plane to route packets between customer sites. There is another, simple alternative to connect MPLS clouds using tunnels. We looked at MPLS over GRE and MPLS over L2TPv3 in another context earlier in the chapter and so do not go into additional detail here. |