Inter-AS Option C is the third option for interconnecting multi-AS backbones covered in RFC 4364. It’s the most scalable option of the three so far and it has its own applicability scenarios that we must be aware of to apply this design properly.
This inter-as option has a lot of similarities with the Carrier’s Carrier architecture and concepts, like external and internal routes, the protocols used to exchange that routing information and how to set up the labeled switched paths from ingress to egress PEs. A previous quick view to the previous CsC discussion should help to understand easily this option and vice versa.
The strong point of this option is scalability. In this architecture, the ASBRs doesn’t carry any of the VPN routes. ASBRs only take care of distribution of labeled IPv4 routes of the PEs within their own AS.
To improve scalability, one MP-EBGP VPNv4 session transports all VPN routes (external routes) between PEs or RR. In the case of using RR to exchange the external routes, the next-hop of the VPNv4 routes must be preserved.
The ASBR use EBGP to exchange the internal PE routing information between AS (internal routes). These internal routes correspond to the BGP next-hops of the external routes advertised through the multi-hop MP-EBGP session between PEs or RRs. The internal routes advertised by the ASBRs can be used to establish the MP-EBGP sessions between PEs and allows for LSP setup from the ingress to the egress PE.
This solution has its strong points:
- The ASBRs do not store external routing information
- Resource conservation as the external information is not duplicated on the ASBRs. The RRs already store the routes.
- Planes isolation
- Multi-hop EBGP VPNv4 for VPN routes
- EBGP labeled IPv4 for internal routes
Option C is a very good solution from the scalability point of view and is the way to go for the same SP multi-AS networks. But it has its weak points as well:
- Advertising of PE addresses to another AS is not always a good decision
- QoS enforcement per VPN is not possible at ASBR
- VPN context doesn’t exist at ASBRs
- Not possible to perform policing, filtering or accounting with per VPN granularity at ASBR
Which make this solution not a very good option when Autonomous Systems don’t have a strong trust relationship between them.
Control and Data planes
For simplicity, we’ll use the same topology used for the two previous discussions. The figure shows two AS interconnected using Inter-AS Option C. In the example, a route is advertised by customer GREEN site CE5 (AS #65002 on the right) to site CE2 (AS #65001 on the left).
A more typical setup would include at least one BGP route reflector per AS, but that would overcomplicate the control plane data exchange shown in the figure. The same concepts of internal and external routing information exchange would apply to the RR scenario.
- Only one link or sub-interface is needed between ASBR1 and ASBR2.
- Direct connection between ASBRs.
In the control plane:
- ASBR devices exchange internal route reachability of the PE devices
- EBGP IPv4 session + label (recommended approach)
- IGP + LDP
- PE devices (or RR in case they exist) exchange external VPN routes plus associated labels with end-to-end significance
- Multi-hop MP-EBGP VPNv4 AF between PEs or RRs
- Next-hop must be preserved
In the data plane:
- VPN label remains the same along the path from the head-end to the tail-end
- Transport label is switched at every hop along the path
- Stack depth = 2 if the addresses of the PE routers are redistributed in both domains and the P devices know about them.
- Stack depth = 3 if the P devices don’t have internal routing information of the other domain.
Inter-AS Option C is an optimized version of Option B and has its own applicability scenarios to shine. As with the other options, there are advantages and disadvantages that will be mentioned as a summary here.
The main advantages of Inter-AS Option C are:
- Good scalability
- Simplified MPLS integration
- Improved plane isolation
- Resource conservation
There are some disadvantages that you may want to consider as well in advance to making a deployment:
- Invasive solution
- QoS control at ASBR is lost
Every design scenario is an opportunity to choose. Evaluate how likely each of the options is to meet your goals is one of the main steps of the choosing process and let you make an informed decision.
I hope you find it useful.