[an error occurred while processing this directive][an error occurred while processing this directive]

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 1 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.

Figure 1: RSVP ResvErr Message

Image g017066.gif

Action

To examine the ResvErr message, enter the following JUNOS 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 {
    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

Meaning

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 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.

  • Session7 Len 16 10.0.0.5(port/tunnel ID 13527) Proto 0

    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).

  • Hop Len 12 10.0.13.1/0x08554198

    The Hop object indicates the last IP address (10.1.13.1) visited by this ResvErr message.

  • Error Len 12 code 4 value 0 flag 0 by 10.0.16.1

    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.

  • Style Len 8 FF

    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 JUNOS MPLS Applications Configuration Guide.

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

    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 for Inf in the Flow 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 MTU rate. RSVP treats any packet smaller than m20 as 20 bytes, and any packet larger than M1500 as 1500 bytes.
  • Filter7 Len 12 10.0.0.1(port/lsp ID 2)

    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.


Published: 2010-01-30

[an error occurred while processing this directive]