Switches : Software de WAN Cisco BPX/IGX/IPX

Script de Atualização Nó-por-Nó do WAN Switch Software

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento descreve Cisco recomendou o processo de ponto 34 para um IPX, umas IGX 8400 series switch, ou uma upgrade de series switch software bem sucedida do BPX 8600. Esta elevação é para as redes que executam um WAN Switch Software Release que apoie a característica de upgrade de nó por nó. Este documento lista os passos mínimos requeridos e discute cada passo em detalhes. O plano delineado neste documento foi utilizado para atualizar com êxito as redes Cisco IPX/IGX/BPX.

Este documento é pretendido ser usado como um auxílio para upgrades de Switch Software bem-sucedido de condução, mas não é um substituto para o planeamento apropriado com seu coordenador de vendas Cisco, coordenador de sistemas, ou gerenciador de conta.

cuidado Cuidado: É essencial que você segue as etapas no Planejador de WAN Switch Software Upgrade antes de executar as etapas abaixo. A execução das etapas listadas abaixo sem antes consultar o Planejador de atualizações resultará em problemas de rede.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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 você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Background

Elevações ao software de switch para o Produtos IPX/IGX/BPX, ao geralmente exigir algum planeamento, frequentemente resultado em quase nenhuma interrupção de rede percebida.

A técnica empregada para obter atualizações que não afetem o serviço permaneceu a mesma desde as primeiras versões do produto. Antes da versão 8.4, a arquitetura dos softwares IPX/IGX/BPX necessitava que todos os nós da rede executassem a mesma versão principal do software de switch. A fim cumprir esta exigência, era necessário promover ao mesmo tempo todos os Nós.

À medida que o tamanho das redes aumentou, o mesmo aconteceu com a quantidade de tráfego de gerenciamento gerado no momento da atualização. Em consequência este procedimento foi planejado para assegurar um upgrade graceful em todo o tamanho da rede. Essa técnica de atualização é a ação recomendada quando você está atualizando uma versão de software com suporte para o recurso de atualização Node-by-Node (Nó por Nó) para outra versão de software que também suporta esse recurso de atualização.

A característica do Nó-por-nó permite que muitas das etapas sejam costuradas somente 2 aqueles switch IPX/IGX/BPX que estão sendo promovidos. Isto que costura permite o maior controle durante uma upgrade de software de switch.

Neste documento, os nós da rede a serem atualizados são chamados de nós de destino. Os nós de destino são supostos para ser um subconjunto da população de nós da rede total. Um número razoável de nós de destino em uma rede do 100-node seria 10. Para o switch software release 8.4, a função da upgrade de nó por nó pode precisar de ser permitido usando o comando cnffunc.

Este documento foi escrito para auxiliar os usuários que estejam envolvidos nas atualizações IPX/IGX/BPX em um ambiente 8.4.X e posterior. Não se supõe que o leitor tem um conhecimento aprofundado deste Switches, mas supõe-se que o leitor tem uma compreensão de configurações do switch básico.

Note por favor que até à data do switch software release 9.2 a plataforma IPX não está apoiada. O Switches IPX pode precisar de ser substituído antes de uma elevação a 9.2.

Plano de alto nível

O que se segue resume as etapas necessárias para uma atualização bem-sucedida. Todas as etapas devem ser concluídas independente do tamanho da rede.

Fase 1: Planejamento

Tarefa Descrição
1 Selecione a nova revisão do software de switch ou do Cisco WAN Manager (CWM) (conhecido anteriormente como o StrataView Plus (SV+)).
2 Avalie anomalias de software conhecidas nas versões selecionadas.
3 Revise as notas de versão para etapas de atualização específicas para esta versão.
4 Inspecione as revisões do firmware e do hardware da placa e verifique se elas são suportadas pela nova versão do software.
5 Escreva scripts, que são uma tarefa opcional para auxiliar as alterações de parâmetros necessárias em certas seções do estágio 3.

Fase 2: Preparação de rede

Nota: Esta fase precisa de ser terminada uma semana antes do upgrade de software

Tarefa Descrição
6 Verificação de saúde de rede.
7 Empregue placas de controle em standby.
8 Monitore a rede rigorosamente até o momento da atualização.
9 Atualize as estações CWM (SV+).
10 Verifique a conectividade do gerenciamento de rede para os nós de rede.

Fase 3: A elevação

O acesso de gerenciamento à rede durante esse período deve ser estritamente gerenciada com o uso do mapa de topologia CWM (SV+) e dos comando dspcds e dspalms.

Tarefa Descrição
11 Provisionamento de freeze starts.
12 Se disponível, salve a configuração da rede para CWM (SV+).
13 Pare a coleta de estatística.
14 Limpe erros da placa, registros do software e desative os testes automáticos do processador.
15 Desabilite as máquinas de estado de exemplo de estatística.
16 Carregue uma nova revisão nas estações de CWM (SV+).
17 Altere os parâmetros cnfdlparm
18 Pare todas as tarefas automáticas.
19 Carregue uma nova revisão nos nós de rede de destino.
20 Valide a gravação de placa do processador.
21 Defina os parâmetros na preparação para a atualização de rede.
22 Remova a causa de todos alarmes PRINCIPAIS e, se possível, de todos os alarmes MENORES.
23 Feche as estações de CWM (SV+) - reconfigure se for necessário.
24 Se necessário, implemente soluções identificadas nas tarefas 2 e 3.
25 Se a rede foi estável por 30 minutos, promova o software de switch.
26 Deixe que a rede se estabeleça e execute testes de validação específicos de cliente.
27 Desbloqueie processadores em standby Repita as tarefas 25 a 27 para cada um dos Nós que estão sendo promovidos.
28 Configure parâmetros operacionais.
29 Reinicie as estações de trabalho CWM (SV+).
30 Verificação de saúde de rede.
31 Reiniciar coleta de estatísticas.
32 Reinicie todos os trabalhos automáticos.
33 Salve a configuração da rede para CWM (SV+).
34 Provisionamento de freeze ends.

Detalhe da tarefa

Fase 1: Planejamento

Tarefa 1 Selecione a nova revisão do software de switch CWM (SV+).

A seleção de software de switch apropriado, e daqui, CWM (SV+) dependerá de um número de variáveis que incluem a revisão do software atual, requisitos de hardware, e assim por diante. Contacte o Suporte técnico de Cisco para mais informações.

Para selecionar a versão adequada de CWM (SV+), revise as notas de versão da versão adequada da documentação Versões do Cisco WAN Manager em CCO.

Nota: O CWM precisa de uma a duas horas para iniciar a coleta e mostrar as estatísticas, após uma atualização ou reinício do aplicativo.

Tarefa 2 Avalie anomalias de software conhecidas nas versões selecionadas.

Algumas anomalias de software podem exigir preparação adicional para garantir uma atualização mais suave. Isso pode significar:

Tarefa 3 Revise as notas de versão para etapas de atualização específicas para esta versão.

Assim como na Tarefa 2, esta tarefa pode resultar em:

Tarefa 4 Inspecione as revisões do firmware e do hardware da placa e verifique se elas são suportadas pela nova versão do software.

Em um IPX/IGX/BPX, a revisão de uma placa pode ser obtida com o comando dspcds. Esta informação pode então ser usada conjuntamente com o software de switch/firmware/matriz de compatibilidade de hardware fornecida nas notas de switch software release para avaliar se alguma mudança é necessária. Você pode encontrar essas notas de versão nas páginas Soluções de switching de WAN Cisco.

Para o Switches com cartões do processador redundante (NPC, NPM, ou BCC), verifique que a versão de firmware, o tamanho BRAM, e o tamanho de RAM para ambos os cartões combinam.

Comando dspcds

O comando dspcds produz esta saída para cada slot:

3 FRM DTV FRI-V35 BF Standby

Este é significado de cada um dos elementos da saída:

Saída: 3 FRM DTV FRI-V35 BF Standby
Significado: <nº slot> <tipo de placa> <revisão de placa frontal> type> do cartão do <back <revisão da placa traseira> <card state>

A seção <revisão de placa frontal> está ilustrada com "DTV" na saída acima. A maneira como isso é interpretado é mostrada abaixo.

Saída: D T V
Significado: Modelo do cartão Revisão de hardware do cartão Revisão de firmware

A primeira letra indica o modelo da placa (nesse caso, "D"). Descreve o conjunto de recursos da placa e só pode ser alterado pela Cisco ou seus parceiros.

A segunda letra indica a revisão de hardware da placa (nesse caso, "T"). Só pode ser alterada através do envio da placa à fábrica.

A terceira letra indica a revisão do firmware (no caso 'V'). Essa é uma variação no modelo e é alterada após melhorias secundárias de recursos e correções de erros. Pode ser alterado fazendo-se o download do novo código de uma estação de trabalho CWM (SV+) e, em seguida, gravando-o na placa.

O designador de uma imagem de firmware particular que pode ser localizado no CCO tem a forma A.B.C., em que:

  • A especifica o tipo de placa

  • B especifica o designador de modelo, que especifica muitas das potencialidades que uma placa possui. Por exemplo, C do modelo UVM (rev. A) tiver o DCA de firmware, quando UVM D modelo (rev. A) possui DDA de firmware. O modelo C foi o primeiro modelo UVM compatível com compactação G.729 (entre outros novos recursos) O modelo D suporta tudo que é suportado pelo modelo C e adiciona a compressão de código ocioso aos recursos suportados (entre outros).

  • C especifica o nível da versão do firmware, que, normalmente, indica o nível de correção do erro. O nível do firmware UVM mais recente utilizado para esse exemplo é a versão E ou DDE, indicando UVM modelo D, versão E.

Quando desejar verificar o nível de liberação de uma placa instalada em um BPX ou IGX, é possível fazer a verificação por meio do comando dspcds. Como você perceberá, os nós fornecem as informações sobre versão de uma maneira diferente daquela fornecida pelo método de notação usado nos nomes de arquivo de CCO. De fato, os nós fornecem uma informação extra para a compatibilidade de hardware. A notação usada pelo software de switch é do tipo de formulário B.D.C, onde:

  • TYPE fornece o nome completo do tipo de placa (UVM, por exemplo)

  • B especifica o designador de modelo

  • D especifica o nível da versão do hardware

  • C especifica o nível da versão do firmware

Tarefa 5 Escreva scripts para auxiliar as alterações de parâmetros necessárias em certas seções do estágio 3 (opcional).

Escrever e testar scripts irá:

  • Facilitar a execução do processo de alteração de parâmetro

  • Destaque os comandos any que mudaram no software release novo.

Há produtos para definir parâmetros de preparação para uma atualização de rede. Os pacotes de software que foram usados com êxito para atualizações são:

Fase 2: Preparação de rede

Tarefa 6 Verificação de saúde de rede

consulte o Apêndice A

Tarefa 7 Empregue placas de controle em standby.

Consulte o apêndice B

Tarefa 8 Monitore a rede rigorosamente até o momento da atualização.

A Tarefa 6 deve destacar todos os problemas existentes na rede, mas é recomendável monitorar a rede para verificar se há erros causados pelo novo software e erros relacionados à placa até o momento da atualização. Relate erros recorrente ao Suporte técnico de Cisco.

Consulte o Anexo A para obter detalhes da verificação de erros de software e erros de placa.

Tarefa 9 Atualize as estações CWM (SV+).

Versões do CWM (SV+) podem gerenciar redes que estejam executando um software que está duas versões atrás da versão do CWM (SV+).

Tarefa 10 Verifique a conectividade do gerenciamento de rede para os nós de rede.

Assegure-se de que cada switch de rede possa ser conectar-à utilização Inband ou fora do acesso da faixa. Usando TELNET, conecte-se a cada IPX/IGX/BPX na rede. Se a rede usar o acesso Inband e Out of Band, teste cada método separadamente.

Fase 3: A elevação

Tarefa 11 Provisionamento de freeze starts.

Provisionamento de HALT de novos serviços até a conclusão da atualização.

Tarefa 12 Salve a configuração de rede.

Se os recursos de gravação e restauração de configuração foram comprados, salvar um instantâneo da configuração de rede em uma estação de trabalho CWM (SV+).

Outros detalhes sobre esse procedimento podem ser obtidos no manual de referência de comandos para a versão do software que está sendo usado.

Tarefa 13 Interrompa a coleta de estatísticas e feche o Statistics Collection Manager.

Consulte o Apêndice D.

Tarefa 14 Os erros de placa em branco e os log de software, e desabilitam então auto-testes do processador.

Em todos os Nós a ser erros de placa em branco e log de software promovidos usando os comandos seguintes:

  • clrcderrs *

  • clrswlog

  • clrswlog s

O auto-teste do processador é desabilitado inscrevendo o comando cnftstparm, e então selecionando o tipo de processamento que é relevante ao nó que está sendo reconfigurado.

Tarefa 15 Desabilite as máquinas de estado de exemplo de estatística.

A engenharia da Cisco recomenda agora a desativação das máquinas do estado de amostragem estatística durante a fase loadrev de uma atualização. Previamente, as estatísticas foram desabilitadas durante a fase do runrev.

Essas máquinas de estado podem ser desabilitadas em todos os nós para serem atualizadas usando os comandos off1 ou off2.

Os parâmetros a seguir devem ser desabilitados.

  • Conn Stat Sampling

  • Amostragem de stat de linha

  • Amostragem de status de porta

Nota: A desabilitação destas funções desabilitará eficazmente os dspchstats, dsptrkutl, comandos statistics dos dspportstats. Caso esses comandos sejam necessários para Troubleshooting, a máquina de estado poderá ser ativada novamente nó por nó após um novo software ter sido carregado (o nó está no estado Atualizado). Todas as máquinas de estado re-permitidas devem ser desabilitadas antes da seção do runrev da elevação. As máquinas de estado podem ser reabilitadas usando os comandos on1 ou on2.

Tarefa 16 Carregue a nova revisão de software nas estações CWM (SV+)

Carregue a versão de software nova em estações CWM (SV+). Verifique se as imagens foram carregadas com êxito. Valide a imagem de revisão em cada estação CWM (SV+), emitindo o comando validate_image <filename.img>. Note que o nome de arquivo é diferente para switch IPX/IGX/BPX

  • O número da imagem IPX é anexado a um N.

  • O número de imagem IGX é adicionado com um G.

  • O número de imagem de BPX é adicionado com um B.

Tarefa 17 Altere os parâmetros cnfdlparm

Esta tarefa pode acelerar a fase de distribuição do software em uma atualização (Tarefa 19). Configurar os parâmetros Session Timeout (Intervalo de Sessão) e Request Hop Limit (Solicitar Limite de Nó) da seguinte maneira, usando o comando cnfdlparm. Se os Nós a ser promovidos são aglomerados na mesma região topológica da rede, os Nós do alvo (NON-CWM) podem ter o limite do salto do pedido reduzido a 4. Para determinar o número de saltos entre Nós, emita o comando drtop.

Estamos interessados nos campos de intervalo da sessão e de salto do comando cnfdlparm. Se os nós a ser atualizados estiverem na mesma área, poderemos o limite de nó requisitado. Para determinar o limite de nó da requisição, use o comando drtop.

  • Todos os nós da rede: Timeout de sessão 30000

  • Nós CWM (SV+): Limite de saltos de solicitação 1

  • Nós de destino (não-CWM): Limite 8 do salto do pedido

Tarefa 18 Pare todas as tarefas automáticas.

Apague ou desabilite todos os trabalhos automáticos que foram configurados nos nós IPX/IGX/BPX alvo.

Mais detalhes sobre trabalhos automáticos podem ser obtidos no manual de referência de comando relevante à versão de software em uso.

Tarefa 19 Carregue uma nova revisão nos nós de rede de destino.

Isto é realizado executando o comando loadrev <new_revision> <node_name> em cada um dos nós de destino.

O download do software é concluído quando o comando dsprevs mostra todos os nós redundantes como tendo uma revisão primária em execução e uma revisão secundária atualizada. A revisão secundária deve corresponder à revisão utilizada no comando loadrev. Para obter mais informações sobre o status da placa do processador durante uma atualização de software de switch, consulte Active and Standby Control Card States During a WAN Switch Software Upgrade.

Nós não redundantes mostram a revisão secundária como sendo carregada e não atualizada.

As falhas conectadas com a programação da memória programável somente de leitura apagável eletricamente da placa de processador (EEPROM) conduzem aos alarmes de falha flash conjuntamente com erros de software. Em caso de tal alarme, tente o processo loadrev novamente. Use o comando loadrev trazer o nó de volta à liberação de software atual que é executado na rede. A sintaxe do comando é:

<node_name> do <current_running_revision> do loadrev

Digite o comando e, em seguida, reinicie a tarefa 19. Qualquer falha adicional irá requerer a substituição da placa atualmente Ativa. Neste caso, como antes, emita o comando loadrev restaurar o nó ao software release running atual. Depois que o comando loadrev é emitido, verifique que o nó é estável emitindo os comandos dspcds and dsprevs. O comando dspcds deve indicar o Active e as placas do processador em standby. O comando dsprevs deve indicar somente o software release running atual para o nó. Depois que o nó é estável, inscreva o comando switchcc. (Era o processador ativo) a placa de processador à espera pode agora ser substituída.

Consulte o Apêndice C.

Tarefa 20 Valide a gravação de placa do processador.

Nota:  Esta etapa é ser processadores em standby executados do nó de destino é promovida afinal. Consulte a tarefa 19.

Valide a gravação de placa do processador em todos os nós de destino, executando a seguinte tarefa:

  1. Execute o comando chkflash

  2. Quando o prompt de comando retornar, verifique o registro de erro do software para quaisquer erros registrados como um resultado do comando chkflash (verificar a estampa de tempo de erro).

  3. Se o comando chkflash falhar, os erros de software 872, 873 ou 874 serão registrados, mas outros erros também poderão ocorrer.

  4. Todos os erros devem ser relatados ao Suporte técnico de Cisco. Não continue o processo de upgrade. É possível que a revisão do software no nó ou nos nós que registraram os erros esteja corrompida.

Tarefa 21 Defina os parâmetros na preparação para a atualização de rede.

Consulte o Anexo E para alterações no parâmetro.

Inclua as alterações não padrão necessárias identificadas nas tarefas 2 e 3.

Tarefa 22 Remova a causa de todos os principais alarmes e, se possível, todos os alarmes secundários.

Idealmente, a rede deve ser alarme livre na altura do upgrade de software (tarefa 25). Se isso não for possível, ao menos a razão para todos os alarmes principais deve ser identificada e anotada e, depois, uma reconfiguração adequada deve ser feita para remover o alarme. Verifique os modelos de carga de nós de destino, emitindo os comandos chklm e dsplm, conforme descrito no Apêndice A.

Nota: A reconfiguração adequada não deve envolver alterações de configuração por meio de CLI ou de CWM (SV+) nos nós IGX/BPX/IPX enquanto uma placa de processador se encontra no estado Atualizada.

Qualquer alarme secundário deve ser observado de forma que, depois da atualização, possa ser feita uma comparação.

Nota: Uma upgrade de software de switch não deve ser tentada quando houver uns nós inalcançável na rede.

Tarefa 23 Feche as estações de CWM (SV+) - reconfigure se for necessário.

Para uma atualização de rede completa, todas as estações de trabalho CWM (SV+) devem ser encerradas. Isto é conseguido selecionando a opção central da parada do menu principal CWM (SV+). Parar obter atualização parcial da rede, esta tarefa pode não ser necessária.

Qualquer tipo de reconfiguração obrigatória a fim de que o CWM (SV+) funcione com a nova versão de software deve ser feita neste momento.

Tarefa 24 Se necessário, implemente soluções identificadas nas tarefas 2 e 3.

Todas as soluções necessárias para uma atualização grátis foram identificadas nas tarefas 2 e 3.

Tarefa 25 Atualize o software de switch caso a rede fique estável durante 30 minutos.

Se nenhuma alteração de topologia ocorreu dentro da rede por um período de 30 minutos desde que a conclusão bem sucedida da tarefa 19 e etapas 20 a 24 estiveram terminadas com sucesso, execute

<node_name> do <new_revision> do runrev

de um dos nós de destino. Isto irá executar a nova versão em um nó da rede.

Para verificar a estabilidade do nó de destino, emita os seguintes comandos na ordem listada:

Comando Ação a ser executada
dspprf Verifique que a QUIETUDE RT é maior de 40. Se não é, contacte o Suporte técnico de Cisco.
dsprevs Verifique se as revisões de software corretas estão carregadas.
dspcds Verifique se as placas dos processadores estão no estado Ativo e bloqueado.
dspalms Verifique se não há alarmes principais (MAJOR) no nó de destino.

Nota: Desde que o processo de upgrade envolverá os origens de tempo de switching da rede temporariamente, deve ser tomado ao emitir o comando runrev no nó de rede numerada o mais alto. Coordene a elevação dos mais baixos e nós numerados os mais altos com o coordenador de vendas Cisco, o coordenador de sistemas, ou o gerenciador de conta.

Tarefa 26 Permita que a rede estabeleça e execute testes de validação de rede.

Nota: Para obter informações adicionais sobre o intervalo runrev para usuários avançados, leia o Apêndice G.

Deixe os processadores de nó de destino terminam todas as tarefas de atualização de gerenciamento. O tempo total gasto depende do número de nós da rede. Reserve pelo menos os minutos 10 pelo nó. Durante este período, o logon feito em nós por meio da interface de linha de comando (CLI) deve ser mantido a um nível mínimo.

Depois de 10 minutos, efetue login no nó de destino e verifique a saúde usando os comandos a seguir.

Emita os comandos na ordem listada.

Comando Ação a ser executada
dspprf Verifique que a QUIETUDE RT é maior de 40. Se não é, contacte o Suporte técnico de Cisco.
dsprevs Verifique se as revisões de software corretas estão carregadas.
dspalms Verifique se não há alarmes principais (MAJOR) no nó de destino.
dspcds Verifique se o processador está no estado Bloqueado e se nenhuma placa está no estado Falha.
dspswlog Verifique novos erros de software.
dspswlog s Verifique novos erros de software.
dspcderrs Verifique novos erros da placa.
dsptrks Verifique o estado de todos os troncos.
dspnds Verifique se existem nós não acessíveis.
dspnode Verifique o status das prateleiras do Alimentador (se aplicável).
dspsloterrs Verifique novos erros de slot.

Nota: Várias máquinas de estado foram desabilitadas nesta Tarefa 15, portanto, comandos como dspportstats e dspchstats não funcionaram.

Esse período fornece um tempo ideal para a execução de testes a fim de verificar se o novo software está funcionando corretamente.

Interrogue todos os sistemas de gerenciamento externo que são usados para controlar todo o Roteadores que for conectado à rede IPX/IGX/BPX. Essa questão é feita para certificar-se de que todos os dispositivos sejam alcançáveis.

Se possível, usuários finais devem ser contatados e solicitados a verificar se todas as conexões de rede estão funcionando adequadamente.

Nota: No evento improvável que uma decisão é tomada para reverter de volta à revisão do software anterior, o Suporte técnico de Cisco deve ser contactado antes do interruptor à revisão velha. A informação importante a respeito de porque o software novo não está funcionando corretamente será perdida após a comutação de volta à revisão velha.

Tarefa 27 Desbloqueie processadores em standby

Repita as tarefas 25, 25 e 27 para cada um dos nós que estão sendo atualizados. Defina um tempo suficiente entre atualizações individuais de nó para verificar a estabilidade do nó e executar testes operacionais. Consulte o Apêndice F.

Tarefa 28 Configure parâmetros operacionais.

Todos os parâmetros alterados nas Tarefas 12, 17 e 21 deverão ser revertidos às suas configurações originais, conforme capturado na Tarefa 6;

Nota: Os comandos reais usados para mudar os parâmetros podem ter mudado. Além disso, pode ser necessário ajustar outros parâmetros para uma operação correta da rede durante a execução da nova versão de software. Consulte as notas de versão para verificar as recomendações para coordenação e novos valores padrão.

Tarefa 29 Reinicie as estações CWM (SV+).

Selecione a opção Start Core no menu principal do CWM (SV+).

Tarefa 30 Verificação de saúde de rede

consulte o Apêndice A

Tarefa 31 Reiniciar coleta de estatísticas.

Reinicie o Statistics Collection Manager (SCM), selecionando a opção relevante no menu principal do CWM (SV+).

Selecione todas as estatísticas relevantes (consulte as notas feitas na Tarefa 13). Faça o seguinte:

  1. No menu suspenso Configurar, selecione stats habilitados.

  2. Verifique todos os grupos de estatísticas e, em seguida, mova os tipos de estatística necessários para a seção selecionada.

  3. Envia um stats enable a todos os nós com o seguinte procedimento:

    • No menu suspenso config, escolha a seleção de nó.

    • Verifique se todos os nós foram selecionados, pressione o botão de seleção Send Stats Enable (Enviar Estatísticas Habilitadas) e, em seguida, clique em OK.

    • Monitore as janelas de solicitações de saída / respostas de entrada dentro da janela principal de SCM para assegurar que um SNMP put seja enviado para todos os nós e uma reposta OK correspondente é recebida de volta.

  4. Digite o comando -config.

  5. Insira o comando -node.

  6. Verifique se todos os nós foram selecionados, pressione o botão de seleção Start Statistics Collection (Iniciar Coleção de Estatísticas) e, em seguida, clique em OK.

Tarefa 32 Reinicie todos os trabalhos automáticos.

Todos os trabalhos automáticos configurados nos nós IPX/IGX/BPX de destino devem ser novamente habilitados. Essa ação também se aplica aos trabalhos do cron nas estações CWM (SV+).

Outros detalhes sobre tarefas podem ser obtidos no manual de referência de comandos que é relevante à versão do software que está sendo usado.

Tarefa 33 Salve a configuração de rede.

Veja a Tarefa 12.

Tarefa 34 Provisionamento de freeze ends.

Apêndice A, Tarefa 6: Verificação de saúde de rede

Siga estas instruções.

  1. Examine os parâmetros usando os comandos seguintes. Configurações devem ser consistentes em todos os nós do mesmo tipo dentro da rede. Diferenças de documento e qualquer variação a partir de valores padrão.

    • cnfnodeparm

    • cnfcmparm

    • cnfdlparm

    • cnffstparm

    • cnfdiagparm

    • cnftstparm

    • cnfprfparm

    • on1

    • on2

    • on3

    • cnfsysparm (é necessário verificar apenas um nó, pois as configurações abrangem toda a rede)

    • cnffunc

    • dspmnupdt

    • cnftlparm (8.4 e posterior)

    • cnfsnmp

    • cnfcmb (o IGX/IPX somente, ajustes é a rede largamente)

    As diferenças de parâmetro entre os nós do mesmo tipo e variações dos padrões devem ser avaliadas para assegurar que não afetem a atualização de software. Contacte o Suporte técnico de Cisco se o conselho é exigido.

  2. Rede de auditoria para erros de software recente (placas de controlador ativas e em standby), tempo ocioso da CPU, erros em placas, inconsistências de modelo de carga, erros e alarmes de tronco. Utilize os seguintes comandos para realizar essas tarefas:

    • dspswlog

    • dspswlog s

    • dspcderrs ou o <slot-> dos dspcderrs

    • dsptrkerrs

    • dspalms, dspslotalms, dspbuses, dspsloterrs (para o BPX somente)

    • dspprf, ou dspprfhist

    Utilize esses comandos para verificar a quantidade de tempo livre que uma CPU de nó tem. Esses comandos mostram o tempo total da CPU que cada processo está usando a cada 20 segundos. Neste caso, o igx16 do nó é inativo para aproximadamente 88% do tempo. Uma exibição típica é mostrada abaixo:

    igx16   TN   StrataCom   IGX 16    8.2.56   Oct. 13 1997 17:47 GMT
            
    Active    0   262079990   -20   262059990   -40   262039990 Current
            
    Proc   RT  HSds LSds      RT  HSds LSds        RT  HSds LSds 
    IDLE   88   43    0       89   46    0         88   65    0 
    RSRC    0   12    0       0   13    0          0   15    0 
    CBUS    0   76    0       0   75    0          0   78    0 
    NETW    0   53    0       0   48    0          0   58    0 
    TRNS    2  199    0       2  187    0          2  216    0 
    FAIL    4    8    0       3    4    0          4    2    0 
    SNMP    0    0    0       0    0    0          0    1    0 
    PROT    0    0    0       0    2    0          0    1    0 
    TXIO    0    0    0       0    0    0          0    0    0 
    ILMI    0    0    0       0    0    0          0    0    0 
    SUMM    2    4    0       3    1    0          2    2    
    
    • chklm ou dsplm : Estes comandos comparam seções do base de dados do nó atual com todos Nós restantes na rede. Execute o comando chklm em cada nó da rede, em seqüência. Quando terminar, retorne ao primeiro nó e execute o comando dsplm. Uma saída de exemplo é mostrada abaixo:

      igx16   TN   StrataCom   IGX 16   8.2.56   Oct. 13 1997 17:52 GMT 
      
      Nd T L C LC 
      32 P P P P  

      Este exemplo é tomado de uma rede que contenha dois Nós:

      NodeName J/Num
      
      igx16     /16
      igx32     /32
      

      A saída do comando dsplm, executado em igx16, mostra os resultados da comparação entre certas seções do banco de dados de igx16 e de igx32. Nesse caso, o P na saída significa passar, o que indica que está tudo em ordem. Todas as falhas são indicadas por um F na tela de saída do comando dsplm.

      Nota: Com relação a versões de software acima de 8.4, o comando dsplm fornecerá resultados incorretos se a topologia de rede tiver sido alterada recentemente.

Siga estas instruções.

  1. Investigue o seguinte:

    • Erros recentes de software: Todos os Nós que continuamente registrarem erros ou tiverem erros recentes registrados devem ser relatados ao Suporte técnico de Cisco.

    • Erros de placas: Os cartões que estão registrando o auto/falhas de teste de fundo ou têm um histórico de erro de hardware devem ser investigados pelo Suporte técnico de Cisco.

    • Nós com menos de 40% de tempo ocioso da CUP (20% no caso de PCCs): Geralmente, não são encontrados dentro de redes BPX/IGX/IPX. Estes nós devem ser examinados rigorosamente. Se o tempo ocioso é consistentemente baixo, você deve contactar o Suporte técnico de Cisco.

    • Falhas do modelo de carga: Estes devem ser relatados ao Suporte técnico de Cisco. Lembre-se de que a versão 8.4 do software e acima usam tronco com base em carregamento e podem exibir as falhas do modelo de carga brevemente depois de alterações na topologia da rede.

    • Qualquer tronco que estiver registrando erros: Deve ser fixo ou configurado para não passar tráfego de gerenciamento durante o período de duração da atualização.

    • Todos os alarmes devem ser considerados. A finalidade real dessa verificação é garantir que não haja alarmes, tais como falhas de barramento, que exigem intervenção especial antes da atualização.

  2. Garanta que nenhuma correção necessária seja feita antes do início da atualização.

  3. O local de quaisquer tarefas automáticas deve ser anotado, já que deverão ser removidos durante a atualização.

Tarefa 7 do apêndice B: Teste de placa de controle em standby

Essa tarefa levará aproximadamente 60 minutos por nó, dependendo do tamanho da rede.

  1. Entre como o serviço a cada IPX/IGX/BPX na rede por sua vez e verifique que processador é ativo e qual está no apoio emitindo o comando dspcds.

  2. Verifique a redundância CC em cada IPX/IGX/BPX. Emita o comando cnfnodeparm e inspecione o campo CC Redundancy Cnfged para Y. Y no campo CC Redundancy Cnfged indica que a redundância CC está habilitada. Se a redundância CC não estiver habilitada, investigue e habilite outra vez, se possível.

  3. Emita o comando resetcd <número_da_placa> h para reiniciar o processador de standby

    Nota: Se ocorrer um erro na redefinição da placa ativa, o nó será recriado.

  4. Depois que o NPC/NPM/BCC voltar para o modo Standby, verifique os registros do software para obter erros recentes, emitindo os comandos dspswlog e dspswlog s. Uma falha de programação flash causará um alarme e um interruptor da placa de controle. Relate tais ocorrências ao Suporte técnico de Cisco.

  5. Quando a placa de redefinição voltou para Standby:

    • Emita o comando dspqs verificar se há alguma atualização pendente.

    • Se não há nenhuma atualização pendente, emita o comando switchcc, que comutará ao processador em standby.

    • O switchcc desligará a sessão atual.

  6. Faça o registro novamente no IPX/IGX/BPX e monitore a integridade da rede. A placa em Standby passará pelos seguintes estados: Descargador, atualização, à espera. A atualização da placa em standby pode tomar enquanto 3 horas a terminar para cada nó, assim que o tempo devem ser programados em conformidade.

  7. Depois que o NPC/NPM/BCC voltar para o modo Standby, verifique os registros do software para obter erros recentes, emitindo os comandos dspswlog e dspswlog s. Uma falha de programação de flash provocará um alarme e um switch de placa controladora. Relate tais ocorrências ao Suporte técnico de Cisco.

  8. Este procedimento deve ser repetido para cada nó que está sendo atualizado na rede, um nó por vez. Assegure-se de que a placa em standby de cada nó saia do modo de atualização antes de continuar ao próximo nó. Quando o nó do gateway for comutado, a comunicação entre o CWM (SV+) e a rede será temporariamente perdida.

    Nota: No caso dos BPX, recomenda-se que a placa ativa no início de uma elevação (comando do first loadrev) está no entalhe 8.

Tarefa 19 do C do apêndice: Procedimento para carregar a nova revisão na rede

Há dois casos a considerar ao terminar a tarefa 19. Ambos estão listados abaixo e se referem à seguinte topologia:

/image/gif/paws/10843/wan_switch_software_upgrade_node.gif

Caso 1

Se houver uma estação de trabalho CWM (SV+) (indicada pelo prefixo SV+ na imagem de topologia acima) anexada a cada um dos tipos de nós na rede, a Tarefa 19 será facilmente realizada.

Para transferir a revisão do software nova a um de cada tipo de nó na rede acima, supondo que todo o Switches tem configurações padrão e as estações de trabalho CWM (SV+) têm a revisão do software correta carregada, a necessidade dos comandos seguintes executada de algum nó:

  • loadrev <new_revision>BPX1

  • loadrev <new_revision>IGX2

  • loadrev <nova revisão> IPX

Caso 2

Referindo a topologia acima, se o SV+2 e o SV+3 não existem, e novas revisões do software para todos os tipos de switch reside somente no SV+1, a conclusão da tarefa 19 exige uma quantidade pequena de reconfiguração a algum Switches.

O download é iniciado pela execução dos mesmos comandos usados no Caso 1, mas isso por si só resultará apenas no software sendo carregado para IPX. Para carregar o novo software no IGX2 e BPX1, deve ocorrer a seguinte reconfiguração:

  1. Digite o comando cnffunc em ambos os nós, o que irá habilitar o download da função strataview remota.

  2. Use o comando drtop para verificar o número de saltos entre os nós-alvo. O IGX2 está mais de um nó distante do IPX, o nó ao qual a estação CWM (SV+) está conectada. Para acomodar essa distância maior em IGX2, o parâmetro Request Hop Limit (Limite de Nó de Solicitação) deve ser definido para a contagem real de nós (neste caso, 2), utilizando o comando cnfdlparm.

  3. Quando o download do software estiver concluído, reverta qualquer alteração feita.

No Caso 1 e no Caso 2, o download do software é concluído de uma só vez:

  • A saída do comando dsprevs mostra o nó como tendo uma revisão principal sendo executada.

  • Uma revisão secundária Atualizada, que corresponda à revisão utilizada no comando loadrev.

Nota: Os nós não redundantes (Nós com um processador) mostrarão a revisão secundária como sendo carregado e não promovido. Por exemplo, suponha que o BPX1 na topologia acima tenha apenas uma placa de processador. A saída do comando dsprevs após a conclusão do download do software mostraria o seguinte (em que 8.4.09 é a nova revisão do software e 8.1.71 é a revisão atual):

BPX1    TN       StrataCom      BPX 15    8.1.71       Oct. 13 1997 17:20 GMT 

                  ------ Primary ------       ----- Secondary ----- 


NodeName          Status     Revision         Status     Revision 

IGX2              Running    8.1.71           Upgraded   8.4.09 
BPX1              Running    8.1.71           Loaded     8.4.09 
IPX               Running    8.1.71           Upgraded   8.4.09 
BPX2              Running    8.1.71 
IGX1              Running    8.1.71 
Failures connected with the programming of the card's electrically erasable programmable 
read-only memory (EEPROM) will result in Flash failure alarms in conjunction with 
software errors. In the event of such an alarm, try the loadrev process again. 
Any further failures will require the card to be replaced. 

Quando o download do software estiver concluído (veja acima), valide a operação do software, executando as seguintes tarefas:

  1. Execute o comando chkflash nos nós com a nova revisão de software.

  2. Quando os retornos do comando prompt, verificarem as entradas de log de erros de software e os timestamps para ver se há todos os erros registrados em consequência do comando chkflash. Para isso, introduza o comando dspswlog.

Os erros devem ser relatados ao Suporte técnico de Cisco. Não continue o processo de atualização, já que é possível que a revisão do software no nó / nós com erros registrados esteja corrompida.

Tarefa 13 do apêndice D: Procedimento para desabilitar a coleta de estatísticas de CWM (SV+) TFTP

Essa tarefa só precisa ser executada nos nós que serão atualizados. Se o 10 fora de 100 Nós será promovido, a coleta de estatística precisa somente de ser desabilitada nos nós de destino 10.

  1. Determinando o status do conjunto de estatísticas.

    Verifique se a coleta de estatísticas está desabilitada ou habilitada digitando o comando dspstatparms em cada nó na rede. O exemplo de saída é mostra abaixo com a coleção de stats: estado no texto em negrito.

    igx16      TN       StrataCom        IGX 16     8.1.71        Date/Time Not Set 
    
    Statistics Configuration Parameters
    
    TFTP Retry Count:             3     TFTP Read Grant Delay (sec):      1
    TFTP ACK time-out (sec):     10     Enable Date:     00/00/00 00:00:00
    Bucket Interval:              0     Enabled from: not enabled
    File Interval:                0     Rt Interval:     00/00/00 00:00 GMT
    Peak Enable Flag:       DISABLED    Nt Second Offset:                 0
    Object Count:                 0          STATS COLLECTION: DISABLED
    Object Subtype Counts:    0 0 0 0        STANDBY UPDATES: ENABLED
    Total File Memory Used:       0 
    Number of File Allocated:     0 
    Current File Size:          531
    Stat Memory Allocated:        0 
    Auto Memory Allocated:        0 
    Auto Mem Rgn Size:       153600 
    
    Last Command: dspstatparm

    Como é mostrado acima, no lado direito do indicador a coleção de stats do campo: indica o status atual. Em umas liberações mais atrasadas do software este campo é chamado estatísticas de intervalo: e tem a informação adicional no número real de estatísticas permitido.

    Se a coleta de estatísticas for identificada como habilitada, continue as etapas restantes.

  2. Desative a coleta de estatísticas.

    1. Na estação de trabalho mestre de estatística, abra a janela de gerenciador de estatística StrataView. Se o SCM não estiver em execução nesta máquina, ele terá de ser iniciado no menu principal do CWM (SV+).

    2. Dentro da principal janela do SCM, selecione config seguido pela seleção Nó. Todos os nós de destino devem aparecer na caixa Selected Nodes do lado direito da tela. Se não aparecerem, clique na seta à direita, ao lado de cada nó de destino.

    3. Sob a caixa de ação seleta, comprima o botão de rádio da coleta de estatística da parada e feche então a caixa clicando o botão OK.

    4. Na principal janela do SCM, o campo Current Status deve mostrar Stopped.

    5. Registre todas as Estatísticas Selecionadas, de modo que possam ser novamente habilitadas após a atualização.

    6. Selecione config, Stats Enable e selecione cada um dos grupos de estatísticas sucessivamente.

  3. Abaixo de cada grupo de estatística existe uma janela Ativar/desativar estatísticas. Nessa janela há um botão Statistics Type (Tipos de estatística) que lista todas as categorias desse grupo específico. Por exemplo, as seguintes categorias existem no grupo de conexões:

    • Voz

    • Dados

    • Frame Relay

    • ALMOFADA rápida

    • ASI

    • Frame Relay do AXIS

    • Conexão ATM

    • Conexão CE

  4. Cada categoria deve ser selecionada, e qualquer estatística selecionada deve ser movida para a janela Unselected. Quando todas as categorias tiverem sido verificadas, feche a janela Enable / Disable) desse grupo e continue na próxima e repita.

  5. Quando todos os grupos estiverem marcados, todos os tipos de estatísticas devem ter a seleção anulada. Assegure-se de que todas as janelas Enable/Disable estejam fechadas e, em seguida, selecione Config seguido por Node Selection de dentro da janela principal SCM. Essa ação seleciona os nós cujas estatísticas precisam ser reabilitadas.

  6. A mensagem Stats Enable deverá ser enviada para cada um dos nós de destino. A mensagem Stats Enable deve ser enviada para no máximo 10 nós por vez. Para isso, faça o seguinte:

    1. Clique sobre toda a seta esquerda ao lado da palavra para deselect todos os Nós.

    2. Realce os nós de destino na lista (até 10 nós) e mova-os até a caixa Selecionado clicando na seta à direita ao lado da palavra Selecionado.

    3. Na caixa Select Action, clique no botão de rádio Send Stats Enable e, em seguida, clique no botão Apply.

    4. Monitora a janela Solicitações de Saída/Repostas de Entrada para garantir que um resultado do SNMP seja enviado a todos os nós e uma resposta OK correspondente seja recebida de volta.

    5. Repita essa ação para os próximos dez nós na lista.

    6. Quando todos os nós forem processados, selecione o botão OK para fechar a janela.

  7. Verifique se a coleção de estatísticas em todos os nós está desativada digitando o comando dspstatparms em cada nó da rede. Este comando deve mostrar a coleção de stats: DESABILITADO. Se esse não for o caso, reenvie a mensagem de Habilitação de Estatísticas para os nós habilitados individualmente, como você fez acima. Se a coleta de estatística é mostrada ainda como PERMITIDA, contacte o Suporte técnico de Cisco.

Tarefa 21 do apêndice E: Ajuste parâmetros

As alterações listadas abaixo são as recomendadas na preparação para uma atualização de software de switching. Todos os outros parâmetros devem estar nas configurações padrão do software operacional atual. Uma exceção a esta seria os parâmetros que, sendo identificado como sendo diferentes dos padrões durante a verificação de saúde de rede, foram julgados subseqüentemente para não ter um impacto em uma upgrade de software de switch.

Nota: O ponto no qual os parâmetros a seguir aparecem em um comando pode variar de uma versão para outra do software.

IPX e IGX

Comando: cnfnodeparm

Parâmetro Valor para upgrade
Retardo inicial de atualização 10000
Retardo por nó de atualização 60000
Retardo no teste de ruptura Comm 60000
Período de intervalo de rede 10000
Intervalos normais de num 50
Intervalo de falha de com. 30000
Multiplicador de falha de com. 6
Cronômetro de atualização em standby 15
Atualizações em standy por passagem 20
Cronômetro de ID de gateway 90
GLCON Alloc Timer 90
Retardo de falha de com. 240

Comando: cnfdlparm

Parâmetro Valor para upgrade
Intervalo de sessão 30000
Solicitar limite de salto (aplicável apenas para loadrev) 4

Comando: cnffunc

Parâmetro Valor para upgrade
Registro dos eventos de conexão em um registro de eventos local Desabilitado
Registro dos eventos de conexão em um registro de eventos de CWM (SV+) Desabilitado

Comando: off1/on1

Parâmetro Valor para upgrade
Terminal em standby habilitado
Line Diag Desabilitado
Eleição de modem Desabilitado
Conn Stat Sampling Desabilitado

Comando: off2 / on2

Parâmetro Valor para upgrade
Exemplos de estatística (exemplo de estado de linha) Desabilitado
Alarme estatístico Desabilitado
Verificador de trabalho pronto Desabilitado
Monitor da fonte de alimentação Desabilitado
FRP Port Sampling (Port Stat Sampling) Desabilitado
Atualizações robustas Desabilitado
Atualizações de alarme robusto Desabilitado
Contadores de tempo real Desabilitado
Atualizar estatísticas de standby Desabilitado
ID de junção Desabilitado

Comando: cnffstparm

Tempo de medida do RTD 255

Comando: cnftstparm

Desligue autotestes e testes de segundo plano para todos os tipos de placas

BPX

Comando: cnfnodeparm

Parâmetro Valor para upgrade
Retardo inicial de atualização 10000
Retardo por nó de atualização 60000
Retardo no teste de ruptura Comm 60000
Período de intervalo de rede 10000
Intervalos normais de num 50
Intervalo de falha de com. 30000
Multiplicador de falha de com. 6
Cronômetro de atualização em standby 15
Cronômetro de ID de gateway 90
GLCON Alloc Timer 90
Retardo de falha de com. 240

Comando: cnfdlparm

Parâmetro Valor para upgrade
Intervalo de sessão 30000
Solicitar limite de salto (aplicável apenas para loadrev) 4

Comando: cnffunc

Parâmetro Valor para upgrade
Registro dos eventos de conexão em um registro de eventos local Desabilitado
Registro dos eventos de conexão em um registro de eventos de CWM (SV+) Desabilitado

Comando: off1/on1

Parâmetro Valor para upgrade
Terminal em standby habilitado
Line Diag Desabilitado
Conn Stat Sampling Desabilitado

Comando: off2 / on2

Parâmetro Valor para upgrade
Exemplos de estatística (exemplo de estado de linha) Desabilitado
Alarme estatístico Desabilitado
Verificador de trabalho pronto Desabilitado
Card Statistical Alms Desabilitado
Amostragem de stat de placa Desabilitado
Exemplo de porta ASI (amostragem de status de porta) Desabilitado
Atualizações robustas Desabilitado
Atualizações de alarme robusto Desabilitado
Contadores de tempo real Desabilitado
Atualizar estatísticas de standby Desabilitado
ID de junção Desabilitado

Comando: cnftstparm

Desligue autotestes e testes de segundo plano para todos os tipos de placas

Tarefa 27 do apêndice F: Destravar os processadores em standby

Este procedimento garante que uma falha de Flash no processador Ativo resultará apenas em uma comutação da placa do processador, e não em uma recriação do nó.

  1. Faça logon em cada um dos nós-alvo e execute o comando a seguir:

    <node_name> do loadrev X.X.X (x.x.x é um nome de revisão de dummy)

    O nó declarará o revision X.X.X tão não disponível como x.x.x é uma liberação inexistente. Verifique isso digitando o comando dsprevs.

  2. Desabilite a redundância de placa de processador, ajustando o parâmetro da redundância Cnfged CC ao N. Para tanto, digite o comando cnfnodeparm. Isso fará com que o processo de atualização de NPC/NPM/BCC em espera seja iniciado.

    Nota: Aguarde o cartão entrar no estado Standby (Espera).

  3. Reabilite a redundância de placa do processador configurando o parâmetro CC Redundancy Cnfged como Y. Para tanto, digite o comando cnfnodeparm.

  4. Ative o processo de operação utilizando o seguinte comando:

    <new_revision><node_name> do loadrev

  5. Emita o comando dspdnld e verifique que o flash começa apagar.

Apêndice G: Informação adicional no intervalo runrev

Nota: A falha monitora corretamente a rede poderia conduzir a uma parada de rede.

Use o intervalo runrev mencionado na seção do documento principal acima no procedimento de upgrade. Nas redes grandes, as tarefas runrev poderiam tomar um muito tempo terminar; consequentemente, se necessário realmente, diminua o intervalo runrev do padrão. Estão abaixo algumas diretrizes para ajustar este intervalo. Estas diretrizes devem ser usadas cautelosamente e a rede deve proximamente ser monitorada.

O intervalo seguro entre cada tarefas runrev depende sobre se a rede grande é nacional ou international e o grau de entroncamento.

Única linha cada tarefas runrev que começam com os 10-5 minutos pelo runrev nos Nós os maiores (o nó o maior é identificado pelo número mais elevado de conexões no nó). Se a elevação progride sem sinais de alarme, o intervalo entre tarefas runrev pode ser reduzido gradualmente a tão baixo quanto os intervalos um minutos.

Monitore a carga de CPU, o log, e atualizações usando comandos dspprfhist, dsplog, e dspqs. Monitore para sinais de alarme tais como Alarmes inalcançáveis devido ao mensagem de rede excessiva. Se o tempo ocioso está mostrado ser demasiado baixo (menos de 10%) com dspprfhist, a seguir suspenda o processo de upgrade e investigue o baixo tempo ocioso. Se o tempo ocioso retorna aos valores normais quando você suspende a elevação, a seguir continue com a elevação com um intervalo maior entre runrevs.

Um intervalo menos de um minuto entre runrevs faz difícil monitorar o dspprfhist, os dspqs, e o dsplog. Por exemplo cada intervalo dspprfhist é 20 segundos, e você deve monitorar pelo menos dois intervalos para olhar para uma tendência de downward. Consequentemente, não execute runrevs com um intervalo menos de um minuto.

O indicador do comando dsptech fornece uma visão geral concisa monitorando o interruptor.

Como exposto no procedimento de upgrade, feche o Cisco WAN Manager durante o processo de upgrade. Se você não faz este, certifique-se monitorar mais estritamente o nó de gateway.


Informações Relacionadas


Document ID: 10843