Step 1: Verify the RSVP Session

Purpose

In this case study, the unconstrained RSVP LSP from router R1 to R5 uses a strict path through R3, r1-r3-r5.

Action

To verify that the RSVP session is established, enter the following JUNOS command-line interface (CLI) operational mode command:

user@host> show rsvp session ingress detail

Sample Output

user@R1> show rsvp session ingress detail

Ingress RSVP: 1 sessions

10.0.0.5

  From: 10.0.0.1, LSPstate: Dn, ActiveRoute: 0

  LSPname: R1-to-R5, LSPpath: Primary

  Suggested label received: -, Suggested label sent: -

  Recovery label received: -, Recovery label sent: -

  Resv style: 0 -, Label in: -, Label out: -

  Time left:    -, Since: Tue Jul 19 20:42:20 2005

  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500

  Port number: sender 16 receiver 11956 protocol 0

  PATH rcvfrom: localclient 

  Adspec: sent MTU 1500

  Path MTU: received 0

  PATH sentto: 10.1.13.2 (so-0/0/2.0) 3 pkts

  Explct route: 10.1.13.2 

  Record route: <self> ...incomplete

Total 1 displayed, Up 0, Down 1

What It Means

The sample output from ingress router R1 shows that the RSVP session has not been established (Down 1) through the explicit path (10.1.13.2). The Path message was sent to R3 (10.1.13.2) and dropped. In situations like this, you can ping the egress router (R5) to ensure operational communications in the network, and enable RSVP tracing on the router that dropped the packet (R3) to obtain valuable clues as to the nature of the problem.