在VSS世界中-我对此没有直接经验-我们现在拥有控制两个交换机的软件和其他协议。在我期望控制平面软件存在错误的设计中，VSS是否会像我所怀疑的那样降低MTBF，是否与获得的功能进行了权衡？还是我错过了MTBF的改进方式？
#1 楼
答案的简短版本：两者都有一点点，但这并不是要直接提高可用性的技术答案的较长版本：正如其他人指出的那样，制造商对MTBF和可用性着重于硬件故障。其他因素-人为错误，软件故障，计划内的维护等-是开发体系结构时要考虑的因素，但这些因素是在单个用户级别上考虑的。
从纯硬件的角度来看，VSS不会这样做。影响可用性。使用的是相同的硬件，因此使用相同的MTBF / MTTR编号，并且最终可用性方程式相同。
从更全面的角度来看，这确实是一种折腾，并且在很大程度上取决于您个人的需求。一方面，您可能会认为它的可靠性较差，因为它是一项复杂的技术，而单个“虚拟故障点”（即VSS控制平面）将影响两个冗余齿轮。另一方面，可以看到它可以提高可用性，因为单个虚拟设备使网络变得更加简单，从而减少了其他事情出错的可能性（设备管理更少，无HSRP / VRRP，无环路STP域，更简单的L3拓扑等）。
市场已经表明，大多数网络工程师将VSS和类似技术视为对传统L2发行/访问拓扑的改进，但是您还可以使用其他技术一起去。例如，路由的L3接入层可以实现VSS的大部分优势，但是VLAN无法跨越多个接入层设备，这使得该解决方案在某些情况下（例如虚拟数据中心）可能毫无用处。
#2 楼
从功能的角度来看，VSS基本上采用两个机箱，并在单个控制平面上运行它们。如果要创建18插槽6500，则它是理想的技术。如果目标是提高可用性，那么就很难证明其合理性。它们的关键点在于，在建立VSS对时，您已经创建了一个功能正常的机箱。控制平面上的任何故障模式-从软件缺陷到配置错误-都会立即影响整个系统。在过去的五年里，我真正没有真正看到过许多新的VSS部署，但是我看到相当数量的功能被删除，以支持独立的6K对。 br />
评论
我真的很乐意看到有关此的原始数据，但我什至怀疑思科也有。随意查看c-nsp和bugtool会显示许多特定于VSS的故障模式，但显然并不能证明任何事情。在我们的网络中，造成中断的三大原因分别是：1.操作员失误2.损坏的软件3.损坏的硬件/基础设施。但是通常设计的重点是使3.变得更好，而同时使1-2变得更糟。根据您的经验，给出＃2损坏的软件，使用VSS是否会或多或少地发生这种情况？
我们不运行VSS，所以没有数据。我非常想早日采用任何在节点之间增加命运共享信令的解决方案，而我更专注于无状态本地修复解决方案。但是我完全承认，对于某些应用程序，VSS可能具有极大的吸引力。
您是在询问服务中断或实际的线路卡故障吗？ MTBF通常用于描述硬件故障率。在这种情况下，VSS不会以任何方式影响硬件。
@smoothbSE，对MTBF的好处是硬件失败。我用宽松的术语来表示任何类型的故障。