Path messages request labels and define the path
An RSVP-TE head-end signals a unidirectional LSP toward a tail-end. A Path message requests labels and can carry an Explicit Route Object (ERO) describing hops or segments to traverse. The path can be chosen to satisfy constraints such as available bandwidth or to avoid selected links.
Reservation messages (Resv) travel upstream, supplying the labels used along the path and establishing the requested reservation if admitted. The routers maintain signaling state with refreshes. A tunnel in the reverse direction requires a separate LSP in this model.
An engineered path can differ from the IGP route
LDP ordinarily uses the IGP’s selected next hops for prefix forwarding. RSVP-TE can install a path through a different set of routers when the topology and configured constraints permit it. Traffic uses that LSP when it is directed into the tunnel.
If a required path cannot be signaled or a requested reservation cannot be admitted, inspect the tunnel’s signaling error and operational state. The resulting forwarding behavior depends on other available paths and the device’s tunnel policy.
Try it in a lab
- On an RSVP-TE-capable lab, provide two paths between a head-end and tail-end. Record the default IGP route, then signal an explicit path through the other transit routers.
- Verify the tunnel is up and inspect the signaled hops and label operations. Direct test traffic into the tunnel and confirm it follows the chosen path.
- Make a required hop unavailable in the lab. Confirm that the original explicit path cannot be established and inspect the signaling error or configured alternate path.