Routing

 View Only
last person joined: 4 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  LDP-Over-RSVP Coupling MPLS Service to Transport

    Posted 02-26-2024 08:42

    Hi there!  

    I have deployed LDP-Over-RSVP in LAB,  PE2 and PE4 can see each other FECs. I understand the need/benefits of this kind of setup. I have the following scenario (please check the diagram).

    PE4 has 2 eBGP sessions and receives 2 prefixes ( 10.1.110.0/24 and 81.1.1.0/24), the first one is in an L3VPN and the second is sent over inet.0 simulating internet over MPLS.  These routes are sent to PE2 via MP-BGP. By default, the NH of this routes will be 172.30.5.4. PE2 will know how to resolve NH due to LDP tunnelling (enabled on LSP P1-P5 for now).  So PE2 will send both internet and VPN traffic to PE1 and PE1 will tunnel them via LSP P1-P5. 

    But what if I want to take advantage of the RSVP T.E capabilities in my core, I want to use separate LSP for Internet and VPN traffic ( each with his constraints or FRR capability) maybe I want my VPN to have FRR capabilities but my internet traffic not.  

    I defined 2 IPs on PE4, for the VPN route I changed the next-hop on vrf-export policy to 172.30.6.4. I created an LDP-EGRESS policy on PE4 to have that FEC advertised. The FEC is advertised from P5 to P1 but P1 will choose as LDP NH the LSP P1-P5. So even if I try to couple the service to the transport I cannot.  In the end at PE2, I have the same label for VPN and internet traffic.   

    I figured out that if I create another P1-P5 LSP , let's say LSP P1-P5-VPN and enable LDP tunneling on it I cannot select the LDP NH to be a specific LSP because LDP is checking the IGP and it's seeing the LSP as a single next-hop, If there's a way to tell LDP to choose one LSP NH over another for different FEC received over the same LDP session I would like to know how :D 

    So I configured another LSP, to P6, LSP P1-P6-VPN,  I created LDP-EXPORT policies on P5 and P6, on P5 I filtered 172.30.6.4 FEC and on P6 I filtered 172.30.5.4 FEC. In this way P1 receives FEC 172.30.5.4 from P5 and FEC 172.30.6.4 from P6, P1 checks the IGP metric and installs LSP NH P1-P5 for FEC 172.30.5.4 and LSP NH P1-P6 -VPN for FEC 172.30.6.4. because the IGP metric is equal. As long as the IGP metric from P5 to PE4 and P6 to PE4 is the same I can acheive  T.E ,  P1 send different label to PE2 and traffic destined to internet is using LSP P1-P5 and VPN is using LSP P1-P6. 

    The question is, is there another way of achieving this? 



    ------------------------------
    Bandiu Alin-Filip-Gabriel
    ------------------------------


  • 2.  RE: LDP-Over-RSVP Coupling MPLS Service to Transport

    Posted 02-27-2024 05:43

    Hi,

    Not sure, if this could be helpful, but maybe you could define 2 RSVP LSPs, map VPN traffic to one LSP and global RIB traffic to another?

    You would need then below configuration - 

    [edit policy-options]
    policy-statement *name* {
        term *name* {
            from {
                *conditions*;
            }
            then accept;
            install-nexthop lsp *LSP name*;
        }
    }

    As condition, you could apply import policy to eBGP peerings to mark prefixes with a standard community and match it in a policy, then apply this policy under routing-options forwarding-table export <policy-name>



    ------------------------------
    FARID AKHUNDOV
    ------------------------------



  • 3.  RE: LDP-Over-RSVP Coupling MPLS Service to Transport

    Posted 02-27-2024 06:04

    Hi, 

    Thanks! That should work if I have RSVP at PEs and I have 2 LSPs to same egress PE and I will control which one I want to use based on policy, but in the LDP-Over-RSVP case at PEs I have LDP FECs,  I cannot use that policy. If I use that policy at the P1 router, for example, P1 does not have any BGP routing knowledge, is just an LSR. 

    This is on P1:

    172.30.6.4/32      *[LDP/9] 00:00:08, metric 1
                        >  to 10.1.13.3 via ge-0/0/0.0, label-switched-path P1-P5-High-volume-Internet
                           to 10.1.14.4 via ge-0/0/2.0, label-switched-path P1-P6-VPN
                           to 10.2.11.1 via ge-0/0/5.0, label-switched-path P1-P6-VPN
                           to 10.1.14.4 via ge-0/0/2.0, label-switched-path Bypass->10.1.13.3->10.1.35.5

    The install-next-hop lsp does not work in the LDP context. 

    I need something similar to the policy shared by you but in LDP context if that exists, or the only way is to have LDP policies playground :))) 



    ------------------------------
    Bandiu Alin-Filip-Gabriel
    ------------------------------



  • 4.  RE: LDP-Over-RSVP Coupling MPLS Service to Transport

    Posted 02-28-2024 04:33

    Indeed, P router will perform label switching only.

    Then the question is, why don't you establish LSPs between PEs?

    LDP is not flexible in terms of traffic engineering.

    RSVP would be the simplest and the most efficient method to solve the task, unless there are very specific limitations on PEs regarding RSVP usage.



    ------------------------------
    FARID AKHUNDOV
    ------------------------------



  • 5.  RE: LDP-Over-RSVP Coupling MPLS Service to Transport

    Posted 02-28-2024 05:04

    Yeah, but let's scale this to 100 PEs and a big core, it makes sense to bring LDP at the edge and have RSVP at the core, having a PoP design, in this design the goal is that I can do T.E in my core and just have a full mesh at the edge via LDP. However, in my example, you can see that mapping LDP tunnelled traffic to RSVP T.E paths requires ( as per my solution) LDP export policies and so on.   It's just for studying purposes though. I think that's the tradeoff of having LDP tunneling over RSVP, not able to choose what RSVP LSP your tunnelled traffic goes in a simple manner. 



    ------------------------------
    Bandiu Alin-Filip-Gabriel
    ------------------------------



  • 6.  RE: LDP-Over-RSVP Coupling MPLS Service to Transport

    Posted 03-02-2024 05:01

    Well,  unfortunately as you can see, LDP is not as flexible in terms of traffic engineering compared to RSVP.



    ------------------------------
    FARID AKHUNDOV
    ------------------------------



  • 7.  RE: LDP-Over-RSVP Coupling MPLS Service to Transport

    Posted 03-13-2024 04:15

    I found the way without using any redundancy, it was all in the IGP, the takeaway is that when LDP is resolving NH via RSVP LSP, it does not look at RSVP LSP metrics or anything else, simply LDP does what LDP knows and checks the IGP if at routers that perform the LDP tunnelling I do a leaked policy from L1 to L2 I can tweak the metric and achieve the mapping to the LSP. 



    ------------------------------
    Bandiu Alin-Filip-Gabriel
    ------------------------------