MPLS L3VPN Inter-AS Option C

    Designer: Mate, thanks for your help so far. Am still having some concerns regarding the ASBR role in this respective matter, ASBR is still holding VPN information even though no VRFs were configured on it, is this normal? And as per my humble understanding this is lowering my scalability, right?

     

    Consultant: You are right, VPN information do still exist on the ASBR as it was already configured with BGP VPNv4 session to help transporting the prefixes outside the AS toward the destination CE. If scalability is the network design pillar you are looking for, I can suggest you other option to consider but be ready to allow some leakage between the ASes.


    Designer: Leakage? My adrenaline just rose up! I will take the risk and try it out in order to maintain my fast convergence as it is tighten up to scalability.


    Consultant: Great, this new option is called MPLS L3VPN Inter-AS Option C.

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


    MPLS L3VPN Inter-AS Option C.png

     

    What this solution will add to you from resources utilization perspective is that no VRFs to be configured on the ASBRs nor eBGP VPNv4 session will be established.

    What will be configured on the ASBRs is a unicast IPv4 eBGP session between the ASBRs.

    All the VRFs will be as usual configured on the serving MPLS PEs.


    Designer: I have IPv4 eBGP between the ASBRs and VPNv4 session inside each of the ASes, which means I do not have end to end LSP established, right?


    Consultant: You are correct regarding this caveat that is why the session (IPv4 eBGP between the ASBRs) is called labeled unicast, i.e. we will be sending the labels between ASBRs over the established IPv4 session to add the missing LSP piece.


    MPLS L3VPN Inter-AS Option C 2.png

     

    Designer: OK, I got this point but still I cannot get how the CEs traffic will pass through, we need MP-BGP AF (VPNv4) to handle this traffic.


    Consultant: Here where the information leakage takes place, we need to establish eBGP VPNv4 session between the route reflectors which already have an established iBGP VPNv4 session with the serving MPLS PEs inside each AS.


    Designer: So the ASBRs in our case are serving two goals: labels propagation to maintain LSP and prefixes advertisement to achieve the proper communication between the RRs.


    Consultant: Yes that is correct.

     

    MPLS L3VPN Inter-AS Option C 3.png

     

    Designer: I have leaked the loopback subnets of each RR inside the opposite AS and established the BGP session but the session is still in the IDLE state!!


    Consultant: By default external BGP (eBGP) requires the talking routers to be directly connected to each other to bring the adjacency up, and that is because eBGP speakers use a TTL (Time To Live) value of 1, so in our particular case the TTL will be decremented to 0 and the packet will be discarded before reaching the other MPLS PE.

    Thus, you have to implement eBGP Multihop feature globally to bring the session up.

    MPLS L3VPN Inter-AS Option C 4.png

     

    Designer: great the session is up after deploying eBGP multihop.

    Now the routes are not getting to the serving PEs.

     

    Consultant: How many times I have told you to debug and check!

     

    R5-PE#

    *Feb 25 13:24:02.931: BGP(4): (base) 3.3.3.3 send UPDATE (format) 1:1:10.10.7.0/24, next 5.5.5.5, label 16, metric 0, path 10, extended community RT:1:1

    *Feb 25 13:24:03.703: BGP: nbr_topo global 3.3.3.3 VPNv4 Unicast:base (0x6965B148:1) rcvd Refresh Start-of-RIB

    *Feb 25 13:24:03.703: BGP: nbr_topo global 3.3.3.3 VPNv4 Unicast:base (0x6965B148:1) refresh_epoch is 2

    *Feb 25 13:24:03.715: BGP(4): 3.3.3.3 rcvd UPDATE w/ attr: nexthop 4.4.4.4, origin i, localpref 100, metric 0, merged path 2 10, AS_PATH , extended community RT:2:2

    *Feb 25 13:24:03.719: BGP(4): 3.3.3.3 rcvd 2:2:10.10.8.0/24, label 19 -- DENIED due to: extended community not supported;

    *Feb 25 13:24:03.719: BGP: nbr_topo global 3.3.3.3 VPNv4 Unicast:base (0x6965B148:1) rcvd Refresh End-of-RIB

     

    The route-target prevented the routes installation, modify the route-target values under the VRF (As we are using the ASN:NN notation for VRF definition).

     

    Designer: Sorry you are right, it has been installed now.

     

    *Feb 25 13:26:08.651: BGP: nbr_topo global 3.3.3.3 VPNv4 Unicast:base (0x6965B148:1) rcvd Refresh End-of-RIB

    *Feb 25 13:26:08.659: BGP(4): Revise route installing 1 of 1 routes for 10.10.8.0/24 -> 4.4.4.4(MSSK) to MSSK IP table

     

    And I have reachability in place and the CEs can communicate to each other.

    I was reading some related articles and was stopped by a feature called next-hop-unchanged, what will this feature do?

     

    Consultant: This feature is configured per neighbor (eBGP VPNv4 session) to maintain the next-hop of the route to keep as is.

    In other words, if you deployed this feature the next-hop for the routes will be original serving MPLS PE.

    What do you think will happen if you deployed this feature now?

     

    Designer: I guess I will lose connectivity because we leaked only the loopbacks of the RRs and the serving MPLS PEs loopbacks are not leaked which will break the communication due to unknown next-hop which respectively will prevent the routes from being installed inside the RIB.

     

    Consultant: You are absolutely right

    Now as you already deployed MPLS Inter-AS Option C, please fill in the table below to test your knowledge.

    MPLS L3VPN Inter-AS Option C Question.png

    I will post the answers I filled for your reference, please keep it hidden for now and take your time trying.

    And note that I have two versions of the answers based on the variation of using the next-hop-unchanged feature and not using it.

     

    Answer 1:

    MPLS L3VPN Inter-AS Option C Question Solutions 1.png

    Answer 2:

     

    MPLS L3VPN Inter-AS Option C Question Solutions 2.png