 |
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 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 in-service software upgrade can still proceed to successful completion without disrupting IS-IS functionality.
overload advertise-high-metric issu
- host1(config-router)#overload advertise-high-metric
issu
 | Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |