Examining the ResvErr Message
Purpose
When a reservation request fails, a ResvErr error message is delivered to all the receivers involved. ResvErr messages are advisory; these messages do not alter any reservation state along the way.
Figure 17 shows an RSVP ResvErr message that flows downstream to the destination address of the LSP 10.0.0.5 (R5), indicating that an error with the reservation allocation occurred while sending Resv messages back to the ingress node. The destination address of the ResvErr message is the interface from R1 to R3 (so-0/0/2.0), which the Resv message just left.
To ensure that ResvErr messages are displayed in the output, include the error flag at the [edit protocols rsvp traceoptions] hierarchy level.
Action
To examine the ResvErr message, enter the following JUNOS 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...]
Jan 15 15:44:57 RSVP send ResvErr 10.1.13.1->10.0.13.2 Len=104 so-0/0/2.0
Jan 15 15:44:57 Session7 Len 16 10.0.0.5(port/tunnel ID 13527) Proto 0
Jan 15 15:44:57 Hop Len 12 10.0.13.1/0x08554198
Jan 15 15:44:57 Error Len 12 code 4 value 0 flag 0 by 10.0.16.1
Jan 15 15:44:57 Style Len 8 FF
Jan 15 15:44:57 Flow Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500
Jan 15 15:44:57 Filter7 Len 12 10.0.0.1(port/lsp ID 2)
monitor stop
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 sample output from the rsvp-log file indicates that this is a ResvErr message. The source address of the IP packet is 10.1.13.1 (R1) and the destination address is 10.1.13.2 (R3). The outgoing interface on R1 is interface so-0/0/2.0. The ResvErr message is in response to a Resv message indicating an error with the reserved LSP allocation.
All subsequent lines of sample output indicate object values for this ResvErr 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 (R1-to-R5) that experienced the error condition (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 (13527).
The Hop object indicates the last IP address (10.1.13.1) visited by this ResvErr message.
The Error object indicates the error code for the message. In this case, error code 4 value 0 flag 0 is defined by RFC 2205, Resource ReSerVation Protocol (RSVP), Version 1, Functional Specification. The definition specifies that there is no sender information for this Resv message. Although there is path state for this session, it does not include the sender matching some flow descriptor contained in the Resv message. Therefore, the Resv message cannot be forwarded.
The Style object indicates the reservation style. The reservation style for this ResvErr message is fixed filter (FF), indicating that the bandwidth allocation in an Resv message cannot be shared with any other session, or sender/filter combination. Each different physical path is identified by an LSP ID, listed in the Filter object. A reservation message that indicates a fixed filter style consists of distinct reservations among explicit senders. For this session, the router cannot share the bandwidth with any other RSVP LSP signaling messages that share the same session ID and have different LSP IDs.
Other available reservation styles are shared explicit (SE) and wildcard filter (WF). For more information on reservation styles, see the MPLS Applications Configuration Guide.
The Flow object indicates the allocated bandwidth and is the same information contained in the Tspec object in the Path message. In the upstream direction (the direction in which the Resv message flowed), the flow object indicates the bandwidth requested and the minimum and maximum packet sizes. In this case, this RSVP session uses the default of 0, no bandwidth is reserved. The flow 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 theFlowobject. - 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 MTU rate. RSVP treats any packet smaller than m20 as 20 bytes, and any packet larger than M1500 as 1500 bytes.
The Filter object defines the source (ingress) of the session 10.0.0.1 (R1). The number 7 after Filter indicates that this is C-Type 7 for IPv4, defined in RFC 3209. It contains the source address of the LSP and the LSP ID. The LSP ID changes, depending on the signaling path. The Filter object contains the same information as the Sender object of the Path message.