Procedimiento del decluster ASR 9000 nanovoltio

Introducción

Este documento describe algunas de las características del cluster nanovoltio del ASR 9000 y cómo al decluster.

El procedimiento fue probado en el entorno real con los clientes de Cisco que han decidido ya para el proceso declustering explicado en este documento.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• IOS XR
• Plataforma ASR 9000
• característica del cluster nanovoltio

Componentes Utilizados

La información en este documento es plataforma basada del onASR 9000 que ejecuta IOS XR 5.x.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

La unidad comercial del producto (BU) anunció el Fin de la Venta (EOS) para el cluster nanovoltio en la plataforma ASR 9000: El Fin de la Venta y el anuncio de fin de vida útil para Cisco nanovoltio agrupan

Como usted puede leer adentro el aviso, el día más pasado para pedir este producto es de enero el 15 de 2018, y la versión admitida más reciente para el cluster nanovoltio es IOS-XR 5.3.x.

Los jalones a ser conscientes de se enumeran en esta tabla:

Fundamentales y consideraciones del cluster ASR9k nanovoltio

La meta de esta sección es proporcionar una descripción restaura en las configuraciones y los conceptos del cluster necesarios entender las siguientes secciones de esto documento.

Ethernetes fuera del canal de la banda (EOBC)

El Ethernet fuera del canal de la banda amplía el avión del control entre los dos chasis ASR9k y consiste en idealmente 4 interconecta que construyan una malla entre el Route Switch Processor (RSP) de diverso chasis. Esta configuración proporciona la Redundancia adicional en caso de la falla de link EOBC. El Unidirectional Link Detection Protocol (UDLD) asegura el reenvío de datos bidireccional y detecta rápidamente las fallas de link. El malfuncionamiento de todo el EOBC conecta afecta seriamente al sistema del cluster y puede tener consecuencias serias que se presenten más adelante en los escenarios partidos del nodo de la sección.

El estante inter conecta (IRL)

Los links interes del estante amplían el avión de los datos entre los dos chasis ASR9k. Idealmente, solamente la batea del protocolo y el protocolo inyecta los paquetes van a través de IRL, a excepción de los servicios escoja dirigidos, o durante los desperfectos de la red. En la teoría, todos los sistemas finales son duales dirigidos con un link a ambos chasis ASR9K. Similar al EOBC conecta, los funcionamientos UDLD encima de IRL también para monitorear la salud bidireccional de la expedición de los links.

Un umbral IRL se puede definir para prevenir a IRL congestionada de los paquetes de caída en el caso del error LC, por ejemplo. Si el número de links IRL baja debajo del umbral configurado para eso chasis, todas las interfaces del chasis son error inhabilitado y apagan. Esto aísla básicamente el chasis afectado y se aseegura que todo el tráfico atraviesa el otro chasis.

Note: La configuración predeterminada es equivalente a las respaldo-estante-interfaces del mínimo 1 de los datos del borde nanovoltio que significa que si no hay IRL en el estado de reenvío el respaldo señalado el controlador de estante (DSC) está aislado.

Escenarios partidos del nodo

En esta subdivisión usted puede encontrar los diversos escenarios de falla que pueden ser encontrados al ocuparse de los clusteres ASR9k:

IRL abajo

Éste es el único escenario del nodo de la fractura que se puede esperar durante declustering, o si uno del chasis cae debajo del umbral IRL y se aísla por consiguiente.

EOBC abajo

Los dos chasis del ASR9k no pueden actuar como uno sin la controle de plano extendida proporcionada por los links EOBC. Hay los faros periódicos que se intercambian sobre los links IRL así que cada chasis es consciente que el otro chasis está para arriba. Por consiguiente, uno del chasis, generalmente el chasis con el Respaldo-DSC, se toma el Out Of Service y reinicia. El chasis Respaldo-DSC permanece en el loop del inicio mientras reciba los faros del chasis Primario-DSC sobre IRL.

Cerebro partido

En el escenario IRL del cerebro partido y los links EOBC han ido abajo y cada chasis se declara como Primario-DSC. Los dispositivos de la red vecina consideran repentinamente los ID de routeres duplicados para el IGP y el BGP que pueden causar los problemas severos en la red.

Conjuntos

Muchos clientes hacen uso de los conjuntos en el lado del borde y de la base para simplificar la configuración del cluster ASR9K y para facilitar los aumentos del ancho de banda en el futuro. Esto podía causar los problemas al declustering debido a diversos miembros del agrupamiento que conectaban con diverso chasis. Estos acercamientos son posibles:

• Cree a los nuevos conjuntos para todas las interfaces conectadas con el chasis 1 (Respaldo-DSC).
• Introduzca la agregación del link del Multichassis (MCLAG).

Dominio L2

La división del cluster podría potencialmente separado el dominio L2, si no hay Switch en el acceso que interconecta los dos chasis independientes. Para no tráfico del agujero negro, usted necesita ampliar el dominio L2 que puede ser hecho si usted configura el L2 local-conecta en IRL anterior, los seudos alambre (picovatio) entre el chasis, o hace uso de cualquier otra tecnología de Virtual Private Network de la capa 2 (L2VPN). Como los cambios de la topología del dominio de Bridge con declustering, importe de la creación posible del loop cuando usted selecciona la tecnología L2VPN de la opción.

El Static Routing en el acceso hacia una interfaz del (BVI) del Interfaz Virtual de Bridge-Group en el cluster ASR9K es probable dar vuelta en un Hot Standby Router Protocol (HSRP) - solución basada usando la dirección IP anterior BVI como IP virtual.

Servicios escoja dirigidos

Los servicios escoja dirigidos tienen un tiempo muerto extendido durante el procedimiento declustering.

Acceso de administración

Durante el proceso declustering, hay un rato corto donde se aíslan ambos chasis, por lo menos cuando es transitioning del (BVI) del Static Routing al Static Routing (HSRP) para no tener inesperado y Asymmetric Routing.

Usted debe verificar cómo la consola y fuera del trabajo del Acceso de administración de la banda, bloquearse antes hacia fuera.

Procedimiento declustering ASR9000

El estado inicial

Asuma que en el estado inicial el chasis 0 es activo, mientras que el chasis 1 es de reserva (por la simplicidad). En la vida real podría ser la otra manera alrededor o aún el RSP1 en el chasis 0 podría ser activo.

Lista de control antes de la ventana de mantenimiento (MW)

• Prepare las nuevas configuraciones del chasis 0 y del chasis 1 ASR9K (Admin-Config + Config).
• Prepare las nuevas configuraciones del sistema extremo (frontera del cliente (CE), Firewall (FW), Switches, etc.).
• Prepare las nuevas configuraciones del sistema de la base (P-Nodos, Nodos del borde del proveedor (PE), reflector de ruta (RR), etc.).
• Verifique las nuevas configuraciones, sálvelas en el dispositivo y remotamente en un servidor del Trivial File Transfer Protocol (TFTP).
• Defina las pruebas del accesibilidad que deben ser antes ejecutado/durante/después del MW.
• Recoja las salidas de la controle de plano para el Interior Gateway Protocol (IGP), el Border Gateway Protocol (BGP), el Multiprotocol Label Switching (MPLS), el Protocolo de distribución de etiquetas (LDP), el etc. para antes o después de la comparación.
• Abra una solicitud de servicio dinámica con Cisco.

Paso 1. Inicie sesión en el cluster ASR9000 y verifique la configuración actual

1. Verifique la ubicación del chasis del backup principal. En este ejemplo, el chasis primario 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 todo el linecards (LC) /RSPs esté en el estado EJECUTADO XR “IOS”:

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

Paso 2. Umbral mínimo IRL de la configuración para el chasis espera

El chasis espera es el chasis con el BACKUP-DSC y se toma el Out Of Service y declustered primero. En este ejemplo, el BACKUP-DSC está situado en el chasis 1.

Con esta configuración, si el número de IRLs baja debajo del umbral mínimo configurado (1 en este caso), todas las interfaces en el estante especificado (estante de reserva – el 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

Paso 3. Apague a toda la IRL y verifique las interfaces del error invalida en los chasis 1

1. Cierre a toda la IRL existente. En este ejemplo, usted puede ver una interfaz manual apagar en ambos chasis (Ten0/x/x/x activo y Ten1/x/x/x espera):

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 toda la IRL configurada esté abajo:

RP/0/RSP0/CPU0:Cluster# show nv edge data forwarding location <Location>

Un ejemplo del <location> es 0/RSP0/CPU0.

Después de una parada normal de toda la IRL, el chasis 1 se debe aislar completamente del avión de los datos moviendo todas las interfaces externas al estado de error inhabilitado.

3. Verifique que todas las interfaces externas en los chasis 1 estén en el estado del error inhabilitado y que todo el tráfico atraviesa el chasis 0:

RP/0/RSP0/CPU0:Cluster# show error-disable

Paso 4. Apague todos los links EOBC y verifique su estatus

1. Cierre los links EOBC en todos los RSP:

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 abajo:

RP/0/RSP0/CPU0:Cluster#
show nv edge control control-link-protocols location 0/RSP0/CPU0

Después de este paso, los chasis del cluster se aíslan completamente de uno a en términos de control avión – y de los datos. El chasis 1 tiene todos sus links en estado err-disable.

Note: ¡De ahora en adelante, las configuraciones tienen que ser hechas en el chasis 1 a través de la consola RSP y afectar solamente al chasis local!

Paso 5. Inicie sesión en el RSP activo del chasis 1 y quite la antigua configuración

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

Note: Usted necesita substituir primero la configuración para la ejecutar-configuración y solamente luego claro la ejecutar-configuración admin. Esto es debido al hecho de que lo hace la eliminación del umbral IRL en la ejecutar-configuración admin “ningún cerrado” todas las interfaces externas. Esto podía causar los problemas debido a los ID de routeres duplicados, al etc.

Paso 6. Inicie el chasis 1 en el modo ROMMON

1. Fije el registro de la configuración para iniciar en el ROMMON:

RP/1/RSP0/CPU0:Cluster(admin)# config-register boot-mode rom-monitor location all

2. Verifique las variables de arranque:

RP/1/RSP0/CPU0:Cluster(admin)# show variables boot

3. Recargue ambos RSP de los chasis 1:

RP/1/RSP0/CPU0:Cluster# admin reload location all

Después de este paso, normalmente, el chasis 1 inicia en el ROMMON.

Paso 7. Variables Unset del cluster en los chasis 1 en el ROMMON en ambos RSP

Advertencia: El técnico de campo debe quitar todos los links EOBC antes de mover encendido.

Consejo: Hay también una alternativa para fijar las variables del cluster del sistema. Apéndice 2 de la sección del control: Fije el cluster variable sin iniciar el sistema en el rommon.

1. El procedimiento estándar requiere para conectar el cable de la consola con el RSP activo en el chasis 1, y para unset y para sincronizar la variable del cluster ROMMON:

unset CLUSTER_RACK_ID
sync

2. Reajuste los registros de la configuración a 0x102:

confreg 0x102
reset

Se fija El RSP activo.

3. Conecte el cable de la consola con el RSP espera del chasis 1. idealmente, los 4 RSP del cluster tienen acceso a la consola durante la ventana de mantenimiento.

Note: Las acciones descritas en este paso necesitan ser hechas en ambos RSP de los chasis 1. El RSP activo se debe iniciar primero.

Paso 8. Inicie el chasis 1 como sistema independiente y configurelo por consiguiente

Idealmente, la nueva configuración o varios fragmentos de la configuración se salva en cada chasis ASR9k y se carga después del declustering. La sintaxis de configuración correcta se debe probar en el laboratorio previamente. Si no, la consola de la configuración y las interfaces MGMT primero, antes de completar la configuración en el chasis 1 o a través de la copia y de la goma en el teletipo virtual (VTY) o cargan los config remotamente de un servidor TFTP.

Note: los config y el cometer de los comandos load guardan todas las interfaces para apagar, que permite una rampa-para arriba del servicio controlado. los config y el cometer de la carga substituyen, substituyen completamente la configuración y sacan a colación las interfaces. Por lo tanto, se recomienda para utilizar los config y el cometer de la carga.

Adapte la configuración de los sistemas finales conectados (FW, Switches, etc) y de los dispositivos del núcleo (P, PE, RR, etc) al chasis 1.

Paso 9. Servicios de la base del Restore en los chasis 1

1. O.N.U-cierre manualmente las interfaces de la base primero.
2. Verifique el LDP, Intermediate System to Intermediate System (IS-IS o ISIS), las adyacencias BGP/los peeringes.
3. Verifique las tablas de ruteo y asegúrese de que se hayan intercambiado todos los prefijos.

Advertencia: ¡Guárdese de los temporizadores tales como bit de la sobrecarga ISIS (OL), retardo del HSRP, retardo de la actualización de BGP, etc. antes de mover encendido a la Conmutación por falla!

Paso 10. Conmutación por falla - Inicie sesión en el RSP activo del chasis 0 y traiga todas las interfaces en el estado de desactivar error

Precaución: La interrupción del servicio de la causa de los siguientes pasos. Las interfaces en dirección del sur del chasis 1 todavía se inhabilitan, mientras que se aísla el chasis 0

El tiempo en espera predeterminado iguala 180s (3x60s) y representa el peor caso para la convergencia BGP. Hay varias opciones del diseño y las características BGP que permiten un tiempo de convergencia mucho más rápido, tal como seguimiento del Next-Hop BGP. Asuma que hay diversos vendedores de las de otras compañías presentes en la base que se comportan differentely que el Cisco IOS XR, usted necesita eventual acelerar la convergencia BGP manualmente con un software cerrado de las vecindades BGP entre los chasis 0 y el RR, o similar, antes de que usted accione la Conmutación por falla:

RP/0/RSP0/CPU0:Cluster(admin-config)# nv edge data minimum 1 specific rack 0
RP/0/RSP0/CPU0:Cluster(admin-config)# commit

Puesto que toda la IRL está abajo, el chasis 0 se debe ser aislado y todas las interfaces externas trasladar al estado de error inhabilitado.

Verifique que todas las interfaces externas en los chasis 0 estén en el estado del error inhabilitado:

RP/0/RSP0/CPU0:Cluster# show error-disable

Se ha configurado de nuevo el chasis 1 pues un cuadro solo del soporte tan allí no debe ser ninguna interfaces del error inhabilitado. La única cosa dejada para hacer en el chasis 1 es sacar a colación las interfaces en el borde.

Paso 11 Lado sur del Restore en el chasis 1

1. ningún cerrado todas las interfaces de acceso.

Guarde el link de la interconexión (IRL anterior) adentro apagan para ahora.

2. Verifique las adyacencias/peerings/DB IGP y BGP. Mientras que convergen los IGP y el BGP, usted espera ver que una cierta pérdida de tráfico en usted haga ping del telecontrol PE.

Paso 12. Inicie sesión en el RSP activo del chasis 0 y quite la configuración

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

Note: usted debe primero substituir la configuración para la ejecutar-configuración y solamente luego claro la ejecutar-configuración admin. Esto es debido al hecho que quitando el umbral IRL en la ejecutar-configuración admin hacen ningún cerrado todas las interfaces externas. Esto podía causar los problemas debido a los ID de routeres duplicados, al etc.

Paso 13. Inicie el chasis 0 en el ROMMON

1. Fije el registro de la configuración para iniciar en el ROMMON:

RP/0/RSP0/CPU0:Cluster(admin)# config-register boot-mode rom-monitor location all

2. Verifique las variables de arranque:

RP/0/RSP0/CPU0:Cluster# admin show variables boot

3. Recargue ambos RSP de los chasis espera:

RP/0/RSP0/CPU0:Cluster# admin reload location all

Después de este paso, normalmente, el chasis 0 inicia en el modo ROMMON.

Paso 14. Variables Unset del cluster en los chasis 0 en el ROMMON en ambos RSP

1. Conecte el cable de la consola con el RSP activo en el chasis 0.

2. Unset y sincronice la variable del cluster ROMMON:

unset CLUSTER_RACK_ID
sync

3. Reajuste los registros de la configuración a 0x102:

confreg 0x102
reset

Se fija El RSP activo.

4. Conecte el cable de la consola con el RSP espera en el chasis 0.

Note: Las acciones descritas en este paso necesitan ser hechas en ambos RSP de los chasis 1. El RSP activo se debe iniciar primero.

Paso 15. Inicie el chasis 0 como sistema independiente y configurelo por consiguiente

Idealmente, la nueva configuración o varios fragmentos de la configuración se salva en cada chasis ASR9k y se carga después del declustering. La sintaxis de configuración correcta se debe probar en el laboratorio previamente. Si no, la consola de la configuración y las interfaces MGMT primero, antes de completar la configuración en el chasis 0 o con el VTY (copia y goma) o cargan los config remotamente de un servidor TFTP.

Note: los config y el cometer de los comandos load guardan todas las interfaces para apagar, que permite una rampa-para arriba del servicio controlado. los config y el cometer de la carga substituyen, substituyen completamente la configuración y sacan a colación las interfaces. Por lo tanto, se recomienda para utilizar los config y el cometer de la carga.

Adapte la configuración de los sistemas finales conectados (FW, Switches, etc) y de los dispositivos del núcleo (P, PE, RR, etc) al chasis 0.

Paso 16. Servicios de la base del Restore en los chasis 0

1. O.N.U-cierre manualmente las interfaces de la base primero.
2. Verifique el LDP, ISIS, las adyacencias BGP/los peeringes.
3. Verifique que las tablas de ruteo y asegúrese de que se hayan intercambiado todos los prefijos.

Advertencia: ¡Guárdese de los temporizadores tales como OL-bit ISIS, retardo del HSRP, retardo de la actualización de BGP, etc. antes de mover encendido a la Conmutación por falla!

Paso 17. Lado sur del Restore en el chasis 0

1. ningún cerrado todas las interfaces de acceso.

2. Verifique las adyacencias/peerings/DB IGP y BGP

3. Asegúrese de que el link inter del chasis (IRL anterior) esté habilitado, si es necesario para la extensión L2, el etc.

Apéndice 1: Configuración del chasis único

Cambios de Configuración general

Esta configuración del router necesita ser modificada en una del chasis:

1. Direcciones del Loopback Interface.
2. Enumeración de la interfaz (e.g. Te1/x/x/x - > Te0/x/x/x).
3. Descripciones de la interfaz.
4. Dirección de la interfaz (al dividir a los conjuntos existentes).
5. Nuevo BVIS (cuando el dominio L2 es dual dirigido).
6. Extensión L2 (cuando el dominio L2 es dual dirigido).
7. HSRP para el Static Routing en el acceso.
8. Router ID del trayecto más corto primer (OSPF) /LDP BGP/Open.
9. Route Distinguisher BGP.
10. Peeringes BGP.
11. Tipo de red OSPF.
12. Simple Network Management Protocol (SNMP) ID, etc.
13. Lista de control de acceso (ACL), Prefijo-conjuntos, Routing Protocol para LLN (de baja potencia y redes que presentas pérdidas de información) (RPL), etc.
14. Nombre de host.

Descripción del conjunto

Asegúrese que revisen y que estén aplicados a todos los conjuntos a la nueva configuración dual PE. Quizás usted no necesita a los conjuntos más y los dispositivos dual-homed del Customer Premises Equipment (CPE) caben su configuración o usted necesita MCLAG en los dispositivos PE y guarda a los conjuntos hacia CPEs.

Apéndice 2: Fije el cluster variable sin iniciar el sistema en el ROMMON

Hay también una alternativa para fijar las variables del cluster. Las variables del cluster se pueden fijar por adelantado usando 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 al router y lo inicia como cuadro independiente. Con este paso, usted puede saltar para iniciar al router del ROMMON.