Hide Navigation Pane
Show Navigation Pane
Feedback
Download
SHA1
Interruption in Traffic Forwarding for Layer 3 Routing Protocols During Unified ISSU
The routing protocols are affected by two interruptions in traffic forwarding caused by the unified in-service software upgrade during the upgrade phase.
- Switchover from active to standby SRP module—When
the active SRP module running the current release switches over to
the standby SRP module running the upgrade release, the routing protocols
and all other applications restart. A control plane outage of 30–40
seconds prevents the protocols from sending hellos or keepalive messages.
The protocols must gracefully restart to come back online, recover their routing state on the newly active SRP module, and respond to their peers. Therefore, you must enable graceful restart for all protocols before you begin the unified in-service software upgrade. All neighbors of the routing protocols must also be configured to support graceful restart.
A data plane outage of about 1 second for the E120 and E320 routers and about 4 seconds for the ERX1440 router also takes place during the switchover of the fabric from the active primary SRP module to the standby SRP module.
- Upgrade of the forwarding plane for each line module—After the routing protocols reconverge with their peers and rebuild their routing tables, unified ISSU upgrades the forwarding plane on all line modules simultaneously. This upgrade halts forwarding through the chassis. This forwarding outage lasts about 15 seconds for the E120 and E320 routers and about 50 seconds for the ERX1440 router.
If capable, routing protocols temporarily lengthen their timers to survive the outages. During the initialization phase, unified ISSU checks for timers that are set too short and whether the protocol enables timer renegotiation. If these checks fail, unified ISSU generates a warning and enables you to reconfigure the protocols before you issue the issu start command.
We recommend that you configure timers to be longer than usual for the routing protocols that cannot renegotiate timers. You can use bidirectional forwarding detection (BFD) to quickly detect forwarding interruptions.
Table 21 describes how individual routing protocols behave during a unified in-service software upgrade.
Table 21: Behavior of Routing Protocols During a Unified In-Service Software Upgrade
Protocol | Behavior |
|---|---|
BFD | BFD renegotiates its timers as needed. Typically, the timers are lengthened until the SRP module switchover takes place, then shortened for the forwarding plane upgrade, and finally shortened to the original configured values. |
BGP | The configured BGP timers are typically long enough to survive the forwarding outages. If, not, unified ISSU generates a warning message with a recommended timer interval. BGP sends out keepalive messages immediately before and immediately after both the SRP module switchover and the forwarding plane restart, independent of the interval since it last sent them. |
IS-IS | If necessary, temporarily lengthens the hello timers. |
LDP | Unified ISSU warns you if the hello timers or the keepalive timers are not long enough to survive the forwarding plane upgrade. LDP sends out hello messages and keepalive messages immediately before and immediately after both the SRP module switchover and the forwarding plane restart, independent of the interval since it last sent them. |
OSPF | OSPF timers are not negotiable between peers. Unified ISSU generates a warning if the hello timers or the keepalive timers are not long enough to survive the forwarding plane upgrade. OSPF begins a graceful restart before the SRP module switchover. When you configure graceful restart before the unified in-service software upgrade, you must ensure that the graceful restart times are long enough to allow recovery. OSPF sends out hello messages and keepalive messages immediately before and immediately after forwarding plane restart, independent of the interval since it last sent them. |
PIM | If necessary, temporarily lengthens the hold times in hello messages. PIM guarantees that at least one hello message with a lengthened hold time is sent to each neighbor. If necessary, increases the join-prune hold time. PIM guarantees that at least one join-prune message with a lengthened hold time is sent to each neighbor. |
RIP | RIP timers do not affect unified ISSU. |
RSVP-TE | If necessary, temporarily lengthens the graceful restart timers to survive the SRP module switchover. If necessary, lengthens the hello timers to survive the forwarding plane upgrade. |
You might want some or all traffic to be routed around the upgrading router rather than accept a forwarding loss during the forwarding interruption. To do so, you must configure your routing protocols appropriately. For example, you might raise the link cost in IS-IS and OSPF, causing their neighbors to seek alternate routes that have lower link costs. In PIM, you can set the priority for the router interface to zero to ensure that the upgrading router is not selected as a designated router.
