Table of Contents
Advertisement
Providing IPv4 VPN Services Across Multiple Autonomous Systems
Inter-AS Option A
Figure 77: Inter-AS Topology with VRFs on Each AS Boundary Router
Copyright © 2010, Juniper Networks, Inc.
When PE 1 receives the packet on its core-facing interface, it pops all the labels, and
performs a lookup in the IPv6 table of VRF A (which is associated with L1) using the
destination address in the IPv6 header. After that, PE 1 forwards the IPv6 packet out to
CE 1 on the IPv6 link.
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 on page 401 illustrates the first method, where you create a VRF for each VPN
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.
Chapter 6: Configuring BGP-MPLS Applications
401
Advertisement
Table of Contents
Troubleshooting
