Tunneling LDP inside RSVP
Load mpls.te.ldp.tunneling.init.cfg
The basic IP addresses, L3VPN between XRv14 and XRv13, ISIS, RSVP, and MPLS-TE has been pre-configured.
There is currently a TE tunnel between CSR9 and CSR10 that goes via CSR2. This is bidirectional. CSR8 and XRv11 have been modified via ISIS metric to use CSR9 and CSR10 as the bestpath to CSR8/XRv11.
Make the necessary configuration changes so that XRv14 and XRv13 can ping each other in their L3VPN. Do not add any additional TE tunnels.
Answer
First we must enable LDP between CSR8↔CSR9 and CSR10↔XRv11:
You may think we have an end-to-end LSP between CSR8 and XRv11 at this point, however the L3VPN traffic is not working. Here’s what happens:
CSR8 pushes a label stack of { < CSR9’s label for XRv11> < VPN label> }
CSR9 pops the top label and pushes the TE label: { < TE label to CSR10 > < VPN label > }
CSR2 pops the top label and delivers to CSR10 with just { <VPN label> }
CSR10 drops the traffic
To solve this, we must run LDP within the TE tunnel, between CSR9 and CSR10. Then CSR9 will need to push two labels: the TE tunnel label and the LDP label for XRv11 learned from CSR10. Both functions are enabled simply by enabling LDP on the tunnel interface.
An LDP adjacency between CSR9 and CSR10 will come up. This is a targetted session. LDP is not actually running over the tunnel. Instead think of this as enabling LDP functionality on the tunnel. A targetted session is established, and the router will push the TE tunnel endpoint’s LDP label onto traffic forwarded down the tunnel.
Now the label stack outgoing from CSR9 looks like this: { <TE label> <CSR10’s LDP label for XRv11> <VPN label> }
Traffic between XRv13 and XRv14 is working:
The mpls ip command on a TE tunnel instructs the router to form a targetted LDP session with the tunnel destination, and to push the tunnel destination’s LDP label as a second label when forwarding traffic through the RSVP tunnel. (The top label is the RSVP label learned from the downstream RSVP peer as usual).
Conclusion
TE tunnels might be isolated to only the core between P routers. This could be done to provide FRR within the core, and help with scalability, because now you are not forming a full mesh of tunnels between all PE routers. However, you need to tunnel LDP within the TE tunnels so that the label is not prematurely popped, exposing the VPN label too early, which blackholes traffic.
Further Reading
Last updated
