Inter-AS Technology
The MPLS VPN solution is widely used, serving an increasing number of users in a large number of applications. As more sites are developed in an enterprise, sites in different geographical locations often connect to different ISP networks. Consider, for example, the inter-AS issue facing operators who manage different metropolitan area networks (MANs) or backbone networks that span different autonomous systems (AS).
Generally, an MPLS VPN architecture runs within an AS in which VPN routing information is flooded on demand. The VPN routing information within the AS cannot be flooded to the AS of other service providers (SPs). To implement exchange of VPN routing information between different ASs, the inter-AS MPLS VPN model is introduced. The inter-AS MPLS VPN model is an extension of the existing protocol and MPLS VPN framework. This model allows route prefixes and labels to be advertised over the links between different carrier networks.
PWE3 supports inter-AS Option A.
Inter-AS Option A
With Option A, ASBRs of two ASs are directly connected and function as PEs in their respective ASs. The two ASBRs regard each other as a CE.
In Figure 1, ASBR1 in AS 100 regards ASBR2 in AS 200 as a CE. Similarly, ASBR2 regards ASBR1 a CE.
Option A has the following advantages:
Inter-AS Option A is easy to implement. The two PEs used as ASBRs perform IP forwarding but not MPLS forwarding. In addition, the two PEs do not require special configurations.
Option A has low scalability.
- The PE needs to manage all L2VPN information, which occupies many resources.
- As the ASBR works as the PE in an AS, each PW requires an AC interface, which can be a sub-interface, physical interface, or bundled logical interface.
- If a VPN spans multiple ASs, intermediate ASs must support VPN services. As a result, the configuration workload is heavy and the intermediate ASs are affected.
Therefore, inter-AS Option A is applicable only when there are a small number of inter-AS L2VPNs.