Scenarios for APM failover to stand-by APM

book

Article ID: 167912

calendar_today

Updated On:

Products

XOS

Issue/Introduction

List of scenarios for APM failover to stand-by APM

N/A

Cause

Goal - To list the possible scenarios where the stand-by APM will be booted up with the vap member image.

Resolution

Here are the possible scenarios where the CPM will boot a vap image on a standby APM instead of the APM where it was originally running.
Note: This assumes that the ap-list for the vap-group includes the slot where the standby APM is present. Also, the standby APM is rebooted to load the vap image during boot process.

1. The user physically swaps the APM hardware. As soon as the APM is removed from the chassis, the standby APM is rebooted to load the vap-image.

2. The user changes the vap-group ap-list in the cli. The ap-list restricts which APMs are legal targets for the VAP to boot on. If the new ap-list doesn't include the APM slot where the vap image is currently booted up, but includes another slot where a standby APM is present, then the APM with vap-image will be rebooted to boot up as standby, and the syandby APM will be rebooted to boot with vap-image.

3. User disables the APM in the XOS configuration using 'configure module <slot #> disable. This will set that APM to 'Down' state, and boot the vap-image on the standby APM.

4. The system controller dynamically sets the APM to 'Down' state. This occurs when an APM doesn't boot up in the allotted time so the CPM reboots it. If the APM still doesn't boot up in time, then the CPM reboots again. Once the threshold for the number of resets is reached, the CPM set's the APM to 'Down' state. Similar to scenario 3 above, if the APM is in 'Down' state, the vap-image is loaded on the standby APM

5. The user configures 2 vap-groups and sets one VAP group's load-priority higher than that of the other vap-group. If two or more VAPs from different VAP groups are trying to boot at the same time, the VAPs with the higher load-priority will be booted first on the APMs.
This functionality may result in a vap-image to be booted up on a standby APM after a reload occurs. Here is an example: vap-group VG1 has lower load-priority, and it is currently loaded on ap3 and ap4 slots and there is a standby APM in slot ap5. Higher load-priortity is configured for vap-group VG2, but it doesn't include ap5 in it's ap-list. Since the load-priority doesn't preempt, the lower load-priority VAPs from VG1 are not rebooted. However, during the next reboot, the VAP for VG2 will be loaded on the APMs ap3/ap4, and then the vap-image for VG1 will be loaded on the standby APM.

6. The user configures 2 vap-groups and sets one VAP group's preemption-priority higher than the other. If the higher preemption-priority vap-group requires additional APMs to load it's VAP, then it will take them from vap-group with a lower preemption-priority by immediately rebooting them with the higher preemption-priority VAPs. In addition, if a APM failure occurs on a VAP with a higher preemption-priority, it will take an APM from the lower preemption-priority group.

Workaround

N/A