Routing

 View Only
last person joined: 18 hours 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.  Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?

    Posted 27 days ago

    Hi all,

    Let's say the current MPLS is signaling by using LDP and as we know the LDP is using IGP best path. We have other l2 traffic such as L2circuit, l2vpn and also EVPN. To steering the traffic then we must use RSVP-TE by create LSP path. But as i'm understand the RSVP route preference will prefer over LDP. I have read some blog was use PSN-Tunnel-End point to steering traffic using RSVP-TE with other traffic remain using LDP, So my question is any method that we can use to achieve the objective "This special treatment could be the need for the traffic to follow a certain explicit path through the network, or perhaps there are other traffic-engineering constraints that are required" instead using  PSN-Tunnel-End point method?

    Appreciate any feedback.



  • 2.  RE: Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?

    Posted 27 days ago
    Edited by Flashover_ 27 days ago

    For linking specific VPNs to MPLS LSPs you can use a few different solutions:

    Cross-connect

    The oldskool cross-connect (CCC):

    set protocols connections interface-switch [...]

    The CCC has a 1:1 mapping between LSP:VPN. Every VPN has its own LSP in the core. It creates extra state in the core on every hop.

    PSN-tunnel-endpoint

    The PSN-tunnel-endpoint method. I know that it works with L2Circuit.

    https://www.juniper.net/documentation/us/en/software/junos/vpn-l2/topics/concept/vpns-configuring-interfaces-for-layer-2-circuits.html#id-12291402__id-12217017

    The benefit over CCC is that many VPNs can use 1 LSP created with PSN-T-E. It saves state in the core. Samilar as for all the other types below.

    Install-nexthop

    There is a method with combining BGP communities and a PFE policy for "install-nexthop lsp $name":

    https://www.juniper.net/documentation/us/en/software/junos/vpn-l2/topics/concept/vpns-configuring-policies-for-layer-2-circuits.html

    But Google told me it doesn't work for EVPN-VPWS: https://supportportal.juniper.net/s/article/Install-nexthop-do-not-effect-on-EVPN-VPWS-instance?language=en_US

    Segment Routing

    The more modern methods are with Segment Routing:

    • inet(6)color
    • Transport-RIBs / Flexible-Algo (SR-TE preferred but RSVP is supported I believe)
    • controllers (can also be with RSVP)

    If somebody knows another one please add it!




  • 3.  RE: Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?

    Posted 27 days ago

    Hi @flashover,

    The method "Install-nexthop" just can use if we using BGP-VPLS and BGP-L2VPN right? Incase we just use LDP-VPLS and L2Circuit so we cannot use "Install-nexthop" right? 

    If we using "PSN-tunnel-endpoint" then we need to to create "dummy-prefix" so it will make the route still prefer LDP instead RSVP.  But in the url that u given, i'm not see how it will still prefer LDP instead RSVP-TE due the RSVP-TE route preference by default was 7. 

    Thanks and appreciate any feedback




  • 4.  RE: Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?

    Posted 17 days ago
    Edited by Flashover_ 17 days ago
    • The method "Install-nexthop" just can use if we using BGP-VPLS and BGP-L2VPN right? Incase we just use LDP-VPLS and L2Circuit so we cannot use "Install-nexthop" right? 

    I think recent JUNOS also support "community" statements at [protocols l2circuit] level, it was mentioned in a Techpost/Blogpost for SR-TE / Flex-Algo type scenarios.

    I did a "help apropos community | match vpls" in lab there are some hits there too. So likely yes, it can be done for the LDP based VPNs (L2Circuit+VPLS).

    • If we using "PSN-tunnel-endpoint" then we need to to create "dummy-prefix"

    Just noticed the documentation was missing a part. You'd have to create LSP with an extra "install" statement:

    set protocols mpls label-switched-path RouterXYZ to 1.2.3.4
    set protocols mpls label-switched-path RouterXYZ install 192.0.2.0

    Both address should have a route in inet.3 if I remember correctly from old memories.

    Then your L2circuit should refer to the extra dummy address, from the docs:

    [edit protocols l2circuit]
    neighbor 10.255.0.6 {
        interface t1-0/2/2.0 {
            psn-tunnel-endpoint 192.0.2.0;
            virtual-circuit-id 1;
        }
    }

    • <...continue...> so it will make the route still prefer LDP instead RSVP.  But in the url that u given, i'm not see how it will still prefer LDP instead RSVP-TE due the RSVP-TE route preference by default was 7. 

    Uh I'm afraid I don't fully know what you're asking here :)

    LDP cannot do traffic engineering, it will follow IGP (OSPF/ISIS) metrics. If you don't want the previous LSP (or it's "to" address) to be active in inet.3 (then it would apply for all traffic) then it can be deactivated:

    set protocols mpls label-switched-path RouterXYZ no-install-to-address

    There should still be a route in inet.3 for the dummy address "192.0.2.0" and the L2circuit could use it with PSN-T-E.

    Commands were created using notepad, not verified using CLI, but I have seen this work in the past.

    Cheers




  • 5.  RE: Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?

    Posted 14 days ago

    Hi @flashover,

    Thank for your explanation. Actually i'm follow this blog https://danhearty.wordpress.com/2020/12/11/junos-l2-circuit-dedicated-traffic-engineered-lsp/ . But i'm try to search alternative beside using the method as per this blog. In my case the LDP is our signalling. Our services include L2VPN, VPLS and L3VPN. So we need to do Traffic-Engineering without change the network design that currently using LDP. 

    By the way may i know is it ip "192.0.2.0" can be same for each "Label-switched-path" path incase i have multiple "Label-switched-path"? How about the reverse path? Is it the "dummy-prefix" can be same or not?

    Thanks and appreciate your feedback




  • 6.  RE: Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?

    Posted 25 days ago

    If you are looking to enforce a specific path in the network for the lsp that connects the two sites, then the strict path option would be the solution.  Using strict path you can select  a specific hop by hop path for the lsp through the network that would be required for that path to come up and be active.  You can see an example of this configuration here.

    https://www.juniper.net/documentation/en_US/junos9.6/information-products/topic-collections/nog-mpls-frr/primary-path-setting-up.html



    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)
    http://puluka.com/home
    ------------------------------



  • 7.  RE: Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?

    Posted 25 days ago

    Hi @spuluka,

    Yes, i'm understood "strict" path on LSP.  But my objective was want to make sure the other traffic still remain using LDP. Just specific service that will prefer RSVP-TE.

    Thanks