Understanting Virtual Switching Systems



Descargar 185.97 Kb.
Página1/3
Fecha de conversión26.04.2017
Tamaño185.97 Kb.
  1   2   3
Understanting Virtual Switching Systems.
VSS Overview.
Virtual Switching simplifica la red mediante la reducción del número de elementos de red y ocultar la complejidad de la gestión switches y enlaces redundantes.
Un VSS combina un par de Switches de la serie Catalyst 6500 en un único elemento de red. El VSS gestiona los enlaces redundantes, que actúan externamente como un único port chanel. El VSS simplifica la configuración de la red y la operación mediante la reducción del número de vecinos de enrutamiento de Capa 3 y proporcionando una topología de capa 2 de libre de loops.

Virtual Switching System.
Un switch de acceso se conecta a ambos chasis del VSS utilizando un port channel lógico. El VSS administra la redundancia y balanceo de carga en el port channel. Esta capacidad permite a una topología de Capa 2 de red libre de loops. El VSS también simplifica la topología de red de capa 3 porque el VSS reduce el número de peers de enrutamiento en la red.
c:\users\jorge_medina\desktop\evernote.enex_files\image.png
VSS Active and VSS Standby Chassis.
Al crear o reiniciar un VSS, el chasis peer negocia sus roles. Un chasis se convierte en el chasis activo de VSS, y el otro chasis se convierte en el VSS standby. El chasis activo VSS controla el VSS. Se ejecuta los protocolos de control de Capa 2 y Capa 3 para los módulos de switching en ambos chasis. El chasis activo VSS también proporciona funciones de gestión para la VSS, como la module online insertion and removal  (OIR) y la interfaz de la consola. El chasis VSS activo y VSS standby realizar el reenvío de paquetes para el tráfico de datos entrantes en su locally hosted interfaces. Sin embargo, el chasis VSS standby envía todo el tráfico de control al chasis VSS activo para su procesamiento.

Virtual Switch Link.
Para que los dos chasis del VSS actúen como un elemento de red, se necesita compartir información de control y tráfico de datos.
virtual switch link (VSL) es un enlace especial que lleva tráfico de control y tráfico de datos entre los dos chasis de un VSS, como se muestra en la figura. El VSL se implementa como Un Etherchannel con hasta ocho links. El VSL le da mayor prioridad al tráfico de control que al tráfico de datos para que los mensajes de control nunca sean descartados. El tráfico de datos se balancea la carga entre los enlaces VSL por el algoritmo de balanceo de carga del Etherchannel.  

c:\users\jorge_medina\desktop\evernote.enex_files\image [1].png

Al configurar VSL toda la configuración existentes en la interfaz es eliminado, excepto para los comandos específicamente permitidos. Al configurar VSL, el sistema pone a la interface en un modo restringido. Cuando una interfaz esta en modo restringido, solo los comandos de configuración específicos se pueden configurar en la interfaz. 


Multichassis EtherChannel.
Un EtherChannel (también conocido como Port Channel) es una colección de dos o más links físicos que se combinan para formar un link lógico. Protocolos de Capa 2 operan en el EtherChannel como una sola entidad lógica. A EtherChannel multichasis (MEC) es un port channel que se extiende por los dos chasis de un VSS. El switch de acceso ve el MEC como un port channel estándar. El VSS soporta un máximo de 512 EtherChannels. Este límite se aplica al total combinado de EtherChannels regulares y MEC. Debido  a que se requiere de dos Etnerchannel para VSL (uno para cada chasis), hay 510 EtherChannels configurables por el usuario. Si un módulo de servicio instalado utiliza un EtherChannel interno, ese EtherChannel se incluirá en el total.

c:\users\jorge_medina\desktop\evernote.enex_files\image [2].png

Redundancy and High Availability
En un VSS, supervisor engine redundancy opera entre el chassis VSS activo y VSS standby chassis, usando  Stateful Switchover (SSO) y Nonstop Forwarding (NSF). El peer chassis intercambia configuración e información de estado atravesé del VSL y la supervisora VSS Standby corre en hot VSS Standby mode. El chasis VSS Standby supervisa el chasis activo de VSS usando el VSL. Si detecta falla, el chasis VSS Standby, se inicia el Switchover y asume el role activo de VSS. Cuando el chasis se recupera de la falla, él toma el role de VSS Standby. Si el VSL falla completamente, el chasis VSS Standby asume que el chasis VSS activo ha fallado, e inicia una Switchover. Después de la transición, si los dos chasis son VSS activa, la función Dual-Active Detection  detecta esta condición y se inicia la acción de recuperación.
Packet Handling
El VSS utiliza VSL para comunicar el protocolo y la información del sistema entre los pares de chasis y para transportar el tráfico de datos entre los chasis cuando se requiera. Ambos chasis realizar el reenvío de paquetes para el tráfico de entrada en sus interfaces. Si es posible, el tráfico de entrada se envía a una interfaz de salida en el mismo chasis para minimizar el tráfico de datos que debe atravesar la VSL.
System Management
El VSS active supervisor engine actúa como un único punto de control para el VSS. Por ejemplo, VSS active supervisor engine maneja OIR de módulos switching en ambos chasis. El VSS active supervisor engine utiliza VSL para enviar mensajes hacia y desde los puertos locales en el VSS standby chassis. La command console en el VSS active supervisor engine se utiliza para controlar ambos chasis. En el modo de virtual switch mode, la consola de comandos en el VSS standby supervisor engine bloquea intenta entrar en modo de configuración.

Interface Naming Convention
En el modo de VSS, las interfaces se especifican mediante el número de switch (además de slot y puerto), debido a que los mismos números de slots se utilizan en ambos chasis. Por ejemplo, el comando de interfaz 1/5/4 específica el puerto 4 del módulo de conmutación en el slot 5 del switch 1. El comando de interfaz 2/5/4 específica el puerto 4 del switch module en el slot 5 del switch 2.
Software Features
En las versiones anteriores del software de Cisco IOS versión 12.2 (33) SXI, QoS basado en puertos y puertos (ACLs PACLs) sólo se admiten en la capa 2 (MEC) enlaces de un solo chasis o EtherChannel multichasis. Comenzando con Cisco IOS versión 12.2 (33) SXI, QoS y PACLs basadas en puertos se pueden aplicar a cualquier puerto físico en el VSS, con exclusión de los puertos de la VSL. PACLs se pueden aplicar a los puertos no hay más de 2046 en la de VSS.

c:\users\jorge_medina\desktop\evernote.enex_files\image [3].png

VSL Hardware Requirements.
El VSL EtherChannel solo soporta puertos 10 Gigabit Ethernet. Los puertos 10 Gigabit Ethernet puede ser localizado en el módulo de la supervisor engine o alguno de los switching modules.  Nosotros recomendamos que se usen ambos puertos 10 Gigabit Ethernet en el supervisor engines para crear el VSL entre los 2 chasises.  Se puede agregar links físicos adicionales al Etherchannel VSL usando puertos 10 Gigabit Ethernet en los switching modules.  

Understanding VSL Topology.
Un VSS contiene 2 chasises que se comunican usando el VSL, el cual es un grupo especial de puertos. Nosotros recomendamos que se configuren ambos puertos 10 Gigabit Ethernet en el supervisor engines como puertos VSL. Opcionalmente, se puede configurar también grupos de puertos 10 Gigabit Ethernet VSL contenidos en switching modules. Esta configuración provee capacidad adicional al VSL. 
c:\users\jorge_medina\desktop\evernote.enex_files\image [4].png

VSS Redundancy.
Overview.
Un VSS opera entre el VSS activo y el VSS standby supervisor engines en stateful switchover (SSO). Comparado con el modo standalone, el VSS tiene las siguientes diferencias importantes en el modelo de redundancia. 

  


  • El VSS activo y VSS standby supervisor engines son hosteados en chasises separados y usando el VSL para intercambiar información. 

  • El VSS activo supervisor engine controla ambos chasises del VSS. El VSS activo supervisor engine corre los protocolos de control de capa 2 y capa 3 y administra los switching modules en ambos chasises. 

  • El VSS activo y VSS standby chassis ambos realiza él envió de tráfico de datos. 

  • Si el VSS activo supervisor engine falla, el VSS standby supervisor engine inicia un switchover y asume que el rol de VSS activo. 


RPR and SSO Redundancy.
El VSS opera con redundancia stateful switchover (SSO) si cumple con los siguientes requisitos:

  


  • Ambas supervisor engines deben correr la misma versión de software.

  • La configuración relacionada con el VSL debe hacer match en los 2 chassis.  

  • PFC (Policy Feature Card) mode must match.

  • SSO y Nonstop Forwarding (NSF) deben ser configurado en cada chassis. 

Con redundancia SSO, el VSS standby supervisor engine siempre está dispuesto a asumir el control después de un fallo en el VSS Active supervisor engine. Configuración, envió, y la información de estado se sincronizan desde  el VSS active supervisor engine para la redundante supervisor engine en el arranque y siempre que se produzcan cambios en la configuración del VSS active supervisor engine. Si un switchover produce, la interrupción del tráfico se reduce al mínimo.


Si un VSS no cumple con los requisitos para SSO redundancia, el VSS utilizará route processor redundancy (RPR). En el modo de RPR, el VSS active supervisor engine  no sincroniza los cambios de configuración o información de estado con el VSS standby. El VSS standby supervisor engine es sólo parcialmente inicializado y los switching modules en el VSS standby supervisor no se enciende. Si se produce una switchover, el VSS standby supervisor engine finalice su inicialización y enciende los módulos de conmutación. El tráfico se interrumpe durante el tiempo de reinicio normal del chasis.
El VSS normalmente corre stateful switchover (SSO) entre el VSS activo y el VSS standby supervisor engines. El VSS determina el role de cada una de las supervisor engine durante la inicialización. El supervisor engine en el VSS standby chassis corre en Hot Standby state. El VSS usa el VSL link para sincronizar la configuración de datos desde el VSS activo al VSS Standby Supervisor Engine. También, protocolos y funcionalidades que soporten en alta disponibilidad sincronizan sus eventos y estados de información para el VSS Standby Supervisor Engine.  

c:\users\jorge_medina\desktop\evernote.enex_files\image [5].png
Failed Chassis Recovery.
Si el VSS Active chassis o Supervisor Engine falla, El VSS inicia el Stateful Switchover (SSO) y el VSS Standby supervisor engine formado asume el rol de VSS activo. El chassis en falla realiza acciones de recovery vía el reinicio de la supervisor engine. Si el VSS Standby chassis o Supervisor engine falla, no se requiere Switchover. El chassis falla realiza acciones de recovery vía reinicio de la supervisor engine. El link VSL no está disponible mientras que el chassis en falla se recupera. Este se convierte en el nuevo VSS Standby chassis y el VSS reinicializa el link VSL entre los 2 chassis. 
Los switching modules en el chassis falla se encuentra indisponibles durante el recovery, por lo que el VSS opera solo con los enlaces MEC que terminan en el VSS chassis activo. El ancho de banda del VSS es reducido mientras el chassis en falla competa el recovery y se vuelve operacional otra vez. Cualquier dispositivo que está conectado solo conectado en el chassis de falla experimentaría indisponibilidad. 
Después del SSO, mucho del poder de procesamiento del VSS Active Supervisor Engine es consumido en levantar un gran número de puertos simultáneamente en el VSS Standby Chassis. Como resultado, algunos links pueden ser levantados antes de que la supervisor engine este configurado para envió para los links,  causando tráfico a estos links para ser perdido hasta que la configuración este completa. Esta condición es especial disruptiva si el link es un MEC. Hay dos métodos disponibles para reducir el disruptivo de datos siguiendo un SSO: 

  


  • A partir de Cisco IOS versión 12.2 (33) SXH2, puede configurar el VSS para activar puertos no-VSL en grupos más pequeños durante un período de tiempo en lugar de todos los puertos de forma simultánea. Configuring Deferred Port Activation During VSS Standby Recovery 

  • Puede diferir el reparto de carga de los puertos miembros MEC del peer switch durante el restablecimiento de las conexiones de los puertos. Failed Chassis MEC Recovery.


VSL Failure.
Para asegurar la rápida recuperación de una falla de VSL, fast link notification es habilitado en modo vritual switch on todos los miembros de port channel (incluyendo puertos VSL) cuyo hardware admite la notificación de conexión rápida. Si un solo link físico VSL esta indisponible, el VSS ajusta el port group para que el link con falla no sea seleccionado. Si el chassis VSS Standby detecta una falla completa del link VSL, este iniciara un Stateful Switchover (SSO). Si el chassis VSS activo tiene una falla (Causando que el link VSL este indisponible), el escenario es una falla de chassis, como los describimos en la sección previa.  Si solo se tiene una falla con el VSL y el chassis VSS Activo continua en operación, este es un escenario dual-active. El VSS detecta que ambos chassis esta operativos en modo VSS activo y realizan acciones de recovery.

User Actions.
Desde  la consola de comandos del chassis VSS activo, se puede iniciar el Switchover o reiniciar el VSS. Si se ingresa el comando reload desde la consola de comando, el VSS entero realiza un reinicio, para reiniciar solo el chassis VSS Standby, se emplea el comando redundancy reload peer. Para forzar el switchover desde el VSS activo al VSS Standby Supervisor engine, use el comando redundancy force-switchover.  Para reset de la VSS Standby Supervisor engine o para reset de ambos VSS Active y Vss Standby Supervisor Engine, use el comando redundancy reload shelf. 

Multichassis EtherChannels.
Overview
Un mutichassis Etherchannel es un Etherchannel con puertos terminados en ambos chassis del VSS. Un VSS MEC puede conectar cualquier elemento de la red que soporte Etherchannel (Como son host, servers, routers o Switches). En el VSS, el MEC es un Etherchannel con capacidades adicionales: El VSS balancea la carga atravesé del puerto en cada chassis independientemente. Por ejemplo, si el tráfico entra al Chassis VSS Active, el VSS selecciona un link del MEC del Chassis VSS Activo. Esta capacidad del MEC asegura que el tráfico de datos no atraviese innecesariamente el VSL. Cada MEC puede opcionalmente ser configurado para soportar PAgP o LACP. Estos protocolos corren solo en el Chassis VSS activo.  Los paquetes de control de PAgP o LACP destinados a un  link MEC en el Chassis VSS Standby serán enviados atravesé del VSL. Un MEC puede soportar hasta 8 enlaces VSS físicos activos, los cuales pueden ser distribuidos en cualquier porción entre los chassis VSS active y VSS Standby.  

c:\users\jorge_medina\desktop\evernote.enex_files\image [6].png


MEC Failure Scenarios.
Nosotros recomendamos que la configuración del MEC con al menos un Link en cada chassis. Esta configuración conserva el ancho de banda del VSL (El tráfico de salida en el mismo chassis que el trafico entrante), e incrementa la disponibilidad de la red (Si una VSS Supervisor Engine falla, el MEC continuará operando). 

Single MEC Link Failure
Si un link dentro del MEC falla (y otro enlace en el MEC continua operacional), El MEC redistribuye la carga entre los enlaces operacionales, como en un puerto regular. 

All MEC Links to the VSS Active Chassis Fail
Si todos los enlaces al Chassis VSS Active falla, el MEC se convierte en un Etherchannel regular con links operacionales al chassis VSS Standby. Tráfico de datos en el chassis VSS active llegan al MEC cruzando el VSL al chassis VSS Standby. Los protocolos de control continúan corriendo en el chassis VSS Active. Los Protocol messages alcazar el MEC cruzado el VSL. 
All MEC Links to the VSS Standby Chassis Fail
Si todos los enlaces al chassis VSS Standby falla, el MEC se convierte en un Etherchannel regular con links operacionales al chassis VSS Active. Los protocolos de control continuando corriendo en el chassis VSS Active. Todo el tráfico de control y el tráfico de datos desde el chassis VSS Standby alcanzan el MEC cruzando el VSL al chassis VSS Active.  

All MEC Links Fail.
Si todos los link en un MEC falla, la interfaz lógica para la EtherChannel se establece como no disponible. Los protocolos de control de capa 2 realizan la misma acción de corrección como si se tratara de un evento de la caída de una enlace regular Etherchannel. En los interruptores adyacentes, los protocolos de ruteo y Spanning Tree (STP) realizan algunas acciones correctivas como para un Etherchannel regular. 
VSS Standby Chassis Failure.
Si el chassis VSS Standby falla, el MEC se convierte en un Etherchannel regular con links operacionales en el chassis VSS activo. Switches peer conectados detectan los fallos de enlace, y ajustan su algoritmo de balanceo de cargas para usar solo los enlaces al chassis VSS active. 
VSS Active Chassis Failure.
El chassis VSS active falla resulta en un Stateful Switchover (SSO). Después del Switchover, el MEC es operacional en el nuevo chassis VSS Active. Switches peer conectados detectan la falla, y ajustan su algoritmo de balanceo de carga para usar solo los enlaces al Chassis VSS Active. 

Failed Chassis MEC Recovery.
Cuando un chassis regresa de una falla a servicios como nuevo VSS Standby chassis, mensajes de protocolo restablecen los links MEC entre el chassis recuperado y los switches peer conectados. Aunque los links MEC del chassis recuperado están listos para recibir trafico unicast inmediatamente desde los switches peer, el trafico multicast recibido puede ser perdido por un periodo de algunos segundos o por algunos minutos. Para reducir esta perdida, se puede configurar la funcionalidad de load share deferral del puerto en el MEC port channel del switch peer. Cuando load share deferral es configurado, los MEC port channels deferred del peer se establecerán  con un inicial load share de 0. Durante la configuración de intervalo deferral ( deferral interval), el port channel deferred del peer es capaz de recibir datos y control de tráfico, y enviar tráfico de control, pero es incapaz de enviar tráfico de datos al VSS. 

Packet Handling.
Ambos chassis realizan él envió de paquetes de tráfico de ingreso en sus interfaces locales. El VSS minimiza la cantidad de tráfico que debe atravesar el VSL. 
Traffic on the VSL.
El VSL carga con tráfico de datos y tráfico de control in-band entre los 2 chassis. Todas las frames enviadas sobre el link VSL son encapsuladas con un header especial de 32-bytes, el cual provee de información al VSS para enviar los paquetes al chassis peer. 
El VSS necesita transmitir tráfico de datos sobre el VSL bajo las siguientes circunstancias:

  


  • EL tráfico de capa 2 que inundo una VLAN (incluso para los enlaces dual-home).

  • Paquetes que son procesados por software en el VSS active supervisor engine en donde el tráfico de ingreso está en el chassis VSS standby. 

El destino de los paquetes es en el chassis peer, tales como los siguientes ejemplos:

  


  • Trafico dentro de un VLAN donde la interfaces destino conocida se encuentra en el peer chassis. 

  • Trafico que es replicado a un grupo de multicast y los receptores del multicast se encuentra en el peer chassis.

  • La dirección Mac addres del destino conocido unicast está en el peer chassis.

  • Le paquetes es una frame con MAC notificada en un puerto en el peer chassis.

El VSL también trasporta datos de sistema, como son NetFlow export Data y datos de SNMP, desde el chassis VSS Standby al VSS active supervisor engine. 


Para preservar el ancho de banda del VSL para funciones críticas, el VSS usa una estrategia para minimizar el tráfico de datos del usuario atraviese el VSL. Por ejemplo, si el switch de acceso esta

En dual-home (Que se encuentran adjuntos con una terminación MEC en ambos chassis VSS), El VSS transmite los paquetes del switch de acceso usando el link en el mismo chassis como link de ingreso. El tráfico en el VSL es load balanced con el  mismo algoritmo de hashing disponible para los Etherchannels (El algoritmo default es source-destination IP).



Layer 2 Protocols.

El VSS active supervisor engine corre los protocolos de capa 2 (como son STP y VTP) para los módulos de switching en ambos chassis. Los mensajes de protocolo que son trasmitidos y recibidos en el VSS Standby chassis switching modules debe atravesar el VSL para alcanzar el VSS Active Supervisor engine. 



Spanning Tree Protocol.
El VSS active chassis corre el protocolo Spanning Tree (STP). El VSS Standby chassis redirección los BPDUs de STP atravesé del VSL al VSS active chassis. El STP bridge ID es comúnmente deriva de la dirección MAC del chasis. Para asegurar que el bridge ID no sea cambiado después de un Switchover, El VSS continua usando la MAC address original para el STP Bridge ID. 

Virtual Trunk Protocol
Virtual Trunk Protocol (VTP) utiliza la dirección IP del switch y la hora local para el control de versiones en los anuncios. Después de un switchover, VTP usa la dirección IP del nuevo VSS active chassis. 
EtherChannel Control Protocols.
Link Aggregation Control Protocol (LACP) y Port Aggregation Protocol (PAgP) contiene en sus paquetes un identificador de dispositivo. El VSS define un identificador de dispositivo común para identificar ambos chassis en uso.  Una nueva mejora PAgP ha sido definida para ayudar en la detección del escenario Dual-Active detection. 

Layer 3 Protocols.
El MSFC en el VSS active supervisor engine corre los protocolos de capa 3 y sus funcionalidades del VSS. Ambos chassis realizan envió de paquetes de trafico de ingreso en sus interfaces. Si es posible, el tráfico de ingreso es enviado a una interfaces de salida en el mismo chassis, para minimizar el tráfico de datos tenga que atravesar el VSL. Por qué el VSS Standby chassis esta activamente enviando tráfico, el VSS active Supervisor engine distribuye actualizaciones al VSS Standby supervisor engine PFC y a todos los DFCs del VSS standby chassis. 
IPv4.
Las actualizaciones de ruteo se reciben en el VSS Standby chassis son re direccionadas al VSS active Chassis atravesé del VSL. Todo el hardware rounting usa la dirección MAC addres asignada por el VSS active supervisor engine. Después de un switchover, la mac address original se continúa usando. En Virtual Switching Mode, el requerimiento para soportar non-stop forwarding (NSF) son los mismos que en modo standalone. Desde la perspectiva del peer de ruteo, los etherchannels se mantiene operacionales durante un switchover (Solo fallan los links al chassis que se encuentra abajo).  El VSS implementa paths filtring almacenando solo los paths locales (Paths que no atraviesan el VSL) en las entradas del FIB. Por lo tanto, el Ip forwarding realiza una compartir de carga atravesé de los paths locales. Si no hay un path local disponible a un destino, El VSS actualiza la entrada de FIB para incluir los remote paths (Alcanzables atravesé del VSL).
  1   2   3


La base de datos está protegida por derechos de autor ©bazica.org 2016
enviar mensaje

    Página principal