Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Atualização de um cluster de chassis usando atualização de software em serviço

Este tópico explica que o Upgrade de Software em Serviço (ISSU) permite um upgrade de software de uma versão do Junos OS para uma versão posterior do Junos OS, garantindo um tempo de inatividade mínimo.

Use o Explorador de Recursos para confirmar o suporte à plataforma e à versão para recursos específicos.

Consulte a seção Comportamento de upgrade de software em serviço específico da plataforma para ver anotações relacionadas à sua plataforma.

Consulte a seção Informações adicionais da plataforma para obter mais informações.

Entender o ISSU para um cluster de chassis

O upgrade de software em serviço (ISSU) permite um upgrade de uma versão do Junos OS para uma versão posterior do Junos OS com pouco ou nenhum tempo de inatividade. O ISSU é realizado apenas quando os dispositivos estão operando no modo de cluster de chassi.

O tempo de inatividade observado durante um evento de failover pode variar dependendo do ambiente de implantação e de vários fatores externos, incluindo:

  • A velocidade com que os dispositivos conectados processam e respondem a atualizações gratuitas de ARP (GARP).
  • Reaprendizado de endereço MAC e atualizações da tabela de encaminhamento em switches upstream e downstream.
  • Comportamento do aplicativo e os protocolos em uso (por exemplo, as sessões TCP podem se recuperar de forma diferente do tráfego baseado em UDP).

O recurso ISSU de cluster de chassi permite que ambos os dispositivos em um cluster sejam atualizados a partir de versões suportadas do Junos OS com o mínimo de interrupção de tráfego e sem interrupção de serviços, coordenando o processo de atualização entre os nós de cluster.

O ISSU oferece os seguintes benefícios:

  • Elimina o tempo de inatividade da rede durante atualizações de imagem de software

  • Reduz os custos operacionais e oferece níveis de serviço mais altos

  • Permite a implementação rápida de novos recursos

O ISSU tem as seguintes limitações:

  • O ISSU está disponível apenas para o Junos OS versão 10.4R4 ou posterior.

  • O ISSU não oferece suporte a downgrades de software.

  • Se você atualizar de uma versão do Junos OS que oferece suporte apenas a IPv4 para uma versão que oferece suporte a IPv4 e IPv6, o tráfego IPv4 continuará funcionando normalmente durante todo o processo de atualização. Se você atualizar de uma versão do Junos OS que oferece suporte a IPv4 e IPv6 para outra versão que também oferece suporte a ambos os protocolos, o tráfego IPv4 e IPv6 continua funcionando durante a atualização. As plataformas compatíveis com o Junos OS oferecem suporte ao processamento baseado em fluxo para tráfego IPv6.

  • Durante um ISSU, você não pode colocar nenhum PIC online. Você não pode executar operações como confirmar, reiniciar ou parar.

  • Durante um ISSU, operações como monitoramento de malha, recuperação de link de controle e preempção de RGX são suspensas.

  • Durante um ISSU, você não pode confirmar nenhuma configuração.

Para obter detalhes sobre o status de suporte ao ISSU, consulte o artigo da base de dados de conhecimento KB17946.

A sequência a seguir descreve o comportamento de um ISSU para dispositivos que operam em um cluster de chassi. A sequência se aplica quando o RG-0 é hospedado no nó 0, que é o nó primário. Você deve iniciar o ISSU a partir do nó primário RG-0. Se você tentar iniciar o ISSU a partir do nó 1 (o nó secundário RG-0), o sistema exibirá uma mensagem de erro e o upgrade não continuará.

  1. Failover do grupo de redundância inicial

    No início de um ISSU de cluster de chassi, o sistema faz failover automaticamente de todos os grupos de redundância RG-1 e superior (RG-1+) que ainda não são primários no nó a partir do qual o ISSU é iniciado. Essa ação garante que todos os grupos de redundância se tornem ativos no nó primário RG-0 antes do início do upgrade de software.

    O failover automático de todos os grupos de redundância RG-1+ é realizado pelo sistema. Se você estiver executando o Junos OS versão 18.1R1 ou anterior, deverá verificar manualmente — antes de iniciar o ISSU — se todos os grupos de redundância RG-1+ estão ativos no nó primário RG-0.

    Após o failover de todos os grupos de redundância RG-1+, o sistema define o bit de failover manual, impedindo a movimentação do grupo redundante durante a atualização. O sistema altera a prioridade do nó primário de todos os grupos de redundância RG-1+ para 255, independentemente de eles terem falhado para o nó primário RG-0 durante esta etapa.

  2. Durante um ISSU, o nó primário (nó 0) valida a configuração do dispositivo para garantir que ele possa ser confirmado com sucesso usando a nova versão do Junos OS. Como parte desse processo de validação, o sistema executa as seguintes verificações em ambos os nós:

    • Disponibilidade de espaço em disco no sistema de arquivos /var

    • Declarações de configuração sem suporte

    • Placas de interface física (PICs) não suportadas

    Se o espaço em disco disponível no /var sistema de arquivos de qualquer um dos Mecanismos de Roteamento for insuficiente, o processo ISSU falhará e retornará uma mensagem de erro, e a atualização não prosseguirá.

    PICs não suportados não impedem que o ISSU continue. No entanto, o software gera um aviso indicando que esses PICs serão reiniciados durante a atualização.

    Da mesma forma, a presença de uma configuração de protocolo não suportada não bloqueia o ISSU. Nesses casos, o software emite um aviso de que pode ocorrer perda de pacotes para o protocolo afetado durante o processo de atualização.

  3. Quando a validação é bem-sucedida, o daemon de sincronização de estado do kernel (ksyncd) sincroniza o kernel no nó secundário (nó 1) com o nó 0.

  4. O nó 1 é atualizado com a nova imagem de software. Antes de ser atualizado, o nó 1 obtém o arquivo de configuração do nó 0 e valida a configuração para garantir que ela possa ser confirmada usando a nova versão do software. Após ser atualizado, ele é ressincronizado com o nó 0.

  5. O processo de cluster de chassi (chassi) no nó 0 prepara outros processos de software para o lSSU. Quando todos os processos estão prontos, o chassi envia uma mensagem para os PICs instalados no dispositivo.

  6. O Mecanismo de Encaminhamento de Pacotes em cada Concentrador PIC Flexível (FPC) salva seu estado e baixa a nova imagem de software do nó 1. Em seguida, cada Mecanismo de Encaminhamento de Pacotes envia uma mensagem (unificada - ISSU pronta) para o chassi.

  7. Depois de receber a mensagem (pronta para ISSU unificado) de um Mecanismo de Encaminhamento de Pacotes, o chassi envia uma mensagem de reinicialização ao FPC no qual o Mecanismo de Encaminhamento de Pacotes reside. O FPC é reinicializado com a nova imagem de software. Depois que o FPC é reinicializado, o Mecanismo de Encaminhamento de Pacotes restaura o estado do FPC e um link interno de alta velocidade é estabelecido com o nó 1 executando o novo software. O chassi também é restabelecido com o nó 0.

  8. Depois que todos os mecanismos de encaminhamento de pacotes enviarem uma mensagem pronta usando o chassi no nó 0, outros processos de software serão preparados para uma comutação de nó. O sistema está pronto para uma transição neste momento.

  9. A comutação de nó ocorre e o nó 1 se torna o novo nó primário (até então o nó secundário 1).

  10. O novo nó secundário (até então nó primário 0) agora é atualizado para a nova imagem de software.

Quando ambos os nós são atualizados com êxito, o ISSU está completo.

Ao atualizar um cluster de chassis de uma versão do Junos OS que não oferece suporte à criptografia para uma versão que oferece suporte à criptografia, execute a atualização um nó de cada vez:

  1. Atualize o primeiro nó para a nova versão do Junos OS.

    Se a criptografia não estiver configurada e habilitada, a comunicação do cluster entre os dois nós permanecerá intacta, mesmo que eles estejam executando versões de software diferentes, e os serviços continuarão sem interrupção.

  2. Atualize o segundo nó para a mesma nova versão do Junos OS.

Depois que ambos os nós forem atualizados com êxito, você poderá optar por configurar e habilitar a criptografia conforme necessário.

Para downgrades para uma versão do Junos OS que não oferece suporte à criptografia, certifique-se de que a criptografia esteja desativada antes de iniciar o downgrade. Desabilitar a criptografia antes do downgrade evita falhas de comunicação entre:

  • um nó que ainda executa uma versão do Junos OS habilitada para criptografia, e
  • Um nó que foi rebaixado para uma versão sem suporte à criptografia.

Ao garantir que a criptografia esteja desabilitada em ambos os nós, a comunicação do cluster permanece não criptografada e operacional durante todo o processo de downgrade.

As políticas no Mecanismo de Roteamento e no Mecanismo de Encaminhamento de Pacotes devem estar em sincronia para que a configuração seja confirmada. Quando as configurações de política são modificadas e as políticas estão fora de sincronia, o sistema exibe uma mensagem de erro.

Como solução alternativa, você deve usar o request security policies resync comando para sincronizar a configuração de políticas de segurança no Mecanismo de Roteamento e no Mecanismo de Encaminhamento de Pacotes, caso você perceba que as políticas de segurança estão fora de sincronia após uma atualização.

Requisitos do sistema ISSU

Você pode usar o ISSU para atualizar de uma versão de software compatível com ISSU para uma versão posterior.

Para realizar um ISSU, seu dispositivo deve estar executando uma versão do Junos OS que ofereça suporte ao ISSU para a plataforma específica.

Veja a seção Entendendo o ISSU para um cluster de chassis para obter mais informações.

Para obter detalhes adicionais sobre o suporte e as limitações do ISSU, consulte Limitações de atualização do ISSU/ICU em dispositivos da Série SRX.

A seguir estão as limitações ao executar um ISSU:

  • O processo ISSU será encerrado se a versão do Junos OS especificada para instalação for anterior à versão atualmente em execução no dispositivo.

  • O ISSU será encerrado se a atualização especificada entrar em conflito com:

    • A configuração atual do dispositivo

    • Componentes de hardware suportados

    • Outras dependências de plataforma ou software

  • O ISSU não oferece suporte a pacotes de aplicativos de extensão desenvolvidos usando o Junos OS SDK.

  • O ISSU não oferece suporte ao downgrade de versão em todos os firewalls.

  • O ISSU pode falhar sob carga pesada da CPU e é recomendável garantir recursos adequados do sistema antes de iniciar a atualização.

Para fazer o downgrade de uma versão do Junos OS compatível com ISSU para uma versão anterior (seja compatível com ISSU ou não), use o request system software add comando.

Ao contrário de uma atualização de ISSU, um downgrade pode causar interrupções na rede.

Também existe o risco de perda de dados durante o processo de downgrade.

Planeje os downgrades com cuidado e certifique-se de que os backups adequados sejam feitos antes de prosseguir.

É altamente recomendável que você execute o ISSU nas seguintes condições:

  • Quando os nós primário e secundário estão íntegros

  • Durante o período de manutenção do sistema

  • Durante o menor período de tráfego possível

  • Quando o uso da CPU do Mecanismo de Roteamento for inferior a 40 por cento

Em cenários em que o ISSU não é suportado ou não é recomendado, mas o tempo de inatividade de atualização do sistema ainda precisa ser minimizado, o procedimento de atualização de tempo de inatividade mínimo pode ser usado, consulte o artigo relevante da base de conhecimento KB17947.

Atualizar ambos os dispositivos em um cluster de chassi usando ISSU

Antes de iniciar o ISSU para atualizar ambos os dispositivos, observe as seguintes diretrizes:

  • Certifique-se de que os seguintes requisitos de pré-verificação do ISSU sejam atendidos:

    • A prioridade de todos os grupos de redundância é maior que 0

    • Todos os grupos de redundância são primários ou secundários no estado

    • Existe espaço suficiente (o dobro do tamanho da imagem) disponível no /var/tmp

    • O uso da CPU é inferior a 80% no período de 5 segundos

    Se os requisitos de pré-verificação não forem atendidos, o ISSU terminará no início.

  • Faça backup do software usando o request system snapshot comando em cada Mecanismo de Roteamento para fazer backup do software do sistema no disco rígido do dispositivo.

  • Se você estiver usando o Junos OS Release 18.1R1 ou anterior, antes de iniciar o ISSU, defina o failover para todos os grupos de redundância para que todos estejam ativos em apenas um nó (primário). Veja iniciando um failover de grupo de redundância manual de cluster de chassi.

    Se você estiver executando o Junos OS Release 18.1 ou posterior, o sistema fará failover automaticamente de todos os RGs para o RG0 primário.

  • Recomendamos habilitar a reinicialização graciosa para todos os protocolos de roteamento antes de iniciar um ISSU para garantir o mínimo de interrupção do tráfego.

Em todos os firewalls suportados, o primeiro ISSU recomendado a partir da versão é o Junos OS Release 18.1R1.

O recurso ISSU de cluster de chassi permite que ambos os dispositivos em um cluster sejam atualizados a partir de versões do Junos OS suportadas com impacto de tráfego comparável ao de failovers de grupo de redundância.

Para realizar um ISSU a partir da CLI no Mecanismo de Roteamento2:

  1. Baixe o pacote de software do Juniper Networks Suporte website: https://www.juniper.net/support/downloads/
  2. Copie o pacote no nó primário do cluster. Recomendamos que você copie o pacote para o diretório /var/tmp , que é um grande sistema de arquivos no disco rígido. Observe que o nó de onde você inicia o ISSU deve ter a imagem do software.

    user@host>file copy ftp://username:prompt@ftp.hostname.net/filename /var/tmp/filename

  3. Verifique a versão atual do software em execução em ambos os nós emitindo o show version comando no nó primário.
  4. Inicie o ISSU a partir do nó que é primário para todos os grupos de redundância inserindo o seguinte comando:

    Aguarde até que ambos os nós concluam a atualização (após o que você será desconectado do dispositivo).

  5. Aguarde alguns minutos e faça login no dispositivo novamente. Verifique usando o show version comando se ambos os dispositivos no cluster estão executando a nova versão do Junos OS.
  6. Verifique se todas as políticas, zonas, grupos de redundância e outros objetos em tempo real (RTOs) retornam aos seus estados corretos.
  7. Torne o nó 0 o nó primário novamente emitindo o request chassis cluster failover node node-number redundancy-group group-number comando.

Se você quiser que os grupos de redundância revertam automaticamente para o nó 0 como primário após um upgrade de software em serviço (ISSU), deverá configurar as prioridades do grupo de redundância para que o nó 0 tenha a prioridade mais alta e habilitar a preempt opção.

Essa abordagem se aplica a todos os grupos de redundância, exceto o grupo de redundância 0 (RG0). Para RG0, o failover deve ser executado manualmente.

Para definir a prioridade do grupo de redundância e habilitar a opção, consulte Exemplo preempt : Configuração de grupos de redundância de cluster de chassi.

Para definir manualmente o failover de um grupo de redundância, consulte Iniciando um failover de grupo de redundância manual de cluster de chassi.

Durante a atualização, ambos os dispositivos podem experimentar failovers de grupo de redundância; no entanto, o tráfego não é interrompido. Antes de iniciar a atualização, cada dispositivo valida o pacote de atualização e verifica a compatibilidade da versão. Se o sistema detectar que a nova versão do pacote é incompatível com a versão instalada no momento, a atualização será rejeitada ou você será solicitado a tomar uma ação corretiva. Em alguns casos, um recurso específico pode ser incompatível, em tais situações, o software de atualização solicita que você encerre a atualização ou desative o recurso incompatível antes de continuar.

Se você planeja operar o Firewall como um dispositivo autônomo ou remover um nó de um cluster de chassi, certifique-se de que o procedimento ISSU foi totalmente encerrado em ambos os nós (se um ISSU foi iniciado).

Para iniciar o processo ISSU em dispositivos SRX5K com Mecanismo de Roteamento3 e em dispositivos SRX1600, SRX2300, SRX4120 e SRX4300:

  1. Execute o seguinte comando para iniciar o ISSU:

Veja também

Reverter dispositivos em um cluster de chassi após um ISSU

Se um ISSU não for concluído e apenas um dispositivo no cluster for atualizado, você poderá reverter para a configuração anterior apenas no dispositivo atualizado emitindo um dos seguintes comandos no dispositivo atualizado:

  • request chassis cluster in-service-upgrade abort

  • request system software rollback node node-id reboot

  • request system reboot

Habilitar um failback automático de nó de cluster de chassi após um ISSU

Se você quiser que os grupos de redundância retornem automaticamente ao nó 0 como primário após um upgrade de software em serviço (ISSU), deverá configurar a prioridade do grupo de redundância para que o nó 0 tenha a prioridade mais alta e habilitar a preempt opção.

Esse mecanismo se aplica a todos os grupos de redundância, exceto o grupo de redundância 0. O grupo de redundância 0 não oferece suporte à preempção automática e deve ser failover manualmente.

Para definir as prioridades do grupo de redundância e habilitar preempt a opção, consulte Exemplo: Configuração de grupos de redundância de cluster de chassi. Para iniciar manualmente o failover do grupo de aredundância, consulte Iniciando um failover de grupo de redundância manual de cluster de chassi.

Para concluir a atualização e disponibilizar o nó 0 no cluster de chassis após o ISSU, você deve reiniciar manualmente o nó 0. O nó 0 não é reinicializado automaticamente como parte do processo ISSU.

Registrar mensagens de erro usadas para solucionar problemas relacionados ao ISSU

Os problemas a seguir podem ocorrer durante uma atualização do ISSU. Você pode identificar os erros usando os detalhes nos logs. Para obter informações detalhadas sobre mensagens de log específicas do sistema, consulte Explorador de Logs do Sistema.

Erros de processo de chassi

Problema

Descrição

Erros relacionados ao chassi.

Solução

Use as mensagens de erro para entender os problemas relacionados ao chassi.

Quando o ISSU é iniciado, uma solicitação é enviada ao chassi para verificar se há algum problema relacionado ao ISSU do ponto de vista do chassi. Se houver um problema, uma mensagem de log será criada.

Tratamento de erros comuns para ISSU

Problema

Descrição

Você pode encontrar alguns problemas no decorrer de um ISSU. Esta seção fornece detalhes sobre como lidar com eles.

Solução

Quaisquer erros encontrados durante um ISSU geram mensagens de log, e o processo ISSU continua sem impacto no tráfego. Se for necessária uma reversão para uma versão anterior do Junos OS, o evento é registrado ou o processo ISSU é interrompido para evitar incompatibilidades de versão entre os nós no cluster de chassi. A Tabela 1 fornece algumas das condições de erro comuns e suas soluções alternativas correspondentes. As mensagens de log de exemplo mostradas na Tabela 1 são retiradas do dispositivo SRX1500, mas também são aplicáveis a todos os firewalls suportados.

Tabela 1: Erros e soluções relacionados ao ISSU

Condições de erro

Soluções

Tentativa de iniciar um ISSU quando a instância anterior de um ISSU já estiver em andamento

A seguinte mensagem é exibida:

warning: ISSU in progress

Você pode abortar o processo ISSU atual e iniciar o ISSU novamente usando o request chassis cluster in-service-upgrade abort comando.

Falha de reinicialização no nó secundário

Não ocorre nenhum tempo de inatividade de serviço, pois o nó primário continua a fornecer os serviços necessários. Mensagens detalhadas do console são exibidas solicitando que você limpe manualmente os estados ISSU existentes e restaure o cluster de chassi.

error: [Oct  6 12:30:16]: Reboot secondary node failed (error-code: 4.1)

       error: [Oct  6 12:30:16]: ISSU Aborted! Backup node maybe in inconsistent state, Please restore backup node
       [Oct  6 12:30:16]: ISSU aborted. But, both nodes are in ISSU window.
       Please do the following:
       1. Rollback the node with the newer image using rollback command
          Note: use the 'node' option in the rollback command
          otherwise, images on both nodes will be rolled back
       2. Make sure that both nodes (will) have the same image
       3. Ensure the node with older image is primary for all RGs
       4. Abort ISSU on both nodes
       5. Reboot the rolled back node

Falha no nó secundário ao concluir a sincronização fria

O nó primário atinge o tempo limite se o nó secundário não concluir a sincronização fria. Mensagens detalhadas do console são exibidas informando que você limpa manualmente os estados ISSU existentes e restaura o cluster de chassi. Nenhum tempo de inatividade de serviço ocorre neste cenário.

[Oct  3 14:00:46]: timeout waiting for secondary node node1 to sync(error-code: 6.1)
        Chassis control process started, pid 36707 

       error: [Oct  3 14:00:46]: ISSU Aborted! Backup node has been upgraded, Please restore backup node 
       [Oct  3 14:00:46]: ISSU aborted. But, both nodes are in ISSU window. 
       Please do the following: 
      1. Rollback the node with the newer image using rollback command 
          Note: use the 'node' option in the rollback command 
          otherwise, images on both nodes will be rolled back 
      2. Make sure that both nodes (will) have the same image 
      3. Ensure the node with older image is primary for all RGs 
      4. Abort ISSU on both nodes 
      5. Reboot the rolled back node

Falha falha no secundário recém-atualizado

Não ocorre nenhum tempo de inatividade de serviço, pois o nó primário continua a fornecer os serviços necessários. Mensagens detalhadas do console são exibidas solicitando que você limpe manualmente os estados ISSU existentes e restaure o cluster de chassi.

[Aug 27 15:28:17]: Secondary node0 ready for failover.
[Aug 27 15:28:17]: Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
error: remote rg1 priority zero, abort failover.
[Aug 27 15:28:17]: failover all RGs to node node0 failed (error-code: 7.1)
error: [Aug 27 15:28:17]: ISSU Aborted!
[Aug 27 15:28:17]: ISSU aborted. But, both nodes are in ISSU window.
Please do the following:
1. Rollback the node with the newer image using rollback command
    Note: use the 'node' option in the rollback command
           otherwise, images on both nodes will be rolled back
2. Make sure that both nodes (will) have the same image
3. Ensure the node with older image is primary for all RGs
4. Abort ISSU on both nodes
5. Reboot the rolled back node
{primary:node1}

Falha de upgrade no primário

Não ocorre nenhum tempo de inatividade de serviço, pois o nó secundário faz failover como primário e continua a fornecer os serviços necessários.

Falha de reinicialização no nó primário

Antes da reinicialização do nó primário, os dispositivos estão fora da configuração do ISSU, nenhuma mensagem de erro relacionada ao ISSU é exibida. A seguinte mensagem de erro de reinicialização será exibida se qualquer outra falha for detectada:

Reboot failure on     Before the reboot of primary node, devices will be out of ISSU setup and no primary node error messages will be displayed.
Primary node

Erros relacionados ao suporte de ISSU

Problema

Descrição

A falha de instalação ocorre devido a software não suportado e configuração de recursos não suportados.

Solução

Use as seguintes mensagens de erro para entender os problemas relacionados à compatibilidade:

Falha nas verificações de validação inicial

Problema

Descrição

As verificações iniciais de validação falham.

Solução

As verificações de validação falharão se a imagem não estiver presente ou se o arquivo de imagem estiver corrompido. As seguintes mensagens de erro são exibidas quando as verificações iniciais de validação falham quando a imagem não está presente e o ISSU é abortado:

Quando a imagem não está presente

Quando o arquivo de imagem está corrompido

Se o arquivo de imagem estiver corrompido, a seguinte saída será exibida:

O nó primário valida a configuração do dispositivo para garantir que ela possa ser confirmada usando a nova versão do software. Se algo der errado, o ISSU será abortado e mensagens de erro serão exibidas.

Erros relacionados à instalação

Problema

Descrição

O arquivo de imagem de instalação não existe ou o site remoto está inacessível.

Solução

Use as seguintes mensagens de erro para entender os problemas relacionados à instalação:

O ISSU baixa a imagem de instalação conforme especificado no comando ISSU como um argumento. O arquivo de imagem pode ser um arquivo local ou localizado em um local remoto. Se o arquivo não existir ou o site remoto estiver inacessível, um erro será relatado.

Erros de failover de grupo de redundância

Problema

Descrição

Problema com falha de grupo de redundância automática (RG).

Solução

Use as seguintes mensagens de erro para entender o problema:

Erros de sincronização de estado do kernel

Problema

Descrição

Erros relacionados ao ksyncd.

Solução

Use as seguintes mensagens de erro para entender os problemas relacionados ao ksyncd:

O ISSU verifica se há algum erro ksyncd no nó secundário (nó 1) e exibe a mensagem de erro se houver algum problema e aborta a atualização.

Comportamento de upgrade de software em serviço específico da plataforma

Use o Explorador de Recursos para confirmar o suporte à plataforma e à versão para recursos específicos.

Use a tabela a seguir para examinar os comportamentos específicos da plataforma.

Plataforma

Diferença

Série SRX

  • Os firewalls SRX1500, SRX4100 e SRX4200 oferecem suporte para atualizar do Junos OS 17.4 para versões 17.4 sucessivas e não podem atualizar para versões 17.4 de versões anteriores do Junos OS.

  • Os firewalls SRX5400, SRX5600 e SRX5800 oferecem suporte para atualizar do Junos OS 17.3 para versões 17.3 sucessivas e não podem atualizar para versões 17.3 e superiores de versões anteriores do Junos OS.

  • SRX1500, SRX1600, SRX2300, SRX4120, SRX4100, SRX4200, SRX4300 e SRX4600, os firewalls não suportam o request system snapshot comando.

  • Os firewalls SRX1500, SRX4100 e SRX4200 compatíveis com ISSU permitem que você remova o arquivo de imagem original. Incluir unlink ao user@host> request system software in-service-upgrade image-name-with-full-path unlink comando.

Informações adicionais da plataforma

Use o Explorador de Recursos para confirmar o suporte à plataforma e à versão para recursos específicos.

Plataformas adicionais podem ser suportadas.

Tabela 2: Suporte à plataforma ISSU

Dispositivo

Versão do Junos OS

SRX5800 e SRX5600

10.4R4 ou posterior

SRX5400

12.1X46-D20 ou posterior

SRX1500

15.1X49-D70 ou posterior

SRX1600 e SRX2300, SRX4120

23.4R1 ou posterior

SRX4100 e SRX4200

15.1X49-D80 ou posterior

SRX4300

24.2R1 ou posterior

SRX4600

17.4R1 ou posterior

Documentação relacionada