Podcast: Descargar (Duración: 18:45 — 18.1MB)
- ¿Qué es VSS?
- ¿Qué hace el VSS?
- VSL (Virtual Switch Link)
- Redundancia del VSL
- ¿Qué pasa cuando falla la supervisora activa?
- ¿Qué pasa cuando falla un enlace del VSL?
- ¿Qué pasa cuando falla un puerto que no es VSL?
- ¿Qué pasa cuando fallan todos los puertos que no son VSL?
- ¿Qué pasa cuando cae el VSL completo?
¿Qué es VSS?
Lo primero de todo será definir VSS. VSS es el acrónimo de Virtual Switching System, y cuando hablamos de VSS hablamos de un cluster, no de un stack. Un stack no es más que agregar puertos y aquí estamos hablando de montar un cluster con todo lo que significa, de todos modos, no os preocupéis si esto os suena un poco criptico porque explicar esto es justamente el objetivo de este audio.
VSS permite convertir dos switches independientes en un nuevo switch más grande. Esto se puede montar con Cisco 4500, 6500 y 6800 que tengan el hardware específico para VSS, es decir, no vale cualquier 6500 que encontremos, para poder montar un VSS necesitamos versiones de software específicas y hardware específico.
VSS permite la combinación de dos switches para conseguir una única entidad lógica de red desde las perpectivas de plano de control y gestión.
Para que los protocolos de routing puedan funcionar correctamente proporcionando una única entidad Cisco usa la tecnología SSO (IOS Statefull SwitchOver) y las extensiones NSF (Non Stop Forwarding).
Por supuesto el nuevo switch virtual dede fuera se va a ver como una única entidad, como si sólo hubiera un equipo y no dos.
¿Qué hace el VSS?
- A nivel de gestión unifica SNMP, SSH, telnet ….
- En nivel 2 se encarga de las BPUs, del LACP, la gestón de las MACs …
- A nivel 3 se encarga de los protocolos de routing, del direccionamiento …
Como podéis daros cuenta esto va mucho más allá de lo que sería un simple stack
Y en cuanto a la procesadora en el switch activo realiza la programación de forwarding de las DFCs dentro del VSS y además programa la PFC (policy feature card) de la procesadora del switch en standby.
La PFC (policy feature card) de la supervisora activa realizará los lookups del tráfico que entre por el virtual swtich activo y la PFC del otro switch lo que entre por el otro switch. Y las DFCs pues harán lo propio en sus tarjetas.
Ya lo sabéis pero las CFCs no realizan ninguna decisión pues se reenviará la decisión a la supervisora, por si alguien todavía tiene alguna tarjeta de este tipo.
VSS permite la gestión centralizada de todo, ya sea BGP, STP, OSPF, LACP, lo qué queráis.
VSL (Virtual Switch Link)
VSS ya hemos comentado que es un cluster de dos switches, pero claro, estos switches habrá que unirlos de alguna manera, a diferencia de un stack que se suele hacer con cables propietarios aquí la unión de los switches se hace mediante un VSL (Virtual Switch Link), que no es más que un etherchannel de puerto 10 o 40G, esto permite que los equipos que forman el VSS no tienen por qué estar juntos, personalmente no veo utilidad a separar los dos switches que forman en VSS, pero que sepáis que si la encontráis y os sirve podréis usarla.
El tráfico que pasa por el VSL está encapsulado con la cabecera VSH (Virtual Switch Header), algo que es interesante que sepáis más que nada porque la cabecera del VSH tiene una longitud de 32 bytes, por si tenéis que transmitir por unos 10G remotos que tengáis en cuenta el tamaño de la trama.
Una vez hayáis puesto los cables que van a formar el VSL tendréis que iniciarlizarlo, para esto entra en juego un protocolo llamado LMP (Link Management Protocol) que verifica que los enlaces sean correctos, intercambia el ID de los switches y luego la información necesaria para comunicar ambos chasis.
Después tendremos que comprobar que tanto software como hardware sea compatible para posteriormente decidir qué equipo será activo y cual backup para el plano de control del VSS.
Aquí entra un protocolo llamado RRP (Role Resolucion Protocol) que hace justamente eso, comprobar que todo sea compatible y seleccionar un switch activo y uno de standby.
Y en este punto es donde empieza la chicha del asunto porque las comprobaciones pueden ser correctas o no, si son correctas se inicializa todo y el swtitch entra en modo NSF/SSO (Nonstop Forwarding / Statefull Switchover), esto es lo bueno, pero si falla algo el VSS se queda en modo RPR (Route-Processor Redundancy) y todos los módulos se apagan. Aquí es donde puede haber un problema de verdad, cuando ves que se quedan los equipos en modo RPR, esto es lo que nunca vamos a querer ver y la primera vez que lo vemos queremos salir de ahí corriendo, pero realmente es porque hay algo mal configurado, sin más, lo único que tendremos que hacer es respirar y buscar las diferencias.
Redundancia del VSL
Seguramente os estéis dando cuenta que el VSL es una parte fundamental del VSS, realmente sin VSL no tendríamos sincronismo entre los planos de control de las dos procesadoras, además, sin VSL el VSS diretamente no arranca porque el SSO no podrá esblecerse en la vida, así que es fundamental la redundancia del VSL.
De hecho que sean dos cables o cuatro de VSL depende del número de controladoras que tengamos en cada switch. Realmente con una controladora por chasis es suficiente, y si sólo tenemos una controladora por chasis uniremos ambos chasis por un etherchannel de 2 cables.
Ahora, si tenemos dos procesadoras, usaremos un cable para unir la controladora 1 del switch 1 con la controladora 1 del swich 2 y otro con la controladora 2 y luego otro par de cables de la segunda controladora del primer switch con las dos del segundo, es decir, las controladoras conectadas a las dos del switch contrario y claro, esto son 4 cables. Esa es la razón por la que se usan 2 ó 4 cables para redundancia del VSL, dependiendo del número de controladoras de cada switch.
Como veis no es algo tan complicado entender el funcionamiento de un VSS, es algo para muchos nuevo y por tanto puede sonar desconocido, pero no es complicado, simplemente nuevo
Luego hay un tema que realmente no tiene que ver con el VSL, pero si que tiene que ver con el control de lo que llamamos dual active, que es un escenario en el que ambos switches que componen el VSS se quedan activos porque el VSL se ha caído completo, eso es malo muy malo y para evitarlo necesitamos mecanismos de detección.
Estos mecanismos son básicamente dos PAGP+ (enhanced PaGP), que es un protocolo propietario de Cisco y que solo por eso no me gusta y prefiero la opción del BFD que tiene una configuración un poco más larga, hablo de dos líneas más, pero que nos sirve igual.
Esto es algo que siempre hay que configurar en el primer etherchannel que se configure, bueno, y en el segundo y en el tercero.
Tanto PAGP+ como BFD nos permite identificar la situación de dual active en los switches.
Luego que no se me olvide hay una cosa llamada Fast Hello Detection, que se introdujo posteriormente, pero que yo nunca he usado, así que por eso no lo comento, sólo deciros que existe y que es otra opción que por lo que he visto se configura muy fácil.
Y en el caso que se detecte un dual active, ¿qué pasa? mmmm, pues se reinicia uno de ellos para volver a resinconizar, en principio no debería de pasar nada, pero no es una situación deseable.
De todos modos si os parece vamos a dedicar unos minutos a escenarios de fallos con VSS.
¿Qué pasa cuando falla la supervisora activa?
Aquí simplemente conmutará la supervisora al standby y ya está, si hubiera configurado preemtion en el momento de recuperar la rota volvería a ser la activa. Personalmente no creo que sea buena idea tener preemtion configurado ya que, por lo menos a mi, me gusta que cuando las cosas conmuten sin necesidad, sea conmigo delante por lo que pueda pasar. Y si usáis switches iguales no tiene demasiado sentido que uno sea el preferido, aunque he visto gente que pone un switch con preemtion porque está a la izquierda del otro cosas así que quizás no sean razones suficientes.
¿Qué pasa cuando falla un enlace del VSL?
Realmente nada, nos saldrá una alarma, miraremos el puerto, el cable y al recuperar el fallo, que lo normal sería que fuera un SFP roto lo cambiamos y a funcionar.
¿Qué pasa cuando falla un puerto que no es VSL?
Lo mismo que antes
¿Qué pasa cuando fallan todos los puertos que no son VSL?
Eso significa que fallan todos los puertos que no son de la procesadora, esta situación yo solo la he visto cuando el switch entra en modo RPR (Route-Processor Redundancy)