Purpose
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 13 show an RSVP PathTear message that flows downstream from ingress router R1 (10.0.0.1) towards egress router R5 (10.0.0.5). 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 13: RSVP PathTear Message
To ensure that PathTear messages are displayed in the output, include the pathtear flag at the [edit protocols rsvp traceoptions] hierarchy level.
Action
To examine the PathTear message, enter the following JUNOS CLI command:
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 {
disable;
}
Sample Output 2
user@R1> clear log rsvp-log user@R1> monitor start rsvp-log user@R1> *** rsvp-log *** [...Output truncated...] Jun 30 10:05:25 RSVP send PathTear 10.0.0.1->10.0.0.5 Len=84 so-0/0/2.0 Jun 30 10:05:25 Session7 Len 16 10.0.0.5(port/tunnel ID 26619) Proto 0 Jun 30 10:05:25 Hop Len 12 10.1.13.1/0x08678198 Jun 30 10:05:25 Sender7 Len 12 10.0.0.1(port/lsp ID 10) Jun 30 10:05:25 Tspec Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500 monitor stop
Meaning
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 Table 18. 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 10.0.0.1 and destined for 10.0.0.5. 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.
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 (10.0.0.5), 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).
The Hop object indicates the IP address of the last interface (10.1.13.1) that this RSVP PathTear message visited.
The Sender object defines the source of the session 10.0.0.1 (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.
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.