¿Cisco 6500 VSS mejora o daña el MTBF?

Entiendo los beneficios del Cisco 6500 VSS con los puntos de venta obvios de administración única, instancia de enrutamiento única, eliminación de STP, canales de puertos a través del chasis, etc. Con dos Cisco 6500 independientes que pueden tener canales de puertos L3 y L2 entre ellos, al menos no tienen dependencia operativa entre sí a través del plano de control.

En un mundo VSS, y no tengo experiencia directa con esto, ahora tenemos software y otros protocolos que controlan ambos conmutadores. En mis diseños que esperan que el software del plano de control tenga errores, ¿el VSS reduce el MTBF como sospecho y es una compensación con las capacidades obtenidas o me falta cómo se mejora el MTBF?

cisco vss

— generalnetworkerror
fuente

Realmente me encantaría ver datos sin procesar sobre esto, pero dudo que incluso Cisco lo tenga. La apariencia informal en c-nsp y bugtool muestra muchos modos de falla específicos de VSS, pero obviamente no prueba nada. En nuestra red, las 3 razones principales para la interrupción, cada una separada por un gran margen, son: 1. Error del operador. 2. Interruptor roto. Pero, por lo general, los diseños se centran en mejorar 3. mientras que al mismo tiempo empeoran 1-2.

— ytti

Dé su SW # 2 roto, en su experiencia, ¿esto sucede más o menos a menudo con VSS?

— generalnetworkerror

No ejecutamos VSS, por lo que no hay datos. Dudo mucho en adoptar tempranamente cualquier solución que agregue señalización de destino compartido entre nodos, estoy mucho más enfocado en soluciones de reparación local sin estado. Pero reconozco completamente que para algunas aplicaciones VSS puede ser extremadamente atractivo.

— ytti

¿Está preguntando por interrupciones del servicio o fallas reales de la tarjeta de línea? El MTBF se usa generalmente para describir la tasa de fallas de hardware. En ese caso, VSS no afecta el hardware de ninguna manera.

— smoothbSE

@smoothbSE, buen punto sobre MTBF para fallas h / w. Usé el término libremente para indicar cualquier tipo de falla.

— generalnetworkerror

Respuestas:

Versión corta de la respuesta: un poco de ambas, pero no pretende ser una tecnología para mejorar directamente la disponibilidad

Versión larga de la respuesta: como otros han señalado, las definiciones tradicionales de MTBF y la disponibilidad del fabricante se centran en fallas de hardware. Otros factores (error humano, software defectuoso, mantenimiento planificado, etc.) son consideraciones al desarrollar una arquitectura, pero se realizan a nivel de usuario individual.

Para una perspectiva solo de hardware, VSS no afecta la disponibilidad. Se está utilizando el mismo hardware, por lo que se utilizan los mismos números MTBF / MTTR y las ecuaciones de disponibilidad final son las mismas.

Para una perspectiva más holística, es realmente una sacudida y dependerá en gran medida de sus deseos y necesidades individuales. Por un lado, podría considerarlo menos confiable ya que es una pieza compleja de tecnología y un solo "punto virtual de falla" (es decir, el plano de control VSS) afectará a ambas piezas de equipo redundante. Por otro lado, se puede ver para aumentar la disponibilidad, ya que un solo dispositivo virtual hace que la red sea mucho más simple, lo que hace menos probable que otras cosas salgan mal (menos dispositivos para administrar, sin HSRP / VRRP, dominio STP no en bucle, topología L3 más simple, etc.).

El mercado ha demostrado que la mayoría de los ingenieros de redes ven VSS y tecnologías similares como una mejora con respecto a una topología de acceso / distribución L2 tradicional, pero hay otras tecnologías con las que podría optar. Por ejemplo, una capa de acceso L3 enrutada podría lograr la mayoría de los beneficios de VSS, pero las VLAN no podrían abarcar múltiples dispositivos de capa de acceso, lo que haría que la solución sea potencialmente inútil en algunos escenarios (por ejemplo, centros de datos virtualizados).

— totalmente rechoncho
fuente

Desde un punto de vista funcional, VSS básicamente toma dos chasis y los ejecuta en un solo plano de control. Si desea crear un 6500 de 18 ranuras, entonces es la tecnología ideal. Si el objetivo es una mayor disponibilidad, entonces es mucho más difícil de justificar. El punto clave es que al establecer un par VSS ha creado un solo chasis funcional. Cualquier modo de falla en el plano de control, desde el defecto del software hasta el error de configuración, tiene un efecto inmediato en todo el complejo.

Por lo que vale, realmente no he visto muchas implementaciones nuevas de VSS en los últimos cinco años, pero he visto un número justo donde la función se ha eliminado a favor de ejecutar pares 6K independientes.

— rnxrx
fuente

Según mi experiencia, VSS alarga el MTBF a través de una complejidad operativa reducida (es decir, sin HSRP / VRRP, menos sintonización de STP, enrutamiento más simple, etc.) especialmente para tiendas con ingenieros con menos experiencia. La reconvergencia después de fallas en los enlaces es generalmente más rápida ya que el resto de la red ve al par como un dispositivo desde una perspectiva L2 y L3. Supongo que habría menos interrupciones relacionadas con los errores del software VSS, que interrupciones atribuidas a las interacciones y los modos de falla de los distintos protocolos que normalmente se ejecutan en esa capa.

— liso
fuente