# Providing IPv4 VPN Services Across Multiple Autonomous Systems

Inter-AS services, sometimes known as interprovider services, support VPNs that cross AS boundaries. VPNs might need to cross AS boundaries because of a customer deployment that involves geographically separated ASs. The VPN sites can be provided by the same service provider or by different service providers as part of a joint VPN service offering. Inter-AS services are also useful to service providers that use confederations of sub-ASs to reduce the IBGP mesh inside the AS.

You can support these inter-AS services in three different ways, known as inter-AS option A, option B, and option C. Option C is preferred to option B; option B is preferred to option A. For inter-AS options B and C, you must explicitly configure MPLS on all the inter-AS links.

## Inter-AS Option A

Figure 77 illustrates the first method, where you create a VRF for each VPN on each AS boundary router.

Figure 77: Inter-AS Topology with VRFs on Each AS Boundary Router

Within each AS, routes are announced by internal MP-BGP and the data packets are forwarded across an MPLS tunnel. You create a logical connection such as an ATM VC between each pair of VRFs (on separate AS boundary routers); these logical connections can share the same physical connection. The following factors limit the scalability of this method:

- All inter-AS VPN routes (potentially a very large number) must be stored in the BGP RIBs and IP routing tables on the AS boundary routers.
- You must configure VRFs on each AS boundary router.

MPLS tunnels are unidirectional; Figure 77 shows only the tunnels established to carry traffic from ASBR 2 to PE 1 and from PE 4 to ASBR 3. Note that ASBR 2 and ASBR 3 are both also PE routers. In that sense, ASBR 2 treats ASBR 3 as a CE router, and ASBR 3 treats ASBR 2 as a CE router.

## Inter-AS Option B

The second method is known as inter-AS option B or 2547bis option B, after IETF RFC 4364—BGP/MPLS IP Virtual Private Networks (VPNs) (February 2006). This method uses BGP to signal VPN labels between the AS boundary routers (Figure 78). The base MPLS tunnels are local to each AS. Stacked tunnels run from end to end between PE routers on the different ASs. This method provides greater scalability, because only the BGP RIBs store all the inter-AS VPN routes.

Figure 78: Inter-AS Topology with End-to-End Stacked MPLS Tunnels

PE 1 assigns labels for routes to the customer sites, and distributes both the label assignments and the VPN-IPv4 routes throughout AS 42 in extended BGP update messages by means of internal MP-BGP. ASBR 2 then distributes the routes to ASBR 3 with external MP-BGP; ASBR 2 specifies itself as the next-hop address and assigns a new label to the route so that ASBR 3 can properly direct traffic. ASBR 3 propagates the routes by internal MP-BGP throughout AS 35, including to PE 4.

Example

You can use the show ip bgp vpn all field in-label and show ip bgp vpn all field out-label commands in the context of each VPN element to display the in label and out label associated with the route at that point. Suppose that CE 1 advertises a route to prefix 10.10.10.11/32 to its external BGP peer PE 1 (10.2.2.2) in VRF A. PE 1 associates the label 16 with this route; an extended update message sent to internal MP-BGP peer ASBR 2 carries this information as a labeled VPN-IPv4 prefix (label 16, RD 100:0, IPv4 prefix 10.10.10.11/32).

    host1:pe1#show ip bgp vpn all field in-label
    Prefix             In-label
    10.10.10.11/32     16

On PE 1, no out label is associated with the IPv4 prefix 10.10.10.11/32.

    host1:pe1#show ip bgp vpn all field out-label
    Prefix             Out-label
    10.10.10.11/32     none

ASBR 2 receives the labeled VPN-IPv4 prefix and generates a new label, 44, to associate with this VPN-IPv4 prefix instead of label 16 when it sends the prefix to ASBR 3.

    host1:asbr2#show ip bgp vpn all field out-label
    Prefix             Out-label
    10.10.10.11/32     16

    host1:asbr2#show ip bgp vpn all field in-label
    Prefix             In-label
    10.10.10.11/32     44

ASBR 2 receives MPLS frames with label 44 (the in label) from ASBR 3 and sends MPLS frames with label 16 (the out label) to PE 1.

The inter-AS next hop shows label 44 as the label advertised to inter-AS peer ASBR 3. Label 44 was generated for the indirect next hop PE router/label pair, 10.2.2.2 (PE 1) and 16. Indirect next hop 1.1.1.1 is for the MP-IBGP peering between PE 1 (loopback address 1.1.1.1) and ASBR 2. Indirect next hop 10.5.5.5 is ASBR 3.

    host1:asbr2#show ip bgp vpn all next-hops
    Indirect next-hop 1.1.1.1
      Resolution in IP route table of VR
           IP indirect next-hop index 10
           Reachable (metric 3)
           Number of direct next-hops is 1
                  Direct next-hop ATM6/1.20 (10.20.20.1)
      Resolution in IP tunnel-route table of VR
           MPLS indirect next-hop index 29
           Reachable (metric 3)
           Number of direct next-hops is 1
                  Direct next-hop: MPLS next-hop 23
      Reference count is 1

    Indirect next-hop 10.5.5.5
       Resolution in IP route table of VR
           IP indirect next-hop index 5
           Reachable (metric 0)
           Number of direct next-hops is 1
                  Direct next-hop ATM6/0.21 (10.5.5.5)
      Resolution in IP tunnel-route table of VR
           MPLS indirect next-hop index 14
           Reachable (metric 0)
           Number of direct next-hops is 1
                  Direct next-hop ATM6/0.21.mpls
      Reference count is 3

    host1:asbr2#show mpls next-hop 23
    MPLS next-hop: 23, label 33 on ATM6/1.20, nbr 10.20.20.1
      Sent:
        0 packets
        0 bytes
        0 errors
        0 discards

    host1:asbr2#show mpls next-hop 29
    MPLS next-hop: 29, resolved by MPLS next-hop 23, peer 1.1.1.1
      MPLS next-hop: 23, label 33 on ATM6/1.20, nbr 10.20.20.1
      Statistics collection is disabled

    host1:asbr2#show mpls forwarding brief
    ....
    44       bgp      swap to 16, push 34 on ATM6/1.20, nbr 10.20.20.1

    host1:asbr2#show mpls forwarding label 44
    In label: 44
      Label space: platform label space
      Owner: bgp
      Spoof check: router ASBR2
      Action:
        MPLS next-hop: 30, label 43, resolved by MPLS next-hop 29
          MPLS next-hop: 29, resolved by MPLS next-hop 23, peer 1.1.1.1
            MPLS next-hop: 23, label 34 on ATM6/1.20, nbr 10.20.20.1
      Statistics:
        0 in pkts
        0 in Octets
        0 in errors
        0 in discard pkts

ASBR 3 in turn generates a new label, 50, to advertise with the VPN-IPv4 prefix to its internal MP-BGP peer inside its autonomous system, AS 35. Indirect next hop 4.4.4.4 is for the MP-IBGP peering between PE 4 (loopback address 4.4.4.4) and ASBR 3. Indirect next hop 10.5.5.50 is ASBR 2.

    host1:asbr3#show ip bgp vpn all field out-label
    Prefix             Out-label
    10.10.10.11/32     44

    host1:asbr3#show ip bgp vpn all field in-label
    Prefix             In-label
    10.10.10.11/32     50

    host1:asbr3#show ip bgp vpn all next-hops
    Indirect next-hop 4.4.4.4
      Resolution in IP route table of VR
           IP indirect next-hop index 11
           Reachable (metric 3)
           Number of direct next-hops is 1
                  Direct next-hop ATM4/0.33 (33.33.33.2)
      Resolution in IP tunnel-route table of VR
           MPLS indirect next-hop index 28
           Reachable (metric 3)
           Number of direct next-hops is 1
                  Direct next-hop: MPLS next-hop 22
      Reference count is 1

    Indirect next-hop 10.5.5.50
      Resolution in IP route table of VR
           IP indirect next-hop index 4
           Reachable (metric 0)
           Number of direct next-hops is 1
                  Direct next-hop ATM6/1.21 (10.5.5.50)
      Resolution in IP tunnel-route table of VR
           MPLS indirect next-hop index 11
           Reachable (metric 0)
           Number of direct next-hops is 1
                  Direct next-hop ATM6/1.21.mpls
      Reference count is 3

    host1:asbr3#show mpls forwarding brief
    ...
    50       bgp      swap to 44,  on ATM6/1.21

In turn, ASBR 3 receives MPLS frames with label 50 (the in label) from PE 4 and sends MPLS frames with label 44 (the out label) to ASBR 2.

PE 4 receives the VPN-IPv4 prefix with label 50:

    host1:pe4#show ip bgp vpn all field out-label
    Prefix             Out-label
    10.10.10.11/32     50

On PE 4, no in label is associated with the IPv4 prefix 10.10.10.11/32.

    host1:pe4#show ip bgp vpn all field in-label
    Prefix             In-label
    10.10.10.11/32     none

The labels that are generated to be sent to the inter-AS BGP peers are generated for each next-hop PE router/received label tuple. Scaling is improved when all routes advertised from a given VRF have the same label; this is the default E Series router behavior. You can disable this behavior by issuing the ip mpls forwarding-mode label-switched command for the VRF.

## Inter-AS Option C

The third method of configuring inter-AS services and inter-AS VPNs is known as inter-AS option C or 2547bis option C. This method is described in RFC 4364—BGP/MPLS IP Virtual Private Networks (VPNs) (February 2006).

Inter-AS option C, similarly to the carrier-of-carriers configuration, requires a label-switched path from a packet's ingress PE router to its egress PE router. Option C introduces multihop EBGP redistribution of labeled VPN-IPv4 routes between source and destination autonomous systems. Labeled IPv4 routes are redistributed by EBGP between neighboring autonomous systems. Inter-AS option C uses BGP as the label distribution protocol.

In an inter-AS option C network, ASBRs do not maintain or distribute VPN-IPv4 routes. Each ASBR maintains labeled IPv4 /32 routes to the PE routers within its AS. The ASBR distributes these routes to other autonomous systems with EBGP. If transit autonomous systems are included in the topology, their ASBRs must also distribute the labeled /32 routes with EBGP. This configuration creates a label-switched path from the ingress PE router to the egress PE router. This configuration enables the PE routers in different autonomous systems to establish multihop EBGP connections to each other, and to exchange VPN-IPv4 routes over those connections.

Two different configuration scenarios are possible with option C, one employing a two-label stack and the other a three-label stack.

Figure 79 illustrates the three-label stack scenario. PHP is not used in this example.

Figure 79: Topology for Three-label Stack Configuration for Inter-AS Option C

In this topology, you can use either LDP or RSVP-TE to establish an LSP between each ASBR router and the PE router in an autonomous system. A labeled MP-IBGP session exists between the ASBR and the PE router in each autonomous system. A labeled MP-EBGP session exists between the two ASBR routers. The ASBR routers advertise the loopback IP addresses of their PE routers and associates the prefixes with labels.

When PE 1 learns the PE 2 loopback address and PE 2 learns the PE 1 loopback address, these PE routers can establish a multihop MP-EBGP session in order to exchange VPN-IPv4 routes. Because VPN-IPv4 routes are only exchanged between end PE routers, no other router on the path from PE 1 to PE 2 needs to keep or install VPN routes in its RIB or FIB.

1. P 2 learns label L2 for the route to the loopback address on PE 2 by means of LDP or RSVP-TE from PE 2.
2. ASBR 2 learns label L3 for the route to the loopback address on PE 2 by means of LDP or RSVP-TE from P 2.

   Each ASBR builds its own MPLS forwarding table with the received and advertised routes and labels. ASBR 2 uses its own IP address as the next hop.

3. ASBR 2 uses an MP-EBGP labeled unicast session to advertise label L4 for the route to the loopback address on PE 2 to neighboring ASBR 1.
4. ASBR 1 receives this route and the associated label L4.
5. ASBR 1 assigns label L6 to the route to the loopback address on PE 2 and changes the next-hop address to its own address.
6. ASBR 1 then uses an MP-IBGP session to advertise that address to PE 1. PE 1 therefore has an update with the label information and a next hop to ASBR 1.
7. P 1 learns label L7 for the route to the loopback address on ASBR 1 by means of LDP or RSVP-TE from ASBR 1.
8. PE 1 learns label L5 for the route to the loopback address on ASBR 1 by means of LDP or RSVP-TE from P 1.
9. PE 1 learns label L1 for the VPN-IPv4 route from the multihop EBGP session with PE 2.

Because the routes to the PE routers are unknown to all P routers other than the ASBRs, the ingress PE must push a three-label stack on packets received from the VPN end users. This is illustrated in Figure 79 as follows:

1. The first (innermost or bottom) label, L1, is assigned by the egress PE router, PE 2. This label is obtained from the multihop MP-EBGP session. It corresponds to the packet's destination address in a particular VRF at the remote PE router.
2. The middle label, L6, is assigned by ASBR 1. This label is obtained from the MP-IBGP labeled unicast session from the ASBR. It corresponds to the /32 route to the egress PE router, PE 2.
3. The top (outermost) label, L5, is assigned by the ingress PE router’s IGP next hop. P 1. This label is obtained from an LDP or RSVP-TE session with the next hop. It corresponds to the /32 route to ASBR 1.

While the packet travels across the VPN from ingress router PE 1, labels are swapped as follows:

1. P 1 swaps outermost label L5 for L7 to get to its next hop, ASBR 1.
2. ASBR 1 pops outermost label L7 and swaps the middle label L6 for L4 to get to ASBR 2.
3. ASBR 2 swaps outer label L4 for L3 to get to its next hop, P 2.
4. P 2 swaps outer label L3 for L2 to get to its next hop, PE 2.
5. PE 2 pops outer label L2 and inner label L1 and then processes the IP data packet.

In contrast to the three-label stack scenario described previously, in a two-label stack scenario, BGP labeled unicast is not used inside the autonomous system. Instead, only LDP is used as the label distribution protocol. A PE router in one AS has a direct LSP to a PE in another AS, achieved by using LDP labels within the AS and BGP labels across the AS boundary.

For a two-label stack scenario to work, you must issue the mpls ldp redistribute bgp command on the ASBRs. This command enables the BGP prefixes to be advertised by LDP inside the autonomous systems. For more information on this command, see Configuring MPLS.

## Inter-AS Option C with Route Reflectors

When the BGP/MPLS VPN peer is a route reflector (Figure 80), issue the neighbor next-hop-unchanged command to prevent the RR from rewriting the BGP next-hop attribute when the RR advertises routes to external neighbors. Issuing this command causes the VPN RR that is multihop peering with another RR in the AS to send the next hop unchanged for the VPN routes that it advertises.

Figure 80: Topology for Inter-AS Option C with Route Reflectors

neighbor next-hop-unchanged

- Use to prevent BGP from modifying the next hop sent to the BGP peer.
- Outbound route maps take precedence over this command, enabling prefixes that match the route map to be modified, regardless of this command.
- Takes effect immediately.
- Example
  host1:vr1(config-router-af)#neighbor next-hop-unchanged 10.24.15.32
- Issuing this command automatically removes the neighbor next-hop-self configuration (enabled or disabled) on the peer or peer group. Issuing the no or default version of this command has no effect on the neighbor next-hop-self configuration.
- Use the no version to reenable BGP to modify the next hop.
- See neighbor next-hop-unchanged.