Case Study for an RSVP Failure

Purpose

This case study presents a Multiprotocol Label Switching (MPLS) network topology and RSVP failure scenario designed to demonstrate techniques and commands that are particularly useful when addressing RSVP problems in your network. The focus of the study is an unconstrained RSVP label-switched path (LSP) from R1 to R5, which uses a strict path through R3. In this case, the RSVP failure occurs when interface so-0/0/0 on R5 is configured incorrectly. (See Figure 18.)

Figure 18: RSVP Failure in an MPLS Network Topology

The MPLS network in Figure 18 is a router-only network with SONET interfaces that consists of the following components:

• A full-mesh interior Border Gateway Protocol (IBGP) topology, using AS 65432.
• MPLS and RSVP enabled on all routers.
• A send-statics policy on routers R1 and R6, that allows a new route to be advertised into the network.
• Two unidirectional LSPs between routers R1 (ingress) and R5 (egress), which allow bidirectional traffic.
• The no-cspf statement included at the [edit protocols mpls label-switched-path path-name] hierarchy level, indicating that the Constrained Shortest Path First (CSPF) algorithm is not used to compute the LSP path.
• A strict path configured for both unidirectional LSPs, R1-to-R5 and R5-to-R1, at the [edit protocols mpls] hierarchy level.

Although there are a number of ways to examine an RSVP failure in an MPLS network, the following sequence of steps and commands is useful in determining the origin of an RSVP failure.

Steps To Take

To examine the RSVP failure, follow these steps:

1. Verify the RSVP Session
2. Ping the Egress Router
3. Enable RSVP Tracing on Transit Routers
4. View the RSVP Log File on Transit Routers
5. Check the RSVP Log File on the Egress Router
6. Determine and Correct the Problem on the Egress Router
7. Remove the Tracing Configuration