Procedimiento de desclúster nV ASR 9000

Introducción

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.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• IOS XR
• Plataforma ASR 9000
• función de clúster nV

Componentes Utilizados

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.

Antecedentes

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:

AsR9k nV Clústeres fundamentos y consideraciones

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.

Canal Ethernet fuera de banda (EOBC)

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.

Enlaces entre bastidores (IRL)

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).

Escenarios de nodos divididos

En esta subsección puede encontrar los diferentes escenarios de falla que se pueden encontrar al tratar con los clústeres ASR9k:

IRL Down

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.

EOBC Down

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.

Dividir cerebro

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.

Paquetes

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:

• Cree nuevos paquetes para todas las interfaces conectadas al chasis 1 (DSC de respaldo).
• Introducir la agregación de enlaces multichasis (MCLAG).

Dominio L2

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.

Servicios de un solo hogar

Los servicios de un solo inicio tienen un tiempo de inactividad prolongado durante el procedimiento de desclusión.

Acceso de administració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.

Procedimiento de desagrupación ASR9000

El estado inicial

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.

Lista de comprobación antes de la ventana de mantenimiento (MW)

• Prepare las nuevas configuraciones de chasis 0 y 1 ASR9K (Admin-Config + Config).
• Prepare las nuevas configuraciones del sistema final (frontera del cliente (CE), firewall (FW), switches, etc.).
• Prepare las nuevas configuraciones del sistema de núcleo (nodos P, nodos Provider Edge (PE), reflector de ruta (RR), etc.).
• Verifique las nuevas configuraciones, guárdelas en el dispositivo y remotamente en un servidor TFTP (protocolo trivial de transferencia de archivos).
• Definir las pruebas de disponibilidad que deben ejecutarse antes, durante y después del MW.
• Recopile las salidas del plano de control para el protocolo de gateway interior (IGP), el protocolo de gateway fronterizo (BGP), el switching de etiquetas multiprotocolo (MPLS), el protocolo de distribución de etiquetas (LDP), etc. para la comparación antes y después.
• Abra una solicitud de servicio proactiva con Cisco.

Paso 1. Inicie sesión en el clúster ASR9000 y verifique la configuración actual

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

Paso 2. Configure el umbral IRL mínimo para el chasis en espera

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

Paso 3. Apague todas las IRL y verifique las interfaces de desactivación de errores en el chasis 1

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

Paso 4. Cierre todos los enlaces EOBC y verifique su estado

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.

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

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.

Paso 6. Iniciar chasis 1 en modo ROMMON

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.

Paso 7. Desestablecer variables de usuario en el chasis 1 en ROMMON en ambos RSP

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.

Paso 8. Inicie el chasis 1 como un sistema independiente y configúrelo en consecuencia

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.

Paso 9. Restauración de los servicios básicos en el chasis 1

1. Primero, anule manualmente las interfaces de núcleo.
2. Verifique las adyacencias/peerings de BGP, Sistema intermedio a sistema intermedio (IS-IS o ISIS) y LDP.
3. Verifique las tablas de ruteo y asegúrese de que se hayan intercambiado todos los prefijos.

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.

Paso 10. Conmutación por error: inicie sesión en el RSP activo del chasis 0 y lleve todas las interfaces al estado de desactivació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 ³ 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.

Paso 11. Restauración del lado Sur en el chasis 1

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.

Paso 12. Inicie sesión en el RSP activo del chasis 0 y elimine 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

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.

Paso 13. Iniciar chasis 0 en ROMMON

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.

Paso 14. Desestablecer variables de clúster en el chasis 0 en ROMMON en ambos RSP

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.

Paso 15. Inicie el chasis 0 como sistema independiente y configúrelo en consecuencia

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.

Paso 16. Restauración de los servicios básicos en el chasis 0

1. Primero, anule manualmente las interfaces de núcleo.
2. Verifique las adyacencias/peerings de LDP, ISIS y BGP.
3. Verifique que las tablas de ruteo y asegúrese de que se hayan intercambiado todos los prefijos.

Advertencia: Tenga cuidado con temporizadores como ISIS OL-Bit, HSRP delay, BGP Update delay, etc. antes de pasar a la conmutación por fallas.

Paso 17. Restauración del lado Sur en el chasis 0

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.

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

Cambios generales de configuración

Esta configuración del router debe modificarse en uno de los chasis:

1. Direcciones de Interfaz de Loopback.
2. Numeración de la interfaz (por ejemplo, Te1/x/x/x -> Te0/x/x/x).
3. Descripciones de la interfaz.
4. Direccionamiento de interfaz (al dividir paquetes existentes).
5. Nuevas BVI (cuando el dominio L2 tiene doble reposición).
6. Extensión L2 (cuando el dominio L2 está doblemente conectado).
7. HSRP para el ruteo estático en el acceso.
8. BGP/Open Shortest Path First (OSPF)/ID de router LDP.
9. Distinguidores de Ruta BGP.
10. Peerings BGP.
11. tipo de red OSPF.
12. ID del protocolo simple de administración de red (SNMP), etc.
13. Lista de control de acceso (ACL), conjuntos de prefijos, protocolo de routing para LLN (Redes de baja potencia y pérdida) (RPL), etc.
14. Hostname.

Descripción general del paquete

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.

Apéndice 2: Establecer variable de clúster sin arrancar el sistema en ROMMON

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.