OSPF Effects on Graceful Restart and Network Stability During Unified ISSU

OSPF has the following issues to consider before you begin a unified in-service software upgrade:

Configuring Graceful Restart Before Unified ISSU Begins

You must configure OSPF graceful restart before you begin the unified in-service software upgrade. When the unified ISSU process verifies the upgrade requirements during the initialization phase, it detects whether graceful restart is configured. If it is not configured, the CLI displays a warning message and prompts you to proceed or halt. You can stop at this point to configure graceful restart.

If instead you proceed, the unified in-service software upgrade can complete successfully, but the OSPF neighbors are likely to break the adjacencies with the upgrading router and consider that routes formerly reached through this router are now unreachable. When the unified in-service software upgrade completes and the routing protocols restart, the IS-IS neighbors can relearn the routes through the router.

You must also ensure that the OSPF neighbors have been configured as graceful restart helper routers. During the unified ISSU initialization phase, OSPF graceful restart on the upgrading router cannot verify whether its neighbors are helper routers, and reports that fact by means of the CLI.

Configuring Graceful Restart When BGP and LDP Are Configured

When BGP, LDP, and OSPF are all configured on a router on which you want to perform a unified in-service software upgrade, ensure that the OSPF graceful restart timeout is longer than the LDP graceful restart timeout. The OSPF graceful restart does not complete when the LDP graceful restart timeout is longer than the OSPF graceful restart timeout. Configure OSPF graceful restart timeout with the graceful-restart restart-time command. Configure LDP graceful restart timeout with the mpls ldp graceful-restart timers max-recovery command.

Configuring a Longer Dead Interval Than Normal

To prevent OSPF from timing out to the OSPF neighbors, you must configure a dead interval that is longer than the expected forwarding outage for the platform. During the initialization phase, unified ISSU displays the recommended dead interval in a warning message. For information about the expected forwarding outage, see Interruption in Traffic Forwarding for Layer 3 Routing Protocols During Unified ISSU.

When a unified ISSU operation is in progress with OSPF and L2TP subscriber sessions configured on the router, the restarting router sends a graceful restart link-local LSA to inform its neighbors that it is restarting. After receiving this grace LSA, the neighbors do not time out even if the value that is configured using the ip ospf dead-interval command is exceeded (which specifies the time period during which the router's neighbors do not discover hello packets before they declare the router to be down). Until the unified ISSU process completes, the neighboring routers disregard the configured OSPF dead interval and active L2TP sessions are preserved without any disruption in user traffic.

During a unified ISSU operation at the Application Quiesce Start (AQS) phase, hello packets are sent from an OSPF router, which is the restarting router, to neighboring routers before the interface controller (IC) undergoes a reload.

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 OSPF traffic loss occurs during the resulting line module resets. For those reasons, you might want OSPF 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 link cost to its neighbors so that they route around the upgrading router. When you issue the issu start command, the router raises the link cost to the maximum link cost on all interfaces running OSPF. The higher cost is advertised in the OSPF LSAs. OSPF 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, OSPF reverts the link costs 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.

OSPF 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 OSPF functionality.

Related Documentation