MPLS L3VPN Inter-AS Option D

    Designer: Hello, it has been a while since we got in touch.

    I am having some concerns regarding the last Inter-AS Option we deployed: Option C.

    The volume of leaked information in between the two autonomous systems is remarkable and not acceptable, I think this kind of solution is appropriate for acquisitions or mergers in which all become under the same administration umbrella.

    The issue is that I like Option A due to granular QoS support as each sub-interface (generally speaking as it could be a physical interface) is VRF dedicated , as well the security is considerably very good compared to other available options. At the same time, scalability is a pain as I am limited to a sub-interface for each customer to serve with increasing number of BGP sessions (in general) to maintain end to end connectivity.

    On the contrast, Option B offered enhanced scalability as one eBGP session is handling all labeled packets to be exchanged between the two autonomous systems but with lack of VRF isolation and more difficult QoS approach to follow.

    Any advice you can give me?!

    Consultant: Hey, am fine thanks for reaching out.

    Actually, you are lucky as Cisco already released a hybrid solution that combines the best aspects of each of the above mentioned Inter-AS Options: Option A and Option B.

    Designer: This is amazing, can you please clarify more to me in regards?

    Consultant: This new option is called MPLS L3VPN Inter-AS Option D (AKA Inter-AS Option AB).

    We will be using the below topology to illustrate this new option.

     

    MPLS L3VPN Inter-AS Option D.png

     

    What this solution will add is a segregation between the control plane and forwarding plane.

    Designer: Can you please spotlight what you are talking about?

    Consultant: We are going to establish an eBGP VPNv4 session between the ASBRs as well as defining a separate VRF sub-interface for each customer to be served.

    Designer: To be honest, I do not understand what benefit we gained from the mentioned above! We still have plenty of BGP sessions to establish to serve each customer (VRF)!

    Consultant: Calm down, we will not establish any session except for one session.

    The only BGP session to be established is an eBGP VPNv4 session between the ASBRs over the sub-interface placed in the global routing table, which is the same as Option B.

    For each customer (VRF), a dedicated sub-interface to be established between the two autonomous systems (forwarding plane) with no extra BGP sessions to be configured as all traffic will be sent over the unlabeled interfaces.

    So, what we gained actually is VRF isolation (which was lacked in Option B), granular QoS support (which was lacked in Option B) and scalable solution (which is the remarkable weak point of Option A).

    What is distinguishable for this eBGP session established between the ASBRs (Peers) is that it is the peers are called Option AB peers.

    As well, the VRFs configured on the ASBRs are called Option AB VRFs.

     

    MPLS L3VPN Inter-AS Option D 1.png

     

    Designer: Can you please clarify the involved BGP sessions as I got confused!

    Consultant: As I mentioned, similar to Option B we have eBGP VPNv4 session between the ASBRs which is handling the control plane operation (and again it is called Option AB BGP session) and we already have the sessions you know: iBGP VPNv4 sessions between each respective PE and it is corresponding ASBR within the same AS.


    MPLS L3VPN Inter-AS Option D 2.png

     

    Designer: Things are started to be clear for me now as I have did a trace from CE to CE to test connectivity and I saw the packets are traveling the unlabeled connection (which is the Inter-AS connection place inside the respective VRF).

    Consultant: Yes that is correct as the eBGP VPNv4 session is used only for control plane operation.

     

    Designer: So the traffic is sent over the Inter-AS VRF link as pure IPv4 (in our case) traffic?

    Consultant: Yes and the MPLS BGP Forwarding command which is automatically generated once you establish the eBGP VPNv4 session is not needed (you can remove it and test connectivity) as the traffic is sent as you mentioned above as pure IPv4 over the Inter-AS VRF enabled link, the other link is used only for eBGP VPNv4 session establishment used for control plane operation.

    Please have a look at the below diagram.

     

    MPLS L3VPN Inter-AS Option D 4.png

     

    Designer: Can you please highlight more regarding the forwarding operation?

    Consultant: Sure, please check the below steps for more clarification:

    • CE send IPv4 packet destined to the other CE to the serving PE.
    • The serving PE encapsulates the packet with VPN label (Inner label) assigned by the local ASBR.
    • The P router will assign the IGP label (outside label or transport label) to tunnel the packet to the local ASBR.
    • The local ASBR receives the packets and pop the VPN label and send the packet of concern unlabeled using the Inter-AS VRF interface.
    • The remote ASBR receives the packet (IPv4 packet) and encapsulates it with a VPN label assigned by the remote PE.
    • The remote P router assigns the needed transport label to tunnel the packet to the remote PE.
    • The remote PE receives the packet, pop the VPN label and sends unlabeled IPv4 packet to the receiving CE.

    As you go through the above lines (steps), please test your mind with the below table in order to properly check the roles based in the deployed Inter-AS model.


    MPLS L3VPN Inter-AS Option D 5.png

     

    And for your reference, please check the boxes table I prepared for you to recognize the control plane and forwarding plane protocols involved in respect to our topology:

     

    MPLS L3VPN Inter-AS Option D Question.png

     

    Consultant: I posted the solution for you below to check your answers.

     

    MPLS L3VPN Inter-AS Option D 5 Solutions.png