Technical Documentation

Examining the PathErr Message


When path errors occur (usually because of parameter problems in a Path message), the router that notices the error sends a PathErr message hop by hop upstream towards the ingress router that issued the Path message. PathErr messages are advisory; these messages do not alter any path state along the way.

Figure 1 shows an RSVP PathErr message that flows upstream toward the destination address ( on ingress router (R1). From the perspective of the upstream flow, the destination address is the next-hop interface (so-0/0/2 on R1). This message notifies the sending node (R1) that an error occurred during label-switched path (LSP) signaling. This RSVP PathErr message originates at R3, and is destined for R1.

Figure 1: RSVP PathErr Message

Image g017065.gif

To trace the RSVP protocol messages exchange, enable traceoptions at the [edit protocols rsvp traceoptions] configuration hierarchy level and include the error flag to ensure that PathErr messages are traced.


To examine PathErr messages, enter the following JUNOS command-line interface (CLI) command:

user@R1> monitor start filename

Sample Output 1

[edit protocols rsvp]
user@R1# show 
traceoptions {
    file rsvp-log;
    flag packets detail;
    flag error detail;
interface so-0/0/2.0;
interface fxp0.0 {

Sample Output 2

user@R1> clear log rsvp-log

user@R1> monitor start rsvp-log  

*** rsvp-log ***
[...Output truncated...]
Jun 30 13:52:30  RSVP recv PathErr> Len=160 so-0/0/2.0
Jun 30 13:52:30   Session7 Len 16 ID 26679) Proto 0
Jun 30 13:52:30    Error    Len 12 code 24 value 7 flag 0 by  
Jun 30 13:52:30   Sender7  Len 12 ID  2)
Jun 30 13:52:30   Tspec    Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500
Jun 30 13:52:30   ADspec   Len 48 MTU 1500
Jun 30 13:52:30   RecRoute Len 28


Sample Output 1 shows the configuration of RSVP tracing on ingress router R1. The packets and error flags are included at the [edit protocols rsvp traceoptions] hierarchy level to provide slightly different information about RSVP traffic. For more information about RSVP tracing flags, see RSVP Tracing Flags. The detail option is included to show granular details about the configured flags.

Sample Output 2 shows clear commands, the output for the rsvp-log file, and that monitoring was started and then stopped.

The first line of the output from the rsvp-log file indicates that this is a PathErr message. The source address of the IP packet is (R3). The destination address of the IP packet is (R1). The incoming interface on R1 is so-0/0/2.0.

All subsequent lines of sample output indicate object values for this PathErr message and are indented in the output. To facilitate this discussion, each line of output for each object is displayed before the corresponding explanation.

  • Session7 Len 16 ID 26679) Proto 0

    The Session object indicates the session ID for the LSP that experienced the error condition (R1-to-R5). The session ID consists of the destination IP address ( of the LSP, a protocol value (Proto 0), and a 16-bit tunnel ID (26679).

  • Error Len 12 code 24 value 7 flag 0 by

    The Error object indicates the error (code 24 value 7) and the source IP address ( of the interface with the error. In this case, R3 has a routing problem (24) in which the record route object (RRO) indicates a routing loop (07). For more information on error codes, see RSVP Error Codes.

    PathErr messages report a wide variety of problems by means of different code and subcode numbers. You can find a complete list of these PathErr messages in RFC 2205, Resource Reservation Protocol (RSVP), Version 1, Functional Specification; and RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels.

  • Sender7 Len 12 ID 2)

    The Sender object indicates the sender of the message. The number 7 indicates the C-Type defined in RFC 3209. This object contains the source address of the LSP ( and the LSP ID (2). The LSP ID can change, depending upon the signaling path.

  • Tspec Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500

    The Tspec object indicates the allocated bandwidth and is the same information contained in the Tspec object in the Path message. This RSVP session uses the default of 0, no bandwidth is reserved. The Tspec object includes two different types of RSVP bandwidth allocations: controlled load and guaranteed delivery.

  • Controlled load specifies a maximum transmission rate and a maximum burst size. The peak value is always set to infinity (Inf), unless guaranteed delivery is specified. RFC 3209 recommends support only for null service and controlled load bandwidth services. Guaranteed delivery is not currently recommended, so there should never be a value for Inf in the Tspec object.
  • Guaranteed delivery specifies a peak transmission rate. The JUNOS software does not support guaranteed delivery. Instead you can specify a maximum transmission rate; for example, 45 Mbps. Because it is possible to burst at the maximum rate, the size parameter indicates a maximum burst size of 45 Mbps. The lowercase m (m20) and uppercase M (M 1500) indicate the minimum and maximum sizes for the RSVP maximum transmission unit (MTU) rate. RSVP treats any packet smaller than m20 as 20 bytes, and any packet larger than M1500 as 1500 bytes.
  • ADspec Len 48 MTU 1500

    The Adspec object carries a summary of available services, delay and bandwidth estimates, and operating parameters (MTU 1500) used by specific quality-of-service (QoS) control services.

  • RecRoute Len 28

    The record route object (RecRoute) indicates the list of addresses this Path message has transited, in this case, (R6), to (R3), to (R1).

Published: 2010-01-30