|
|
Redundancy means redundant cards are integrated into the SES as standbys. When a primary card malfunctions, the associated standby will take over and continue the services originally provided by the primary hardware component The SES provides redundancy for the PXM1 and the BXM cards. An user can achieve the following with BPX/SES redundancy:
This chapter describes SES redundancy and serviceability in following sections:
The SES platform replicates the following information from active PXM1 to standby PXM1 to support PXM1 redundancy:
1. Images downloaded on the active card get replicated to the standby.
2. System name if changed on the active card gets replicated to the standby.
3. Run time IP changed through the ipifconfig command on the active card gets replicated to the standby.
4. Sys logs are maintained to be the same on both active and standby cards.
5. Users added through the adduser command on the active card are added to the standby as well.
6. Configuration of users through the cnfuser command is also replicated to the standby.
7. Deletion of users on the active card through the deluser command results in their deletion on the standby as well
8. Trap Manager added on the active card through the addtrapmgr command gets replicated to the standby as well.
9. APS configuration done on the active card through the addapsln, delapsln, and cnfapsln commands gets reflected on the standby as well.
The PXM1 consists of an active card and a standby processor card operating as a hot-redundancy pair. The SVC redundancy scope includes the following:
Data redundancy is accomplished through updates messages from the Active controller to Standby. Data persistency is accomplished through disk storage at Active and Standby controller. Both the standby update and disk read/write operation are supported by the SES platform software.
The data persistency and redundancy model for the configuration information and run time data base on a PNNI Controller are managed in the following way:
To support call redundancy, the call states and a minimum set of connection information are sent to the standby PNNI controller. The Call Control Blocks (CCB) task manages the call database, while the Redundancy Manager task manages the standby updates when call becomes active or release.
The standby update function of the Redundancy Manager task is kicked off by a periodic timer. When the call becomes active at active CCB, the call data structures are converted into a single Active Call record and put on the update tracking queue of the Redundancy Manager task. When the Redundancy Manager task kick off after timer expires, all active call records are sent to the standby PXM. There is a delay in SVC call availability to the standby PAM after it is made available on the active side. When a switchover is initiated, some SVC calls made after the timer expires can be lost. However, the loss is minimal.
When a call is releasing, the Active Call record is removed from both the active BCC and the standby BCC. Similar to adding active call record to the standby PXM, all call record removing queries to the standby PXM are sent to the update tracking queue of the Redundancy Manager task until update timer expires.
Provisioning is an infrequent event, but it is required that the data be sent to Standby and Disk before the acknowledgement is returned to the user. Any data learned dynamically from the switch is sent on a 250 millisecond timer.
The redundancy and persistency provisioning process is as follows:
1. Provisioning request is made on the NMS or CLI.
2. Request is sent to CCB.
3. When the provisioning is done, CCB sends a provisioning redundancy request to the Redundancy Manager task.
4. Redundancy Manager task sends out a standby redundancy update to the standby PXM. Unlike call record redundancy, there is no timer delay provisioning data sent to the standby PXM.
5. Standby PXM sends a disk persistency update.
6. Redundancy Manager task sends a response message to the NMS or CLI. Once the response message is returned without an error, redundancy and persistency data is guaranteed, and all the provisioning information is written to the disk on the redundancy side.
SES supports three different uplink redundancy configurations:
Y cable redundancy provides:
APS redundancy provides:
The BXM hot standby redundancy function pre-programs the slave standby BXM card the same as the active BXM card. When the active card fails, the slave card switch over operation can be done quickly (within 250ms). Table 6-1 describes the hardware supported by BXM redundancy.
| Hardware | Type of Support |
|---|---|
OC3 APS 1+1 | Supported on AutoRoute and PNNI. |
OC3 APS 1 by 1 | Supported only on AutoRoute. |
DS3 y-red | Supported on AutoRoute and PNNI. |
E3 y-red | Supported on AutoRoute and PNNI. |
Table 6-2 describes the three forms of BXM redundancy.
| Type of Redundancy | Function |
|---|---|
AutoRoute combus configuration message redundancy | Provides backward AR compatibility. |
VSI slave configuration message and connection data base redundancy | Supported when a standby BXM card is plugged in. |
ILMI configuration message and data base redundancy | Supported when a standby BXM card is plugged in and ILMI function on the active BXM card is turned on. |
Figure 6-1 shows how redundancy is performed between active card and standby card.
The VSI master resides in the PXM1 controller card. The VSI slaves reside on the BXM cards. Without VSI operation, the BXM card provides the hot standby mechanism by duplicating combus messages from BCC to standby BXM card. (The flow of this operation is shown by broken lines in Figure 6-1.)
With VSI operation, the active slave card forwards any VSI configuration messages it receives from the master VSI controller to standby slave VSI card. (The flow of this operation is shown by the continuous line in Figure 6-1.) When the standby BXM card is activated by the user, the active BXM card forwards all Combus/VSI/ILMI configuration messages it received from the master VSI controller to the standby BXM card.
The hot standby operations between active and standby card are performed as below:
Step 2 VSI configuration messages (from Master VSI controller or other slave VSI card) are forwarded to standby slave VSI card by active slave VSI card.
When a standby VSI card is plugged in or reset, the standby card retrieves all VSI configuration messages and connection data bases from the active card. The standby will also check to see if ILMI is enabled on the card. If ILMI is enabled, the standby card will try retrieve the ILMI database from the active card.
The following ILMI data bases on the active card need to be retrieved by the standby card:
The database retrieval will be done by the existing vsi passthru protocol. The standby VSI card will act like a VSI master and use the VSI interface functions (VSI get and getmore commands) to retrieve the VSI/ILMI databases. Normal data transfers and switchovers happen as described below:
To make a standby BXM card a hot-standby card, the user executes the addyred command from the BCC CLI.
To remove the hot-standby status of a BXM card, the user executes an delyred command from the BCC CLI. The primary card of the redundancy pair will become the active card after delyred is issued. This would be the case even the secondary card was active before.
To perform a switchover from an active card to the hot-standby card, the user executes a switchyred command from the BCC CLI, or removes the active BXM card from its slot.
The SES PNNI node achieves system availability through the use of:
Call redundancy applies to the connections as follows:
| Occurrence | Call Redundancy Result |
|---|---|
SES PNNI controller switch-over | All active connections (SVCs/SPVCs) are preserved. |
Platform Controller switch-over | All active connections are preserved. |
Y-redundancy line card switch-over | All active connections are preserved. |
Y-redundancy trunk card switch-over | All active connections are preserved. |
SES PNNI controller software upgrade or downgrade | All active connections are preserved. |
Standalone SES PNNI controller configuration fail-over | All active SVC connections are release. |
Standalone platform controller configuration fail-over | All active SVC connections are release. |
The PNNI redundant controller supports forced switchover. A forced switchover occurs under the following circumstances:
During a forced switchover, the system shuts down the active controller, and the standby controller resumes the active role as described in the following steps:
Step 2 The standby controller resumes the active role, and its applications transition to an ACTIVE_READY state. During this transition, the synchronization of the RAM and the disk is ensured. Asynchronously, it is also waiting for the newly-standby entity to be ready for RAM synchronization.
Step 3 The newly-initialized entity is asked to resume a standby role. During the transition, it performs the RAM is synchronized with the newly-active entity.
Regardless of whether it is fatal or on-demand, a forced switchover will be carried out despite any controller congestion.
During a SES PNNI controller switchover, active connections in the SES PNNI controller component database will be maintained with no impact on the user data plane. Connections in the process of being set up, or not yet mirrored on the standby processor, are released. The control PVC connections are re-established. The signaling layer 2 of the UNI and PNNI will be restarted, but the layer 3 database is preserved.
Post-switchover operations are carried out after a switchover. The post-switchover operations are as follows:
1. Node internal VSI master/slave communications are re-established.
2. Node external SSCOP link is re-established.
3. Node external PNNI RCC link is re-established.
4. Interface resync between the VSI master/slave switch and interface info is performed.
5. Node external routing/topology info is rebuilt.
6. Node external call state resync (SSCOP Status Enquiry) is performed.
7. Node internal call Release Pending queue is processed.
8. Node internal VSI master/slave connection resync is performed.
New SVC calls can be made when steps 1 and 2 are both done.
Because of the possibly large-scale post-switchover operations and the need for handling normal controller operations after the switchover as early as possible, the controller is considered in congestion right after normal switchover. Under switchover congestion, some thresholds are controlled so both normal controller operations and post-switchover operations can be performed smoothly at the same time.
 |
Note Maximum call rate may not be sustained during a resync. |
|
Note During switch over and re-sync, system may not be able to sustain the normal full call setup rate due to CPU utilization. |
|
Note The current redundancy backup has an one-second window to back up the active calls to the standby. When the controller switches over, it may have some inconsistent active call records with switch platform. After the VSI re-synchronizes, it eliminates the inconsistency between the controller and switch platform. Calls established within the last one second before the switchover may be deleted. |
In the standalone SES PNNI controller configuration, upon its fail-over, SVC connections are re-initiated by the ATM CPE. SPVC connections are re-initiated by the master endpoints of SPVCs.
BCC switchovers are managed by the BPX switch. The new active BCC are synchronized with the SES PNNI controller. Mismatched connections are released.
The Y-redundancy BXM card switch-over is managed by the BPX switch. The new active BXM card are synchronized with the SES PNNI controller. Mismatched connections are released.
The Y-redundancy BXM trunk switch-over is managed by the BPX switch. The new active BXM trunk is synchronized with the SES PNNI controller. Mismatched connections are released.
Posted: Thu Jul 27 19:54:57 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.