Procedimento do decluster ASR 9000 nanovolt

(1)

Procedimento do decluster ASR 9000 nanovolt

Índice

Introdução Pré-requisitos Requisitos Componentes Utilizados Informações de Apoio

Fundamentos & considerações do conjunto ASR9k nanovolt Ethernet fora do canal da faixa (EOBC)

A cremalheira inter liga (a IRL) Encenações rachadas do nó IRL para baixo

EOBC para baixo Cérebro rachado Pacotes

Domínio L2

Serviços da conexão residenciada única Acesso de gerenciamento

Procedimento ASR9000 declustering O estado inicial

Lista de verificação antes da janela de manutenção (MW)

Etapa 1. Entre no conjunto ASR9000 e verifique a configuração atual Etapa 2. Configurar o ponto inicial mínimo IRL para o chassi à espera

Etapa 3. Feche toda a IRL e verifique relações do desativar erro nos chassis 1 Etapa 4. Feche todos os links EOBC e verifique seu estado

Etapa 5. Entre no RSP ativo do chassi 1 e remova a configuração antiga Etapa 6. Carreg o chassi 1 no modo ROMMON

Etapa 7. Variáveis Unset do conjunto nos chassis 1 no ROMMON em ambos os RSP Etapa 8. Carreg o chassi 1 como um sistema autônomo e configurar-lo em conformidade Etapa 9. Serviços do núcleo da restauração nos chassis 1

Etapa 10. Failover - Entre no RSP ativo do chassi 0 e traga todas as relações no estado desativar erro

Etapa 11. Sul-lado da restauração no chassi 1

Etapa 12. Entre no RSP ativo do chassi 0 e remova a configuração Etapa 13. Carreg o chassi 0 no ROMMON

Etapa 14. Variáveis Unset do conjunto nos chassis 0 no ROMMON em ambos os RSP Etapa 15. Carreg o chassi 0 como um sistema autônomo e configurar-lo em conformidade Etapa 16. Serviços do núcleo da restauração nos chassis 0

Etapa 17. Sul-lado da restauração no chassi 0 Apêndice 1: Configuração do chassi único Mudanças de configuração geral

(2)

Apêndice 2: Ajuste o conjunto variável sem carreg o sistema no ROMMON

Introdução

Este documento descreve algumas das características do conjunto nanovolt do ASR 9000 e como ao decluster.

O procedimento foi testado no ambiente real com clientes Cisco que têm decidido já para o processo declustering explicado neste documento.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos: IO XR

●

Plataforma ASR 9000

●

característica do conjunto nanovolt

●

Componentes Utilizados

A informação neste documento é plataforma baseada do onASR 9000 que executa IO XR 5.x. As informações neste documento foram criadas a partir de dispositivos em um ambiente de

laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

A unidade de negócio do produto (BU) anunciou a Fim--venda (EOS) para o conjunto nanovolt na plataforma ASR 9000: A Fim--venda e o anúncio End-of-Life para Cisco nanovolt aglomeram-se

Como você pode ler dentro o anúncio, o último dia para pedir este produto é janeiro 15, 2018, e a última liberação suportada para o conjunto nanovolt é IOS-XR 5.3.x.

(3)

Fundamentos & considerações do conjunto ASR9k nanovolt

O objetivo desta seção é fornecer um resumo refresca nas instalações e nos conceitos do conjunto necessários compreender as próximas seções deste documento.

(4)

Ethernet fora do canal da faixa (EOBC)

O Ethernet fora do canal da faixa estende o plano do controle entre os dois chassis ASR9k e consiste idealmente em 4 interconecta que constroem uma malha entre o Route Switch Processor (RSP) do chassi diferente. Esta instalação fornece a Redundância adicional em caso da falha do link EOBC. O protocolo de detecção de enlace unidirecional (UDLD) assegura o encaminhamento de dados bidirecional e detecta rapidamente falhas do link. O mau funcionamento de todo o EOBC liga afeta seriamente o sistema do conjunto e pode ter as consequências sérias que são apresentadas mais tarde nas encenações rachadas do nó da seção.

A cremalheira inter liga (a IRL)

Os links inter da cremalheira estendem o plano dos dados entre os dois chassis ASR9k.

(5)

exceção dos serviços da conexão residenciada única, ou durante falhas de rede. Na teoria, todos os sistemas finais são duplos dirigidos com um link a ambos os chassis ASR9K. Similar ao EOBC liga, corridas UDLD sobre a IRL também para monitorar a saúde bidirecional da transmissão dos links.

Um ponto inicial IRL pode ser definido para impedir a IRL congestionada dos pacotes deixando cair no caso da falha LC, por exemplo. Se o número de links IRL cai abaixo do limiar configurado para aquele chassi, todas as relações do chassi são desabilitados por erro e fecham. Isto isola basicamente o chassi afetado e certifica-se de que todo o tráfego corre através do outro chassi.

Nota: A configuração padrão é equivalente às backup-cremalheira-relações do mínimo 1 dos dados da borda nanovolt que significa que se nenhuma IRL está no estado de encaminhamento o backup designado o controlador da prateleira (DSC) está isolado.

Encenações rachadas do nó

Nesta subseção você pode encontrar os cenários de falha diferentes que podem ser encontrados ao tratar os conjuntos ASR9k:

IRL para baixo

Esta é a única encenação rachada do nó que pode ser esperada durante declustering, ou se um do chassi cai abaixo do ponto inicial IRL e se torna isolado consequentemente.

EOBC para baixo

Os dois chassis do ASR9k não podem atuar como um sem o controle plano prolongado fornecido pelos links EOBC. Há as balizas periódicas que são trocadas sobre os links IRL assim que cada chassi está ciente que o outro chassi está acima. Consequentemente, um do chassi, geralmente o chassi com o Backup-DSC, toma-se fora de serviço e repartições. O chassi Backup-DSC permanece no laço da bota enquanto recebe as balizas do chassi Preliminar-DSC sobre a IRL. Cérebro rachado

Na encenação IRL do cérebro rachado e nos links EOBC foram para baixo e cada chassi declara-se como o Preliminar-DSC. Os dispositivos da rede de vizinhança veem de repente ID do

roteador duplicado para o IGP e o BGP que podem causar edições severas na rede.

Pacotes

Muitos clientes utilizam pacotes no lado da borda e do núcleo para simplificar a instalação do conjunto ASR9K e para facilitar no futuro aumentos da largura de banda. Isto podia causar edições ao declustering devido aos membros de conjunto diferentes que conectam ao chassi diferente. Estas aproximações são possíveis:

Crie pacotes novos para todas as relações conectadas ao chassi 1 (Backup-DSC).

●

Introduza a agregação do link de Multichassi (MCLAG).

●

(6)

Rachar acima do conjunto poderia potencialmente separar o domínio L2, se não há nenhum interruptor no acesso que interconecta os dois chassis autônomos. Tráfego do buraco negro, você precisa de estender o domínio L2 que pode ser feito se você configura o L2 local-conecta na IRL precedente, os fiações pseudo (picowatt) entre o chassi, ou utiliza toda a outra tecnologia de Virtual Private Network da camada 2 (L2VPN). Como as alterações de topologia do domínio de Bridge com declustering, ocupe-se da criação possível do laço quando você seleciona a

tecnologia L2VPN da escolha.

O roteamento estático no acesso para uma relação do Bridge Group Virtual Interface (BVI) no conjunto ASR9K é provável transformar em um Hot Standby Router Protocol (HSRP) - solução baseada usando o endereço IP de Um ou Mais Servidores Cisco ICM NT precedente BVI como o IP virtual.

Serviços da conexão residenciada única

Os serviços da conexão residenciada única têm um tempo ocioso da máquina prolongado durante o procedimento declustering.

Acesso de gerenciamento

Durante o processo declustering, há um curto período de tempo onde ambos os chassis sejam isolados, pelo menos quando transição do roteamento estático (BVI) ao roteamento estático (HSRP) para não ter inesperado e o roteamento assimétrico.

Você deve verificar como o console e fora do trabalho do acesso de gerenciamento da faixa, para travar-se antes para fora.

Procedimento ASR9000 declustering

O estado inicial

Supõe que no estado inicial o chassi 0 é ativo, enquanto o chassi 1 é alternativo (para a

simplicidade). Na vida real poderia ser a outra maneira em torno ou mesmo o RSP1 no chassi 0 poderia ser ativo.

(7)

Lista de verificação antes da janela de manutenção (MW)

Prepare as configurações novas do chassi 0 e do chassi 1 ASR9K (Admin-configuração + configuração).

●

Prepare as configurações novas do sistema final (edge de cliente (CE), Firewall (FW), Switches, etc.).

●

Prepare as configurações de sistema novas do núcleo (P-Nós, Nós da ponta de provedor (PE), refletor de rota (RR), etc.).

●

Verifique as configurações novas, armazene-as no dispositivo e remotamente em um server do Trivial File Transfer Protocol (TFTP).

●

Defina os testes da alcançabilidade que devem ser antes executado/durante/após o MW.

●

Recolha saídas do controle plano para o Interior Gateway Protocol (IGP), o Border Gateway Protocol (BGP), o Multiprotocol Label Switching (MPLS), o protocolo de distribuição de rótulo

(8)

(LDP), etc. para antes ou depois da comparação. Abra um pedido pro-ativo do serviço com Cisco.

●

Etapa 1. Entre no conjunto ASR9000 e verifique a configuração atual

1. Verifique o lugar do chassi do backup principal. Neste exemplo, o chassi preliminar é 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 as placas de linha (LC) /RSPs estão “no estado EXECUTADO XR IO”:

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

Etapa 2. Configurar o ponto inicial mínimo IRL para o chassi à espera

O chassi à espera é o chassi com o BACKUP-DSC e é tomado fora de serviço e declustered primeiramente. Neste exemplo, o BACKUP-DSC é ficado situado no chassi 1.

Com esta configuração, se o número de IRLs cai abaixo do limiar mínimo configurado (1 neste caso), todas as relações na cremalheira especificada (cremalheira alternativa – chassi 1 neste caso) são fechadas:

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

(9)

Etapa 3. Feche toda a IRL e verifique relações do desativar erro nos chassis 1

1. Feche toda a IRL existente. Neste exemplo, você pode ver uma parada programada manual da relação em ambos os chassis (Ten0/x/x/x ativo e 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

(10)

2. Verifique que toda a IRL configurada está para baixo:

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

Um exemplo do <location> é 0/RSP0/CPU0.

Após uma parada programada de toda a IRL, o chassi 1 deve inteiramente ser isolado do plano dos dados movendo todas as interfaces externas para o estado desabilitado por erro.

3. Verifique que todas as interfaces externas nos chassis 1 estão no estado desabilitado por erro e que todo o tráfego corre através do chassi 0:

(11)

(12)

1. Feche os links EOBC em todos os 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

(13)

RP/0/RSP0/CPU0:Cluster#

show nv edge control control-link-protocols location 0/RSP0/CPU0

Após esta etapa, os chassis do conjunto são isolados inteiramente de se em termos do controle plano – e dos dados. O chassi 1 tem todos seus links no estado errdisable.

Nota: A partir de agora, as configurações têm que ser feitas no chassi 1 através do console RSP e somente afetar o chassi local!

Etapa 5. Entre no RSP ativo do chassi 1 e remova a configuração antiga

Cancele a configuração existente no chassi 1:

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

Nota: Você precisa de substituir primeiramente somente mais tarde a configuração para a executar-configuração e claro a executar-configuração admin. Isto é devido ao fato de que remover o ponto inicial IRL na executar-configuração admin faz “nenhum fechado” todas as interfaces externas. Isto podia causar as edições devido aos ID do roteador duplicado, etc.

Etapa 6. Carreg o chassi 1 no modo ROMMON

1. Ajuste o registro de configuração para carreg no ROMMON:

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

2. Verifique os variáveis de inicialização:

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

3. Recarregue ambos os RSP dos chassis 1:

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

Após esta etapa, normalmente, botas do chassi 1 no ROMMON.

Etapa 7. Variáveis Unset do conjunto nos chassis 1 no ROMMON em ambos os

RSP

aviso: O técnico de campo deve remover todos os links EOBC antes de mover-se sobre.

Dica: Há igualmente uma alternativa para ajustar variáveis do conjunto do sistema. Verifique o apêndice 2 da seção: Ajuste o conjunto variável sem carreg o sistema no rommon.

1. O procedimento padrão exige para conectar o cabo do console ao RSP ativo no chassi 1, e para unset e variável do conjunto ROMMON da sincronização:

(14)

unset CLUSTER_RACK_ID sync

2. Restaure os registros de configuração a 0x102:

confreg 0x102 reset

O RSP ativo é ajustado.

3. Conecte o cabo do console ao RSP à espera do chassi 1. idealmente, todos os 4 RSP do conjunto têm o acesso de console durante a janela de manutenção.

Nota: As ações descritas nesta etapa precisam de ser feitas em ambos os RSP dos chassis 1. O RSP ativo deve ser carreg primeiramente.

Etapa 8. Carreg o chassi 1 como um sistema autônomo e configurar-lo em

conformidade

Idealmente, a configuração nova ou diversos snippet de configuração são armazenados em cada chassi ASR9k e carregados após declustering. A sintaxe da configuração correta deve ser testada no laboratório previamente. Se não, configurar o console e as relações MGMT primeiramente, antes de terminar a configuração no chassi 1 através da cópia e da pasta no teletipo virtual (VTY) ou carregue a configuração remotamente de um servidor TFTP.

Nota: a configuração dos comandos load e compromete mantém toda a parada

programada das relações, que permite uma rampa-acima do serviço controlado. carregue a

configuração e comprometa-a substituem, substitui inteiramente a configuração e traz

acima as relações. Consequentemente, recomenda-se usar a configuração da carga e

comprometê-la.

Adapte a configuração dos sistemas finais conectados (FW, Switches, etc.) e dos dispositivos centrais (P, PE, RR, etc.) ao chassi 1.

Etapa 9. Serviços do núcleo da restauração nos chassis 1

Un-feche manualmente relações do núcleo primeiramente. 1.

Verifique o LDP, Intermediate System to Intermediate System (IS-IS ou ISIS), adjacências BGP/peerings.

2.

Verifique as tabelas de roteamento e assegure-se de que todos os prefixos estejam trocados.

3.

aviso: Ter cuidado com temporizadores tais como o bit da sobrecarga ISIS (OL), o atraso HSRP, o atraso da atualização BGP, etc. antes de mover-se sobre para o Failover!

(15)

Etapa 10. Failover - Entre no RSP ativo do chassi 0 e traga todas as relações no

estado desativar erro

Cuidado: O rompimento do serviço da causa das próximas etapas. As relações que ruma para o sul do chassi 1 estão desabilitadas ainda, enquanto o chassi 0 é isolado

(16)

O hold-time do padrão iguala 180s (3x60s) e representa o pior caso para a convergência de BGP. Há diversas opções do projeto e características BGP que permitem um tempo de convergência muito mais rápido, tal como o seguimento do salto seguinte BGP. Supõe que há os vendedores diferentes da 3ª parte atuais no núcleo que se comportam differentely do que o Cisco IOS XR, você precisa eventualmente de acelerar manualmente a convergência de BGP com um software fechado das vizinhanças de BGP entre chassis 0 e o RR, ou similar, antes que você provoque o Failover:

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

Desde que toda a IRL está para baixo, o chassi 0 deve ser isolado e todas as interfaces externas ser movido no estado desabilitado por erro.

(17)

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

O chassi 1 foi reconfigurado porque uma caixa sozinha do suporte tão lá não deve ser nenhuma relações desabilitado por erro. A única coisa deixada para fazer no chassi 1 é trazer acima as relações na borda.

Etapa 11. Sul-lado da restauração no chassi 1

1. nenhum fechado todas as interfaces de acesso.

Mantenha o link da interconexão (IRL precedente) na parada programada por agora.

2. Verifique as adjacências IGP e BGP/peerings/DB. Quando os IGP e o BGP convirgirem, você espera ver que alguma perda de tráfego em você sibila do PE remoto.

(18)

Etapa 12. Entre no RSP ativo do chassi 0 e remova a configuração

Cancele a configuração existente no chassi ativo:

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

Nota: você deve primeiramente substituir a configuração para a executar-configuração e somente mais tarde claro a executar-configuração admin. Isto é devido ao fato que removendo o ponto inicial IRL na executar-configuração admin fazem o nenhum fechado todas as interfaces externas. Isto podia causar as edições devido aos ID do roteador duplicado, etc.

Etapa 13. Carreg o chassi 0 no ROMMON

1. Ajuste o registro de configuração para carreg no ROMMON:

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

2. Verifique os variáveis de inicialização:

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

3. Recarregue ambos os RSP de chassis à espera:

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

Após esta etapa, normalmente, chassi 0 botas no modo ROMMON.

Etapa 14. Variáveis Unset do conjunto nos chassis 0 no ROMMON em ambos os

RSP

1. Conecte o cabo do console ao RSP ativo no chassi 0. 2. Unset e variável do conjunto ROMMON da sincronização:

unset CLUSTER_RACK_ID sync

3. Restaure os registros de configuração a 0x102:

confreg 0x102 reset

O RSP ativo é ajustado.

4. Conecte o cabo do console ao RSP à espera no chassi 0.

Nota: As ações descritas nesta etapa precisam de ser feitas em ambos os RSP dos chassis 1. O RSP ativo deve ser carreg primeiramente.

(19)

Etapa 15. Carreg o chassi 0 como um sistema autônomo e configurar-lo em

conformidade

Idealmente, a configuração nova ou diversos snippet de configuração são armazenados em cada chassi ASR9k e carregados após declustering. A sintaxe da configuração correta deve ser testada no laboratório previamente. Se não, configurar o console e as relações MGMT primeiramente, antes de terminar a configuração no chassi 0 com o VTY (cópia & pasta) ou carregue a

configuração remotamente de um servidor TFTP.

Nota: a configuração dos comandos load e compromete mantém toda a parada

programada das relações, que permite uma rampa-acima do serviço controlado. carregue a

configuração e comprometa-a substituem, substitui inteiramente a configuração e traz

acima as relações. Consequentemente, recomenda-se usar a configuração da carga e

comprometê-la.

Adapte a configuração dos sistemas finais conectados (FW, Switches, etc.) e dos dispositivos centrais (P, PE, RR, etc.) ao chassi 0.

Etapa 16. Serviços do núcleo da restauração nos chassis 0

Un-feche manualmente relações do núcleo primeiramente. 1.

Verifique o LDP, ISIS, adjacências BGP/peerings. 2.

Verifique que tabelas de roteamento e assegure-se de que todos os prefixos estejam trocados.

3.

aviso: Ter cuidado com temporizadores tais como o OL-bit ISIS, o atraso HSRP, o atraso da atualização BGP, etc. antes de mover-se sobre para o Failover!

(20)

Etapa 17. Sul-lado da restauração no chassi 0

1. nenhum fechado todas as interfaces de acesso. 2. Verifique as adjacências IGP e BGP/peerings/DB

3. Assegure-se de que o link inter do chassi (IRL precedente) esteja permitido, se necessário para a extensão L2, etc.

(21)

Apêndice 1: Configuração do chassi único

Mudanças de configuração geral

Esta configuração de roteador precisa de ser alterada em um do chassi: Endereços de interface de loopback.

1.

Numeração da relação (por exemplo Te1/x/x/x - > Te0/x/x/x). 2.

Descrições da relação. 3.

Endereçamento da relação (ao rachar acima dos pacotes existentes). 4.

BVIS novo (quando o domínio L2 for duplo dirigido). 5.

Extensão L2 (quando o domínio L2 for duplo dirigido). 6.

(22)

HSRP para o roteamento estático no acesso. 7.

Router ID do caminho mais curto primeiro (OSPF) /LDP BGP/Open. 8.

Distinguidores de rota BGP. 9.

BGP Peerings. 10.

Tipo de rede OSPF. 11.

Simple Network Management Protocol (SNMP) ID, etc. 12.

Access Control List (ACL), Prefixo-grupos, protocolo de roteamento para LLN (potência baixa e redes com perdas) (RPL), etc.

13.

Hostname. 14.

Vista geral do pacote

Assegure-se de que todos os pacotes estejam revistos e aplicados à instalação dupla nova PE. Talvez você não precisa pacotes anymore e os dispositivos dual-homed do Customer Premises Equipment (CPE) cabem sua instalação ou você precisa MCLAG em dispositivos PE e mantém pacotes para CPE.

Apêndice 2: Ajuste o conjunto variável sem carreg o sistema no

ROMMON

Há igualmente uma alternativa para ajustar as variáveis do conjunto. As variáveis do conjunto podem ser ajustadas honestos usando este procedimento:

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#

Recarregue o roteador e carreg o como uma caixa autônoma. Com esta etapa, você pode saltar para carreg o roteador do ROMMON.