Confirmar y sincronizar una configuración en planos de control redundantes mediante el protocolo XML de Junos
Un motor de enrutamiento se encuentra dentro de un plano de control. Para configuraciones de chasis único, hay un plano de control. En los sistemas redundantes, hay dos planos de control, el plano principal y el plano de respaldo. En configuraciones de varios chasis, el plano de control incluye todos los motores de enrutamiento con la misma designación de motor de enrutamiento. Por ejemplo, todos los motores de enrutamiento principales residen dentro del plano de control principal y todos los motores de enrutamiento de respaldo residen dentro del plano de control de respaldo .
Confirmar una configuración aplica una nueva configuración al motor del dispositivo. En una configuración de varios chasis, una vez que se confirma un cambio en la configuración en el sistema, este cambio se propaga por todo el plano de control mediante la función de distribución.
En una arquitectura redundante, puede emitir el synchronize
comando para confirmar la nueva configuración con los planos de control principal y de respaldo. Cuando se emite, este comando guarda la configuración actual en ambos motores de enrutamiento de dispositivos y confirma la nueva configuración en ambos planos de control. En un sistema multichasis, una vez confirmada la configuración en ambos planos, la función de distribución distribuye la nueva configuración entre ambos planos. Para obtener más información acerca de la redundancia del motor de enrutamiento, consulte la Guía del usuario de alta disponibilidad de Junos OS.
En una arquitectura multichasis con planos de control redundantes, hay una diferencia entre sincronizar los dos planos y distribuir la configuración a lo largo de cada plano. La sincronización solo se produce entre los motores de enrutamiento dentro del mismo chasis. Una vez que se completa esta sincronización, la nueva configuración se distribuye a todos los demás motores de enrutamiento dentro de los planos de control de otros chasis como una función de distribución independiente.
Dado que la sincronización se realiza en dos planos de control independientes, la sincronización de configuraciones solo es válida en arquitecturas de motor de enrutamiento redundantes. Además, se deben definir grupos de configuración re0 y re1 en cada plataforma de enrutamiento, conmutación o seguridad. Para obtener más información acerca de los grupos de configuración, consulte la Guía del usuario de CLI.
Si ejecuta el synchronize
comando en un sistema de motor de enrutamiento no redundante, el servidor de protocolo XML de Junos confirma la configuración en un plano de control.
Para obtener más información acerca de cómo sincronizar la base de datos de configuración efímera, consulte Confirmar y sincronizar datos de configuración efímera mediante el protocolo NETCONF o Junos XML. Para obtener más información acerca de cómo sincronizar la configuración del candidato, consulte las siguientes secciones:
Sincronización de la configuración de candidato en ambos motores de enrutamiento
Para sincronizar la configuración del candidato o la copia privada en <commit-configuration>
un sistema de motor de enrutamiento redundante, una aplicación cliente encierra la etiqueta vacía <synchronize/>
y <rpc>
los elementos de etiqueta:
<rpc> <commit-configuration> <synchronize/> </commit-configuration> </rpc>
El servidor de protocolo JUnos XML verifica la corrección sintáctica de la configuración en el motor de enrutamiento donde se emite la <synchronize/>
etiqueta (conocido como el motor de enrutamiento local), copia la configuración en el motor de enrutamiento remoto y verifica su corrección sintáctica allí, y, luego, confirma la configuración en ambos motores de enrutamiento .
El servidor de protocolo JUnos XML encierra su respuesta y <rpc-reply>
<commit-results>
los elementos de etiqueta. Emite un elemento de etiqueta independiente <routing-engine>
para cada operación en cada motor de enrutamiento:
Si la comprobación de sintaxis se realiza correctamente en un motor de enrutamiento, el
<routing-engine>
elemento tag encierra la<commit-check-success/>
etiqueta y el<name>
elemento tag, que informa el nombre del motor de enrutamiento en el que se produjo la comprobación (re0 o re1):<routing-engine> <name>(re0 | re1)</name> <commit-check-success/> </routing-engine>
Si la configuración es incorrecta, un
<xnm:error>
elemento tag adjunta una descripción del error.Si la operación de confirmación se realiza correctamente en un motor de enrutamiento, el
<routing-engine>
elemento tag encierra la<commit-success/>
etiqueta y el<name>
elemento tag, que informa el nombre del motor de enrutamiento en el que se produjo correctamente la operación de confirmación:<routing-engine> <name>(re0 | re1)</name> <commit-success/> </routing-engine>
Si se produce un error en la operación de confirmación, un
<xnm:error>
elemento tag adjunta una descripción del error. Las causas más comunes de falla son errores semánticos o sintácticos en la configuración.
En el siguiente ejemplo, se muestra cómo confirmar y sincronizar la configuración de candidato en ambos motores de enrutamiento.
Forzar una operación de confirmación sincronizada
La operación de sincronización falla si la configuración candidata del segundo motor de enrutamiento está bloqueada. Si se produce un error de sincronización, es mejor determinar la causa de la falla, tomar medidas correctivas y, luego, volver a sincronizar los dos motores de enrutamiento. Sin embargo, cuando sea necesario, puede usar el <force-synchronize/>
comando para invalidar una configuración bloqueada y forzar la sincronización.
Cuando utilice un force-synchronize
comando, se perderán los cambios no comprometidos en la configuración.
Para forzar una sincronización, encierre las etiquetas vacías <synchronize/>
y <force-synchronize/>
en los <rpc>
elementos y <commit-configuration>
tag:
<rpc> <commit-configuration> <synchronize/> <force-synchronize/> </commit-configuration> </rpc>
En un entorno multichasis, se produce la sincronización entre motores de enrutamiento en el mismo chasis. Una vez que se produce la sincronización, los cambios de configuración se propagan por cada plano de control mediante la función de distribución. Si uno o varios motores de enrutamiento se bloquean durante la distribución de la configuración, la distribución y, por lo tanto, la sincronización fallarán. Deberá borrar el error en el chasis remoto y ejecutar el synchronize
comando de nuevo.
En el siguiente ejemplo, se muestra cómo forzar una sincronización en ambos planos de motor de enrutamiento:
Aplicación de cliente |
Servidor de protocolo XML de Junos |
<rpc> <commit-configuration> <synchronize/> <force-synchronize/> </commit-configuration> </rpc> |
|
<rpc-reply xmlns:junos= "http://xml.juniper.net/junos/9.010/junos"> <commit-results> <routing-engine junos:style="show-name"> <name>re0</name> <commit-check-success/> </routing-engine> <routing-engine junos:style="show-name"> <name>re1</name> <commit-success/> </routing-engine> <routing-engine junos:style="show-name"> <name>re0</name> <commit-success/> </routing-engine> </commit-resuls> </rpc-reply> |
Sincronización simultánea de la configuración del candidato con otras operaciones
La <synchronize/>
etiqueta se puede combinar con los otros elementos de etiqueta que se pueden producir dentro del <commit-configuration>
elemento tag. El servidor de protocolo JUnos XML comprueba, copia y confirma la configuración, y emite los mismos elementos de etiqueta de respuesta que cuando la <synchronize/>
etiqueta se utiliza por sí mismo. Las combinaciones posibles se describen en las siguientes secciones.
Verificar la configuración en ambos motores de enrutamiento
Para comprobar la corrección sintáctica de una configuración local en ambos motores de enrutamiento sin confirmarlo, la aplicación encierra los <synchronize/>
elementos de etiqueta y <check/>
etiqueta en <commit-configuration>
y <rpc>
los elementos de etiqueta:
<rpc> <commit-configuration> <synchronize/> <check/> </commit-configuration> </rpc>
La <force-synchronize/>
etiqueta no se puede combinar con los elementos de etiqueta <check/>
.
Para obtener más información acerca de cómo verificar configuraciones, consulte Verificar la sintaxis de configuración mediante el protocolo XML de Junos.
Programación de sincronización para un tiempo especificado
Para confirmar una configuración en ambos motores de enrutamiento en un momento especificado en el futuro, la aplicación encierra los <synchronize/>
elementos de etiqueta y <at-time>
etiqueta en <commit-configuration>
y <rpc>
los elementos de etiqueta:
<rpc> <commit-configuration> <synchronize/> <at-time>time</at-time> </commit-configuration> </rpc> <rpc> <commit-configuration> <force-synchronize/> <at-time>time</at-time> </commit-configuration> </rpc>
Como cuando el <at-time>
elemento de etiqueta se emite por sí mismo, el servidor de protocolo Junos XML verifica la corrección sintáctica de inmediato y no emite elementos de etiqueta adicionales cuando realmente realiza la operación de confirmación en cada motor de enrutamiento.
Sincronización de configuraciones pero que requieren confirmación
Para confirmar la configuración candidata en ambos motores de enrutamiento, pero requiere confirmación para que la confirmación sea permanente, la aplicación encierra los <synchronize/>
elementos de etiqueta , <confirmed/>
y (opcionalmente) <confirm-timeout>
en <commit-configuration>
y <rpc>
los elementos de etiqueta:
<rpc> <commit-configuration> <synchronize/> <confirmed/> [<confirm-timeout>minutes</confirm-timeout>] </commit-configuration> </rpc>
La misma fecha límite de devolución se aplica a ambos motores de enrutamiento y puede extenderse en ambos a la vez emitiendo de nuevo los <synchronize/>
elementos de etiqueta , <confirmed/>
y (opcionalmente) <confirm-timeout>
en el motor de enrutamiento donde se emitieron los elementos de etiqueta la primera vez.
La <force-synchronize/>
etiqueta no se puede combinar con los <confirmed/>
elementos y <confirm-timeout>
tag.
Para obtener más información acerca de las operaciones de confirmación confirmadas, consulte Confirmar la configuración del candidato solo después de la confirmación con el protocolo XML de Junos.
Registro de un mensaje sobre configuraciones sincronizadas
Para sincronizar configuraciones y registrar un mensaje de registro cuando la confirmación tiene éxito en cada motor de enrutamiento, la aplicación encierra los <synchronize/>
elementos de etiqueta y <rpc>
<log/>
etiqueta y <commit-configuration>
los elementos de etiqueta:
<rpc> <commit-configuration> <synchronize/> <log>message</log> </commit-configuration> </rpc> <rpc> <commit-configuration> <force-synchronize/> <log>message</log> </commit-configuration> </rpc>
La operación de confirmación procede como se describe anteriormente en las descripciones de la <synchronize/>
etiqueta o <force-synchronize/>
. El mensaje de cada motor de enrutamiento se registra en el registro del historial de confirmación que mantiene ese motor de enrutamiento. Para obtener más información acerca del registro, consulte Registrar un mensaje acerca de una operación de confirmación con el protocolo JUnos XML.