Specifications

Page 124 /148
image is unstable, the user can issue a second switchover command to revert
back to the original master.
4.2.3 Redundant System and Switching Board
The M20 supports a redundant System and Switch Board (SSB), that has been
implemented is a cold standby, “spare-in-the-box, automatic fail-over” model.
SSB redundancy gives providers the option to deploy the M20 with extra
protection against switch fabric failure. The model allows for the automatic fail-
over of the SSB in the case of failure, without having to be physically present to
swap components, improving both reliability and availability.
Master SSB vs Standby SSB
An SSB can either be a master SSB or a standby SSB. The master SSB
performs all packet forwarding engine operations. The standby SSB is held in
reset and is not active. There is no management access to the standby SSB and
its condition is not known until a fail-over occurs and the standby SSB becomes
the master. However, the presence of a backup SSB can be determined using
the show chassis SSB command in the CLI, which displays status information of
the master SSB (included how many times mastership has changed) and the
presence/absence of the backup SSB. The system checks for the
presence/absence of the backup SSB every 0.5 seconds to ensure current
information.
In order to become active and assume mastership when a fail-over is initiated,
the standby SSB must run through the entire PFE boot sequence. The time
required to initialize chassisd, and dcd, bring up FPCs and start to exchange
routing information is 1-2 minutes.
Default Mastership Setting
By default, if there are two SSB’s present in a chassis, then the SSB in slot 0 is
the master and will automatically take on mastership when the system is powered
up. The SSB in slot 1 will be held in reset.
Configurable Mastership
Users can override the default mastership slot setting using a CLI command. This
configuration setting indicates to the system that a particular SSB should be
preferred over the other (and the redundant one should be used if the preferred
one fails), or a particular SSB should always be used, even if it crashes. Note
that if the user configures a router to always use a particular SSB but that SSB is
not present, then the other SSB is allowed to become active.
Switching of mastership between SSBs is non-preemptive. If an SSB has been
selected and is running, the other SSB cannot become master until the user
rehomes or removes the current SSB from the system.
Note that if there are two routing engines present then this command must be
configured consistently on both routing engines to avoid an unnecessary SSB
fail-over. The RE is the component of the system that contains the state
regarding which of the two SSB’s should be active and which should be backup.
In systems with redundant REs, each RE is configured separately. This means
that it is possible to configure each RE differently with respect to which SSB is
master and which is backup. The user should be encouraged to configure the
SSB redundancy consistently -- otherwise it's possible for an RE switch-over to
cause an (unnecessary) SSB switch-over..
Automatic Mastership Switchover Conditions
There are a number of scenarios in which the fail-over of an SSB will occur.
§ 1) Local SSB Offline Request—If the operator physically presses the offline
request button (on the front of the chassis) of the master SSB for a duration
of 3 seconds, then the standby SSB will take over as the master SSB. The
old master will be held in reset as the redundant SSB. The operator can
then remove the redundant SSB.
§ 2) Remote SSB Offline Request—The operator can request a switch-over to
the backup SSB by issuing a CLI command. When the command is issued, a
warning message is displayed asking the operator to confirm the switchover
request.
§ 3) SSB Crash or Loss of Communication between SSB and RE.
§ 4) Failure to establish connection with the master RE.