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.
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:
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.
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.
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.
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.
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:
While the packet travels across the VPN from ingress router PE 1, labels are swapped as follows:
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.
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
- host1:vr1(config-router-af)#neighbor next-hop-unchanged
10.24.15.32
 | Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |