Cisco Cisco 1700 2600 3600 3700 Series VPN Module White Paper

Page 46 of 55

*Jun 26 16:06:37.297: %VSLP-SW2_SPSTBY-3-VSLP_LMP_FAIL_REASON: Port 5/5: Link
down

*Jun 26 16:06:37.297: %VSL-SW2_SPSTBY-2-VSL_STATUS: -======== VSL is DOWN
========-

*Jun 26 16:06:37.301: %PFREDUN-SW2_SPSTBY-6-ACTIVE: Initializing as Virtual
Switch ACTIVE processor

*Jun 26 16:06:37.353: %SYS-SW2_SPSTBY-3-LOGGER_FLUSHED: System was paused for
00:00:00 to ensure console debugging output.

*Jun 26 16:06:37.441: %DUALACTIVE-SP-1-VSL_DOWN: VSL is down - switchover, or
possible dual-active situation has occurred

Recovery from Dual-Active Scenario

If a VSL flap occurs, the system recovers automatically. Upon a link-up event from any of the VSL links, the

previous active supervisor engine that is now in recovery mode reloads itself, allowing it to initialize as the hot-

standby supervisor engine.

If the peer chassis is not detected because the VSL is down again, the dual-active detection mechanism

determines whether or not the peer chassis is active. If the peer chassis is detected, this event is treated as

another VSL failure event, and the chassis once again enters into recovery mode.

When the VSL is restored, the following messages are displayed on the console and the switch in recovery mode

(previous active virtual switch) reloads:

*Jun 26 16:23:34.877: %DUALACTIVE-1-VSL_RECOVERED: VSL has recovered during dual-
active situation: Reloading switch 1

*Jun 26 16:23:34.909: %SYS-5-RELOAD: Reload requested Reload Reason: Reload
Command.

<…snip…>

***

*** --- SHUTDOWN NOW ---

***

*Jun 26 16:23:42.012: %SYS-SW1_SP-5-RELOAD: Reload requested

*Jun 26 16:23:42.016: %OIR-SW1_SP-6-CONSOLE: Changing console ownership to switch
processor

*Jun 26 16:23:42.044: %SYS-SW1_SP-3-LOGGER_FLUSHED: System was paused for
00:00:00 to ensure console debugging output.

System Bootstrap, Version 8.5(1)

<…snip…>

After the chassis reloads, it reinitializes and the supervisor engine enters into standby virtual switch mode. If Switch

Preemption is configured to prioritize this chassis to become active, it assumes this role after the preempt timer

expires.

Finally, traffic convergence associated with a VSL failure scenario involves the dual-active detection mechanisms,

the recovery mode operations, and the restoration period, which involves a reload of the previously active VSS

chassis. In each of the three previous stages, there is a possibility for some traffic disruption. Typically, the

disruption will be similar to the NSF/SSO switchover scenarios described previously but other factors from the

overall network design can have an impact as well. These include the types of connections to the VSS, either L2 or

L3 Multichassis EtherChannels or Equal Cost Paths. For more detailed analysis on convergence times associated

with the VSS failure scenarios please refer to following document: