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

Examining the PathTear Message


PathTear messages remove (tear down) path states as well as dependent reservation states in any routers along a path. PathTear messages follow the same path as Path messages. A PathTear message typically is initiated by a sender application or a router when its path state times out.

PathTear messages are not required, but they enhance network performance because they release network resources quickly. If PathTear messages are lost or not generated, path states eventually time out when they are not refreshed, and the resources associated with the path are released.

Figure 1 show an RSVP PathTear message that flows downstream from ingress router R1 ( towards egress router R5 ( PathTear messages set the IP router-alert option so that intermediate routers check the contents of the PathTear message, ensuring that the network removes the allocation of resources along the path that the downstream Path message followed.

Figure 1: RSVP PathTear Message

Image g017062.gif

To ensure that PathTear messages are displayed in the output, include the pathtear flag at the [edit protocols rsvp traceoptions] hierarchy level.


To examine the PathTear 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 pathtear 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 10:05:25  RSVP send PathTear> Len=84 so-0/0/2.0
Jun 30 10:05:25   Session7 Len 16 ID 26619) Proto 0
Jun 30 10:05:25   Hop      Len 12 
Jun 30 10:05:25   Sender7  Len 12 ID  10)
Jun 30 10:05:25   Tspec    Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500
monitor stop 


Sample Output 1 shows the configuration of RSVP tracing on ingress router R1. The packets and pathtear 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 rsvp-log output indicates that this is a PathTear message originating from address and destined for The outgoing interface is so-0/0/2.0 on R1. When a Path message containing an route record object (RRO) is received by an intermediate router, the router stores a copy of it in the path state block. The PathTear message deletes state information for the specified RSVP session from the path state blocks for all routers with knowledge of this MPLS tunnel.

All subsequent lines of sample output indicate object values for this PathTear 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 26619) Proto 0

    The Session object (Session7) indicates that this is C-Type 7 for LSP tunnel IPv4, defined in RFC 3209. The RSVP session is defined by three values: the destination IP address (, a 16-bit field that indicates the tunnel ID (26619) and is unique for the length of the RSVP session, and the protocol number (Proto 0).

  • Hop Len 12

    The Hop object indicates the IP address of the last interface ( that this RSVP PathTear message visited.

  • Sender7 Len 12 ID 10)

    The Sender object defines the source of the session (R1). The number (7) after sender indicates that this is C-Type 7 for IPv4, defined in RFC 3209. The Sender is defined by the source IP address and the LSP ID. The LSP ID changes, depending on the signaling path.

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

    The traffic specification (Tspec) object indicates the allocated bandwidth. 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 MTU rate. RSVP treats any packet smaller than m20 as 20 bytes, and any packet larger than M1500 as 1500 bytes.

Published: 2010-01-30

[an error occurred while processing this directive]