Table of Contents
Advertisement
JUNOSe 10.0.3 Release Notes
Stateful SRP Switchover (High Availability)
32
Known Behavior
Additional processing is required to maintain and mirror the necessary state
information that enables subscriber sessions to stay up across an SRP failover.
As a result, the performance of other control plane functions is reduced.
Specifically, call setup rates are lower than in previous releases.
Rapid call setup rates are most important following an outage that causes all
NOTE:
subscribers to drop, because many of the dropped subscribers will immediately
attempt to reconnect. This type of outage occurs far less frequently with stateful
SRP switchover.
We have ongoing development activities to characterize and improve call setup
rates in future releases.
Stateful SRP switchover remains inactive for 20 minutes after an initial
cold-start or cold-restart of the router. This delay enables the system to reach a
stable configuration before starting stateful SRP switchover.
If you want to override the 20-minute timer, turn high availability off by using
the mode file-system-synchronization command, and then on again by using
the mode high-availability command.
When IP tunnels are configured on a router enabled for stateful SRP
switchover, and the Service Module (SM) carrying these tunnels is reloaded,
stateful SRP switchover transitions to the pending state. Stateful SRP
switchover remains in the pending state for 10 minutes following the
successful reloading of the SM. This amount of time allows for IP tunnel
relocation and for the tunnels to become operational again on the SM. If an SRP
switchover occurs while in the pending state, the router performs a cold restart.
Work-around: None.
After a stateful SRP switchover, each layer of the interface columns must
reconstruct its interfaces from the mirrored information. While the interfaces
are being reconstructed the SRP module cannot send or receive frames,
including the protocol frames that signal graceful restart behavior with OSPF
and IS-IS peers. If the configured hold time is too short, peers might mistakenly
declare the adjacency down during the time in which the graceful restart is
taking place. [Defect ID 65132]
Work-around: Increase the hold time to provide sufficient time for interface
synchronization before the peers declare the adjacency down.
For OSPF, use the ip ospf dead-interval command to set the hold time.
We recommend that you use Bidirectional Forwarding Detection (BFD)
with a longer OSPF dead interval to achieve fast failure detection.
For IS-IS, use the isis hello-interval and isis hello-multiplier commands
to set the hold time.
Advertisement
Table of Contents
