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?
Original Message:
Sent: 01-28-2025 18:04
From: Flashover_
Subject: Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?
- 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.4set 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
Original Message:
Sent: 01-18-2025 12:17
From: kronicklez
Subject: Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?
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
Original Message:
Sent: 01-18-2025 08:36
From: Flashover_
Subject: Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?
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!
Original Message:
Sent: 01-18-2025 07:32
From: kronicklez
Subject: Other alternative to steering l2circuit or VPLS traffic beside use PSN-Tunnel Endpoint method?
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.