Table of Contents
Advertisement
JUNOSe 11.0.x BGP and MPLS Configuration Guide
Node-based hellos are an attractive alternative to link-based hellos for graceful restart
when you use bidirectional forwarding detection (BFD) for link monitoring and you
have configured node-based hellos on all RSVP-TE peers.
Link-based RSVP-TE hellos are used for monitoring RSVP-TE adjacencies with
neighboring routers and for providing RSVP-TE graceful restart. However, the BFD
protocol is more effective at monitoring RSVP-TE adjacencies than are link-based
hellos.
Link-based RSVP-TE hellos for graceful restart are more resource-intensive option
than node-based RSVP-TE hellos when your configuration has several interfaces
enabled with MPLS RSVP-TE and carrying RSVP-TE data traffic. Link-based hellos
generate a volume of network traffic and processing overhead that is directly
proportional to the number of interfaces that are carrying active RSVP-TE tunnels.
Node-based hellos require less messaging and processing overhead in these
circumstances. Node hellos require only a single hello session between the two node
IDs, compared to link-based hellos that have hello sessions between all interface
pairs. Less traffic and overhead result in a lesser impact on scaling.
Node-based hellos can therefore be advantageous even when you are interoperating
with routers that are running JUNOSe software or JUNOS software, if you are using
BFD to monitor your RSVP-TE links. If you are not using BFD, then you must use
link-based hellos for link monitoring, and link-based hellos then become more practical
for graceful restart.
BFD Protocol and RSVP-TE
The Bidirectional Forwarding Detection (BFD) protocol uses control packets and
shorter detection time limits to more rapidly detect failures in a network. Also,
because they are adjustable, you can modify the BFD timers for more or less
aggressive failure detection.
Without BFD, RSVP-TE can learn about adjacency failures by either of two methods.
If RSVP-TE hellos are configured, then hello message timeouts indicate a failure. If
hellos are not configured, then RSVP-TE learns about failures from resv and path
messages.
When a BFD session exists between RSVP-TE peers, a peer that goes down is detected
quickly, enabling faster rerouting of traffic. Adjacency failure detection by means of
hello messages takes place on the order of seconds, whereas BFD fast failure detection
can take place on the order of hundreds of milliseconds.
When you issue the mpls rsvp bfd-liveness-detection command on an RSVP-TE
major interface, BFD liveness detection is established with all BFD-enabled RSVP-TE
peers associated with that interface.
When an RSVP-TE session is established with the remote peer if BFD is enabled
and if the BFD session is not already present then the local peer attempts to create
a BFD session to the remote peer. The BFD session is established only if when both
of the following are true:
252
BFD Protocol and RSVP-TE
Advertisement
Table of Contents
Troubleshooting
