Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Cisco Stackwise Virtual - Stack Redundancy Half

Hi,

On Cisco 9500 devices in a stackwise virtual configuration, Orion is reporting the stack is at half redundancy…

I am assuming its because it is set up with a single virtual link (However that actually is comprised of 4 ports (2 links)…

I have read this:

https://solarwindscore.my.site.com/SuccessCenter/s/article/https-support-solarwinds-com-SuccessCenter-s-article-Switch-St?language=en_US

And the output does match what is here but I am not sure how/where to resolve?

Find more posts tagged with

Accepted answers

All comments

stuartd

It's not clear whether your role is just on the monitoring side or if like myself you also have a hand in the physical side. But the fix is to complete the ring and perhaps this page is your starter for 10: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-9/configuration_guide/ha/b_179_ha_9500_cg/configuring_cisco_stackwise_virtual.html

cnorborg

Hopefully they've improved it recently. And by that I mean not in terms of how it works, but how it recovers from issues. I did some pretty good testing on 9500 stackwise setups a couple years ago, and decided not to use them. Not because of how they worked. They did just fine in operations and it was quite neat to work with. But, I had problems in getting them to recover from problems. With a normal Catalyst Stack, if one switch dies, you can yank it out of the stack, put a new one in, and it will not only do things like upgrade it to the right OS for the stack, but program it to replace the switch that left the stack, and you can do all of this without taking down the stack.

With the 9500 stackwise, if one of the switches dies, there is no way to recover the stack that I could figure out, without rebooting the other switch. So, in my case I wanted better redundancy so a single 9500 which is in the role of a L3 switch doing distribution duties to other switches wouldn't bring down the network if one switch went bad. So I wanted not only for the failure to go mostly unnoticed by the end-users, but for the replacement of the failed switch to go unnoticed during normal working hours. Plus, to be able to do things like upgrade one switch, and get it fully working, before upgrading the other.

The 9500 stackwise doesn't do this, if a switch fails I couldn't get the replacement to actually be active in the stackwise without a reboot of the switch that didn't fail. Software upgrades were equally disruptive to the network. So, I just made both 9500's active routing partners using HSRP rather than doing stackwise. One fails? The other takes over and I replace it with zero disruption. Upgrading IOS? Just as simple.

Monitoring in Orion? Equally simple.