Examining the Hello Message
Purpose
RSVP monitors the status of the interior gateway protocol (IGP) (Intermediate System-to-Intermediate System [ISIS] or Open Shortest Path First [OSPF]) neighbors and relies on the IGP protocols to detect when a node fails. If an IGP protocol declares a neighbor down (because Hello messages are no longer being received), RSVP also brings down that neighbor. However, the IGP protocols and RSVP still act independently when bringing a neighbor up.
RSVP Hello messages are exchanged between neighbors. The destination address is the neighbor node. RSVP Hello messages are used to determine loss of interface more quickly than determined by the RSVP state timeout.
 |
NOTE: RSVP Hello messages are required to establish the protocol or to maintain adjacency information. RSVP Hello messages do not establish state. |
Figure 15 shows two RSVP Hello messages exchanged between routers R1 and R3.
To ensure that Hello messages are displayed in the output, include the packets flag at the [edit protocols rsvp traceoptions] hierarchy level.
Action
To examine the Hello 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;
}
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 29 15:48:59 RSVP send Hello New 10.1.13.1->10.1.13.2 Len=32 so-0/0/2.0
Jun 29 15:48:59 HelloReq Len 12
Jun 29 15:48:59 RestartCap Len 12 restart time 0, recovery time 0
Jun 29 15:48:59 RSVP recv Hello New 10.1.13.2->10.1.13.1 Len=32 so-0/0/2.0
Jun 29 15:48:59 HelloRply Len 12
Jun 29 15:48:59 RestartCap Len 12 restart time 0, recovery time 0
monitor stop
What It Means
Sample Output 1 shows the configuration of RSVP tracing on ingress router R1. The packets flag is included at the [edit protocols rsvp traceoptions] hierarchy level to provide 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 flag.
Sample Output 2 shows clear commands, the output for the rsvp-log file, and that monitoring was started and then stopped. The rsvp-log output shows two RSVP Hello messages exchanged between R1 and R3.
The first Hello message in the rsvp-log output is a request sent from R1 (10.1.13.1) to R3 (10.1.13.2). The outgoing interface is so-0/0/2.0 on R1. The second Hello message was a reply sent from R3 to R1, also through the outgoing interface so-0/0/2.0 on R3.
The next two lines of output indicate object values for the two Hello messages, and are indented in the output. To facilitate this discussion, each line of output for each object is displayed before the corresponding explanation.
The Hello request (HelloReq) object indicates that this is a Hello request. RFC 3209 defines the RSVP Hello message. An RSVP Hello message can either be a request or a reply. Every request should generate a reply.
The restart object (RestartCap) indicates the graceful restart capability of the sender node. The restart time of 0 milliseconds is the length of time that this node takes to restart its RSVP traffic engineering functionality. At the end of this time, the node can send and receive RSVP messages again. The recovery time of 0 milliseconds indicates the length of time the LSR retains MPLS forwarding information. A recovery time of 0 in this case indicates that no forwarding state was preserved across a restart. Because both values are set to 0, graceful restart was not enabled for this RSVP session.
The Hello reply (HelloRply) object indicates that this is an RSVP Hello message sent from R3 to R1 out of interface so-0/0/2.0.
In standard RSVP, node failure detection occurs as a consequence of the RSVP soft-state timeout model. However, detection typically requires several minutes to time out the soft state. Hello packets allow the detection of the neighboring node state changes more quickly.
In JUNOS software, RSVP Hello messages are optional and are backward-compatible with RSVP implementations that do not support Hello messages. For neighboring routers that do not support Hello messages or on which RSVP Hello is disabled, RSVP uses the soft-state timeout for loss detection and cannot benefit from fast IGP Hello detection.
Configuring a short time for the IS-IS or OSPF Hello timers allows these protocols to detect node failures more quickly. RSVP also benefits from early detection by the IGP protocols. It is not necessary to explicitly configure a short RSVP Hello timer. If you do configure the RSVP Hello timer, you can configure a longer value and can still expect the failure of a neighboring router to be quickly detected by IGP.
Between Hello-capable neighbors, Hello messages are sent unicast toward each other. A loss of (2 x keep-multiplier + 1) consecutive Hello messages causes the neighbor's state to go down, and all RSVP sessions to and from that neighbor are declared to be down.
By default, RSVP sends Hello messages every 9 seconds. For information on how to configure the RSVP Hello message timer, see the JUNOS MPLS Applications Configuration Guide.