Examining the PathErr Message
Purpose
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. PathErr messages are advisory; these messages do not alter any path state along the way.
Figure 16 shows an RSVP PathErr message that flows upstream toward the destination address (10.1.13.1) 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 (even though R1 had the problem), and is destined for R1.
The RSVP PathErr message contains the session and sender information, the error code, and the requested bandwidth information. For more information on RSVP PathErr messages, see the JUNOS MPLS Applications Configuration Guide.
To ensure that PathErr messages are displayed in the output, include the error flag at the [edit protocols rsvp traceoptions] hierarchy level.
Action
To examine PathErr messages, enter the following JUNOS command-line interface (CLI) command:
user@R1>monitor startfilename
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 {
disable;
}
Sample Output 2
user@R1>clear log rsvp-log
user@R1>monitor start rsvp-log
user@R1>
*** rsvp-log ***
[...Output truncated...]
Jun 30 13:52:30 RSVP recv PathErr 10.1.13.2->10.1.13.1 Len=160 so-0/0/2.0
Jun 30 13:52:30 Session7 Len 16 10.0.0.5(port/tunnel ID 26679) Proto 0
Jun 30 13:52:30 Error Len 12 code 24 value 7 flag 0 by 10.1.36.1
Jun 30 13:52:30 Sender7 Len 12 10.0.0.1(port/lsp 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 10.1.36.2 10.1.36.1 10.1.13.1
What It Means
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 Table 17. 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 10.1.13.2 (R3). The destination address of the IP packet is 10.1.13.1 (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.
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 (10.0.0.5) of the LSP, a protocol value (Proto 0), and a 16-bit tunnel ID (26679).
The Error object indicates the error (code 24 value 7) and the source IP address (10.1.36.1) of the interface with the error. In this case, R3 has a routing problem (24) in which the record route object (RRO), in the output of the show mpls lsp extensive command, indicates a routing loop (07). For more information on error codes, see Table 21.
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.
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 (10.0.0.1) and the LSP ID (2). The LSP ID can change, depending upon the signaling path.
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 forInfin theTspecobject. - 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 uppercaseM(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.
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.
The record route object (RecRoute) indicates the list of addresses this Path message has transited, in this case, 10.1.36.1 (R6), to 10.1.36.1 (R3), to 10.1.13.1 (R1).