CCNP/JNCIS EN ESPAÑOL: Capítulo 6: Virtual Chassis

Virtual chassis nos ofrece la posibilidad de conectar dos o más switches EX para administrarlos como si fuera una sola unidad. El número máximo de dispositivos que podemos interconectar depende de los modelos de switch y la combinación entre ellos.

XRE: Re Externa

Cuando añadimos la XRE es está la encargada del proceso del Virtual Chassis. Si tenemos dos XRE, el master y el backup se elegirá a la que más tiempo lleve levantada (uptime).

En muchos entornos al agregar switches en Virtual Chassis se unen la capa de acceso y distribución.

Cuando montamos un Virtual Chassis, uno de los switches representa el rol de "Master RE" y un segundo switch como "Backup RE". Si tenemos redundancia de RE, podemos habilitar lo servicios NSR (nonstop active routing) y NSB (nonstop active bridging), que nos permite una conmutación transparente de master a backup y al revés, sin que se reinicien protocolos de capa 2.

RE: Routing Engine; LC: Line Card

Cuando conectamos switches en Virtual Chassis, las PFEs están conectadas a través de los VCP (Virtual Chassis Port), bien a través de una conexión interna o, cuando conectamos a través de los "uplink" (normalmente de 10 Gb). Las conexiones internas se habilitan por defecto, es decir, cuando conectamos en Virtual Chassis se crea el Virtual Chassis Backplane automáticamente.

Si queremos usar los uplink, tenemos que configurar en el equipo:

user@Switch-1> request virtual-chassis vc-port set pic-slot 1 port 0

El interfaz xe-0/1/0 se convierte a vcp-255/1/0

CABLEADO EN VIRTUAL CHASSIS

Método Daisy-Chained Ring

Máximo 5 metros de distancia del cable

Método Braided-Chained Ring

Máximo 22,5 metros de dsitancia del cable

Método Extended Ring

Máximo 100 km usando 1GBE o 10GBE

Otro factor importante a tener en cuenta es el lugar donde queda la RE en un Virtual Chassis. En caso de fallo no queremos que se produzca una interrupción en los servicios que comparten todos los switches. Para ello, el emplazamiento de la RE debería ser:

ELECCIÓN DE MASTER

El miembro con la prioridad configurada más alta (de 1 a 255, por defecto es 128)
El miembro que antes del reinicio funcionaba como master
El miembro que lleve más tiempo levantado (la diferencia debe ser de más de 1 min.)
El miembro con la dirección mac más baja (se usa para desempatar la elección)
El segundo miembro elegido por el árbol de Virtual Chassis será el miembro de backup. Los otros miembros son los llamados "line cards", es decir, solo miembros planos que se convertirán en backup si falla el master o el backup de ese momento.

El ID sirve también para identificar los números de los slots de los puertos

El número del miembro cuenta para la nomenclatura de las interfaces

A todos los miembros del Virtual Chassis se les asigna un ID del 0 al 9. Se puede asignar manualmente y dejar al Virtual Chassis que los elija, escogiendo siempre al 0 como master, que suele ser el primer switch que se enciende, y asigna los ID según vayan integrándose los miembros al Virtual Chassis. Hay que tener en cuenta que el ID se conserva incluso si se reinicia el switch.

Si queremos configurar manualmente:

> request virtual-chassis renumber member-id 0 new-member-id 5

Si queremos apagar un miembro en concreto:

> request system halt member 0-9

Si queremos acceder a un miembro individual:

> request session member 0-9

Cuando tenemos que sustituir un switch miembro del Virtual Chassis, el ID de este no se libera ni lo hereda el nuevo switch que instalemos. Los pasos recomendados por Juniper a la hora de reemplazar un switch miembro de un Virtual Chassis. Vamos al "master" y:

Reciclamos o liberamos el ID del equipo que quitamos
Añadimos el nuevo switch y automáticamente el nuevo coge el ID y la config del antiguo

Para ello:

> request virtual-chassis recycle member-id X

Cuando sustituimos un switch, el nuevo tiene que tener la misma versión de software. Si no la tiene, el master le asignará un ID, generará un mensaje de Syslog y lo dejará en estado inactivo. Si este es el caso, habría que actualizar el software antes de poder integrarlo en el Virtual Chassis.

Para la administración del Virtual Chassis tenemos una interfaz de administración (me0) y una dirección ip dedicadas. Esta interfaz está asociada a la "interface vlan vme".

Los switches en Virtual Chassis dan conectividad al master por la interfaz me0 física de cualquiera de los miembros. Siempre nos podremos conectar a los switches del chassis individualmente a través de conexiones vty con el comando

request session member X

ACTUALIZACIÓN DEL SOFTWARE

Se puede actualizar el software de todo el Virtual Chassis o de uno de los miembros. Siempre se hará desde el master:

> request system software add - para todo el chassis

> request system software add member X - para un miembro en concreto

El switch se puede actualizar manualmente, es decir, entramos en el switch y lo actualizamos o, podemos hacerlo automáticamente haciendo que el nuevo switch coja el software de los equipos miembros que ya forman el Virtual Chassis y de esta manera se integre inmediatamente en el chassis. A esto le llama Juniper el NSSU (nonstop software upgrade)

El NNSU tiene la capacidad de actualizar el software en el Virtual Chassis con una menor interrupción del servicio. Para poder habilitar NSSU el Virtual Chassis tiene que cumplir los siguientes requerimientos:

Los miembros tienen que estar conectados en anillo (ring)
Master y backup deben ser equipos adyacentes para asegurar la sincronización
Mismo software en todos los miembros
NSR y GRES (graceful routing engine switchover) estarán habilitados
Los line cards deben haber sido provisionados (configurados explícitamente)
Opcionalmente podemos habilitar NSB
Podemos hacer un backup previo de la config: request system snapshot

Cuando actualicemos 2 miembros de un Virtual Chassis usaremos la opción "no-split-detection" para evitar que los separe del Chassis.

Proceso para actualizar usando NSSU:

Bajamos el paquete de software
Copiamos el software en el switch master. Recomendado guardarlo en: /var/tmp
Entrar en el switch por consola o por la vme.
Iniciar el proceso NSSU que consiste en:

request system software nonstop-upgrade /var/tm/paquetedesoftware.tgz
Si tenemos un entorno mixto con diferentes modelos:

request system software nonstop-upgrade set [ /var/tm/paquete1.tgz /var/tm/paquete2.tgz]

Descubrimiento de la Topología

Virtual Chassis usa VCCP (Virtual Chassis Control Protocol) para descubrir la topología y asegurar que no haya bucles. Cada miembro del chassis envía LSA, mensajes de descubrimiento entre las PFE interconectadas. En base a estos mensajes se construye la topología de PFE's para determinar el mejor camino de comunicación entre las PFE.

Una vez creada la topología se ejecuta individualmente en cada PFE el algoritmo SPF. Este algoritmo se basa en el número de saltos y el ancho de banda. Al final cada PFE tendrá una tabla para llegar a las otras PFEs.

Para prevenir bucles se crea un ID fuente de salida para cada PFE

Ejemplo de descubrimiento de la topología. Es un proceso automático.

Flujo de intercambio de paquetes

Los paquetes escogen siempre el camino más corto a través de los miembros del Virtual Chassis.

Para configurar un Virtual Chassis:

#set virtual chassis...

Opciones de Virtual Chassis

También podemos configurar el GRES (graceful routing engine switchover):

#set chassis redundancy switch-over

Configuración dinámica:

Instalamos el switch que queremos que sea Master. Lo encendemos el primero, coge el ID 0 y le configuramos una prioridad de 255 (0-255, 128 es la de por defecto).
Instalamos el switch que queramos como backup. Conectamos los cables VC, lo encendemos, coge el ID 1 y le asignamos una prioridad de 255. Así nos aseguramos que cualquier otro switch que añadamos al VC, no tomará ni el rol de master ni el de backup.
Añadimos un Line Card Switch (switch que pertence al VC pero que no es master ni backup). Conectamos los cables VC. Dinámicamente se le asignará el ID 2
Repetimos el paso 3 hasta que instalamos el último LC Switch y conectamos los cables VC (uno cerrará el anillo y tendrá que conectarse con el master)

#set virtual-chassis member mastership-priority X

También podemos hacer una preprovisión, es decir, configuramos los roles de los switches antes de formar un Virtual Chassis. Para ello, configuramos el switch que queramos que tome el rol de master y le configuramos los roles de los switches que posteriormente encenderemos y añadiremos: