Checking That RSVP Path Messages Are Sent and Received

Purpose

The presence or absence of various RSVP messages can help determine if there is a problem with Multiprotocol Label Switching (MPLS) in your network. For example, if path messages occur in the output without Resv messages, it might indicate that label-switched paths (LSPs) are not being created.

Action

To check that RSVP Path messages are sent and received, enter the following JUNOS command-line interface (CLI) operational mode command:

user@host>show rsvp statistics

Sample Output

user@R1> show rsvp statistics

  PacketType              Total                  Last 5 seconds

                   Sent      Received        Sent      Received

  Path            114523         80185           1             0

  PathErr              5            10           0             0

  PathTear            12             6           0             0

  Resv FF          80515        111476           0             0

  Resv WF              0             0           0             0

  Resv SE              0             0           0             0

  ResvErr              0             0           0             0

  ResvTear             0             5           0             0

  ResvConf             0             0           0             0

  Ack                  0             0           0             0

  SRefresh             0             0           0             0

  Hello           915851        915881           0             0

  EndtoEnd RSVP        0             0           0             0

  Errors                          Total            Last 5 seconds

  Rcv pkt bad length                0                         0

  Rcv pkt unknown type              0                         0

  Rcv pkt bad version               0                         0

  Rcv pkt auth fail                 0                         0

  Rcv pkt bad checksum              0                         0

  Rcv pkt bad format                0                         0

  Memory allocation fail            0                         0

  No path information               0                         0

  Resv style conflict               0                         0

  Port conflict                     0                         0

  Resv no interface                 0                         0

  PathErr to client                15                         0

  ResvErr to client                 0                         0

  Path timeout                      0                         0

  Resv timeout                      0                         0

  Message out-of-order              0                         0

  Unknown ack msg                   0                         0

  Recv nack                         0                         0

  Recv duplicated msg-id            0                         0

  No TE-link to recv Hop            0                         0

What It Means

The sample output shows RSVP messages sent and received. The total number of RSVP Path messages is 11,4532 sent and 80,185 received. Within the last 5 seconds, no messages have been sent or received.

A total of 5 PathErr messages were sent and 10 received. When path errors occur (usually because of parameter problems in a path message), the router sends a unicast PathErr message to the sender that issued the path message. In this case, R1 sent at least 10 path messages with an error, as indicated by the 10 PathErr messages that R1 has received. The downstream router sent R1 five path messages with an error, as indicated by the five PathErr messages that R1 has sent. PathErr messages transmit in the opposite direction to path messages.

A total of 12 PathTear messages were sent and 6 received, none in the last 5 seconds. In contrast to PathErr messages, PathTear messages travel in the same direction as path messages. Since path messages are both sent and received, PathTear messages are also sent and received. However, if only path messages are sent, then only the PathTear messages that are sent appear in the output.

A total of 80,515 reservation (Resv) messages with the fixed filter (FF) reservation style were sent and 111,476 received, none in the last 5 seconds. An FF reservation style indicates that within each session, each receiver establishes its own reservation with each upstream sender, and that all selected senders are listed. No messages for the wildcard filter (WF) or shared explicit (SE) reservation styles are sent or received. For more information on RSVP reservation styles, see the JUNOS MPLS Applications Configuration Guide.

Other RSVP message types are not sent or received. For information on the ResvErr, ResvTear, and Resvconf message types, see the JUNOS MPLS Applications Configuration Guide.

Ack and summary refresh (SRefresh) messages do not appear in the output. Ack and summary refresh messages are defined in RFC 2961 and are part of the RSVP extensions. Ack messages are used to reduce the amount of RSVP control traffic in the network.

A total of 915,851 hello messages were sent and 915,881 received, with none transmitted or received in the last 5 seconds. The RSVP hello interval is 9 seconds. If more than one hello message is sent or received in the last 5 seconds, it implies that more than one interface supports RSVP.

EndtoEnd RSVP messages are legacy RSVP messages that are not used for RSVP traffic engineering. These counters increment only when RSVP forwards legacy RSVP messages issued by a virtual private network (VPN) customer for transit across the backbone to the other site(s) in the VPN. They are called end-to-end messages because they are intended for the opposite side of the network and only have meaning at the two ends of the provider network.

The Errors section of the output shows statistics about RSVP packets with errors. A total of 15 PathErr to client packets were sent to the Routing Engine. The total combines the sent and received PathErr packets. For more information about error statistics and packets, see the JUNOS System Basics and Services Command Reference.