LDP Tunneling over RSVP Paths between LER/LSR for L2VPN/L3VPN.
Hello J-net community,
I was trying to figure out whether if it's possible or not to achieve a setup that consists of a bidriectional RSVP path between an LER and an LSR which tunnels a LDP session between them, that would be from its role to carry applications such L2VPN and L3VPN to other LERs.
This is a custom setup, so please bear with me, normally we're enabling LDP/RSVP on all core-facing interfaces, the main purpose for that setup is to carry L2VPN/L3VPN applications traffic from their edge [PE1] to other ends [PE2] using RSVP traffic engineering features, but only till a specific hop [P2] where it wouldn't be optimal for the rest of the path [till PE2] to be forwarded using RSVP, but rather we would prefer LDP instead, for many reasons such as load-balancing if different payload header information exists.
In other words, we want to create an end-to-end PE1 to PE2 LDP path, where two sections of the path takes place, one is tunneled through RSVP paths [bidirectional] from PE1 to P2, and the other is plain LDP from P2 till PE2. This RSVP path would be used to carry applications traffic that is destained to be end-to-end, althought this path ends at P2. I guess the LDP session that is carried over the RSVP path should exchange PE1/2 transport address labels for this approach to work.
Now, I know that this setup would work if we simply create two RSVP paths with the transport address in the "to" field for remote node direction and enable "ldp-tunneling" feature for this path, as I saw instantly all LDP learned routes in inet.3 table are forwarded through the RSVP path at PE-2, and on the other hand P2 is installing the PE-2 loopback through an LDP route over its RSVP path.
However, in order to selectively forward traffic over this RSVP path on PE-2 only when needed, I thought of creating RSVP paths with secondary loopback addresses for both nodes, so that the next-hop installed into inet.3 table would be a different address to the primary one which is used mainly for mpls forwarding based on plain LDP LSPs, and the result for this was that only a route to the remote node address was installed in each inet.3 table for both nodes, and this would make the setup obviously break, as PE-1 wouldn't be able to exchange labels with PE-2 through P2.
I see a manual workaround to this is to add on PE-2 the "install " command follows by the PE-1 primary transport to the label-switched-path stanza, and the same goes to P2, but with PE-1 address. However, that does defy with the main purpose of creating the tunnel from the first place, which is selectively forwarding PE-2 to PE-1 traffic over it.
Can anyone have any different ideas about how to bring this setup to an operational state taking in consideration its purpose?
Thanks in advance.
The HLD topology is as following: [All used nodes models are Juniper MX104, 480 and M10i]
Re: LDP Tunneling over RSVP Paths between LER/LSR for L2VPN/L3VPN.
[ Edited ]
Hi Mengzhe, First of all, thanks for your reply, second, on PE1, P1, P2, enable ldp-tunneling and define bi-directional rsvp tunnels PE1&P2
》》I'm sorry I didn't explain myself clearly enough. I already achieved this setup and it works well. However, that will replace the LDP LSPs for our primary mpls forwarding path, and subsequently will NOT selectively enable the use of the tunnel. I guess I've figured out a manual workaround for this setup. Which is to configure on each PE-1, P2, and PE-2 secondary inet addresses, where P2 and PE-2 secondary addresses would be the sources and destinations of the bidirectional RSVP paths.
This would obviously break the end-to-end LDP path through this tunnel, as on PE-2, PE-1 primary route in inet.3 would be still learned via plain LDP LSP, and not the tunneled LDP LSP (Not not be forwarded via RSVP path), and on the other hand, on P2, PE-2 route in inet.3 primary route would also still be learned via plain LDP. To fix this LSP, we have to add "install to " to each of the RSVP LSPs [PE-2 AND P2] with PE-1 secondary address and PE-2 secondary address respectively. This will also inquire to selectively use those new [secondary] next-hops for the L3VPN/L2VPN..etc applications that will use this tunnel.