Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Examining the Hello Message



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.


RSVP Hello messages are required to establish the protocol or to maintain adjacency information. RSVP Hello messages do not establish state.

Figure 1 shows two RSVP Hello messages exchanged between routers R1 and R3.

Figure 1: RSVP Hello Message
RSVP Hello Message

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


To examine the Hello message, enter the following Junos OS CLI command:

Sample Output 1

Sample Output 2


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. 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 ( to R3 ( 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.

  • HelloReq Len 12

    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.

  • RestartCap Len 12 restart time 0, recovery time 0

    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.

  • HelloRply Len 12

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

Every node maintains a timer for every neighbor hello session where the timer value is 3.5 times the configured hello-interval. The timer corresponding to a neighbor is reset whenever the node receives a Hello message from that neighbor. If the timer expires, then it means no Hello message has been received from the neighbor for 3.5 hello-interval seconds, and the neighbor hello session is marked as down.