Installation guide

Booting and System Images

GRP Redundant Processor Support 3

Functional Description

This section provides additional information on GRP redundant processor implementation.

• Booting and System Images

• Redundancy Arbitration

• Secondary Console

• Device Access

• Local Ethernet

• Failover

• Field Diagnostics

• System Logs

• Crash Dumps

• Additional Diagnostic Aids

• Additional GRPs

Booting and System Images

On hardware reset, each GRP in a dual GRP system will boot the Cisco IOS image speciﬁed in the

startup-conﬁg. The image speciﬁcation is identiﬁed in a ROM monitor variable, and it is this

variable, in combination with the conﬁg-register settings, that determines the boot image. In basic

redundant GRP operations, the two GRPs run identical Cisco IOS images and identical

conﬁgurations. User and conﬁguration commands assist this duplication of software and data.

It is also possible to run dual GRPs with different IOS images and conﬁgurations in the two GRPs.

This is useful if you want to experiment with a different IOS version or try new conﬁguration

features while providing for automated fallback to a previous version.

When a GRP that supports redundancy detects another GRP running an earlier version of Cisco IOS

software that does not support redundancy, the former GRP will reload itself and enter a wait state.

This action allows the latter GRP to operate without interference so that it can be reconﬁgured and

loaded with Cisco IOS software that supports redundant processors.

Redundancy Arbitration

After the GRPs have booted the Cisco IOS software, but before they parse the startup-conﬁg, the two

GRPs arbitrate

to decide which one should be the primary and which one should be the secondary. If

all else is equal, the GRP in the lowest- numbered slot will become the primary. If the GRPs differ

in some way, such as running different versions of software or ﬁrmware, the arbitration mechanism

makes the best choice as determined by the arbitration algorithms. These may account for the

versions of IOS running on the GRPs, how recent the startup-conﬁgs are, and whether the

startup-conﬁg was saved in this chassis.

Once the arbitration mechanism selects a primary GRP, it will load its startup-conﬁg. If the

startup-conﬁg does not explicitly disallow it, the primary GRP ensures that the startup-conﬁg on the

secondary GRP is identical to that on the primary GRP. This synchronization typically involves

copying the startup-conﬁg to the secondary GRP. The primary also loads the linecards and completes

the remainder of the initialization.