A public-library branch verifies describe-level behavior of LSPs for traffic to HQ and back. What implication follows from LSPs being unidirectional?
Select an answer to reveal the explanation.
Short Explanation
LSPs are one-way streets. Going to HQ is one labeled path; coming home is another. Do not assume the forward freeway magically carries the return trip.
Full Explanation
A public-library branch verifying LSP behavior to HQ and back must remember that LSPs are unidirectional. Traffic from the branch toward HQ follows one label-switched path; return traffic needs its own LSP (or forwarding path) in the reverse direction. There is no default assumption that the forward LSP is a bidirectional circuit that automatically carries library catalog replies home on the same labels.
A single LSP automatically carrying both directions with identical labels on every hop contradicts unidirectionality. Labels and bindings are installed per direction/FEC; reverse traffic uses reverse bindings.
Unidirectional LSPs only working for multicast civic video and never for unicast library catalog traffic is false. Unicast traffic routinely uses unidirectional LSPs in each direction.
The CE mirroring LDP sessions so every LSP becomes a GRE multipoint tunnel mixes CE attachment, LDP, and GRE multipoint models incorrectly. Unidirectionality does not require CEs to mirror LDP into GRE multipoint tunnels.
Exam caveat: some RSVP-TE deployments can signal bidirectional LSPs explicitly, but the default conceptual model—and what describe questions usually want—is unidirectional LSPs with independent return paths. Troubleshooting one direction up/other down is common.
Operational check: test flows both ways; use MPLS traceroute in each direction; compare show mpls forwarding-table for the HQ FEC versus the branch FEC on reverse path routers. Asymmetry in IGP metrics can yield different forward and return LSPs—expected, not broken by default.