Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
Expert Advice: What are the points to be considered when implementing LDP tunnelling over RSVP?
When you set up LDP tunneling between equipment from different vendors, you need to:
If one area is NSSA, then the loopback (/32 prefix) is not redistributed from backbone to the NSSA area, which means you will have only the default route. You need to test whether the default route visibility (instead of /32) is sufficient to establish an inter-area RSVP TE tunnel and targeted LDP session.
Based on the original LDP specification (RFC 5036), for LDP to process FEC, that is, to generate a label, an exact match must be present in the routing table. If a loopback route in the backbone area is 172.16.0.1/32 and is in the NSSA area, only summary route 172.16.0.0/24 is visible, then the labels for 172.16.0.1/32 are not generated in the NSSA.
RFC 5283 removes that restriction, and is enough to have some summary (or default) route -- an exact match is not needed. RFC 5283 is currently not implemented in Junos, but it will be available in a future release. Until Junos OS supports RFC 5283, you need to use the inter-area RSVP tunnel up. Note that no Forward Equivalence Class (FEC) labels are exchanged unless you redistribute the /32 loopbacks between areas.
The inter-domain configuration statement allows you to establish an RSVP tunnel to a destination outside local area (destination not included in OSPF LSA Type 1, but in other LSA types).
For more information, see Tunneling LDP LSPs Inside RSVP-TE LSPs.