Routing Around The Restarting Router To Minimize Network Instability; Unexpected L2Tp Failover Of Established Tunnels During Unified Issu - Juniper SERVICE AVAILABILITY - CONFIGURATION GUIDE V 11.1.X Configuration Manual

Routing Around the Restarting Router to Minimize Network Instability

NOTE: The situation described in this section is very uncommon. This rare
circumstance arises when you have redundant uplinks to the core and network
topology changes cause routes to go through the upgrading router. In a typical network
design, this is not an issue and you do not need to route peers around the upgrading
router.
During the unified ISSU upgrade phase, network instability can result if the restarting
router goes into an unstable state after the unified ISSU process fails. Some IS-IS
traffic loss occurs during the resulting line module resets. For those reasons, you
might want IS-IS peers to route around the router that is being upgraded.
You can use the overload advertise-high-metric issu command to cause the router
to advertise a high metric to its neighbors so that they route around the upgrading
router. When you issue the issu start command, the router raises the metric to the
maximum link cost on all interfaces running IS-IS. The maximum value depends on
the metric type. IS-IS neighbors then choose a path with lower metrics to reach any
destination that was previously reached through the upgrading router. When unified
ISSU is completed, IS-IS reverts the metrics back to the values that were configured
before the unified in-service software upgrade.
When traffic engineering has been configured, the traffic engineering metrics are
also increased. New tunnels are not established through the upgrading router and
any tunnels undergoing re-optimization in other routers go around the upgrading
router.
IS-IS support for unified ISSU does not depend on this configuration. If you do not
issue the overload advertise-high-metric issu command, the unified in-service
software upgrade can still proceed to successful completion without disrupting IS-IS
functionality.
Related Topics

Unexpected L2TP Failover of Established Tunnels During Unified ISSU

L2TP never declares itself as unified ISSU unsafe. However, unified ISSU forces an
L2TP failover for all established tunnels. Successful recovery of a tunnel and its
sessions following the unified in-service software upgrade requires a successful L2TP
failover resynchronization, either by the L2TP silent failover method or the L2TP
failover protocol.
When the L2TP silent failover method is configured on ERX1440 router, use the l2tp
retransmission command to set the retransmission retry count to 8 for the remote
peers. A value of more than 7 helps ensure that the remote peers keep retransmitting
control messages for the duration of the unified ISSU warm restart and the tunnels
are not disconnected.
Application Support for Unified ISSU on page 71

Unexpected L2TP Failover of Established Tunnels During Unified ISSU

Chapter 4: Configuring a Unified In-Service Software Upgrade
87