Confirmar la configuración

La configuración del dispositivo se guarda mediante un modelo de confirmación: una configuración candidata se modifica según se desee y, a continuación, 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 encuentran errores, 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 cualquier otro archivo de configuración de reversión se incrementa en 1. Por ejemplo, juniper.conf.1.gz se incrementa a juniper.conf.2.gz, convirtiéndolo 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 /config directorio. (Los archivos de reversión restantes, del 4 al 49, se encuentran en /var/db/config.)

Si existe el archivo rescue.conf.gz de configuración de recuperación, este archivo también se encuentra en el /config directorio. Los archivos predeterminados de fábrica se encuentran en el /etc/config directorio.

Existen dos mecanismos que se utilizan 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 de dispositivo.

  Para sincronizar configuraciones, utilice el comando de la commit synchronize CLI. Si uno de los motores de enrutamiento está bloqueado, se produce un error en la sincronización. Si se produce un error en la sincronización debido a un archivo de configuración bloqueado, puede utilizar el commit synchronize force comando. 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 se bloquea durante una distribución de una configuración, la configuración bloqueada no recibe el archivo de configuración distribuida, por lo que se produce un error en la sincronización. Debe borrar el bloqueo antes de la configuración y volver a sincronizar los planos de enrutamiento.

  Nota:

  Cuando se utiliza el comando CLI commit synchronize force 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 donde se emitió el comando, se producirá un error en la sincronización en el dispositivo remoto. Debe borrar el bloqueo y volver a emitir el synchronization comando.

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, utilice el comando de commit modo de configuración. Puede emitir el commit comando desde cualquier nivel jerárquico:

Cuando se introduce el commit comando, primero se comprueba si hay errores de sintaxis (commit check). A continuación, si la sintaxis es correcta, la configuración se activa y se convierte en la configuración actual del dispositivo operativo.

Una confirmación de configuración puede fallar por cualquiera de los siguientes motivos:

• La configuración incluye una sintaxis incorrecta, lo que provoca 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 está bloqueada por un usuario que escribió el configure exclusive comando.

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 siguiente formato:

Por ejemplo:

Debe corregir el error antes de volver a confirmar la configuración. Para volver rápidamente al nivel de jerarquía donde 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 [edit] nivel de jerarquía.

El archivo de configuración candidato no confirmado es /var/rundb/juniper.db. Está limitado a 700 MB. Si se produce un error en la confirmación con un mensaje configuration database size limit exceeded, introduzca el comando run file list /var/rundb detailpara ver el tamaño del archivo desde el modo de configuración. Puede simplificar la configuración y reducir el tamaño del archivo creando grupos de configuración con caracteres comodín o definiendo políticas de coincidencia menos específicas en los filtros de firewall.

Cuando se confirma una configuración, se confirma toda la configuración en su forma actual.

Hasta 32 usuarios pueden estar en modo de configuración realizando cambios simultáneamente 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, edito delete.

Cuando alguno de los usuarios que editan la configuración emite un commit comando, la CLI comprueba y activa todos los cambios de todos los usuarios.

Si entra en modo de configuración con el configure private comando, cada usuario tiene una configuración candidata privada para editar de forma algo independiente de otros usuarios. Cuando confirma la configuración, la CLI confirma solo sus propios cambios. Para sincronizar su 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 de candidatos privados. 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 vista por el usuario Y incluye los cambios realizados por el usuario X.

Si entra en el modo de configuración con el configure exclusive comando, bloqueará 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 cierto incluso si los demás usuarios entraron en el modo de configuración antes de escribir el configure exclusive comando. Por ejemplo, supongamos que el usuario X ya está en el configure private modo o configure . Entonces 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 introdujo 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.

El proceso de confirmación de dos pasos es superior al proceso de un solo paso para confirmaciones de tiempo crítico. En el proceso de un solo paso, el tiempo de preparación puede variar dependiendo de 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 activar la configuración. 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 solo están disponibles para confirmaciones privadas, exclusivas y compartidas. Los comandos no son aplicables para los modos dinámico y efímero. Esta característica es aplicable a dispositivos multichasis, pero no a confirmaciones por lotes.

Para admitir esta funcionalidad mediante el Protocolo de configuración de red (NETCONF), se proporcionan las siguientes llamadas a procedimiento remoto (RPC) nuevas:

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

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

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

La confirmación por lotes agrega o combina varias ediciones de configuración de diferentes sesiones o usuarios de CLI 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 más 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 cola.

En comparación con la operación de confirmación normal, en la que todas las confirmaciones se confirman secuencialmente de forma 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.

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.