commit

Execute o comando de confirmação sem nenhuma opção de comprometer as alterações de configuração no banco de dados de configuração.

Complete o compromisso em duas etapas para preparar a configuração para confirmar e depois ativar a configuração. Isso permite configurar vários dispositivos e ativar simultaneamente as configurações em vários dispositivos.

Comprometa a configuração e, se a configuração não conter erros e o commit for bem-sucedido, saia do modo de configuração.

(Opcional) Economize mudanças na configuração do software e ative a configuração em um momento futuro ou após a reinicialização. A variável string é reboot ou o tempo futuro para ativar as mudanças de configuração. Inclua o string valor (incluindo reboot) entre aspas (“ ”). 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 em pelo menos um minuto, mas antes das 23h59:59 no dia em que o comando de commit at 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 dispositivo.

• 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, 2003-08-21 12:30:00 são 12:30 pm em 21 de agosto de 2003. O tempo é interpretado em relação às configurações do relógio e do fuso horário no roteador.

  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 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 Junos OS falhar antes que as mudanças de configuração se tornem ativas, todas as mudanças de configuração serão perdidas.

  Você não pode entrar no comando do commit at modo de configuração quando há uma reinicialização pendente.

  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 usar o clear system commit comando para cancelar uma configuração de confirmação agendada, consulte um compromisso claro do sistema.

(Opcional) Verifique a sintaxe da configuração, mas não ative-a.

(Opcional) Adicione um comentário que descreve a configuração comprometida. O comentário pode ter até 512 bytes e deve ser digitado em uma única linha. Você não pode incluir um comentário com o commit check comando. Inclua comment-string aspas (" "). Por exemplo, commit comment "Includes changes recommended by user".

(Opcional) Exija que o compromisso seja confirmado dentro do tempo especificado.

• Para confirmar um compromisso, entre em um commit ou commit check comando.

• Se o commit não for confirmado dentro do prazo, a configuração volta automaticamente para a configuração pré-acomodada e uma mensagem de transmissão é enviada a todos os usuários conectados. Para mostrar quando uma reversão está programada, entre no show system commit comando. O intervalo permitido é 1 por 65,535 minutos, e o padrão é 10 de minutos.

• O tempo limite para o commit confirmed comando é calculado com base no tempo do sistema, quando o commit confirmed comando é emitido. Caso o tempo do sistema seja modificado enquanto um commit confirmed está pendente, o tempo restante até a execução do compromisso pode ser reduzido (caso o tempo antigo do sistema esteja atrasado) ou prolongado (caso o tempo antigo do sistema esteja à frente) do intervalo pretendido.

• No Junos OS Release 11.4 e posterior, você também pode usar o commit confirmed comando no [edit private] modo de configuração.

(Opcional) Configure o commit comando para ser executado sem sincronização. Isso pode ser útil em situações, por exemplo, em que uma configuração de mecanismo de rotina é corrupta de maneira que uma sincronização de compromisso não seja possível ou bloqueie o compromisso.

• Essa opção permite que você se comprometa apenas no mecanismo de roteamento atual, mesmo que set system commit synchronize esteja configurado.

• Essa opção também substitui a commit peer-synchronize configuração. Se você tiver configurado o commit synchronize usando set system commit synchronize e depois use o comando commit no-synchronize, o commit acontecerá apenas no dispositivo emitindo o comando.

• Ao usar commit synchronize, o commit é feito pela primeira vez no outro Mecanismo de Roteamento e depois no atual. Se o outro Mecanismo de Rotina estiver corrupto, o commit falhará. Nesses casos, você pode usar commit no-synchronize. Este comando não pode ser configurado usando set. Ele só pode ser executado.

(Opcional) Configure o comando de compromisso para realizar automaticamente uma ação de sincronização entre pares. O peer local (ou peer de solicitação) no qual você habilita a sincronização de peers em cópias de declaração e carrega sua configuração para o peer remoto (ou resposta). Cada peer então realiza uma verificação de sintaxe no arquivo de configuração que está sendo cometido. Se não forem encontrados erros, a configuração será ativada e se tornará a configuração operacional atual em ambos os pares.

(Opcional) Se o seu roteador tiver dois mecanismos de roteamento, você pode direcionar manualmente um mecanismo de roteamento para sincronizar sua configuração com o outro, emitindo o commit synchronize comando. O mecanismo de roteamento no qual você executa este comando (o mecanismo de roteamento de solicitação) copia e carrega a configuração do candidato para o outro mecanismo de roteamento (o mecanismo de roteamento que responde). Ambos os mecanismos de roteamento então realizam uma verificação de sintaxe no arquivo de configuração do candidato que está sendo cometido. Se não forem encontrados erros, a configuração será ativada e se tornará a configuração operacional atual em ambos os mecanismos de roteamento.

A opção de sincronização tem as seguintes duas opções adicionais:

• força —(Opcional) Aplicar a sincronização de comprometimento nos mecanismos de roteamento usando a opção force .

  O commit synchronize comando não funciona se o mecanismo de roteamento de resposta tiver alterações de configuração não comprometidas. Você pode aplicar a sincronização de confirmação nos mecanismos de roteamento usando a opção force . Quando você emite o commit synchronize comando com a opção force de um mecanismo de roteamento, as sessões de configuração no outro Mecanismo de Roteamento são terminadas e a configuração é sincronizada com a do mecanismo de roteamento do qual você emitiu o comando.

• scripts — (Opcional) Sincronizar todos os scripts de commit, event, lib, op e SNMP desde o mecanismo de roteamento solicitado até o mecanismo de roteamento que responde e confirmar e sincronizar a configuração.

  Se a commit check operação falhar na solicitação do Mecanismo de Roteamento, o processo será interrompido e os scripts não forem copiados para o mecanismo de roteamento que responde. Se a operação ou commit a commit check operação falhar para o mecanismo de roteamento que responde, os scripts ainda estarão sincronizados, já que a sincronização ocorre antes da commit check operação no mecanismo de roteamento que responde.

• Se a load-scripts-from-flash declaração estiver configurada no [edit system scripts] nível de hierarquia para o mecanismo de roteamento solicitado, o dispositivo sincroniza os scripts da memória flash no mecanismo de roteamento solicitando para piscar a memória no mecanismo de roteamento que responde. Caso contrário, o dispositivo sincroniza os scripts do disco rígido na solicitação do Mecanismo de Roteamento para o disco rígido no mecanismo de roteamento que responde. O dispositivo sincroniza todos os scripts, independentemente de estarem habilitados na configuração ou terem sido atualizados desde a última sincronização.

(Opcional) Prepare a configuração para ativar posteriormente. Durante a fase de preparação, todos os arquivos e bancos de dados necessários são gerados e a configuração é validada. Um arquivo é criado que indica se o commit está pendente para ativação. Em caso de falha durante a fase de preparação, a preparação para o compromisso da mensagem de log é gerada com falha.

(Opcional) Comprometa scripts recém-habilitados durante a operação de confirmação e empurre scripts para o outro mecanismo de roteamento.

(Opcional) Use o | (tubulação)) opções para filtrar a saída do commit comando.