Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Nesta página
 

Confirmar a configuração

O commit comando de modo de configuração permite que você economize as alterações de configuração do dispositivo no banco de dados de configuração e ative a configuração no dispositivo.

O modelo de confirmação para configurações

A configuração do dispositivo é salva usando um modelo de confirmação — uma configuração do candidato é modificada conforme desejado e depois comprometida com o sistema. Quando uma configuração é comprometida, o dispositivo verifica a configuração por erros de sintaxe e, se não forem encontrados erros, a configuração é salva como juniper.conf.gz e ativada. O arquivo de configuração ativo anteriormente é salvo como o primeiro arquivo de configuração de reversão (juniper.conf.1.gz), e quaisquer outros arquivos de configuração de reversão são incrementados por 1. Por exemplo, juniper.conf.1.gz é incrementado para juniper.conf.2.gz, tornando-o o segundo arquivo de configuração de reversão. O dispositivo pode ter no máximo 49 configurações de reversão (numeradas de 1 a 49) salvas no sistema.

No dispositivo, o arquivo de configuração atual e os três primeiros arquivos de reversão (juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3) estão localizados no /config diretório. (Os arquivos de reversão restantes, de 4 a 49 anos, estão localizados em /var/db/config.)

Se o arquivo rescue.conf.gz de configuração de recuperação existir, este arquivo também está localizado no /config diretório. Os arquivos padrão da fábrica estão localizados no /etc/config diretório.

Existem dois mecanismos usados para propagar as configurações entre mecanismos de roteamento dentro de um dispositivo:

  • Sincronização: Propaga uma configuração de um mecanismo de roteamento para um segundo mecanismo de roteamento dentro do mesmo chassi do dispositivo.

    Para sincronizar configurações, use o commit synchronize comando CLI. Se um dos mecanismos de roteamento estiver bloqueado, a sincronização falhará. Se a sincronização falhar por causa de um arquivo de configuração bloqueado, você pode usar o commit synchronize force comando. Esse comando substitui a fechadura e sincroniza os arquivos de configuração.

  • Distribuição: Propaga uma configuração em todo o plano de roteamento em um dispositivo multichassis. A distribuição ocorre automaticamente. Não há nenhum comando de usuário disponível para controlar o processo de distribuição. Se uma configuração for bloqueada durante uma distribuição de uma configuração, a configuração bloqueada não receberá o arquivo de configuração distribuído, de modo que a sincronização falha. Você precisa limpar a fechadura antes da configuração e ressincronizar os planos de roteamento.

    Nota:

    Quando você usa o commit synchronize force comando CLI em uma plataforma multichassis, a sincronização forçada dos arquivos de configuração não afeta a distribuição do arquivo de configuração em todo o plano de roteamento. Se um arquivo de configuração for bloqueado em um dispositivo remoto do dispositivo onde o comando foi emitido, a sincronização falhará no dispositivo remoto. Você precisa limpar a fechadura e reeditar o synchronization comando.

Consulte também

Confirmar uma configuração de dispositivo

Para salvar mudanças na configuração do dispositivo no banco de dados de configuração e ativar a configuração no dispositivo, use o comando do commit modo de configuração. Você pode emitir o commit comando de qualquer nível de hierarquia:

Quando você insira o commit comando, a configuração é verificada pela primeira vez para verificar se há erros de sintaxe (commit check). Então, se a sintaxe estiver correta, a configuração será ativada e se tornará a configuração atual e operacional do dispositivo.

Nota:

Não recomendamos realizar uma operação de confirmação no mecanismo de roteamento de backup quando a comutação graciosa do mecanismo de roteamento estiver habilitada no roteador.

Um commit de configuração pode falhar por qualquer um dos seguintes motivos:

  • A configuração inclui sintaxe incorreta, o que faz com que a verificação de confirmação seja reprovada.

  • A configuração do candidato que você está tentando confirmar é maior que 700 MB.

  • A configuração é bloqueada por um usuário que entrou no configure exclusive comando.

Se a configuração conter erros de sintaxe, uma mensagem indica a localização do erro e a configuração não será ativada. A mensagem de erro tem o seguinte formato:

Por exemplo:

Você deve corrigir o erro antes de recompor a configuração. Para retornar rapidamente ao nível de hierarquia onde o erro está localizado, copie o caminho da primeira linha do erro e cole-o no prompt de modo de configuração no nível de [edit] hierarquia.

O arquivo de configuração do candidato não comprometido é /var/rundb/juniper.db. Ela é limitada a 700 MB. Se o commit falhar com uma mensagem configuration database size limit exceeded, visualize o tamanho do arquivo do modo de configuração entrando no comando run file list /var/rundb detail. Você pode simplificar a configuração e reduzir o tamanho do arquivo criando grupos de configuração com curingas ou definindo políticas de correspondência menos específicas em seus filtros de firewall.

Nota:

Os avisos de tempo de compromisso da CLI exibidos para alterações de configuração no nível de [edit interfaces] hierarquia são removidos e são registrados como mensagens de log do sistema.

Isso também é aplicável à configuração VRRP nos seguintes níveis de hierarquia:

  • [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

Quando você confirma uma configuração, você confirma toda a configuração em sua forma atual.

Nota:

  • Não recomendamos realizar uma operação de confirmação no mecanismo de roteamento de backup quando o switchover gracioso do mecanismo de roteamento estiver habilitado no dispositivo.

  • Se você configurar o mesmo endereço IP para uma interface de gerenciamento ou interface interna, como fxp0 e uma interface física externa como ge-0/0/1, quando o switchover gracioso do Mecanismo de Roteamento (GRES) é habilitado, a CLI exibe uma mensagem de erro de confirmação apropriada de que endereços idênticos foram encontrados nas interfaces privadas e públicas. Nesses casos, você deve atribuir endereços IP exclusivos para as duas interfaces que têm endereços duplicados.

Confirmar a operação quando vários usuários configurarem o software

Até 32 usuários podem estar no modo de configuração simultaneamente fazendo alterações na configuração. Todas as mudanças feitas por todos os usuários são visíveis para todos que editam a configuração — as mudanças se tornam visíveis assim que o usuário pressiona a chave Enter no final de um comando que muda a configuração, como set, editou delete.

Quando qualquer um dos usuários que editam a configuração emite um commit comando, a CLI verifica e ativa todas as mudanças por todos os usuários.

Se você entrar no modo de configuração com o configure private comando, cada usuário tem uma configuração de candidato privado para editar um pouco independentemente de outros usuários. Quando você confirma a configuração, a CLI confirma apenas suas próprias mudanças. Para sincronizar sua cópia da configuração após outros usuários terem cometido alterações, você pode executar o update comando no modo de configuração. Uma operação de confirmação também atualiza todas as configurações do candidato privado. Por exemplo, suponha que o usuário X e o usuário Y estejam no configure private modo, e o usuário X cometa uma mudança de configuração. Quando o usuário Y realiza uma operação de confirmação subsequente e depois visualiza a nova configuração, a nova configuração vista pelo usuário Y inclui as mudanças feitas pelo usuário X.

Se você entrar no modo de configuração com o configure exclusive comando, bloqueie a configuração do candidato enquanto permanecer no modo de configuração. Isso permite que você faça alterações sem interferência de outros usuários. Outros usuários podem entrar e sair do modo de configuração, mas não podem confirmar a configuração. Isso é verdade mesmo que os outros usuários tenham entrado no modo de configuração antes de você entrar no configure exclusive comando. Por exemplo, suponha que o usuário X já esteja no modo ou configure no configure private modo. Então suponha que o usuário Y entre no configure exclusive modo. O usuário X não pode confirmar nenhuma alteração na configuração, mesmo que o usuário X insira essas alterações antes que o usuário Y se conecte. Se o usuário Y sair configure exclusive do modo, o usuário X pode então confirmar as alterações feitas no configure private ou configure modo.

Visão geral de preparação e ativação do Commit

Você pode concluir o processo de confirmação em duas etapas. O recurso de confirmação em duas etapas permite configurar vários dispositivos e ativar simultaneamente as configurações. O commit de duas etapas fornece um prazo definitivo para que o compromisso seja eficaz no sistema. Você pode entrar no modo de confirmação após a preparação do commit, mas receberá uma mensagem de que o compromisso está pendente de ativação.

Na primeira etapa, a fase de preparação, o commit é validado e um novo banco de dados com os arquivos necessários é gerado. Se a configuração conter algum erro de sintaxe, uma mensagem de erro apropriada será exibida e a configuração não estiver preparada. Em caso de falha durante a fase de preparação, a mensagem commit check-out failedde erro é exibida.

Na segunda etapa, no estágio de ativação, a configuração previamente preparada é ativada. Em seguida, se você precisar limpar a configuração preparada, você pode fazê-lo usando clear system commit prepared o comando. Uma mensagem de log é gerada após a limpeza bem-sucedida do commit pendente.

Nota:

Você não pode realizar operações de confirmação entre as fases de preparação e ativação.

O processo de confirmação em duas etapas é superior ao processo de etapa única para compromissos críticos de tempo. No processo de etapa única, o tempo de preparação pode variar dependendo da configuração existente no dispositivo. No processo de duas etapas, o trabalho de preparação complexo é tratado com mais eficiência.

São fornecidos comandos de configuração que permitem preparar o cache de configuração e ativar a configuração. Você pode preparar os dispositivos com novas configurações e ativá-los nos momentos exatos que quiser.

O commit prepare comando valida as configurações e o commit activate comando ativa as configurações. Os comandos têm as seguintes opções de configuração:

  • and-quit

  • no-synchronize

  • peers-synchronize

  • synchronize

O e commit activate os commit prepare comandos estão disponíveis apenas para confirmações privadas, exclusivas e compartilhadas. Os comandos não são aplicáveis para modos dinâmicos e efêmeros. Este recurso é aplicável para dispositivos multichassis, mas não é aplicável para confirmações de lotes.

Para dar suporte a essa funcionalidade usando o Protocolo de configuração de rede (NETCONF), as seguintes novas chamadas de procedimento remoto (RPCs) são fornecidas:

  • <commit-configuration>< prepare/></commit-configuration>

  • <commit-configuration><activate/></commit-configuration>

  • <clear-system-commit><prepared/></clear-system-commit>

Nota:

  • Em uma configuração do Virtual Chassis da Série MX, o seguinte se aplica: Quando commit prepare é emitido em um mecanismo de roteamento seguido de switchover, o Mecanismo de roteamento onde o comando de switchover é emitido reinicializa. Portanto, o cache preparado é liberado nesse mecanismo de roteamento.

  • Em uma configuração do Virtual Chassis da Série MX, é aconselhável executar clear system commit prepared comando apenas em vc primário.

Confirmar configurações de dispositivos em duas etapas: Preparação e ativação

Você pode concluir o processo de confirmação em duas etapas. Isso permite que você configure vários dispositivos, e as configurações podem ser ativadas simultaneamente. Na primeira etapa, conhecida como estágio de preparação, o commit é validado e um novo banco de dados, juntamente com os arquivos necessários, é gerado. Se a configuração conter algum erro de sintaxe, uma mensagem de erro apropriada será exibida e a configuração não estiver preparada. Na segunda etapa, conhecida como estágio de ativação, a configuração previamente preparada é ativada e se torna a configuração atual e operacional do dispositivo.

Para preparar a configuração:

  1. No nível de hierarquia no [edit] modo de configuração, faça as alterações necessárias na configuração.

    Por exemplo, para configurar os scripts do sistema, emita o seguinte comando:

    Por exemplo:

  2. Emite o commit prepare comando.

    A mensagem commit prepare successful é exibida.

    Se a fase de preparação falhar, a mensagem commit check-out failed de erro será exibida.

  3. Para verificar a saída do comando após commit prepare a show system commit emissão, use o seguinte comando:

Para ativar a configuração preparada:

  1. Use o commit activate comando

    A mensagem commit complete é exibida.

  2. Para verificar a configuração ativada do sistema, use o seguinte comando:

Para verificar a saída dos comandos e show system commit revision detail após commit activate a show system commit emissão, emita os seguintes comandos.

Ativar uma configuração de dispositivo com confirmação

Ao confirmar a configuração atual do candidato, você pode exigir uma confirmação explícita para que o compromisso se torne permanente. Isso é útil se você quiser verificar se uma mudança de configuração funciona corretamente e não impede o acesso ao dispositivo. Se a mudança impedir o acesso ou causar outros erros, o dispositivo retorna automaticamente à configuração anterior e restaura o acesso após a aprovação do tempo de confirmação da reversão. Esse recurso é chamado de reversão automática.

Para confirmar a configuração atual do candidato, mas exigir uma confirmação explícita para que o compromisso se torne permanente, use o comando do commit confirmed modo de configuração:

Depois de verificar se a mudança funciona corretamente, você pode manter a nova configuração ativa entrando em um commit ou commit check comando dentro de 10 minutos após o commit confirmed comando. Por exemplo:

Se o commit não for confirmado em um determinado tempo (10 minutos por padrão), o sistema operacional volta automaticamente para a configuração anterior e uma mensagem de transmissão é enviada a todos os usuários conectados.

Para mostrar quando uma reversão é agendada após um commit confirmed comando, entre no show system commit comando. Por exemplo:

Assim como o commit comando, o commit confirmed comando verifica a sintaxe de configuração e relata quaisquer erros. Se não houver erros, a configuração será ativada temporariamente (10 minutos por padrão) e começa a ser executada no dispositivo.

Figura 1: Confirme uma configuraçãoConfirme uma configuração

Para alterar o tempo antes de confirmar a nova configuração, especifique o número de minutos quando você emitir o comando:

Você também pode usar o commit confirmed comando no modo de [edit private] configuração.

Agende uma operação de compromisso

Você pode agendar quando quiser que a configuração do seu candidato fique ativa. Para salvar mudanças na configuração do dispositivo e ativar a configuração no dispositivo em um momento futuro ou após a reinicialização, use o comando do commit at modo de configuração, especificando reboot ou um momento futuro no nível de hierarquia:edit

string é reboot ou o tempo futuro para ativar as mudanças de configuração. Você pode especificar o tempo em dois formatos:

  • Um valor de tempo no formulário hh:mm[:ss] (horas, minutos e segundos opcionalmente)— Comprometa a configuração no momento especificado, que deve ser no futuro, mas antes das 23h59:59 no dia em que o comando do commit at modo de configuração for emitido. Use o hh tempo de 24 horas pelo valor; por exemplo, 04:30:00 é às 4h30 e 20:00 às 20h. O tempo é interpretado em relação às configurações do relógio e do fuso horário no roteador.

  • Um valor de data e hora no formulário yyyy-mm-dd hh:mm[:ss] (ano, mês, data, horas, minutos e, opcionalmente, segundos)— Comprometa a configuração no dia e hora especificados, que devem ser após a emissão do commit at comando. Use o tempo de 24 horas pelo hh valor. Por exemplo, 2018-08-21 12:30:00 são 12h30 de 21 de agosto de 2018. O tempo é interpretado em relação às configurações do relógio e do fuso horário no roteador.

Coloque o string valor em cotações (" "). Por exemplo, commit at "18:00:00". Para data e hora, inclua ambos os valores no mesmo conjunto de cotações. Por exemplo commit at "2018-03-10 14:00:00".

Uma verificação de confirmação é realizada imediatamente quando você emite o comando do commit at modo de configuração. Se o resultado da verificação for bem-sucedido, o usuário atual está logado para fora do modo de configuração, e os dados de configuração são deixados em um estado somente de leitura. Nenhum outro compromisso pode ser realizado até que o compromisso agendado seja concluído.

Nota:

Se o software do dispositivo falhar antes que as alterações de configuração se tornem ativas, todas as mudanças de configuração serão perdidas.

Você não pode entrar no comando de commit at configuração depois de emitir o request system reboot comando.

Você não pode entrar no request system reboot comando depois de agendar uma operação de confirmação para um momento específico no futuro.

Você não pode confirmar uma configuração quando um compromisso agendado está pendente. Para obter informações sobre como cancelar uma configuração agendada por meio do clear comando, consulte o CLI Explorer.

Nota:

Não recomendamos realizar uma operação de confirmação no mecanismo de roteamento de backup quando o switchover gracioso do mecanismo de roteamento estiver habilitado no dispositivo.

Monitore o processo de confirmação

Para monitorar o processo de confirmação da configuração do dispositivo, use o display detail comando após o pipe com o commit comando:

Por exemplo:

Adicione um comentário para descrever a configuração comprometida

Você pode incluir um comentário que descreve alterações na configuração comprometida. Para isso, inclua a commit comment declaração. O comentário pode ser de até 512 bytes e você deve digitá-lo em uma única linha.

comment-string é o texto do comentário.

Nota:

Você não pode incluir um comentário com o commit check comando.

Para adicionar um comentário ao commit comando, inclua a comment declaração após o commit comando:

Para adicionar um comentário ao commit confirmed comando, inclua a comment declaração após o commit confirmed comando:

Para visualizar esses comentários de confirmação, emita o comando do show system commit modo operacional.

Nota:

Você também pode usar o commit confirmed comando no modo de [edit private] configuração.

A partir do Junos OS Release 24.2R1, o Junos OS obriga você a emitir um comentário para cada solicitação de confirmação. Isso ajuda a rastrear mudanças feitas por vários usuários ou administradores no momento do compromisso.

Nota:

O commit comando não é executado sem o comment argumento.

Para fazer com que o usuário adicione um comentário para cada solicitação de confirmação, configure force-commit-log a opção no nível de [edit system commit] hierarquia.

Visão geral do Batch Commits

O batch confirma agrega ou mescla várias edições de configuração de diferentes sessões ou usuários de CLI e as adiciona a uma fila de confirmação de lotes. Um servidor de confirmação de lotes em execução no dispositivo tira uma ou mais vagas da fila de confirmação de lotes, aplica as alterações de configuração no banco de dados de configuração compartilhada e, em seguida, confirma as mudanças de configuração em uma única operação de confirmação.

Os lotes são priorizados pelo servidor de confirmação com base na prioridade do lote especificado pelo usuário ou no momento em que a tarefa do lote é adicionada. Quando um lote é comprometido, o próximo conjunto de alterações de configuração é agregado e carregado na fila de lotes para a próxima sessão da operação de confirmação de lotes. Os lotes são criados até que não haja nenhuma entrada de confirmação no diretório da fila.

Quando comparado com a operação de confirmação regular, em que todos os compromissos são comprometidos sequencialmente de forma independente, o lote compromete a economia de tempo e recursos do sistema, cometendo várias edições de configuração pequenas em uma única operação de confirmação.

Os compromissos em lotes são realizados a [edit batch] partir do modo de configuração. As propriedades do servidor de confirmação podem ser configuradas no nível de [edit system commit server] hierarquia.

Agregação e manuseio de erros

Quando há um erro de tempo de carga em uma das vagas agregadas, o trabalho de confirmação que encontra o erro é descartado e os empregos restantes são agregados e comprometidos.

Por exemplo, se houver cinco vagas de confirmação (commit-1, commit-2e commit-4commit-5commit-3) agregadas, e commit-3 encontrar um erro durante o carregamento, commit-3 ela será descartada e commit-4commit-1commit-2agregada e commit-5 comprometida.

Se houver um erro durante a operação de confirmação quando duas ou mais vagas forem agregadas e comprometidas, a agregação é descartada e cada uma dessas vagas é comprometida individualmente, como uma operação de compromisso regular.

Por exemplo, se houver cinco vagas de confirmação (commit-1, commit-2, commit-3e commit-4commit-5) agregadas e se houver um erro de commit-3confirmação causado por, a agregação for descartada, commit-2commit-3commit-4commit-1, e commit-5 forem cometidas individualmente, e a CLI relatar um erro de confirmação para.commit-3

Exemplo: Configure as propriedades do servidor de confirmação de lotes

Este exemplo mostra como configurar as propriedades do servidor de confirmação de lotes para gerenciar as operações de confirmação de lotes.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Plataforma de roteamento universal 5G da Série MX

Visão geral

Você pode controlar como a fila de confirmação de lotes é tratada pelo servidor de confirmação configurando as propriedades do servidor no nível de [edit system commit server] hierarquia. Isso permite que você controle quantas vagas de confirmação são agregadas ou mescladas em um único lote de confirmação, o número máximo de empregos que podem ser adicionados à fila, dias para manter logs de erro de confirmação de lotes, intervalo entre dois compromissos de lotes e operações de rastreamento para operações de confirmação de lotes.

Configuração

Configuração rápida da CLI

Para configurar rapidamente esta seção do exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no [edit] nível de hierarquia. Você pode configurar as propriedades do servidor de confirmação a partir do modo regular [edit] ou do [edit batch] modo.

Dispositivo R0

Configuração das propriedades do servidor commit

Procedimento passo a passo

  1. (Opcional) Configure o número de transações de compromisso para agregar ou mesclar em uma única operação de compromisso.

    O valor maximum-aggregate-pool padrão é 5.

    Nota:

    Configuração maximum-aggregate-pool para 1 comprometer cada uma das vagas individualmente.

    Neste exemplo, o número de transações de compromisso está definido para 4 indicar que quatro diferentes empregos de compromisso são agregados em um único compromisso antes que a operação de compromisso seja iniciada.

  2. (Opcional) Configure o número máximo de vagas permitidas em um lote.

    Isso limita o número de empregos comprometidos que são adicionados à fila.

    Nota:

    Se você definir maximum-entries1, o servidor de confirmação não pode adicionar mais de um trabalho à fila, e a CLI exibe uma mensagem apropriada quando você tenta comprometer mais de um trabalho.

  3. (Opcional) Configure o tempo (em segundos) para esperar antes de iniciar a próxima operação de confirmação de lotes.

  4. (Opcional) Configure o número de dias para manter logs de erro.

    O valor padrão são 30 dias.

  5. (Opcional) Configure operações de rastreamento para registrar eventos de confirmação de lotes.

    Neste exemplo, o nome do arquivo para registrar eventos de confirmação de lotes é commitd_nov, e todas as bandeiras de traceoption estão definidas.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show system commit server comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Comprometendo a configuração do modo de configuração de lotes

Procedimento passo a passo

Para confirmar a configuração do [edit batch] modo, faça um dos seguintes:

  • Faça login no dispositivo e insira commit.

  • Para atribuir uma prioridade superior a um trabalho de confirmação de lotes, emita o commit comando com a opção priority .

  • Para comprometer uma configuração sem agregar as mudanças de configuração com outras vagas de confirmação na fila, emita o commit comando com a opção atomic .

  • Para comprometer uma configuração sem agregar as mudanças de configuração com outras vagas de compromisso na fila, e emitir uma prioridade maior para o trabalho de compromisso, emita o commit comando com a opção atomic priority .

Verificação

Confirme se a configuração está funcionando corretamente.

Verificando o status do servidor de confirmação de lotes

Propósito

Verifique a situação do servidor de confirmação do lote.

Ação

Por padrão, o status do servidor de confirmação é Not running. O servidor de confirmação começa a ser executado apenas quando um trabalho de confirmação de lotes é adicionado à fila.

Quando um trabalho de compromisso em lote é adicionado à fila, o status do servidor de compromisso muda para Running.

Significado

O Jobs in process campo lista os IDs de compromisso de vagas que estão em processo.

Verificando o status de confirmação de lotes

Propósito

Verifique a fila de servidores de confirmação para obter o status dos compromissos do lote.

Ação
Significado

Pending commits os displays confirmam trabalhos que são adicionados à fila de confirmação, mas ainda não estão comprometidos. Completed commits apresenta a lista de empregos comprometidos que são bem-sucedidos. Error commits são confirmações que falharam por causa de um erro.

Visualizando os arquivos de patch em um trabalho de confirmação de lotes

Propósito

Veja os tempostamps, arquivos de patch e o status de cada um dos trabalhos de confirmação. Os arquivos de patch mostram as alterações de configuração que ocorrem em cada operação de confirmação que é adicionada à fila de confirmação de lotes.

Ação

  1. Use o show system commit server queue patch comando para visualizar os patches para todas as operações de confirmação.

    A saída mostra as mudanças na configuração para cada ID de trabalho de compromisso.

  2. Para visualizar o patch para uma ID de trabalho de confirmação específica, emita o show system commit server queue patch id <id-number> comando.

Significado

A saída mostra o patch criado para um trabalho de confirmação. O + sinal ou - o sinal indica as mudanças na configuração para um trabalho de confirmação específico.

Visualizando os arquivos de rastreamento para operações de confirmação de lotes

Propósito

Veja os arquivos de rastreamento para operações de confirmação de lotes. Você pode usar os arquivos de rastreamento para solucionar problemas.

Ação

  • Use o file show /var/log/<filename> comando para visualizar todas as entradas do arquivo de log.

    A saída mostra logs de eventos de servidor de confirmação e outros logs para confirmações de lotes.

  • Para visualizar entradas de log apenas para operações de confirmação de lotes bem-sucedidas, emita o file show /var/log/<filename> comando com a opção | match committed de pipe.

    A saída mostra IDs de trabalho em lotes para operações de confirmação bem-sucedidas.

  • Para visualizar entradas de log apenas para operações de confirmação de lotes com falha, emita o file show /var/log/<filename> comando com a opção | match “Error while” de pipe.

    A saída mostra a confirmação de IDs de trabalho para operações de confirmação fracassadas.

  • Para visualizar entradas de log apenas para eventos de servidor de confirmação, emita o file show /var/log/<filename> comando com a opção | match “commit server” de pipe.

    A saída mostra logs de eventos de servidor de confirmação.

Fazer backup da configuração comprometida no boot drive alternativo

Depois de confirmar a configuração e ficar satisfeito de que ela está sendo executada com sucesso, você deve emitir o request system snapshot comando para fazer o backup do novo software no sistema de /altconfig arquivos. Se você não emitir o request system snapshot comando, a configuração no drive de inicialização alternativo está fora de sincronia com a configuração no boot drive principal.

O request system snapshot comando apoia o sistema de arquivos raiz para/altroot./config/altconfig Os sistemas raiz e /config de arquivo estão no flash drive do roteador, e os sistemas e /altconfig arquivos /altroot estão no disco rígido do roteador (se disponível).

Depois de emitir o request system snapshot comando, você não pode retornar à versão anterior do software porque as cópias em execução e backup do software são idênticas.

Tópicos relacionados