Inter-AS VPN

In an inter-AS VPN networking scenario, multiple sites of a VPN are connected to multiple ISPs in different ASs, or to multiple ASs of an ISP.

The following inter-AS VPN solutions are available:

• VRF-to-VRF connections between ASBRs—This solution is also called "inter-AS option A."

• EBGP redistribution of labeled VPN-IPv4 routes between ASBRs—ASBRs advertise VPN-IPv4 routes to each other through MP-EBGP. This solution is also called "inter-AS option B."

• Multi-hop EBGP redistribution of labeled VPN-IPv4 routes between PE routers—PEs advertise VPN-IPv4 routes to each other through MP-EBGP. This solution is also called "inter-AS option C."

In this solution, PEs of two ASs are directly connected through multiple subinterfaces, and each PE is also the ASBR of its AS. Each PE treats the other as a CE and advertises unlabeled IPv4 unicast routes through EBGP. The PEs associate a VPN instance with at least one subinterface.

As shown in Figure 38, VPN 1 routes are advertised from CE 1 to CE 3 by using the following process:

1. PE 1 advertises the VPN routes learned from CE 1 to ASBR 1 through MP-IBGP.

2. ASBR 1 adds the routes to the routing table of the VPN instance whose import target attribute matches the export target attribute of the routes, and advertises the routes as IPv4 unicast routes to its CE (ASBR 2) through EBGP.

3. ASBR 2 adds the IPv4 unicast routes to the routing table of the VPN instance bound to the receiving subinterface, and advertises the routes to PE 3 through MP-IBGP.

4. PE 3 advertises the received routes to CE 3.

Packets forwarded within an AS are VPN packets that carry two labels. Packets forwarded between ASBRs are common IP packets.

Inter-AS option A is easy to carry out because no special configuration is required on the PEs acting as the ASBRs.

However, it has limited scalability because the PEs acting as the ASBRs must manage all the VPN routes and create VPN instances on a per-VPN basis. This leads to excessive VPN-IPv4 routes on the PEs. Creating a separate subinterface for each VPN also requires additional system resources.

In this solution, two ASBRs use MP-EBGP to exchange VPN-IPv4 routes that they obtain from the PEs in their respective ASs.

As shown in Figure 39, VPN 1 routes are advertised from CE 1 to CE 3 by using the following process:

1. PE 1 advertises the VPN routes learned from CE 1 to ASBR 1 through MP-IBGP.

   Assume that the inner label assigned by PE 1 to the routes is L1.

2. ASBR 1 advertises the VPN-IPv4 routes to ASBR 2 through MP-IBGP.

   Before advertising the routes, ASBR 1 modifies the next hop as its own address, assigns a new inner label (L2) to the routes, and associates L1 with L2.

3. ASBR 2 advertises the VPN-IPv4 routes to PE 3 through MP-IBGP.

   Before advertising the routes, ASBR 2 modifies the next hop as its own address, assigns a new inner label (L3) to the routes, and associates L2 with L3.

4. PE 3 advertises the received routes to CE 3.

A packet is forwarded from CE 3 to CE 1 by using the following process:

1. PE 3 encapsulates the received packet with two labels, and forwards the encapsulated packet to ASBR 2.

   The two labels are the inner label for the VPN (L3) and the outer tag for the public tunnel from PE 3 to ASBR 2.

2. ASBR 2 removes the outer tag, replaces L3 with L2, and forwards the packet to ASBR 1.

   Packets between ASBR 1 and ASBR 2 carry only one inner label.

3. ASBR 1 replaces L2 with L1, adds the outer tag of the public tunnel from ASBR 1 to PE 1, and forwards the packet to PE 1.

4. PE 1 removes the outer tag and inner label from the packet, and then forwards the packet to CE 1.

In this solution, ASBRs must receive all inter-AS VPN routes. Therefore, ASBRs cannot filter incoming VPN-IPv4 routes by route targets.

Inter-AS option B has better scalability than option A. However, it requires that ASBRs maintain and advertise VPN routes.

The inter-AS option A and option B solutions require that the ASBRs maintain and advertise VPN-IPv4 routes. When every AS needs to exchange a great amount of VPN routes, the ASBRs might become bottlenecks, which hinders network extension. Inter-AS option C has better scalability because it makes PEs directly exchange VPN-IPv4 routes.

In inter-AS option C solution, PEs in different ASs exchange VPN-IPv4 routes over a multi-hop MP-EBGP session. Each PE must have a route to the peer PE and a label for the route, so the inter-AS public tunnel between the PEs can be set up. Inter-AS option C sets up a public tunnel by using the following methods:

• A label distribution protocol, for example, LDP.

• Labeled IPv4 unicast route advertisement by ASBRs.

  Labeled IPv4 unicast route advertisement refers to the process of assigning MPLS labels to IPv4 unicast routes and advertising the IPv4 unicast routes and their labels.

As shown in Figure 40, VPN 1 routes are advertised from CE 1 to CE 3 by using the following process:

1. PE 1 advertises the VPN routes learned from CE 1 as VPN-IPv4 routes to PE 3 through multi-hop MP-EBGP.

   Assume that the inner label assigned by PE 1 for the routes is Lx.

2. PE 3 advertises the received routes to CE 3.

Setting up an inter-AS public tunnel is the difficulty in this solution. A public tunnel, for example, the one from PE 3 to PE 1, is set up by using the following process:

1. Within AS 100, the public tunnel from ASBR 1 to PE 1 is set up by using a label distribution protocol, for example, LDP.

   Assume that the outgoing label for the public tunnel on ASBR 1 is L1.

2. ASBR 1 advertises labeled IPv4 unicast routes to ASBR 2 through EBGP to set up the public tunnel from ASBR 2 to ASBR 1.

   ASBR 1 assigns a label (L2) to the route destined for PE 1, and advertises the route and its label (L2) to ASBR 2. The next hop for the route is ASBR 1. The incoming label for the public tunnel on ASBR 1 is L2.

3. ASBR 2 advertises labeled IPv4 unicast routes to PE 3 through IBGP to set up the public tunnel from PE 3 directly to ASBR 2.

   ASBR 2 assigns a label (L3) to the route destined for PE 1, and advertises the route and its label (L3) to PE 3. The next hop for the route is ASBR 2. The incoming label for the public tunnel on ASBR 2 is L3, and the outgoing label is L2.

4. MPLS packets cannot be forwarded directly from PE 3 to ASBR 2. Therefore, another public tunnel from PE 3 to ASBR 2 is required to be set up hop by hop through a label distribution protocol, for example, LDP.

   Assume that the outgoing label for the public tunnel on PE 3 is Lv.

After route advertisement and public tunnel setup, a packet is forwarded from CE 3 to CE 1 by using the following process:

1. PE 3 performs the following routing table lookups for the packet:

   1. Finds a matching route with next hop PE 1 and inner label Lx, and encapsulates the packet with label Lx.

   2. Finds the route to PE 1 with next hop ASBR 2 and label L3, and encapsulates the packet with label L3 as the outer label.

   3. Finds the route to ASBR 2 with outgoing label Lv, and encapsulates the packet with label Lv as the outmost label.

2. AS 200 transmits the packet to ASBR 2 by the outmost label.

3. ASBR 2 removes the outmost label, replaces L3 with L2, and forwards the packet to ASBR 1.

4. ASBR 1 replaces L2 with L1, and forwards the packet.

5. AS 100 transmits the packet to PE 1 by the outer label.

6. PE 1 removes the outer label, and forwards the packet to CE 1 according to the inner label Lx.

As shown in Figure 41, to improve scalability, you can specify an RR in each AS to exchange VPN-IPv4 routes with PEs in the same AS. The RR in each AS maintains all VPN-IPv4 routes. The RRs in two ASs establish a multi-hop MP-EBGP session to advertise VPN-IPv4 routes.