Inter-Autonomous System Connectivity: Another Application of Tunnels


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 Carrier

Carrier 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 Topology


Figure 5-13 shows the CsC topology.

The major differences between CsC and a standard MPLS VPN solution are as follows:

  • CE-PE interface use MPLS.

  • CE-PE exchange routes and labels.

  • Packets on the CsC backbone have three labels on their label stack.

Figure 5-13 shows CsC data-plane operation, specifically the label stack of a packet as it traverses the ISP and backbone carrier networks:

  1. CE1 sends a packet with a destination address in the 10.2.0.0/24 network. The next hop for this address is PE1.

  2. PE1 pushes two labels: the VPN identifier, 20, and the next-hop label announced by P1, 31.

  3. P1 does a label swap and forwards the packet with outer label value of 33.

  4. CSC-CE1 does a label swap and forwards the packet with outer label 26. This label was announced by CSC-PE1.

  5. CSC-PE1 removes label 26 and pushes two labels onto the stack. Label 19 is the VPN identifier that identifies the ISP's VRF. Label 36 is the value announced by the CSC-P router, which is the next hop on the CSC backbone network.

  6. CSC-P performs a PHP operation and forwards the packet with outer label value 19.

  7. CSC-PE2 matches the incoming label value to the correct VRF and pushes label 48 before forwarding to CSC-CE2.

  8. CSC-CE2 does a PHP and forwards the packet with outer label value of 20.

  9. PE2 matches the incoming label value to the correct VRF and forwards an IP packet to the customer router, CE2.

Figure 5-13 also illustrates the control-plane operation:

  1. PE1 and PE2 exchange labels and VPNv4 routes using MP-BGP. The labels identify customer VRFs.

  2. PE1, P1, and CSC-CE1 exchange labels using LDP. These labels identify the next-hop FEC.

  3. CSC-CE1 and CSC-PE1 exchange labels and routes. There are two ways to do this. The first uses LDP; the second, specified in RFC 3107, uses external BGP (eBGP) to exchange IPv4 and labels.

  4. CSC-PE1 and CSC-PE2 exchange labels and VPNv4 routes using MP-BGP. These labels identify customer VRFs.

  5. CSC-PE1, CSC-P, and CSC-PE2 exchange labels using LDP.

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 Routing

CsC 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 Topology


Because 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 Summary

In 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.




Network Virtualization
Network Virtualization
ISBN: 1587052482
EAN: 2147483647
Year: 2006
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net