EN ESTA PÁGINA
Confirmar operación cuando varios usuarios configuran el software
Descripción general de la preparación y activación de confirmaciones
Confirme las configuraciones de dispositivos en dos pasos: preparación y activación
Agregar un comentario para describir la configuración confirmada
Ejemplo: Configurar propiedades del servidor de confirmación por lotes
Realice una copia de seguridad de la configuración confirmada en la unidad de arranque alternativa
Confirmar la configuración
El commit comando del modo de configuración permite guardar los cambios de configuración del dispositivo en la base de datos de configuración y activar la configuración en el dispositivo.
El modelo de confirmación para configuraciones
La configuración del dispositivo se guarda mediante un modelo de confirmación: una configuración candidata se modifica según se desee y luego se confirma en el sistema. Cuando se confirma una configuración, el dispositivo comprueba si hay errores de sintaxis en la configuración y, si no se encuentra ninguno, la configuración se guarda como juniper.conf.gz y se activa. El archivo de configuración anteriormente activo se guarda como el primer archivo de configuración de reversión (juniper.conf.1.gz) y los demás archivos de configuración de reversión se incrementan en 1. Por ejemplo, juniper.conf.1.gz se incrementa a juniper.conf.2.gz, lo que lo convierte en el segundo archivo de configuración de reversión. El dispositivo puede tener un máximo de 49 configuraciones de reversión (numeradas del 1 al 49) guardadas en el sistema.
En el dispositivo, el archivo de configuración actual y los tres primeros archivos de reversión (juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3) se encuentran en el directorio /config . (Los archivos de reversión restantes, del 4 al 49, se encuentran en /var/db/config.)
Si el archivo de configuración de recuperación rescue.conf.gz existe, este archivo también se encuentra en el directorio /config . Los archivos predeterminados de fábrica se encuentran en el directorio /etc/config .
Existen dos mecanismos que se usan para propagar las configuraciones entre motores de enrutamiento dentro de un dispositivo:
Sincronización: propaga una configuración de un motor de enrutamiento a un segundo motor de enrutamiento dentro del mismo chasis del dispositivo.
Para sincronizar configuraciones, utilice el
commit synchronizecomando CLI. Si uno de los motores de enrutamiento está bloqueado, se producirá un error en la sincronización. Si la sincronización falla debido a un archivo de configuración bloqueado, puede usar elcommit synchronize forcecomando. Este comando anula el bloqueo y sincroniza los archivos de configuración.-
Distribución: propaga una configuración a través del plano de enrutamiento en un dispositivo multichasis. La distribución se produce automáticamente. No hay ningún comando de usuario disponible para controlar el proceso de distribución. Si una configuración está bloqueada durante una distribución de una configuración, la configuración bloqueada no recibe el archivo de configuración distribuido, por lo que se produce un error en la sincronización. Debe desactivar el bloqueo antes de la configuración y volver a sincronizar los planos de enrutamiento.
Nota:Cuando se utiliza el comando de la
commit synchronize forceCLI en una plataforma multichasis, la sincronización forzada de los archivos de configuración no afecta a la distribución del archivo de configuración en el plano de enrutamiento. Si un archivo de configuración está bloqueado en un dispositivo remoto desde el dispositivo en el que se emitió el comando, se producirá un error en la sincronización en el dispositivo remoto. Debe borrar el bloqueo y volver a emitir elsynchronizationcomando.Nota:Junos OS evolucionado no admite las siguientes
commitopciones de configuración:-
fast-synchronize -
peers -
peer-synchronize -
commit-synchronize-server
-
Confirmar una configuración de dispositivo
Para guardar los cambios de configuración del dispositivo en la base de datos de configuración y activar la configuración en el dispositivo, use el comando del modo de commit configuración. Puede emitir el commit comando desde cualquier nivel de jerarquía:
[edit]
user@host# commit
commit complete
[edit]
user@host#
Cuando se introduce el commit comando, primero se comprueba la configuración en busca de errores de sintaxis (commit check). Luego, si la sintaxis es correcta, la configuración se activa y se convierte en la configuración actual del dispositivo operativo.
No se recomienda realizar una operación de confirmación en el motor de enrutamiento de respaldo cuando el cambio normal del motor de enrutamiento está habilitado en el enrutador.
Una confirmación de configuración puede fallar por cualquiera de los siguientes motivos:
-
La configuración incluye una sintaxis incorrecta, lo que hace que se produzca un error en la comprobación de confirmación.
-
La configuración candidata que está intentando confirmar es mayor de 700 MB.
-
La configuración se bloquea por un usuario que ingresó el
configure exclusivecomando.
Si la configuración contiene errores de sintaxis, un mensaje indica la ubicación del error y la configuración no está activada. El mensaje de error tiene el formato siguiente:
[editedit-path] ‘offending-statement;’error-message
Por ejemplo:
[edit firewall filter login-allowed term allowed from] ‘icmp-type [ echo-request echo-reply ];’ keyword ‘echo-reply’ unrecognized
Debe corregir el error antes de volver a confirmar la configuración. Para volver rápidamente al nivel de jerarquía en el que se encuentra el error, copie la ruta de acceso de la primera línea del error y péguela en el indicador del modo de configuración en el nivel de [edit] jerarquía.
El archivo de configuración candidato no confirmado es /var/rundb/juniper.db. De forma predeterminada, el tamaño del archivo está limitado al tamaño máximo predeterminado de la base de datos de configuración. Puede comprobar el tamaño de la base de datos en el disco y el tamaño máximo de la base de datos ejecutando el show system configuration database usage comando. También puede ver el tamaño del archivo desde el modo de configuración ejecutando el run file list /var/rundb detail comando. Si la configuración candidata supera el tamaño máximo de la base de datos, se produce un error en la confirmación con el mensaje configuration database size limit exceeded. Para corregir el error, puede hacer lo siguiente:
-
Aumente el tamaño máximo de la base de datos de configuración configurando la
extend-sizeinstrucción en el nivel de jerarquía en los[edit system configuration-database]dispositivos que admitan esta instrucción. Debe reiniciar el dispositivo para que el cambio sea efectivo. -
Simplifique la configuración y reduzca el tamaño de archivo creando grupos de configuración con comodines o definiendo políticas de coincidencia menos específicas en sus filtros de firewall.
Después de confirmar la configuración y, si es necesario, reiniciar, puede comprobar cualquier actualización del tamaño de la base de datos en el disco o del tamaño máximo de la base de datos ejecutando el show system configuration database usage comando.
Las advertencias sobre el tiempo de confirmación de la CLI que se muestran para los cambios de configuración en el nivel jerárquico se eliminan y se registran como mensajes de registro del [edit interfaces] sistema.
Esto también se aplica a la configuración de VRRP en los siguientes niveles jerárquicos:
-
[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]
Cuando se confirma una configuración, se confirma toda la configuración en su forma actual.
-
No se recomienda realizar una operación de confirmación en el motor de enrutamiento de respaldo cuando el cambio normal del motor de enrutamiento está habilitado en el dispositivo.
-
Si configura la misma dirección IP para una interfaz de administración o una interfaz
re0:mgmt-0interna como y una interfaz física externa comoxe-0/0/1, cuando la conmutación normal del motor de enrutamiento (GRES) está habilitada, la CLI mostrará un mensaje de error de confirmación adecuado que indica que se encontraron direcciones idénticas en las interfaces privadas y públicas. En tales casos, debe asignar direcciones IP únicas para las dos interfaces que tengan direcciones duplicadas.
Confirmar operación cuando varios usuarios configuran el software
Hasta 32 usuarios pueden estar en el modo de configuración simultáneamente realizando cambios en la configuración. Todos los cambios realizados por todos los usuarios son visibles para todos los que editan la configuración: los cambios se hacen visibles tan pronto como el usuario presiona la tecla Intro al final de un comando que cambia la configuración, como set, edit, o delete.
Cuando alguno de los usuarios que editan la configuración emite un commit comando, la CLI comprueba y activa todos los cambios realizados por todos los usuarios.
Si ingresa al modo de configuración con el configure private comando, cada usuario tiene una configuración candidata privada para editar de manera independiente de otros usuarios. Cuando confirma la configuración, la CLI confirma solo sus propios cambios. Para sincronizar la copia de la configuración después de que otros usuarios hayan confirmado los cambios, puede ejecutar el comando en modo update de configuración. Una operación de confirmación también actualiza todas las configuraciones candidatas privadas. Por ejemplo, supongamos que el usuario X y el usuario Y están en configure private modo y el usuario X confirma un cambio de configuración. Cuando el usuario Y realiza una operación de confirmación posterior y, a continuación, ve la nueva configuración, la nueva configuración que ve el usuario Y incluye los cambios realizados por el usuario X.
Si entra en el modo de configuración con el configure exclusive comando, bloquea la configuración candidata mientras permanezca en el modo de configuración. Esto le permite realizar cambios sin interferencia de otros usuarios. Otros usuarios pueden entrar y salir del modo de configuración, pero no pueden confirmar la configuración. Esto es así incluso si los otros usuarios entraron en el modo de configuración antes de que usted ingrese el configure exclusive comando. Por ejemplo, supongamos que el usuario X ya está en el configure private modo o configure . A continuación, supongamos que el usuario Y entra en el configure exclusive modo. El usuario X no puede confirmar ningún cambio en la configuración, incluso si el usuario X escribió esos cambios antes de que el usuario Y iniciara sesión. Si el usuario Y sale del configure exclusive modo, el usuario X puede confirmar los cambios realizados en configure private o configure modo.
Descripción general de la preparación y activación de confirmaciones
Puede completar el proceso de confirmación en dos pasos. La función de confirmación en dos pasos le permite configurar varios dispositivos y activar las configuraciones simultáneamente. La confirmación en dos pasos proporciona una ventana de tiempo definitiva para que la confirmación sea efectiva en el sistema. Puede entrar en el modo de confirmación después de preparar la confirmación, pero recibirá un mensaje que indica que la confirmación está pendiente de activación.
En el primer paso, la etapa de preparación, se valida el commit y se genera una nueva base de datos con los archivos necesarios. Si la configuración contiene algún error de sintaxis, se muestra un mensaje de error adecuado y la configuración no está preparada. En caso de falla durante la etapa de preparación, se muestra el mensaje commit check-out failedde error.
En el segundo paso, la etapa de activación, se activa la configuración previamente preparada. A continuación, si necesita borrar la configuración preparada, puede hacerlo mediante clear system commit prepared el comando. Se genera un mensaje de registro cuando se borra correctamente la confirmación pendiente.
Le recomendamos que no realice cambios en la configuración entre las etapas de preparación y activación.
El proceso de confirmación de dos pasos es superior al proceso de un solo paso para las confirmaciones críticas en el tiempo. En el proceso de un solo paso, el tiempo de preparación puede variar según la configuración existente en el dispositivo. En el proceso de dos pasos, el complejo trabajo de preparación se maneja de manera más eficiente.
Se proporcionan comandos de configuración que le permiten preparar la caché de configuración y activarla. Puede preparar los dispositivos con nuevas configuraciones y activarlos en los momentos exactos que desee.
El commit prepare comando valida las configuraciones y el commit activate comando activa las configuraciones. Los comandos tienen las siguientes opciones de configuración:
-
and-quit -
no-synchronize -
peers-synchronize -
synchronize
Los commit prepare comandos y commit activate están disponibles solo para confirmaciones privadas, exclusivas y compartidas. Los comandos no son aplicables a los modos dinámico y efímero. Esta función se aplica a dispositivos de varios chasis, pero no a las confirmaciones por lotes.
Para admitir esta funcionalidad mediante el protocolo de configuración de red (NETCONF), se proporcionan las siguientes llamadas de procedimiento remoto (RPC):
-
<commit-configuration>< prepare/></commit-configuration> -
<commit-configuration><activate/></commit-configuration> -
<clear-system-commit><prepared/></clear-system-commit>
Confirme las configuraciones de dispositivos en dos pasos: preparación y activación
Puede completar el proceso de confirmación en dos pasos. Esto le permite configurar varios dispositivos y las configuraciones se pueden activar simultáneamente. En el primer paso, conocido como etapa de preparación, se valida el commit y se genera una nueva base de datos junto con los archivos necesarios. Si la configuración contiene algún error de sintaxis, se muestra un mensaje de error adecuado y la configuración no está preparada. En el segundo paso, denominado etapa de activación, se activa la configuración previamente preparada y se convierte en la configuración actual del dispositivo operativo.
Para preparar la configuración:
Para activar la configuración preparada:
Utilice el
commit activatecomando[edit] user@host#
commit activateSe muestra el mensaje
commit complete.Para comprobar la configuración del sistema activado, utilice el siguiente comando:
user@host>
show configuration system scriptslanguage python;
Para comprobar el resultado de los show system commit comandos y show system commit revision detail después commit activate , emita los siguientes comandos.
user@host> show system commit
0 2018-07-12 22:54:46 PDT by user via cli commit activate
user@host> show system commit revision detail
Revision: re0-1499925285-2214
User : user
Client : cli
Time : 2018-07-12 22:54:46 PDT
Comment : commit activate
Activar la configuración de un dispositivo con confirmación
Cuando confirme la configuración candidata actual, puede requerir una confirmación explícita para que la confirmación se convierta en permanente. Esto resulta útil si desea comprobar que un cambio de configuración funciona correctamente y no impide el acceso al dispositivo. Si el cambio impide el acceso o provoca otros errores, el dispositivo vuelve automáticamente a la configuración anterior y restaura el acceso después de que pase el tiempo de espera de confirmación de reversión. Esta característica se denomina reversión automática.
Para confirmar la configuración candidata actual, pero requerir una confirmación explícita para que la confirmación se convierta en permanente, utilice el comando del modo de commit confirmed configuración:
[edit]
user@host# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
#commit confirmed will be rolled back in 10 minutes
[edit]
user@host#
Una vez que haya verificado que el cambio funciona correctamente, puede mantener activa la nueva configuración ingresando un commit comando or commit check dentro de los 10 minutos posteriores al commit confirmed comando. Por ejemplo:
[edit]
user@host# commit check
configuration check succeeds
Si la confirmación no se confirma en un plazo determinado (10 minutos de forma predeterminada), el sistema operativo vuelve automáticamente a la configuración anterior y se envía un mensaje de difusión a todos los usuarios que hayan iniciado sesión.
Para mostrar cuándo se programa una reversión después de un commit confirmed comando, escriba el show system commit comando. Por ejemplo:
user@host>show system commit
0 2018-01-05 15:00:37 PST by root via cli commit confirmed, rollback in 3mins
Al igual que el commit comando, el commit confirmed comando verifica la sintaxis de configuración e informa de cualquier error. Si no hay errores, la configuración se activa temporalmente (10 minutos de forma predeterminada) y comienza a ejecutarse en el dispositivo.
Para cambiar la cantidad de tiempo antes de tener que confirmar la nueva configuración, especifique el número de minutos durante los cuales ejecuta el comando:
[edit]
user@host# commit confirmed minutes
commit complete
[edit]
user@host#
También puede usar el commit confirmed comando en el [edit private] modo de configuración.
Programar una operación de confirmación
Puede programar cuándo desea que se active la configuración del candidato. Para guardar los cambios en la configuración del dispositivo y activar la configuración en el dispositivo en un momento futuro o al reiniciar, use el comando del modo de commit at configuración, especificando reboot o una hora futura en el nivel de jerarquía [edit]:
[edit]
user@host # commit at string
string es reboot o el futuro para activar los cambios de configuración. Puede especificar la hora en dos formatos:
Un valor de tiempo con el formato
hh:mm[:ss] (horas, minutos y, opcionalmente, segundos): confirme la configuración a la hora especificada, que debe ser en el futuro, pero antes de las 11:59:59 p. m. del día en que se emite el comando delcommit atmodo de configuración. Utilice la hora de 24 horas para el valor; por ejemplo,04:30:00es 4hh:30:00 a. m. y20:00es 8:00 p. m. La hora se interpreta con respecto a la configuración del reloj y la zona horaria del enrutador.Un valor de fecha y hora en formato
yyyy-mm-dd hh:mm[:ss] (año, mes, fecha, horas, minutos y, opcionalmente, segundos): confirme la configuración en el día y la hora especificados, que deben ser después de que se emita elcommit atcomando. Utilice el tiempo de 24 horas para elhhvalor. Por ejemplo,2018-08-2112:30:00son las 12:30 p. m. del 21 de agosto de 2018. La hora se interpreta con respecto a la configuración del reloj y la zona horaria del enrutador.
Escriba el string valor entre comillas (" "). Por ejemplo, commit at "18:00:00". Para fecha y hora, incluya ambos valores en el mismo conjunto de comillas. Por ejemplo, commit at "2018-03-10 14:00:00".
Se realiza una comprobación de confirmación inmediatamente cuando se ejecuta el comando de commit at modo de configuración. Si el resultado de la comprobación se realiza correctamente, la sesión del usuario actual se cierra en el modo de configuración y los datos de configuración se dejan en estado de solo lectura. No se puede realizar ninguna otra confirmación hasta que se complete la confirmación programada.
Si se produce un error en el software del dispositivo antes de que se activen los cambios de configuración, se perderán todos los cambios de configuración.
No puede introducir el comando de commit at configuración después de emitirlo request system reboot .
No puede introducir el request system reboot comando una vez que programe una operación de confirmación para un momento específico en el futuro.
No puede confirmar una configuración cuando hay una confirmación programada pendiente. Para obtener información acerca de cómo cancelar una configuración programada mediante el clear comando, consulte el Explorador de CLI.
No se recomienda realizar una operación de confirmación en el motor de enrutamiento de respaldo cuando el cambio normal del motor de enrutamiento está habilitado en el dispositivo.
Supervise el proceso de confirmación
Para supervisar el proceso de confirmación de configuración del dispositivo, use el display detail comando después de la canalización con el commit comando:
user@host# commit | display detail
Por ejemplo:
[edit]
user@host# commit | display detail2021-10-08 10:33:42.619908 PDT: Obtaining lock for commit
2021-10-08 10:42:36.341266 PDT: Obtaining lock for commit
2021-10-08 10:42:36.343401 PDT: updating commit revision
2021-10-08 10:42:36.343639 PDT: UI extensions feature is not configured
2021-10-08 10:42:36.343718 PDT: UI change-notification feature is not configured
2021-10-08 10:42:36.343877 PDT: Started running translation script
2021-10-08 10:42:36.398596 PDT: No delta input for translation
2021-10-08 10:42:36.398679 PDT: Finished running translation script
2021-10-08 10:42:36.398904 PDT: start loading commit script changes
2021-10-08 10:42:36.398944 PDT: no commit script changes
2021-10-08 10:42:36.399006 PDT: no transient commit script changes
2021-10-08 10:42:36.399046 PDT: finished loading commit script changes
2021-10-08 10:42:36.399091 PDT: No translation output from the scripts
2021-10-08 10:42:36.400007 PDT: building groups inheritance path proportional in
candidate db
2021-10-08 10:42:36.400074 PDT: finished groups inheritance path
2021-10-08 10:42:36.400112 PDT: copying juniper.db to juniper.data+
2021-10-08 10:42:36.402278 PDT: finished copying juniper.db to juniper.data+
2021-10-08 10:42:36.402357 PDT: exporting juniper.conf
2021-10-08 10:42:36.404504 PDT: expanding interface-ranges
2021-10-08 10:42:36.404566 PDT: finished expanding interface-ranges
2021-10-08 10:42:36.404598 PDT: setup foreign files
2021-10-08 10:42:36.411776 PDT: propagating foreign files
2021-10-08 10:42:36.411824 PDT: Sending constraint check command to evaluate con
straints
2021-10-08 10:42:36.580667 PDT: constraints passed in mustd - not checking const
raints in propagation
2021-10-08 10:42:36.586908 PDT: complete foreign files
2021-10-08 10:42:36.663944 PDT: Forking child for configd-streamer operation
2021-10-08 10:42:36.666585 PDT: dropping unchanged foreign files
2021-10-08 10:42:36.666768 PDT: start ffp propagate
2021-10-08 10:42:36.855945 PDT: propagate stp-portid-ffp
2021-10-08 10:42:37.120224 PDT: propagate stp-portid-ffp done
2021-10-08 10:42:37.120447 PDT: propagate interface-alias-ffp
2021-10-08 10:42:37.464777 PDT: propagate interface-alias-ffp done
2021-10-08 10:42:37.467692 PDT: finish ffp propagate
2021-10-08 10:42:37.467826 PDT: Sending command to evaluate validation hooks
2021-10-08 10:42:37.471143 PDT: daemons checking new configuration
2021-10-08 10:42:37.761146 PDT: Collecting status of mustd hooks validation, sta
tus 0
2021-10-08 10:42:37.761273 PDT: commit wrapup...
2021-10-08 10:42:37.761519 PDT: Checking status of configd-streamer child before
ffp activate
2021-10-08 10:42:37.761562 PDT: ev.ops+ file generated successfully
2021-10-08 10:42:37.761635 PDT: start ffp activate
2021-10-08 10:42:37.938324 PDT: activate stp-portid-ffp
2021-10-08 10:42:38.181781 PDT: activate stp-portid-ffp done
2021-10-08 10:42:38.181953 PDT: activate interface-alias-ffp
2021-10-08 10:42:38.373063 PDT: activate interface-alias-ffp done
2021-10-08 10:42:38.373125 PDT: activate hostname-ffp
2021-10-08 10:42:38.731220 PDT: activate hostname-ffp done
2021-10-08 10:42:38.731575 PDT: activate configd-ffp
2021-10-08 10:42:38.904529 PDT: activate configd-ffp done
2021-10-08 10:42:38.906425 PDT: activating '/var/etc/cosd.conf'
2021-10-08 10:42:38.906598 PDT: activating '/var/etc/pam.conf'
2021-10-08 10:42:38.906716 PDT: activating '/var/etc/pam_radius.conf'
2021-10-08 10:42:38.983913 PDT: activating '/var/etc/pam_tacplus.conf'
2021-10-08 10:42:38.984100 PDT: activating '/var/etc/issue'
2021-10-08 10:42:38.984202 PDT: activating '/var/etc/certs'
2021-10-08 10:42:38.991939 PDT: activating '/var/etc/motd'
2021-10-08 10:42:38.992178 PDT: activating '/var/etc/max-db-size-cfg'
2021-10-08 10:42:38.992267 PDT: activating '/var/etc/subs-mgmt-cfg'
2021-10-08 10:42:38.992342 PDT: activating '/var/etc/nc_notification'
2021-10-08 10:42:38.992464 PDT: activating '/var/etc/ephinst.conf'
2021-10-08 10:42:38.992557 PDT: activating '/var/etc/config-apps.txt'
2021-10-08 10:42:38.992674 PDT: executing foreign_commands
2021-10-08 10:42:38.992722 PDT: /bin/sh /etc/rc.ui ui_setup_users (sh)
2021-10-08 10:42:39.24126 PDT: not executing commit in cli_sysctl
2021-10-08 10:42:39.24234 PDT: finish ffp activate
2021-10-08 10:42:39.24278 PDT: db_groups_info_clear start
2021-10-08 10:42:39.419569 PDT: db_groups_info_clear done
2021-10-08 10:42:39.419653 PDT: activating '/var/rundb/juniper.data'
2021-10-08 10:42:40.14698 PDT: Rotate backup configs
2021-10-08 10:42:40.142039 PDT: ssync begins
2021-10-08 10:42:40.566324 PDT: ssync ends
2021-10-08 10:42:40.566392 PDT: ssync begins
2021-10-08 10:42:40.807541 PDT: ssync ends
2021-10-08 10:42:40.807608 PDT: notifying daemons of new configuration
2021-10-08 10:42:40.807804 PDT: ssync begins
2021-10-08 10:42:40.924440 PDT: ssync ends
2021-10-08 10:42:40.924630 PDT: mgd tracing: disabled
2021-10-08 10:42:40.924684 PDT: New database revision 're0-1633714956-29' and ol
d database revision 're0-1633714422-28'
2021-10-08 10:42:40.924709 PDT: commit complete
commit complete
Agregar un comentario para describir la configuración confirmada
Puede incluir un comentario que describa los cambios en la configuración confirmada. Para hacerlo, incluya la commit comment declaración. El comentario puede tener una longitud de hasta 512 caracteres y debe escribirlo en una sola línea.
[edit]
user@host# commit comment comment-string
comment-string es el texto del comentario.
No puede incluir un comentario con el commit check comando.
Para agregar un comentario al commit comando, incluya la comment instrucción después del commit comando:
[edit]
user@host# commit comment "add user joe"
commit complete
[edit]
user@host#
Para agregar un comentario al commit confirmed comando, incluya la comment instrucción después del commit confirmed comando:
[edit]
user@host# commit confirmed comment "add customer to port 27"
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
[edit]
user@host#
Para ver estos comentarios de confirmación, ejecute el comando de show system commit modo operativo.
También puede usar el commit confirmed comando en el [edit private] modo de configuración.
A partir de la versión 24.2R1 de Junos OS, Junos OS le obliga a emitir un comentario para cada solicitud de confirmación. Esto ayuda a realizar un seguimiento de los cambios realizados por varios usuarios o administradores en el momento de la confirmación.
El commit comando no se ejecuta sin el comment argumento.
Para obligar al usuario a agregar un comentario para cada solicitud de confirmación, configure force-commit-log en el nivel jerárquico [edit system commit] .
Descripción general de confirmaciones por lotes
La confirmación por lotes agrega o combina varias ediciones de configuración de diferentes sesiones de CLI o usuarios y las agrega a una cola de confirmación por lotes. Un servidor de confirmación por lotes que se ejecuta en el dispositivo toma uno o varios trabajos de la cola de confirmación por lotes, aplica los cambios de configuración a la base de datos de configuración compartida y, a continuación, confirma los cambios de configuración en una sola operación de confirmación.
El servidor de confirmación prioriza los lotes en función de la prioridad del lote especificado por el usuario o la hora en que se agrega el trabajo por lotes. Cuando se completa una confirmación por lotes, el siguiente conjunto de cambios de configuración se agrega y se carga en la cola por lotes para la siguiente sesión de la operación de confirmación por lotes. Los lotes se crean hasta que no quedan entradas de confirmación en el directorio de la cola.
En comparación con la operación de confirmación normal, en la que todas las confirmaciones se confirman de forma secuencial independiente, las confirmaciones por lotes ahorran tiempo y recursos del sistema al confirmar varias ediciones de configuración pequeñas en una sola operación de confirmación.
Las confirmaciones por lotes se realizan desde el [edit batch] modo de configuración. Las propiedades del servidor de confirmación se pueden configurar en el nivel de [edit system commit server] jerarquía.
Agregación y manejo de errores
Cuando hay un error de tiempo de carga en uno de los trabajos agregados, el trabajo de confirmación que encuentra el error se descarta y los trabajos restantes se agregan y confirman.
Por ejemplo, si se agregan cinco trabajos de confirmación (commit-1, commit-2, commit-3, commit-4y commit-5) y commit-3 encuentra un error durante la carga, commit-3 se descarta y commit-1, commit-2, commit-4y commit-5 se agregan y confirman.
Si hay un error durante la operación de confirmación cuando se agregan y confirman dos o más trabajos, la agregación se descarta y cada uno de esos trabajos se confirma individualmente como una operación de confirmación normal.
Por ejemplo, si hay cinco trabajos de confirmación (commit-1, commit-2, commit-3, commit-4y ) que se agregan y commit-5si hay un error de confirmación causado por , la agregación se descarta, commit-1, , commit-2commit-4commit-3, y commit-5 se confirman individualmente, y la CLI notifica un error de commit-3confirmación para .commit-3
Ejemplo: Configurar propiedades del servidor de confirmación por lotes
En este ejemplo se muestra cómo configurar las propiedades del servidor de confirmación por lotes para administrar las operaciones de confirmación por lotes.
Descripción general
Puede controlar cómo maneja el servidor de confirmación la cola de confirmación por lotes configurando las propiedades del servidor en el [edit system commit server] nivel de jerarquía. Esto le permite controlar cuántos trabajos de confirmación se agregan o combinan en una sola confirmación por lotes, el número máximo de trabajos que se pueden agregar a la cola, los días para mantener los registros de errores de confirmación por lotes, el intervalo entre dos confirmaciones por lotes y las operaciones de seguimiento para las operaciones de confirmación por lotes.
Configuración
- Configuración rápida de CLI
- Configuración de las propiedades del servidor de confirmación
- Confirmar la configuración desde el modo de configuración por lotes
Configuración rápida de CLI
Para configurar rápidamente esta sección del ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el nivel jerárquico [edit] . Puede configurar las propiedades del servidor de confirmación desde el modo normal [edit] o desde el [edit batch] modo.
Dispositivo R0
set system commit server maximum-aggregate-pool 4set system commit server maximum-entries 500set system commit server commit-interval 5set system commit server days-to-keep-error-logs 30set system commit server traceoptions file commitd_novset system commit server traceoptions flag all
Configuración de las propiedades del servidor de confirmación
Procedimiento paso a paso
-
(Opcional) Configure el número de transacciones de confirmación que se agregarán o fusionarán en una sola operación de confirmación.
El valor predeterminado para
maximum-aggregate-pooles5.Nota:Configuración
maximum-aggregate-poolpara comprometer cada1uno de los trabajos de forma individual.En este ejemplo, el número de transacciones de confirmación se establece para
4indicar que se agregan cuatro trabajos de confirmación diferentes en una sola confirmación antes de que se inicie la operación de confirmación.[edit system commit server]user@R0#set maximum-aggregate-pool 4 -
(Opcional) Configure el número máximo de trabajos permitidos en un lote.
Esto limita el número de trabajos de confirmación que se agregan a la cola.
[edit system commit server]user@R0#set maximum-entries 500Nota:Si establece
maximum-entriesen1, el servidor de confirmación no puede agregar más de un trabajo a la cola y la CLI mostrará un mensaje adecuado cuando intente confirmar más de un trabajo. -
(Opcional) Configure el tiempo (en segundos) que se debe esperar antes de iniciar la siguiente operación de confirmación por lotes.
[edit system commit server]user@R0#set commit-interval 5 -
(Opcional) Configure el número de días para conservar los registros de errores.
El valor predeterminado es
30días.[edit system commit server]user@R0#set days-to-keep-error-logs 30 -
(Opcional) Configure operaciones de seguimiento para registrar eventos de confirmación por lotes.
En este ejemplo, el nombre de archivo para registrar eventos de confirmación por lotes es
commitd_nov, y se establecen todas las marcas traceoption.[edit system commit server]user@R0#set traceoptions commitd_novuser@R0#set traceoptions flag all
Resultados
Desde el modo de configuración, ingrese el comando para confirmar la show system commit server configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregirla.
user@R0# show system commit server
maximum-aggregate-pool 4;
maximum-entries 500;
commit-interval 5;
days-to-keep-error-logs 30;
traceoptions {
file commitd_nov;
flag all;
}
Confirmar la configuración desde el modo de configuración por lotes
Procedimiento paso a paso
Para confirmar la configuración desde el [edit batch] modo, realice una de las siguientes acciones:
-
Inicie sesión en el dispositivo e ingrese
commit.[edit batch]user@R0#commitAdded to commit queue request-id: 1000 -
Para asignar una prioridad más alta a un trabajo de confirmación por lotes, ejecute el
commitcomando con lapriorityopción.[edit batch]user@R0#commit priorityAdded to commit queue request-id: 1001 -
Para confirmar una configuración sin agregar los cambios de configuración con otros trabajos de confirmación en la cola, ejecute el
commitcomando con laatomicopción.[edit batch]user@R0#commit atomicAdded to commit queue request-id: 1002 -
Para confirmar una configuración sin agregar los cambios de configuración con otros trabajos de confirmación en la cola y dar una prioridad más alta al trabajo de confirmación, emita el
commitcomando con laatomic priorityopción.[edit batch]user@R0#commit atomic priorityAdded to commit queue request-id: 1003
Verificación
Confirme que la configuración funcione correctamente.
- Comprobación del estado del servidor de confirmación por lotes
- Comprobación del estado de confirmación del lote
- Visualización de los archivos de revisión en un trabajo de confirmación por lotes
- Visualización de los archivos de seguimiento para las operaciones de confirmación por lotes
Comprobación del estado del servidor de confirmación por lotes
Propósito
Compruebe el estado del servidor de confirmación por lotes.
Acción
user@R0> show system commit server
Commit server status : Not running
De forma predeterminada, el estado del servidor de confirmación es Not running. El servidor de confirmación comienza a ejecutarse solo cuando se agrega un trabajo de confirmación por lotes a la cola.
Cuando se agrega un trabajo de confirmación por lotes a la cola, el estado del servidor de confirmación cambia a Running.
user@R0> show system commit server
Commit server status : Running
Jobs in process:
1003 1004 1005
Significado
El Jobs in process campo enumera los ID de confirmación de los trabajos que están en proceso.
Comprobación del estado de confirmación del lote
Propósito
Compruebe en la cola del servidor de confirmación el estado de las confirmaciones por lotes.
Acción
user@R0> show system commit server queue
Pending commits:
Id: 1005
Last Modified: Tue Nov 1 23:56:43 2018
Completed commits:
Id: 1000
Last Modified: Tue Nov 1 22:46:43 2018
Status: Successfully committed 1000
Id: 1002
Last Modified: Tue Nov 1 22:50:35 2018
Status: Successfully committed 1002
Id: 1004
Last Modified: Tue Nov 1 22:51:48 2018
Status: Successfully committed 1004
Id: 1007
Last Modified: Wed Nov 2 01:08:04 2018
Status: Successfully committed 1007
Id: 1009
Last Modified: Wed Nov 2 01:16:45 2018
Status: Successfully committed 1009
Id: 1010
Last Modified: Wed Nov 2 01:19:25 2018
Status: Successfully committed 1010
Id: 1011
Last Modified: Wed Nov 2 01:28:16 2018
Status: Successfully committed 1011
Error commits:
Id: 1008
Last Modified: Wed Nov 2 01:08:18 2018
Status: Error while commiting 1008
Significado
Pending commits Muestra los trabajos de confirmación que se agregan a la cola de confirmación pero que aún no se han confirmado. Completed commits Muestra la lista de trabajos de confirmación que se realizaron correctamente. Error commits son confirmaciones que fallaron debido a un error.
Visualización de los archivos de revisión en un trabajo de confirmación por lotes
Propósito
Vea las marcas de tiempo, los archivos de revisión y el estado de cada uno de los trabajos de confirmación. Los archivos de revisión muestran los cambios de configuración que se producen en cada operación de confirmación que se agrega a la cola de confirmación por lotes.
Acción
-
Utilice el
show system commit server queue patchcomando para ver los parches de todas las operaciones de confirmación.user@R0>
show system commit server queue patchPending commits: none Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit groups] re1 { ... } + GRP-DHCP-POOL-NOACCESS { + access { + address-assignment { + pool <*> { + family inet { + dhcp-attributes { + maximum-lease-time 300; + grace-period 300; + domain-name verizon.net; + name-server { + 4.4.4.1; + 4.4.4.2; + } + } + } + } + } + } + } Id: 1002 Last Modified: Tue Nov 1 22:50:35 2018 Status: Successfully committed 1002 Patch: [edit] + snmp { + community abc; + } Id: 1010 Last Modified: Wed Nov 2 01:19:25 2018 Status: Successfully committed 1010 Patch: [edit system syslog] file test { ... } + file j { + any any; + } Error commits: Id: 1008 Last Modified: Wed Nov 2 01:08:18 2018 Status: Error while commiting 1008 Patch: [edit system] + radius-server { + 10.1.1.1 port 222; + }El resultado muestra los cambios en la configuración de cada ID de trabajo de confirmación.
-
Para ver el parche de un ID de trabajo de confirmación específico, ejecute el
show system commit server queue patch id <id-number>comando.user@R0>
show system commit server queue patch id 1000Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit system] + radius-server { + 192.168.69.162 secret teH.bTc/RVbPM; + 192.168.64.10 secret teH.bTc/RVbPM; + 192.168.60.52 secret teH.bTc/RVbPM; + 192.168.60.55 secret teH.bTc/RVbPM; + 192.168.4.240 secret teH.bTc/RVbPM; + }
Significado
El resultado muestra el parche creado para un trabajo de confirmación. El + signo o - indica los cambios en la configuración de un trabajo de confirmación específico.
Visualización de los archivos de seguimiento para las operaciones de confirmación por lotes
Propósito
Vea los archivos de seguimiento de las operaciones de confirmación por lotes. Puede utilizar los archivos de rastreo para solucionar problemas.
Acción
-
Utilice el
file show /var/log/<filename>comando para ver todas las entradas del archivo de registro.user@R0>
file show/var/log/commitd_novEl resultado muestra los registros de eventos del servidor de confirmación y otros registros para las confirmaciones por lotes.
Nov 1 22:46:43 Successfully committed 1000 Nov 1 22:46:43 pausing after commit for 0 seconds ... Nov 1 22:46:43 Done working on queue ... Nov 1 22:47:17 maximum-aggregate-pool = 5 Nov 1 22:47:17 maximum-entries= 0 Nov 1 22:47:17 asynchronous-prompt = no Nov 1 22:47:17 commit-interval = 0 Nov 1 22:47:17 days-to-keep-error-logs = -1 ... Nov 1 22:47:17 Added to commit queue request-id: 1001 Nov 1 22:47:17 Commit server status=running Nov 1 22:47:17 No need to pause ... Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:47:18 doing rollback ...
-
Para ver las entradas de registro solo de las operaciones de confirmación por lotes correctas, ejecute el
file show /var/log/<filename>comando con la| match committedopción de canalización.El resultado muestra los ID de trabajo de confirmación por lotes para las operaciones de confirmación correctas.
user@R0>
file show/var/log/commitd_nov | match committedNov 1 22:46:43 Successfully committed 1000 Nov 1 22:50:35 Successfully committed 1002 Nov 1 22:51:48 Successfully committed 1004 Nov 2 01:08:04 Successfully committed 1007 Nov 2 01:16:45 Successfully committed 1009 Nov 2 01:19:25 Successfully committed 1010 Nov 2 01:28:16 Successfully committed 1011 -
Para ver las entradas de registro solo de las operaciones de confirmación por lotes con errores, ejecute el
file show /var/log/<filename>comando con la| match “Error while”opción de canalización.El resultado muestra los ID de trabajo de confirmación de las operaciones de confirmación con error.
user@R0>
file show/var/log/commitd_nov | match “Error while”Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:51:10 Error while commiting 1003 Nov 1 22:52:15 Error while commiting 1005 ... -
Para ver las entradas de registro solo para confirmar eventos del servidor, ejecute el
file show /var/log/<filename>comando con la| match “commit server”opción de canalización.El resultado muestra registros de eventos del servidor de confirmación.
user@R0>
file show/var/log/commitd_nov | match “commit server”Nov 1 22:46:39 Commit server status=running Nov 1 22:46:39 Commit server jobs=1000 Nov 1 22:46:43 Commit server status=not running Nov 1 22:46:43 Commit server jobs= Nov 1 22:47:17 Commit server status=running Nov 1 22:47:18 Commit server jobs=1001 Nov 1 22:47:18 2 errors reported by commit server Nov 1 22:47:18 Commit server status=not running Nov 1 22:47:18 Commit server jobs= Nov 1 22:50:31 Commit server status=running Nov 1 22:50:31 Commit server jobs=1002 Nov 1 22:50:35 Commit server status=not running Nov 1 22:50:35 Commit server jobs= Nov 1 22:51:09 Commit server status=running Nov 1 22:51:10 Commit server jobs=1003 Nov 1 22:51:10 2 errors reported by commit server Nov 1 22:51:10 Commit server status=not running ...
Realice una copia de seguridad de la configuración confirmada en la unidad de arranque alternativa
Después de confirmar la configuración y estar satisfecho de que se está ejecutando correctamente, debe ejecutar el request system snapshot comando para hacer una copia de seguridad del nuevo software en el /altconfig sistema de archivos. Si no ejecuta el request system snapshot comando, la configuración de la unidad de arranque alternativa no estará sincronizada con la configuración de la unidad de arranque principal.
El request system snapshot comando realiza una copia de seguridad del sistema de archivos raíz en /altroot, y /config en . /altconfig Los sistemas raíz y /config de archivos se encuentran en la unidad flash del enrutador, y los /altroot sistemas de archivos y /altconfig se encuentran en el disco duro del enrutador (si está disponible).
Después de ejecutar el request system snapshot comando, no puede volver a la versión anterior del software, ya que las copias en ejecución y de copia de seguridad del software son idénticas.