Cat6500 - VSS, VSL Link Down Requires Standby Chassis Reboot

[Robert Ho]

we're still in the testing phase of the VSS system.

what we notice is that if we disable the link between the active/standby chassis (by pulling the fibers), and connect them back in, it requires a complete chassis reboot of the standby. is this normal? code is 12.2(33)SXI3.

thanks!

-robert

[Reza Sharifi]

Robert,

Yes, that is a normal behavior of VSS.  Once you connect the VSL links back, the primary switch reboot itself and comes back on line as backup switch

HTH

Reza

[Robert Ho]

Reza, it didnt seem to happen in our case.

We pulled the two 10GE fibers and:

- both chassis never rebooted

- all interfaces on the standby chassis was down

- log messages indicated that a manual reboot of the standby was required

is there an enhancement to not require a reboot if all vsl links go down?

thanks

-robert

Log message from active chassis:

*Mar 28 21:57:40.750: %VSLP-SW1_SP-2-VSL_DOWN:   All VSL links went down while switch is in ACTIVE role
*Mar 28 21:58:19.438: %ISSU-SW1_SP-3-ERP_CLIENT: For context ID -248369152, send failed in issu_receive
-Traceback= 40965794 40A96BB4 40A94C90 40895A0C 408959F8
*Mar 28 21:58:19.442: %VSLP_ISSU-SW1_SP-3-ISSU_ERROR: ISSU register peer failed with error code 0 for peer 0014.f132.3000
*Mar 28 21:58:45.306: %VSLP-SW1_SP-5-RRP_MSG: Peer Switch with unsaved configurations needs to be reloaded.
Please save relevant configurations on the peer switch and reload it.

[Reza Sharifi]

Robert,

When you pull both VSL links, the primary goes into the "recovery mode".  At this time neither one of the switches reboot.  Now, as soon as you connect the VSL links back to both switches, the switch that is in recovery mode (old primary) will reboot itself and of course the backup take over the responsibility and becomes primary.  When the old primary finish rebooting, it will be the backup switch

Is it more clear to you now?

HTH

Reza

[Robert Ho]

we ran the test again:

- chassis1-active; chassis2-standby

- pull fibers between chassis

- both chassis went active (no recovery mode on either)

- traffic still forwarding on both switches

- connect fibers back

- chassis1 remains active

- chassis2 goes to recovery mode but all links (besides vsl) are down

- log message indicates to reboot standby chassis

- reboot standby chassis and everything back to normal

it seems to differ than what you describe. is this normal?

From chassis2 when fibers were pulled:

!

*Mar 29 21:22:40.601: %VSLP-SW2_SPSTBY-2-VSL_DOWN:   All VSL links went down while switch is in Standby role
*Mar 29 21:22:40.601: %DUAL_ACTIVE-SW2_SPSTBY-1-VSL_DOWN: VSL is down - switchover, or possible dual-active situation has occurred
*Mar 29 21:22:40.601: %PFREDUN-SW2_SPSTBY-6-ACTIVE: Initializing as Virtual Switch ACTIVE processor

From chassis2 when fibers were pulled:

!

Core-VSS#

Core-VSS#sh sw virtual link
VSL Status : DOWN
VSL Uptime : -
VSL SCP Ping : -
VSL ICC Ping : -
VSL Control Link : -
Core-VSS#sh sw vir
Switch mode                  : Virtual Switch
Virtual switch domain number : 10
Local switch number          : 2
Local switch operational role: Virtual Switch Active
Core-VSS#

Core-VSS#

Core-VSS#sh sw virtual rol

Switch  Switch Status  Preempt    Priority  Role     Session ID
        Number         Oper(Conf) Oper(Conf)         Local  Remote
------------------------------------------------------------------
LOCAL    2     UP      FALSE(N )   100(100)  ACTIVE   0      0

In dual-active recovery mode: No

Core-VSS#

From chassis2 when all fibers were plugged back in:

!

*Mar 29 21:26:18.526: %VSLP-SW2_SP-5-RRP_MSG: Role change from Active to Standby and hence need to reload
*Mar 29 21:26:18.526: %VSLP-SW2_SP-5-RRP_UNSAVED_CONFIG: Ignoring system reload since there are unsaved configurations.
Please save the relevant configurations
*Mar 29 21:26:18.526: %VSLP-SW2_SP-5-RRP_MSG: Use 'reload' to bring this switch to its preferred STANDBY role
*Mar 29 21:26:18.534: %DUAL_ACTIVE-SW2_SP-1-RECOVERY: Dual-active condition detected: Starting recovery-mode, all non-VSL and non-excluded interfaces have been shut down

[Arber_123]

Hello,

Any news about this problem????? I am having the exact issue, IOS version 12.2(33)SXH7. When the VSL link is brought up, then the secondary switch waits for a reload command given in the console. Normally it has tono reboot automatically according to the document, right?

It is very annoying, because the standby switch is in remote location, and we have to travel in order to get there and perform manual reload.

Has anyone solved this?

Regards,

Arber.