Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Como comprometer uma configuração

O comando modo de configuração permite salvar as alterações de configuração do dispositivo no banco de dados de configuração e commit ativar a configuração no dispositivo.

Entender o modelo commit para configurações

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

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

Se o arquivo de rescue.conf.gz configuração de recuperação for salvo no sistema, esse arquivo também deve ser salvo no /config diretório. Os arquivos padrão de fábrica estão localizados no /etc/config diretório.

Existem dois mecanismos usados para propagar as configurações entre os 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 comando commit synchronize CLI. Se um dos Mecanismos de Roteamento estiver preso, a sincronização falha. Se a sincronização falhar por causa de um arquivo de configuração bloqueado, você pode usar o commit synchronize force comando. Esse comando sobrescreva o bloqueio e sincronizava 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á comando do 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ída, e assim a sincronização falha. Você precisa limpar o bloqueio antes da configuração e ressincronizar os planos de roteamento.

    Nota:

    Quando você usa o 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 no plano commit synchronize force de roteamento. Se um arquivo de configuração estiver preso em um dispositivo remoto do dispositivo onde o comando foi emitido, a sincronização falha no dispositivo remoto. Você precisa limpar o bloqueio e reeditar o synchronization comando.

Como comprometer uma configuração de dispositivo

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

Quando você entra no commit comando, a configuração é primeiro marcada por erros de sintaxe ( commit check ). Em seguida, se a sintaxe estiver correta, a configuração é ativada e torna-se a configuração atual do dispositivo operacional.

Nota:

Não recomendamos realizar uma operação de commit na base de Mecanismo de Roteamento quando Mecanismo de Roteamento switchover elegante está ativado no roteador.

Uma confirmação de configuração pode falhar por qualquer um dos seguintes motivos:

  • A configuração inclui sintaxe incorreta, o que faz o check-commit falhar.

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

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

Se a configuração contiver erros de sintaxe, uma mensagem indicará o local 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 recommitir a configuração. Para retornar rapidamente ao nível da hierarquia onde o erro está localizado, copie o caminho da primeira linha do erro e o conaque no alerta do modo de configuração no nível [edit] da hierarquia.

O arquivo de configuração do candidato não comprometida é /var/rundb/juniper.db . Ele está limitado a 700 MB. Se o commit falhar com uma mensagem, exibir o tamanho do arquivo no modo de configuration database size limit exceeded configuração inserindo o 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 wildcards ou definindo políticas de combinação menos específicas em seus filtros de firewall.

Nota:

Os avisos de tempo de compromisso CLI exibidos para alterações de configuração no nível da hierarquia são removidos e são [edit interfaces] conectados 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]

Ao cometer uma configuração, você compromete toda a configuração no formato atual.

Nota:
  • Não recomendamos realizar uma operação de commit na base de Mecanismo de Roteamento quando Mecanismo de Roteamento switchover elegante está ativado no dispositivo.

  • Se você configurar o mesmo endereço IP para uma interface de gerenciamento ou interface interna, como e uma interface física externa, como, quando fxp0 o SWITCHOVER (GRES) da Série Mecanismo de Roteamento está ativado, a CLI exibirá uma mensagem de erro de confirmação apropriada que endereços idênticos foram encontrados nas ge-0/0/1 interfaces privadas e públicas. Nesses casos, você deve designar endereços IP exclusivos para as duas interfaces que tenham endereços duplicados.

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

Até 32 usuários podem estar no modo de configuração ao mesmo tempo, e todos eles podem estar fazendo alterações na configuração. Todas as alterações feitas por todos os usuários são visíveis para todos que editam a configuração, e as alterações tornam-se visíveis assim que o usuário pressionar a tecla Enter ao final de um comando que altera a configuração, como, ou seteditdelete .

Quando algum dos usuários que edita a configuração emite um comando, todas as alterações feitas commit por todos os usuários são controladas e ativadas.

Se você entrar no modo de configuração com o comando, cada usuário terá uma configuração de candidato privada para editar de forma configure private independente de outros usuários. Quando você compromete a configuração, apenas as próprias alterações são comprometidas. Para sincronizar sua cópia da configuração depois que outros usuários cometerem alterações, você pode executar update o comando no modo de configuração. Uma operação de commit também atualiza todas as configurações de candidatos privados. Por exemplo, imagine que o usuário X e o usuário Y estão em modo, e que o configure private usuário X compromete uma mudança de configuração. Quando o usuário Y realiza uma operação de confirmação posterior e visualiza a nova configuração, a nova configuração vista pelo usuário Y inclui as alterações feitas pelo usuário X.

Se você entrar no modo de configuração com o comando, você bloqueará a configuração do candidato pelo tempo que permanecer no modo de configuração, permitindo que você faça alterações sem interferência configure exclusive de outros usuários. Outros usuários podem entrar e sair do modo de configuração, mas não podem comprometer a configuração. Isso é verdade, mesmo que os outros usuários entrem no modo de configuração antes de você entrar no configure exclusive comando. Por exemplo, imagine que o usuário X já está configure private no ou configure modo. Em seguida, imagine que o usuário Y entre no configure exclusive modo. O usuário X não pode cometer alterações na configuração, mesmo se essas alterações foram inseridas antes do usuário Y fazer login. Se o usuário Y sair configure exclusive do modo, o usuário X pode cometer as alterações feitas configure private no configure modo.

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

A começar pela versão 17.3R1 Junos OS, você pode concluir o processo de confirmação em duas etapas. Esse recurso permite configurar vários dispositivos e, ao mesmo tempo, ativar as configurações. Antes da versão do Junos OS 17.3R1, o processo de confirmação foi concluído em uma única etapa. O objetivo de desaplificar esses estágios de compromisso é fornecer uma janela de tempo definitiva para que o compromisso seja eficaz no sistema. Você pode entrar no modo commit depois que o commit for preparado, mas você receberá uma mensagem informando que o commit está pendente de ativação.

Na primeira etapa, conhecida como estágio de preparação, o commit é validado e um novo banco de dados com os arquivos necessários é gerado. Se a configuração contiver erros de sintaxe, uma mensagem de erro apropriada é exibida e a configuração não está preparada. No caso de falha durante o estágio de preparação, a mensagem commit check-out failed de erro é exibida.

Na segunda etapa, chamada de 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 eliminação bem-sucedida do commit pendente.

Nota:

Não é possível realizar operações de compromisso entre os estágios de preparação e ativação.

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

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 ative-los na hora exata que você quiser.

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

  • and-quit

  • no-synchronize

  • peers-synchronize

  • synchronize

Os commit prepare comandos e os comandos estão disponíveis apenas para commit activate compromissos privados, exclusivos e compartilhados. Os comandos não são aplicáveis a modos dinâmicos e efêmeras. Esse recurso é aplicável para dispositivos multichassis, mas não é aplicável para confirmações em lotes.

Para dar suporte a essa funcionalidade usando o Network Configuration Protocol (NETCONF), são fornecidas as seguintes novas chamadas de procedimentos remotos (RPCs):

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

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

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

Nota:
  • Em uma configuração Virtual Chassis série MX, as seguintes aplicações: Quando é emitido em um Mecanismo de Roteamento seguido de comover, a Mecanismo de Roteamento onde o comando commit prepare comover é reinicializado. Portanto, o cache preparado é limpo nessa Mecanismo de Roteamento.

  • Em uma configuração Virtual Chassis série MX, é recomendável executar clear system commit prepared comando apenas no principal VC.

Como comprometer as configurações dos dispositivos em duas etapas: Preparação e ativação

Começando com a versão 17.3 do Junos OS, você pode concluir o processo de confirmação em duas etapas. Com isso, você pode configurar 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 contiver erros de sintaxe, uma mensagem de erro apropriada é exibida e a configuração não está preparada. Na segunda etapa, chamada de estágio de ativação, a configuração previamente preparada é ativada e torna-se a configuração do dispositivo operacional atual.

Para preparar a configuração:

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

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

    Por exemplo:

  2. Emito o commit prepare comando.

    A mensagem commit prepare successful é exibida.

    Se o estágio de preparação falhar, a mensagem de commit check-out failed erro será visualizada.

  3. Para verificar a saída do show system commit comando após commit prepare a 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 do sistema ativado, use o seguinte comando:

Para verificar a saída dos comandos e depois show system commitshow system commit revision detail da commit activate emissão, emide os seguintes comandos.

Ativação de uma configuração de dispositivo, mas solicitando confirmação

Quando você compromete a configuração do candidato atual, 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. Caso a alteração impeça o acesso ou cause outros erros, o roteador retornará automaticamente à configuração anterior e restaurará o acesso após o tempo de tempo de confirmação de reversões passar. Esse recurso é chamado de rebaixamento automático.

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

Depois de verificar se a mudança funciona corretamente, você pode manter a nova configuração ativa inserindo um ou comando no prazo de commitcommit check 10 minutos do commit confirmed comando. Por exemplo:

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

Para mostrar quando uma reação está programada após um commit confirmed comando, insira o show system commit comando. Por exemplo:

Assim como commit o comando, commit confirmed o comando verifica a sintaxe de configuração e informa erros. Caso não haja erros, a configuração é ativada temporariamente (10 minutos por padrão) e começa a ser executado no dispositivo.

Figura 1: Confirmar uma configuraçãoConfirmar uma configuração

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

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

Programação de uma operação de commit

Você pode programar quando quiser que a configuração do seu candidato se torne ativa. Para salvar alterações na configuração do dispositivo e ativar a configuração no roteador em uma hora futura ou após a reinicialização, use o comando do modo de configuração, especificando ou em um tempo futuro no commit at nível [ ] da rebootedit hierarquia:

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

  • Um valor de tempo no formulário [ ] (horas, minutos e, opcionalmente, segundos)— Compromete a configuração no tempo especificado, que deve ser no futuro, mas antes das hh:mm:ss 11:59:59 do dia em que o comando do modo de configuração é commit at lançado. Use o tempo de 24 horas para o valor; por hh exemplo, 04:30:00 são 4:30h00 e 20:00 são 20h00. O tempo é interpretado com relação às configurações de relógio e 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)— Compromete a configuração no dia e hora especificados, que devem ser após a emissão commit at do comando. Use o tempo de 24 horas para o hh valor. Por exemplo, 2018-08-2112:30:00 são 12h30 em 21 de agosto de 2018.  O tempo é interpretado com relação às configurações de relógio e fuso horário no roteador.

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

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

Nota:

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

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

Você não pode entrar no request system reboot comando depois de programar uma operação de commit por um tempo específico no futuro.

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

Nota:

Não recomendamos realizar uma operação de commit na base de Mecanismo de Roteamento quando Mecanismo de Roteamento switchover elegante está ativado no dispositivo.

Monitoramento do processo de commit

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

Por exemplo:

Adicionar 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 ter até 512 bytes e digitá-lo em uma única linha.

comment-string é o texto do comentário.

Nota:

Não é possível 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 ver esses comentários comprometem-se, emito o comando show system commit do modo operacional.

Nota:

Começando com a Versão 11.4 do Junos OS, você também pode usar o commit confirmed comando no modo de [edit private] configuração.

Visão geral de confirmações da lote

O grupo compromete agregados ou mescla várias edições de configuração de diferentes sessões de CLI ou usuários e as adiciona a uma fila de compromisso de lotes. Um servidor commit em lotes em execução no dispositivo requer um ou mais trabalhos da fila de compromisso de lotes, aplica as alterações de configuração ao banco de dados de configuração compartilhada e, em seguida, compromete as alterações de configuração em uma única operação de commit.

Os lotes são priorizados pelo servidor commit com base na prioridade do lote especificado pelo usuário ou na hora em que o trabalho em lotes é adicionado. Quando um commit em lotes está completo, 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 entradas de confirmação deixadas no diretório da fila.

Quando comparamos com a operação regular de commit onde todos os compromissos são comprometidos de forma seqüencial, o grupo compromete economizar tempo e recursos do sistema ao cometer várias edições de configuração pequenas em uma única operação de commit.

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

Agregação e tratamento de erros

Quando ocorre um erro de tempo de carga em um dos empregos agregados, o trabalho de compromisso que encontra o erro é descartado e os restantes empregos são agregados e comprometidos.

Por exemplo, se houver cinco commit-1commit-2 empregos comprometidos (, , , e) sendo commit-3commit-4commit-5commit-3 agregados, commit-3commit-1commit-2commit-4 e commit-5 encontrar um erro durante o carregamento, será descartado e, e será agregado e comprometido.

Se houver um erro durante a operação de commit quando dois ou mais empregos são agregados e comprometidos, a agregação é descartada e cada um desses trabalhos é comprometido individualmente, como uma operação regular de commit.

Por exemplo, se houver cinco empregos comprometidos (, , , e) agregados e se houver um erro de commit causada por isso, a agregação é descartada, , e comprometida commit-1commit-2commit-3commit-4commit-5commit-3commit-1commit-2commit-3commit-4commit-5 individualmente, e a CLI commit-3 informa um erro de commit for .

Exemplo: Configurando propriedades do servidor de commit em lotes

Este exemplo mostra como configurar propriedades de servidor de compromisso em lotes para gerenciar operações de commit em lotes.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Plataforma de Roteamento Universal 5G da Série MX

  • Junos OS Release 12.1 ou posteriormente executado no dispositivo

Visão geral

Você pode controlar como a fila de compromisso de lotes é manipulada pelo servidor commit configurando as propriedades do servidor em nível [edit system commit server] de hierarquia. Com isso, você pode controlar quantos trabalhos de compromisso são agregados ou mesclados em um único commit em lotes, o número máximo de empregos que podem ser adicionados à fila, dias para manter registros de erro do commit em lotes, intervalo entre dois commits em lotes e o rastreamento de operações de confirmação de lotes.

Configuração

Configuração rápida CLI

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

Dispositivo R0

Configurando as propriedades do servidor commit

Procedimento passo a passo
  1. (Opcional) Configure o número de transações de commit para agregar ou fundir em uma única operação de commit.

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

    Nota:

    Configuração maximum-aggregate-pool para comprometer cada um dos trabalhos 1 individualmente.

    Neste exemplo, o número de transações de commit indica que quatro empregos de compromisso diferentes são agregados em um único commit antes de iniciar 4 a operação de commit.

  2. (Opcional) Configure o número máximo de empregos permitidos em um grupo.

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

    Nota:

    Se você estiver definido como , o servidor de confirmação não pode adicionar mais de um trabalho à fila, e a CLI exibirá uma mensagem adequada ao tentar cometer mais de maximum-entries1 um trabalho.

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

  4. (Opcional) Configure o número de dias para manter registros de erros.

    O valor padrão é 30 de dias.

  5. (Opcional) Configure as operações de rastreamento para registrar eventos de commit em lotes.

    Neste exemplo, o nome de arquivo para registrar eventos de commit em lotes commitd_nov é, e todas as bandeiras de rastreamento estão definidas.

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show system commit server comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Como comprometer a configuração do modo de configuração em lotes

Procedimento passo a passo

Para comprometer a configuração do [edit batch] modo, faça uma das seguintes opções:

  • Faça login no dispositivo e insira commit .

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

  • Para cometer uma configuração sem agregar as alterações de configuração com outros trabalhos de compromisso na fila, emigreça o commit comando com a atomic opção.

  • Para cometer uma configuração sem agregar as alterações de configuração com outros trabalhos de compromisso na fila, e emitando uma prioridade maior ao trabalho de compromisso, emita o comando com a commitatomic priority opção.

Verificação

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

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

Propósito

Verificar o status do servidor de confirmação de lotes.

Ação

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

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

Significado

O Jobs in process campo lista as IDs de compromisso dos trabalhos em processo.

Verificação do status de confirmação de lotes

Propósito

Marque a fila do servidor commit para saber o status do lote.

Ação
Significado

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

Exibição dos arquivos de correção em um trabalho de compromisso em lotes

Propósito

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

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

    A saída mostra as alterações na configuração de cada ID de trabalho de compromisso.

  2. Para exibir o patch para uma ID de trabalho de compromisso específica, emide o show system commit server queue patch id <id-number> comando.

Significado

A saída mostra o patch criado para um trabalho de compromisso. A + placa ou a placa indica as alterações na - configuração para um trabalho de compromisso específico.

Exibição dos 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 fins de solução de problemas.

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

    A saída mostra logs de eventos do servidor commit e outros logs para commits em lotes.

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

    A saída mostra IDs de trabalho de compromisso em lotes para operações de commit bem-sucedidas.

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

    A saída mostra IDs de trabalho de compromisso para operações com falha de compromisso.

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

    A saída mostra logs de eventos do servidor commit.

Como fazer o back-up da configuração comprometida na unidade de boot alternativa

Depois de comprometer a configuração e ter a satisfação de que ela está em execução com sucesso, você deve emitir o comando para fazer o back-up do request system snapshot novo software no sistema de /altconfig arquivo. Se você não emitir o comando, a configuração na unidade de boot alternativa estará fora de sincronização com a request system snapshot configuração na unidade de boot primária.

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

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