ASR 9000 nV - Procedura di decluster

Introduzione

In questo documento vengono descritte alcune delle funzionalità del cluster NV di ASR 9000 e viene spiegato come eseguire il decluster.

La procedura è stata testata in ambiente reale con i clienti Cisco che hanno già scelto il processo di declustering descritto in questo documento.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• IOS XR
• Piattaforma ASR 9000
• Funzionalità cluster nV

Componenti usati

Le informazioni di questo documento si basano sulla piattaforma ASR 9000 con IOS XR 5.x.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

La Product Business Unit (BU) ha annunciato la fine della vendita (EOS) per il cluster nV sulla piattaforma ASR 9000: Annuncio di fine ciclo di vita e di vendita per il cluster Cisco nV

Come si può leggere nell'annuncio, l'ultimo giorno per ordinare questo prodotto è il 15 gennaio 2018 e l'ultima release supportata per il cluster NV è IOS-XR 5.3.x.

Nella tabella seguente sono elencate le fasi cardine di cui tenere conto:

Nozioni fondamentali e considerazioni sui cluster ASR9k nV

L'obiettivo di questa sezione è fornire un breve aggiornamento sulle impostazioni dei cluster e sui concetti necessari per comprendere le sezioni successive di questo documento.

EOBC (Ethernet Out of Band Channel)

Il canale Ethernet fuori banda estende il piano di controllo tra i due chassis ASR9k e idealmente è costituito da 4 interconnessioni che creano una rete tra i processori Route Switch (RSP) di chassis diversi. Questa configurazione fornisce ridondanza aggiuntiva in caso di errore del collegamento EOBC. Il protocollo UDLD (Unidirectional Link Detection Protocol) assicura l'inoltro bidirezionale dei dati e rileva rapidamente gli errori dei collegamenti. Il malfunzionamento di tutti i collegamenti EOBC influisce gravemente sul sistema cluster e può avere gravi conseguenze, descritte più avanti nella sezione Scenari di suddivisione dei nodi.

IRL (Inter Rack Link)

I collegamenti tra rack estendono il piano dati tra i due chassis ASR9k. In teoria, solo il protocollo punt e il protocollo inject passano attraverso l'IRL, ad eccezione dei servizi single-home, o durante errori di rete. In teoria, tutti i sistemi terminali sono dotati di un collegamento a entrambi gli chassis ASR9K. Analogamente ai collegamenti EOBC, il protocollo UDLD viene eseguito sull'IRL anche per monitorare lo stato dei collegamenti nell'inoltro bidirezionale.

Ad esempio, è possibile definire una soglia IRL per impedire che un IRL congestionato scarti i pacchetti in caso di guasto del LC. Se il numero di collegamenti IRL scende al di sotto della soglia configurata per lo chassis, tutte le interfacce dello chassis vengono disabilitate a causa di un errore e chiuse. In questo modo viene isolato lo chassis interessato e viene garantito il flusso di tutto il traffico attraverso l'altro chassis.

Nota: la configurazione predefinita equivale a nv edge data minimum 1 backup-rack-interfaces, il che significa che se nessun IRL è nello stato di inoltro, il backup Designated Shelf Controller (DSC) è isolato.

Scenari di divisione dei nodi

In questa sottosezione sono illustrati i diversi scenari di errore che possono verificarsi quando si utilizzano cluster ASR9k:

IRL verso il basso

Questo è l'unico scenario di split-nodo che si può prevedere durante il declustering, o se uno dei chassis scende sotto la soglia IRL e diventa di conseguenza isolato.

EOBC inattivo

I due chassis dell'ASR9k non possono funzionare come uno senza il control-plane esteso fornito dai collegamenti EOBC. Esistono beacon periodici scambiati sui collegamenti IRL, in modo che ogni chassis sia consapevole che l'altro è attivo. Di conseguenza, uno degli chassis, in genere lo chassis con Backup-DSC, si disattiva e viene riavviato. Lo chassis Backup-DSC rimane nel loop di avvio finché riceve i beacon dello chassis Primary-DSC tramite l'IRL.

Suddividi cervello

Nello scenario Split Brain, i collegamenti IRL ed EOBC sono stati interrotti e ogni chassis si dichiara Primary-DSC. I dispositivi di rete adiacenti rilevano improvvisamente ID router duplicati per IGP e BGP, che possono causare gravi problemi nella rete.

Pacchetti

Molti clienti utilizzano i bundle sul lato Edge e Core per semplificare l'installazione del cluster ASR9K e per facilitare l'aumento della larghezza di banda in futuro. Ciò potrebbe causare problemi durante il declustering a causa di diversi membri del bundle che si connettono a chassis diversi. Tali approcci sono possibili:

• Creare nuovi pacchetti per tutte le interfacce collegate allo chassis 1 (backup-DSC).
• Introduzione di Multicassis Link Aggregation (MCLAG).

Dominio L2

La divisione del cluster potrebbe potenzialmente separare il dominio L2, se nell'accesso non è presente alcuno switch che interconnette i due chassis standalone. Per evitare il traffico di buchi neri, è necessario estendere il dominio L2 che può essere eseguito se si configurano connessioni locali L2 sull'IRL precedente, pseudo-fili (PW) tra lo chassis o si utilizza qualsiasi altra tecnologia L2VPN (Virtual Private Network) di layer 2. Man mano che la topologia del dominio di bridge cambia con il declustering, è importante considerare la possibile creazione di loop quando si seleziona la tecnologia L2VPN scelta.

Il routing statico nell'accesso a un'interfaccia BVI (bridge-group virtual interface) sul cluster ASR9K diventerà probabilmente una soluzione basata su HSRP (Hot Standby Router Protocol) utilizzando l'indirizzo IP BVI precedente come indirizzo IP virtuale.

Servizi monocamerali

Durante la procedura di declustering, i servizi single-homed hanno un tempo di inattività prolungato.

Accesso alla gestione

Durante il processo di declustering, si ha poco tempo quando entrambi gli chassis vengono isolati, almeno durante la transizione dal routing statico (BVI) al routing statico (HSRP) in modo da non avere un routing imprevisto e asimmetrico.

È necessario verificare il funzionamento dell'accesso alla gestione da console e fuori banda prima di bloccarsi.

Procedura di declustering di ASR9000

Stato iniziale

Si supponga che nello stato iniziale lo chassis 0 sia attivo, mentre lo chassis 1 è di backup (per semplicità). Nella realtà potrebbe essere il contrario o persino RSP1 nello chassis 0 potrebbe essere attivo.

Elenco di controllo prima della finestra di manutenzione (MW)

• Preparare le nuove configurazioni dello chassis 0 e dello chassis 1 di ASR9K (configurazione amministratore + configurazione).
• Preparare le nuove configurazioni del sistema terminale (CE (Customer Edge), firewall (FW), switch, ecc.).
• Preparare le nuove configurazioni del sistema di base (nodi P, nodi PE (Provider Edge), router Reflector (RR), ecc.).
• Verificare le nuove configurazioni, memorizzarle sul dispositivo e in remoto su un server TFTP (Trivial File Transfer Protocol).
• Definire le prove di raggiungibilità che devono essere eseguite prima/durante/dopo l'MW.
• Raccolta degli output del control plane per IGP (Interior Gateway Protocol), BGP (Border Gateway Protocol), MPLS (Multiprotocol Label Switching), LDP (Label Distribution Protocol), ecc. per il confronto prima/dopo il confronto.
• Aprire una richiesta di servizio proattiva con Cisco.

Passaggio 1. Accedere al cluster ASR9000 e verificare la configurazione corrente

1. Verificare la posizione dello chassis Principale - Backup. Nell'esempio, lo chassis principale è 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. Verificare che tutte le schede di linea (LC)/RSP si trovino nello stato "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

Passaggio 2. Configurazione della soglia minima IRL per lo chassis in standby

Lo chassis in standby è lo chassis con backup-DSC; è fuori servizio e viene prima disconnesso. In questo esempio, BACKUP-DSC si trova nello chassis 1.

Con questa configurazione, se il numero di IRL scende al di sotto della soglia minima configurata (1 in questo caso), tutte le interfacce sul rack specificato (rack di backup - chassis 1 in questo caso) vengono chiuse:

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

Passaggio 3. Arrestare tutte le IRL e verificare le interfacce con stato err-disabled sullo chassis 1

1. Chiudere tutte le IRL esistenti. In questo esempio, è possibile vedere un'interfaccia chiusa manualmente in entrambi gli chassis (attivo Ten0/x/x/x e in standby 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. Verificare che tutti gli IRL configurati siano inattivi:

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

Un esempio di <location> è 0/RSP0/CPU0.

Dopo lo spegnimento di tutte le IRL, lo chassis 1 deve essere completamente isolato dal piano dati spostando tutte le interfacce esterne allo stato err-disabled.

3. Verificare che tutte le interfacce esterne sullo chassis 1 siano in stato err-disabled e che tutto il traffico passi attraverso lo chassis 0:

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

Passaggio 4. Chiudi tutti i collegamenti EOBC e verifica il loro stato

1. Chiudere i collegamenti EOBC su tutti i 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. Verificare che tutti i collegamenti EOBC siano inattivi:

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

Dopo questa fase, lo chassis del cluster è completamente isolato l'uno dall'altro in termini di controllo e piano dati. Lo chassis 1 ha tutti i suoi collegamenti in stato err-disabled.

Nota: da ora in poi, le configurazioni devono essere eseguite sullo chassis 1 tramite la console RSP e interessano solo lo chassis locale.

Passaggio 5. Accedere all'RSP attivo dello chassis 1 e rimuovere la configurazione precedente

Cancellare la configurazione esistente sullo chassis 1:

RP/1/RSP0/CPU0:Cluster(config)# commit replace
RP/1/RSP0/CPU0:Cluster(admin-config)# commit replace

Nota: è necessario sostituire prima la configurazione per la configurazione corrente e solo dopo cancellare la configurazione corrente dell'amministratore. Ciò è dovuto al fatto che la rimozione della soglia IRL nella configurazione di esecuzione dell'amministratore non comporta la "nessuna chiusura" di tutte le interfacce esterne. Ciò potrebbe causare problemi dovuti a ID di router duplicati, ecc.

Passaggio 6. Avviare lo chassis 1 in modalità ROMMON

1. Impostare il registro di configurazione per l'avvio in ROMMON:

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

2. Verificare le variabili di avvio:

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

3. Ricaricare entrambi gli RSP dello chassis 1:

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

Dopo questo passaggio, normalmente lo chassis 1 si avvia in ROMMON.

Passaggio 7. Annullamento dell'impostazione delle variabili CLuster sullo chassis 1 in ROMMON su entrambi gli RSP

Avvertenza: il tecnico sul campo deve rimuovere tutti i collegamenti EOBC prima di procedere.

Suggerimento: esiste anche un'alternativa per impostare le variabili del cluster di sistema. Vedere la sezione Appendice 2: Impostare la variabile Cluster senza avviare il sistema in rommon.

1. La procedura standard richiede di collegare il cavo console all'RSP attivo sullo chassis 1 e di annullare l'impostazione e sincronizzare la variabile Cluster ROMMON:

unset CLUSTER_RACK_ID
sync

2. Reimpostare i registri di configurazione su 0x102:

confreg 0x102
reset

L'RSP attivo è impostato.

3. Collegare il cavo della console all'RSP di standby dello chassis 1. In teoria, tutti e quattro i RSP del cluster hanno accesso alla console durante la finestra di manutenzione.

Nota: le azioni descritte in questo passaggio devono essere eseguite su entrambi i RSP dello chassis 1. È necessario avviare prima l'RSP attivo.

Passaggio 8. Avviare lo chassis 1 come sistema standalone e configurarlo di conseguenza

Idealmente, la nuova configurazione o diversi snippet di configurazione vengono memorizzati su ogni chassis ASR9k e caricati dopo il declustering. La sintassi di configurazione corretta deve essere testata in precedenza in laboratorio. In caso contrario, configurare prima la console e le interfacce di gestione, prima di completare la configurazione sullo chassis 1 tramite copia e incolla su VTY (Virtual Teletype) o caricare la configurazione in remoto da un server TFTP.

Nota: i comandi load config e commit mantengono chiuse tutte le interfacce, consentendo un aumento controllato dei servizi. load config e commit sostituiscono, sostituiscono completamente la configurazione e richiamano le interfacce. Pertanto, si consiglia di utilizzare il comando load config e il comando commit.

Adattare la configurazione dei sistemi terminali collegati (FW, switch, ecc.) e dei dispositivi principali (P, PE, RR, ecc.) allo chassis 1.

Passaggio 9. Ripristino dei servizi di base sullo chassis 1

1. Prima di tutto, annullare la chiusura manuale delle interfacce principali.
2. Verificare LDP, Intermediate System to Intermediate System (IS-IS o ISIS), adiacenze/peer BGP.
3. Verificare le tabelle di routing e assicurarsi che tutti i prefissi siano stati scambiati.

Avviso: prestare attenzione a timer quali il bit di sovraccarico ISIS (OL), il ritardo HSRP, il ritardo di aggiornamento BGP e così via prima di passare al failover.

Passaggio 10. Failover: accesso all'RSP attivo dello chassis 0 e attivazione di tutte le interfacce in stato err-disabled

Attenzione: i passaggi successivi causano l'interruzione del servizio. Le interfacce verso sud dello chassis 1 sono ancora disabilitate, mentre lo chassis 0 è isolato

Il tempo di attesa predefinito è uguale a 180 (3x60) e rappresenta il caso peggiore per la convergenza BGP. Sono disponibili diverse opzioni di progettazione e funzionalità BGP che consentono tempi di convergenza molto più rapidi, ad esempio BGP Next-Hop Tracking. Si supponga che nel core siano presenti diversi fornitori di terze parti che si comportano in modo diverso rispetto a Cisco IOS XR e che prima di attivare il failover sia necessario accelerare manualmente la convergenza BGP con un software di chiusura del vicinato BGP tra lo chassis 0 e l'RR o simile:

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

Poiché tutti gli IRL sono inattivi, lo chassis 0 deve essere isolato e tutte le interfacce esterne devono essere messe nello stato err-disabled.

Verificare che tutte le interfacce esterne sullo chassis 0 siano in stato err-disabled:

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

Lo chassis 1 è stato riconfigurato come unità indipendente, pertanto non devono essere presenti interfacce con stato err-disabled. L'unica cosa che rimane da fare sullo chassis 1 è di sollevare le interfacce sul bordo.

Passaggio 11. Ripristino lato sud sullo chassis 1

1. no chiudi tutte le interfacce di accesso.

Per il momento, tenere il collegamento di interconnessione (IRL precedente) chiuso.

2. Verificare le adiacenze/peer IGP e BGP/DB. Mentre gli IGP e i BGP convergono, ci si aspetta di vedere alcune perdite di traffico sui ping dal server PE remoto.

Passaggio 12. Accedere all'RSP attivo dello chassis 0 e rimuovere la configurazione

Cancellare la configurazione esistente sullo chassis attivo:

RP/0/RSP0/CPU0:Cluster(config)# commit replace
RP/0/RSP0/CPU0:Cluster(admin-config)# commit replace

Nota: sostituire la configurazione per la configurazione corrente e cancellare la configurazione corrente solo in seguito. Ciò è dovuto al fatto che la rimozione della soglia IRL nella configurazione di esecuzione dell'amministratore non comporta la chiusura di tutte le interfacce esterne. Ciò potrebbe causare problemi dovuti a ID di router duplicati, ecc.

Passaggio 13. Chassis di avvio 0 in ROMMON

1. Impostare il registro di configurazione per l'avvio in ROMMON:

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

2. Verificare le variabili di avvio:

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

3. Ricaricare entrambi gli RSP dello chassis in standby:

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

Dopo questo passaggio, normalmente lo chassis 0 viene avviato in modalità ROMMON.

Passaggio 14. Annullamento dell'impostazione delle variabili cluster sullo chassis 0 in ROMMON su entrambi gli RSP

1. Collegare il cavo della console all'RSP attivo sullo chassis 0.

2. Annullare e sincronizzare la variabile ROMMON del cluster:

unset CLUSTER_RACK_ID
sync

3. Reimpostare i registri di configurazione su 0x102:

confreg 0x102
reset

L'RSP attivo è impostato.

4. Collegare il cavo della console all'RSP di standby sullo chassis 0.

Nota: le azioni descritte in questo passaggio devono essere eseguite su entrambi i RSP dello chassis 1. È necessario avviare prima l'RSP attivo.

Passaggio 15. Avviare lo chassis 0 come sistema standalone e configurarlo di conseguenza

Idealmente, la nuova configurazione o diversi snippet di configurazione vengono memorizzati su ogni chassis ASR9k e caricati dopo il declustering. La sintassi di configurazione corretta deve essere testata in precedenza in laboratorio. In caso contrario, configurare prima la console e le interfacce di gestione, prima di completare la configurazione sullo chassis 0 tramite VTY (Copy & Paste) o caricare la configurazione in remoto da un server TFTP.

Nota: i comandi load config e commit mantengono chiuse tutte le interfacce, consentendo un aumento controllato dei servizi. load config e commit sostituiscono, sostituiscono completamente la configurazione e richiamano le interfacce. Pertanto, si consiglia di utilizzare il comando load config e il comando commit.

Adattare la configurazione dei sistemi terminali collegati (FW, switch, ecc.) e dei dispositivi principali (P, PE, RR, ecc.) allo chassis 0.

Passaggio 16. Ripristino dei servizi di base sullo chassis 0

1. Prima di tutto, annullare la chiusura manuale delle interfacce principali.
2. Verificare le adiacenze/peer LDP, ISIS e BGP.
3. Verificare che le tabelle di routing e tutti i prefissi siano stati scambiati.

Avviso: prestare attenzione a timer quali ISIS OL-Bit, ritardo HSRP, ritardo di aggiornamento BGP e così via prima di passare al failover.

Passaggio 17. Ripristino lato sud sullo chassis 0

1. no chiudi tutte le interfacce di accesso.

2. Verificare le adiacenze/peer IGP e BGP/DB

3. Verificare che il collegamento tra chassis (IRL precedente) sia abilitato, se necessario per l'estensione L2, ecc.

Appendice 1: Configurazione a chassis singolo

Modifiche alla configurazione generale

La configurazione del router deve essere modificata su uno degli chassis:

1. Indirizzi di interfaccia di loopback.
2. Numerazione interfaccia (es. Te1/x/x/x -> Te0/x/x/x).
3. Descrizioni interfaccia.
4. Indirizzamento interfaccia (quando si suddividono pacchetti esistenti).
5. Nuovi BVI (quando il dominio L2 è dual-homed).
6. Estensione L2 (quando il dominio L2 ha una doppia casa).
7. HSRP per il routing statico in access.
8. ID router BGP/Open Shortest Path First (OSPF)/LDP.
9. Distintori di route BGP.
10. Peer BGP.
11. Tipo di rete OSPF.
12. ID SNMP (Simple Network Management Protocol), ecc.
13. Access Control List (ACL), Prefix-Sets, Routing Protocol per LLN (Low-Power and Lossy Networks) (RPL), ecc.
14. Nome host.

Panoramica del bundle

Verificare che tutti i bundle vengano esaminati e applicati alla nuova configurazione di PE doppia. È possibile che non siano più necessari pacchetti e dispositivi CPE (Customer-Premises Equipment) dual-homed oppure che sia necessario MCLAG sui dispositivi PE e mantenere i pacchetti verso i CPE.

Appendice 2: Impostazione della variabile cluster senza avviare il sistema in ROMMON

È inoltre disponibile un'alternativa per l'impostazione delle variabili cluster. Le variabili cluster possono essere impostate in anticipo utilizzando la seguente procedura:

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#

Ricaricare il router e il router viene avviato come unità autonoma. In questo passaggio è possibile saltare l'avvio del router da ROMMON.