¿Tiene una cuenta?
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe algunas de las características del clúster nV del ASR 9000 y cómo decluster.
El procedimiento se probó en un entorno real con clientes de Cisco que ya han decidido el proceso de desclusión explicado en este documento.
Cisco recomienda que tenga conocimiento sobre estos temas:
La información en este documento se basa en la plataforma ASR 9000 que ejecuta IOS XR 5.x.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Product Business Unit (BU) anunció el fin de venta (EOS) para nV Cluster en la plataforma ASR 9000: Anuncio de fin de venta y fin del ciclo de vida del clúster de Cisco nV
Como puede leer en el anuncio, el último día para pedir este producto es el 15 de enero de 2018, y la última versión admitida para el clúster nV es IOS-XR 5.3.x.
Los hitos que deben tenerse en cuenta se enumeran en esta tabla:
El objetivo de esta sección es proporcionar una breve actualización de las configuraciones de clúster y los conceptos necesarios para comprender las siguientes secciones de este documento.
El canal Ethernet fuera de banda extiende el plano de control entre los dos chasis ASR9k y, idealmente, consta de 4 interconexiones que crean una malla entre el Procesador de switch de ruta (RSP) de diferentes chasis. Esta configuración proporciona redundancia adicional en caso de falla del link EOBC. El protocolo de detección de enlaces unidireccionales (UDLD) garantiza el reenvío de datos bidireccional y detecta rápidamente las fallas de los enlaces. El mal funcionamiento de todos los links EOBC afecta seriamente al sistema de clúster y puede tener consecuencias graves que se presentan más adelante en la sección Escenarios de nodos divididos.
Los Inter Rack Links amplían el plano de datos entre los dos chasis ASR9k. Lo ideal es que sólo los paquetes de inserción de protocolo y de inserción de protocolo atraviesen el IRL, excepto los servicios de enlace único, o durante fallas de red. En teoría, todos los sistemas finales están doblemente conectados con un enlace a ambos chasis ASR9K. Al igual que los links EOBC, el UDLD se ejecuta sobre el IRL así como para monitorear el estado de reenvío bidireccional de los links.
Se puede definir un umbral IRL para evitar que el IRL congestionado descarte paquetes en caso de falla de LC, por ejemplo. Si el número de links IRL cae por debajo del umbral configurado para ese chasis, todas las interfaces del chasis se desactivan y desactivan por error. Básicamente, esto aísla el chasis afectado y garantiza que todo el tráfico fluye a través del otro chasis.
Nota: La configuración predeterminada es equivalente a nv edge data minimum 1 backup-rack-interfaces, lo que significa que si no hay IRL en el estado de reenvío, se aísla la copia de seguridad Designated Shelf Controller (DSC).
En esta subsección puede encontrar los diferentes escenarios de falla que se pueden encontrar al tratar con los clústeres ASR9k:
Este es el único escenario de nodo dividido que se puede esperar durante la desclusión, o si uno de los chasis cae por debajo del umbral IRL y se aísla como consecuencia.
Los dos chasis del ASR9k no pueden actuar como uno sin el plano de control extendido proporcionado por los links EOBC. Hay señales periódicas que se intercambian a través de los links IRL, de modo que cada chasis es consciente de que el otro chasis está activo. Como consecuencia, uno de los chasis, normalmente el chasis con el DSC de respaldo, se retira del servicio y se reinicia. El chasis Backup-DSC permanece en el loop de inicio mientras recibe las balizas del chasis Primary-DSC sobre el IRL.
En el escenario Split Brain, los links IRL y EOBC se han caído y cada chasis se declara como Primary-DSC. Los dispositivos de red vecinos de repente ven ID de router duplicadas para IGP y BGP que pueden causar problemas graves en la red.
Muchos clientes utilizan los paquetes en el extremo y el núcleo para simplificar la configuración del clúster ASR9K y facilitar el aumento del ancho de banda en el futuro. Esto podría causar problemas al descluir debido a que diferentes miembros del paquete se conectan a diferentes chasis. Estos enfoques son posibles:
La división del clúster podría separar potencialmente el dominio L2 si no hay switch en el acceso que interconecta los dos chasis independientes. Para evitar el tráfico de agujero negro, debe ampliar el dominio L2 que se puede hacer si configura las conexiones locales L2 en la IRL anterior, los pseudo-cables (PW) entre el chasis o si utiliza cualquier otra tecnología de red privada virtual de capa 2 (L2VPN). A medida que la topología de dominio de bridge cambia con la desclustering, tenga en cuenta la posible creación de loop cuando seleccione la tecnología L2VPN elegida.
Es probable que el routing estático en el acceso hacia una interfaz de interfaz virtual de grupo de bridges (BVI) en el clúster ASR9K se convierta en una solución basada en el protocolo de router en espera activo (HSRP) que utilice la dirección IP de BVI anterior como IP virtual.
Los servicios de un solo inicio tienen un tiempo de inactividad prolongado durante el procedimiento de desclusión.
Durante el proceso de desclusión, hay poco tiempo en el que ambos chasis se aíslan, al menos cuando se pasa del routing estático (BVI) al routing estático (HSRP) para no tener un routing inesperado y asimétrico.
Debe comprobar cómo funciona el acceso a la administración de la consola y fuera de banda antes de bloquearse.
Suponga que en el estado inicial, el chasis 0 está activo, mientras que el chasis 1 es de respaldo (por razones de simplicidad). En la vida real, podría ser al revés o incluso RSP1 en el chasis 0 podría estar activo.
1. Verifique la ubicación del chasis Primary - Backup (Primario - Copia de seguridad). En este ejemplo, el chasis principal es 0:
RP/0/RSP0/CPU0:Cluster(admin)# show dsc --------------------------------------------------------- Node ( Seq) Role Serial# State --------------------------------------------------------- 0/RSP0/CPU0 ( 1279475) ACTIVE FOX1441GPND PRIMARY-DSC <<< Primary DSC in Ch1 0/RSP1/CPU0 ( 1223769) STANDBY FOX1432GU2Z NON-DSC 1/RSP0/CPU0 ( 0) ACTIVE FOX1432GU2Z BACKUP-DSC 1/RSP1/CPU0 ( 1279584) STANDBY FOX1441GPND NON-DSC
2. Verifique que todas las tarjetas de línea (LC)/RSP estén en el estado "IOS XR RUN":
RP/0/RSP0/CPU0:Cluster# sh platform Node Type State Config State ----------------------------------------------------------------------------- 0/RSP0/CPU0 A9K-RSP440-TR(Active) IOS XR RUN PWR,NSHUT,MON 0/RSP1/CPU0 A9K-RSP440-TR(Standby) IOS XR RUN PWR,NSHUT,MON 0/0/CPU0 A9K-MOD80-SE IOS XR RUN PWR,NSHUT,MON 0/0/0 A9K-MPA-4X10GE OK PWR,NSHUT,MON 0/0/1 A9K-MPA-20X1GE OK PWR,NSHUT,MON 0/1/CPU0 A9K-MOD80-TR IOS XR RUN PWR,NSHUT,MON 0/1/0 A9K-MPA-20X1GE OK PWR,NSHUT,MON 0/2/CPU0 A9K-40GE-E IOS XR RUN PWR,NSHUT,MON 1/RSP0/CPU0 A9K-RSP440-TR(Active) IOS XR RUN PWR,NSHUT,MON 1/RSP1/CPU0 A9K-RSP440-SE(Standby) IOS XR RUN PWR,NSHUT,MON 1/1/CPU0 A9K-MOD80-SE IOS XR RUN PWR,NSHUT,MON 1/1/1 A9K-MPA-2X10GE OK PWR,NSHUT,MON 1/2/CPU0 A9K-MOD80-SE IOS XR RUN PWR,NSHUT,MON 1/2/0 A9K-MPA-20X1GE OK PWR,NSHUT,MON 1/2/1 A9K-MPA-4X10GE OK PWR,NSHUT,MON
El chasis en espera es el chasis con el BACKUP-DSC y se retira del servicio y se desagrupa primero. En este ejemplo, el BACKUP-DSC se encuentra en el chasis 1.
Con esta configuración, si el número de IRL cae por debajo del umbral mínimo configurado (1 en este caso), todas las interfaces en el rack especificado (rack de respaldo - chasis 1 en este caso) se apagan:
RP/0/RSP0/CPU0:Cluster(admin-config)# nv edge data min 1 spec rack 1 RP/0/RSP0/CPU0:Cluster(admin-config)# commit
1. Cierre todas las IRL existentes. En este ejemplo, puede ver un apagado manual de la interfaz en ambos chasis (activo Ten0/x/x/x y en espera Ten1/x/x/x):
RP/0/RSP0/CPU0:Cluster(config)# interface Ten0/x/x/x shut interface Ten0/x/x/x shut […] interface Ten1/x/x/x shut interface Ten1/x/x/x shut […] commit
2. Verifique que todos los IRL configurados estén inactivos:
RP/0/RSP0/CPU0:Cluster# show nv edge data forwarding location
Un ejemplo de <location> es 0/RSP0/CPU0.
Después de un apagado de todo IRL, el chasis 1 debe estar completamente aislado del plano de datos al mover todas las interfaces externas al estado inhabilitado por error.
3. Verifique que todas las interfaces externas en el chasis 1 estén en estado err-disabled y que todo el tráfico fluya a través del chasis 0:
RP/0/RSP0/CPU0:Cluster# show error-disable
1. Cierre los links EOBC en todos los RSPs:
RP/0/RSP0/CPU0:Cluster(admin-config)# nv edge control control-link disable 0 loc 0/RSP0/CPU0 nv edge control control-link disable 1 loc 0/RSP0/CPU0 nv edge control control-link disable 0 loc 1/RSP0/CPU0 nv edge control control-link disable 1 loc 1/RSP0/CPU0 nv edge control control-link disable 0 loc 0/RSP1/CPU0 nv edge control control-link disable 1 loc 0/RSP1/CPU0 nv edge control control-link disable 0 loc 1/RSP1/CPU0 nv edge control control-link disable 1 loc 1/RSP1/CPU0 commit
2. Verifique que todos los links EOBC estén inactivos:
RP/0/RSP0/CPU0:Cluster# show nv edge control control-link-protocols location 0/RSP0/CPU0
Después de este paso, el chasis de clúster se aísla completamente entre sí en términos de control y plano de datos. El chasis 1 tiene todos sus links en el estado err-disable.
Nota: A partir de ahora, las configuraciones deben realizarse en el chasis 1 a través de la consola RSP y solo afectan al chasis local.
Borre la configuración existente en el chasis 1:
RP/1/RSP0/CPU0:Cluster(config)# commit replace RP/1/RSP0/CPU0:Cluster(admin-config)# commit replace
Nota: Debe reemplazar primero la configuración para la configuración en ejecución y sólo después borrar la configuración en ejecución del administrador. Esto se debe al hecho de que la eliminación del umbral IRL en la configuración de ejecución del administrador "no shut" todas las interfaces externas. Esto podría causar problemas debido a ID de router duplicadas, etc.
1. Configure el registro de configuración para arrancar en ROMMON:
RP/1/RSP0/CPU0:Cluster(admin)# config-register boot-mode rom-monitor location all
2. Verifique las variables de inicio:
RP/1/RSP0/CPU0:Cluster(admin)# show variables boot
3. Recargue ambos RSP del chasis 1:
RP/1/RSP0/CPU0:Cluster# admin reload location all
Después de este paso, normalmente, el chasis 1 se inicia en ROMMON.
Advertencia: El técnico de campo debe quitar todos los enlaces EOBC antes de continuar.
Consejo: También hay una alternativa para establecer las variables de clúster del sistema. Consulte la sección Apéndice 2: Establezca la variable de clúster sin arrancar el sistema en rommon.
1. El procedimiento estándar requiere conectar el cable de la consola al RSP activo en el chasis 1 y desconfigurar y sincronizar la variable ROMMON del clúster:
unset CLUSTER_RACK_ID sync
2. Restablecer los registros de configuración a 0x102:
confreg 0x102 reset
El RSP activo está configurado.
3. Conecte el cable de la consola al RSP en espera del chasis 1. Lo ideal es que los 4 RSPs del clúster tengan acceso a la consola durante la ventana de mantenimiento.
Nota: Las acciones descritas en este paso deben realizarse en ambos RSP del chasis 1. El RSP activo debe iniciarse primero.
Lo ideal es que la nueva configuración o varios fragmentos de configuración se almacenen en cada chasis ASR9k y se carguen después de la desclusión. La sintaxis de configuración correcta se debe probar previamente en el laboratorio. Si no es así, configure primero las interfaces de consola y MGMT, antes de completar la configuración en el chasis 1 mediante copiar y pegar en Virtual Teletype (VTY) o cargue la configuración remotamente desde un servidor TFTP.
Nota: los comandos load config y commit mantienen todas las interfaces apagadas, lo que permite una rampa de servicio controlada. load config y commit replace, reemplaza por completo la configuración y activa las interfaces. Por lo tanto, se recomienda utilizar la configuración de carga y commit.
Adapte la configuración de los sistemas finales conectados (FW, switches, etc.) y los dispositivos de núcleo (P, PE, RR, etc.) al chasis 1.
Advertencia: Tenga en cuenta los temporizadores como el bit de sobrecarga de ISIS (OL), el retraso de HSRP, el retraso de actualización de BGP, etc. antes de pasar a la conmutación por error.
Precaución: Los siguientes pasos provocan la interrupción del servicio. Las interfaces descendentes del chasis 1 siguen desactivadas, mientras que el chasis 0 está aislado
El tiempo de espera predeterminado es igual a 180s (3x60s) y representa el peor caso para la convergencia de BGP. Hay varias opciones de diseño y funciones BGP que permiten un tiempo de convergencia mucho más rápido, como el Seguimiento de Siguiente Salto BGP. Suponga que hay diferentes proveedores de terceros 3 presentes en el núcleo que se comportan de manera diferente que Cisco IOS XR, usted necesita acelerar la convergencia BGP manualmente con un cierre de software de los vecindarios BGP entre el chasis 0 y el RR, o similar, antes de activar la conmutación por fallas:
RP/0/RSP0/CPU0:Cluster(admin-config)# nv edge data minimum 1 specific rack 0 RP/0/RSP0/CPU0:Cluster(admin-config)# commit
Dado que todos los IRL están inactivos, el chasis 0 debe estar aislado y todas las interfaces externas deben moverse al estado error-disabled.
Verifique que todas las interfaces externas en el chasis 0 estén en el estado err-disabled:
RP/0/RSP0/CPU0:Cluster# show error-disable
El chasis 1 se ha reconfigurado como una caja independiente, por lo que no debe haber ninguna interfaz err-disabled. Lo único que queda por hacer en el chasis 1 es activar las interfaces en el perímetro.
1. no shut all access interfaces.
Mantenga el enlace de interconexión (IRL anterior) en modo apagado por ahora.
2. Verifique las adyacencias/peerings/DB de IGP y BGP. Mientras los IGP y BGP convergen, usted espera ver alguna pérdida de tráfico en sus pings desde el PE remoto.
Borre la configuración existente en el chasis activo:
RP/0/RSP0/CPU0:Cluster(config)# commit replace RP/0/RSP0/CPU0:Cluster(admin-config)# commit replace
Nota: primero debe reemplazar la configuración para la configuración en ejecución y sólo después borrar la configuración en ejecución del administrador. Esto se debe al hecho de que eliminar el umbral IRL en la configuración de ejecución del administrador no cierra todas las interfaces externas. Esto podría causar problemas debido a ID de router duplicadas, etc.
1. Configure el registro de configuración para arrancar en ROMMON:
RP/0/RSP0/CPU0:Cluster(admin)# config-register boot-mode rom-monitor location all
2. Verifique las variables de inicio:
RP/0/RSP0/CPU0:Cluster# admin show variables boot
3. Recarga ambos RSP del chasis en espera:
RP/0/RSP0/CPU0:Cluster# admin reload location all
Después de este paso, normalmente, el chasis 0 se inicia en el modo ROMMON.
1. Conecte el cable de la consola al RSP activo en el chasis 0.
2. Variable ROMMON de clúster no establecida y sincronizada:
unset CLUSTER_RACK_ID sync
3. Restablecer los registros de configuración a 0x102:
confreg 0x102 reset
El RSP activo está configurado.
4. Conecte el cable de la consola al RSP en espera en el chasis 0.
Nota: Las acciones descritas en este paso deben realizarse en ambos RSP del chasis 1. El RSP activo debe iniciarse primero.
Lo ideal es que la nueva configuración o varios fragmentos de configuración se almacenen en cada chasis ASR9k y se carguen después de la desclusión. La sintaxis de configuración correcta se debe probar previamente en el laboratorio. Si no es así, configure primero las interfaces de consola y MGMT, antes de completar la configuración en el chasis 0 a través de VTY (copiar y pegar) o cargue la configuración remotamente desde un servidor TFTP.
Nota: los comandos load config y commit mantienen todas las interfaces apagadas, lo que permite una rampa de servicio controlada. load config y commit replace, reemplaza por completo la configuración y activa las interfaces. Por lo tanto, se recomienda utilizar la configuración de carga y commit.
Adapte la configuración de los sistemas finales conectados (FW, switches, etc.) y los dispositivos de núcleo (P, PE, RR, etc.) al chasis 0.
Advertencia: Tenga cuidado con temporizadores como ISIS OL-Bit, HSRP delay, BGP Update delay, etc. antes de pasar a la conmutación por fallas.
1. no shut all access interfaces.
2. Verifique las adyacencias/peerings IGP y BGP/DB
3. Asegúrese de que el enlace entre chasis (IRL anterior) esté habilitado, si es necesario para la extensión L2, etc.
Esta configuración del router debe modificarse en uno de los chasis:
Asegúrese de que todos los paquetes se revisan y aplican a la nueva configuración PE dual. Tal vez ya no necesite paquetes y los dispositivos duales de alojamiento en las instalaciones del cliente (CPE) se adapten a su configuración o necesita MCLAG en los dispositivos PE y mantener los paquetes hacia CPE.
También hay una alternativa para establecer las variables de clúster. Las variables de clúster se pueden configurar por adelantado mediante este procedimiento:
RP/0/RSP0/CPU0:xr#run Wed Jul 5 10:19:32.067 CEST # cd /nvram: # ls cepki_key_db classic-rommon-var powerup_info.puf sam_db spm_db classic-public-config license_opid.puf redfs_ocb_force_sync samlog sysmgr.log.timeout.Z # more classic-rommon-var PS1 = rommon ! > , IOX_ADMIN_CONFIG_FILE = , ACTIVE_FCD = 1, TFTP_TIMEOUT = 6000, TFTP_CHECKSUM = 1, TFTP_MGMT_INTF = 1, TFTP_MGMT_BLKSIZE = 1400, TURBOBOOT = , ? = 0, DEFAULT_GATEWAY = 127.1.1.0, IP_SUBNET_MASK = 255.0.0.0, IP_ADDRESS = 127.0.1.0, TFTP_SERVER = 127.1.1.0, CLUSTER_0_DISABLE = 0, CLUSTERSABLE = 0, CLUSTER_1_DISABLE = 0, TFTP_FILE = disk0:asr9k-os-mbi-5.3.4/0x100000/mbiasr9k-rp.vm, BSS = 4097, BSI = 0, BOOT = disk0:asr9k-os-mbi-6.1.3/0x100000/mbiasr9k-rp.vm,1;, CLUSTER_NO_BOOT = , BOOT_DEV_SEQ_CONF = , BOOT_DEV_SEQ_OPER = , CLUSTER_RACK_ID = 1, TFTP_RETRY_COUNT = 4, confreg = 0x2102 # nvram_rommonvar CLUSTER_RACK_ID 0 <<<<<<< to set CLUSTER_RACK_ID=0 # more classic-rommon-var PS1 = rommon ! > , IOX_ADMIN_CONFIG_FILE = , ACTIVE_FCD = 1, TFTP_TIMEOUT = 6000, TFTP_CHECKSUM = 1, TFTP_MGMT_INTF = 1, TFTP_MGMT_BLKSIZE = 1400, TURBOBOOT = , ? = 0, DEFAULT_GATEWAY = 127.1.1.0, IP_SUBNET_MASK = 255.0.0.0, IP_ADDRESS = 127.0.1.0, TFTP_SERVER = 127.1.1.0, CLUSTER_0_DISABLE = 0, CLUSTERSABLE = 0, CLUSTER_1_DISABLE = 0, TFTP_FILE = disk0:asr9k-os-mbi-5.3.4/0x100000/mbiasr9k-rp.vm, BSS = 4097, BSI = 0, BOOT = disk0:asr9k-os-mbi-6.1.3/0x100000/mbiasr9k-rp.vm,1;, CLUSTER_NO_BOOT = , BOOT_DEV_SEQ_CONF = , BOOT_DEV_SEQ_OPER = , TFTP_RETRY_COUNT = 4, CLUSTER_RACK_ID = 0, confreg = 0x2102 #exit RP/0/RSP0/CPU0:xr#
Recargue el router y lo inicia como una caja independiente. Con este paso, puede saltar para iniciar el router desde ROMMON.