Confirmar e sincronizar uma configuração em planos de controle redundantes usando o protocolo Junos XML
Um mecanismo de roteamento reside em um plano de controle. Para configurações de chassi único, há um plano de controle. Em sistemas redundantes, há dois planos de controle, o plano principal e o plano de backup. Em configurações multichassis, o plano de controle inclui todos os mecanismos de roteamento com a mesma designação de Mecanismo de Roteamento. Por exemplo, todos os mecanismos de roteamento primários residem no plano de controle principal , e todos os mecanismos de roteamento de backup residem dentro do plano de controle de backup .
Comprometer uma configuração aplica uma nova configuração ao mecanismo do dispositivo. Em uma configuração multichassis, uma vez que uma mudança na configuração foi comprometida com o sistema, essa mudança é propagada por todo o plano de controle usando a função de distribuição.
Em uma arquitetura redundante, você pode emitir o synchronize
comando para comprometer a nova configuração para os planos de controle primários e de backup. Quando emitido, este comando salva a configuração atual para ambos os mecanismos de roteamento de dispositivos e compromete a nova configuração para ambos os planos de controle. Em um sistema multichassis, uma vez que a configuração tenha sido comprometida em ambos os planos, a função de distribuição distribui a nova configuração em ambos os planos. Para obter mais informações sobre a redundância do mecanismo de roteamento, consulte o Guia de usuário de alta disponibilidade do Junos OS.
Em uma arquitetura multichassis com planos de controle redundantes, há uma diferença entre sincronizar os dois planos e distribuir a configuração por todo o plano. A sincronização ocorre apenas entre os mecanismos de roteamento dentro do mesmo chassi. Assim que essa sincronização estiver concluída, a nova configuração é distribuída a todos os outros mecanismos de roteamento dentro dos planos de controle de outros chassis como uma função de distribuição separada.
Como a sincronização acontece em dois planos de controle separados, a sincronização das configurações só é válida em arquiteturas redundantes do Mecanismo de Roteamento. Além disso, os grupos de configuração re0 e re1 devem ser definidos em cada plataforma de roteamento, comutação ou segurança. Para obter mais informações sobre grupos de configuração, consulte o Guia do usuário da CLI.
Se você emitir o synchronize
comando em um sistema de mecanismo de roteamento nãoredundant, o servidor de protocolo Junos XML confirma a configuração em um único plano de controle.
Para obter informações sobre como sincronizar o banco de dados de configuração efêmero, veja dados de configuração efêmeros comprometidos e sincronizados usando o protocolo NETCONF ou Junos XML. Para obter mais informações sobre a sincronização da configuração do candidato, veja as seguintes seções:
Sincronização da configuração do candidato em ambos os mecanismos de roteamento
Para sincronizar a configuração do candidato ou a cópia privada em um sistema redundante de mecanismo de roteamento, um aplicativo do cliente inclui a tag <commit-configuration>
vazia <synchronize/>
e <rpc>
os elementos de tag:
<rpc> <commit-configuration> <synchronize/> </commit-configuration> </rpc>
O servidor de protocolo Junos XML verifica a correção sintactica da configuração no Mecanismo de Roteamento onde a <synchronize/>
tag é emitida (referida como mecanismo de roteamento local), copia a configuração para o mecanismo de roteamento remoto e verifica sua correção sintactica lá e, em seguida, confirma a configuração em ambos os mecanismos de roteamento .
O servidor de protocolo Junos XML inclui elementos de resposta <rpc-reply>
e <commit-results>
tag. Ela emite um elemento de tag separado <routing-engine>
para cada operação em cada mecanismo de roteamento:
Se a verificação da sintaxe for bem sucedida em um mecanismo de roteamento, o
<routing-engine>
elemento tag inclui a<commit-check-success/>
tag e o<name>
elemento tag, que informa o nome do Mecanismo de roteamento no qual a verificação foi bem sucedida (re0 ou re1):<routing-engine> <name>(re0 | re1)</name> <commit-check-success/> </routing-engine>
Se a configuração estiver incorreta, um
<xnm:error>
elemento de tag inclui uma descrição do erro.Se a operação de confirmação for bem sucedida em um mecanismo de roteamento, o
<routing-engine>
elemento tag inclui a<commit-success/>
tag e o<name>
elemento tag, que informa o nome do Mecanismo de Roteamento no qual a operação de confirmação foi bem sucedida:<routing-engine> <name>(re0 | re1)</name> <commit-success/> </routing-engine>
Se a operação de confirmação falhar, um
<xnm:error>
elemento de tag inclui uma descrição do erro. As causas mais comuns de falha são erros semânticos ou sintáticos na configuração.
O exemplo a seguir mostra como comprometer e sincronizar a configuração do candidato em ambos os mecanismos de roteamento.

Forçando uma operação de confirmação sincronizada
A operação de sincronização falha se a configuração do candidato do segundo mecanismo de roteamento estiver bloqueada. Se ocorrer uma falha de sincronização, é melhor determinar a causa da falha, tomar medidas corretivas e, em seguida, sincronizar os dois mecanismos de roteamento novamente. No entanto, quando necessário, você pode usar o <force-synchronize/>
comando para substituir uma configuração bloqueada e forçar a sincronização.
Quando você usa um force-synchronize
comando, qualquer alteração não comprometida na configuração será perdida.
Para forçar uma sincronização, coloque o vazio <synchronize/>
e <force-synchronize/>
as etiquetas nos <rpc>
elementos e <commit-configuration>
marque:
<rpc> <commit-configuration> <synchronize/> <force-synchronize/> </commit-configuration> </rpc>
Em um ambiente multichassis, a sincronização ocorre entre mecanismos de roteamento no mesmo chassi. Assim que a sincronização ocorre, as alterações de configuração são propagadas em cada plano de controle usando a função de distribuição. Se um ou mais mecanismos de roteamento estiverem bloqueados durante a distribuição da configuração, a distribuição e, portanto, a sincronização falhará. Você precisará limpar o erro no chassi remoto e executar o synchronize
comando novamente.
O exemplo a seguir mostra como forçar uma sincronização em ambos os planos do Mecanismo de Roteamento:
Aplicativo para clientes |
Servidor de protocolo Junos XML |
<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> |
Sincronização da configuração do candidato simultaneamente com outras operações
A <synchronize/>
tag pode ser combinada com os outros elementos de tag que podem ocorrer dentro do <commit-configuration>
elemento tag. O servidor de protocolo Junos XML verifica, copia e confirma a configuração, e emite os mesmos elementos de tag de resposta que quando a <synchronize/>
tag é usada por si só. As possíveis combinações são descritas nas seções a seguir.
Verificando a configuração em ambos os mecanismos de roteamento
Para verificar a correção sintactica de uma configuração local em ambos os mecanismos de roteamento sem compensá-lo, o aplicativo inclui os <synchronize/>
elementos <commit-configuration>
de tag e <check/>
<rpc>
elementos de tag:
<rpc> <commit-configuration> <synchronize/> <check/> </commit-configuration> </rpc>
A <force-synchronize/>
tag não pode ser combinada com os elementos da <check/>
tag.
Para obter mais informações sobre a verificação das configurações, consulte Verificar a sintaxe de configuração usando o protocolo Junos XML.
Sincronização de agendamento por um horário especificado
Para confirmar uma configuração em ambos os mecanismos de roteamento em um momento especificado no futuro, o aplicativo inclui os <synchronize/>
elementos de tag e <at-time>
<rpc>
elementos <commit-configuration>
de tag:
<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 quando o <at-time>
elemento tag é emitido por si mesmo, o servidor de protocolo Junos XML verifica a correção sintactica imediatamente e não emite elementos de tag adicionais quando ele realmente realiza a operação de confirmação em cada Mecanismo de Roteamento.
Sincronização de configurações, mas exigindo confirmação
Para confirmar a configuração do candidato em ambos os mecanismos de roteamento, mas exigir a confirmação para que o compromisso se torne permanente, o aplicativo inclui os <synchronize/>
elementos de tag, <confirmed/>
e (opcionalmente) <confirm-timeout>
elementos <commit-configuration>
<rpc>
de tag:
<rpc> <commit-configuration> <synchronize/> <confirmed/> [<confirm-timeout>minutes</confirm-timeout>] </commit-configuration> </rpc>
O mesmo prazo de reversão se aplica tanto aos Mecanismos de roteamento quanto pode ser estendido de uma vez, emitindo novamente os <synchronize/>
elementos de tag, <confirmed/>
e (opcionalmente) <confirm-timeout>
no Mecanismo de Roteamento, onde os elementos da tag foram emitidos pela primeira vez.
A <force-synchronize/>
tag não pode ser combinada com os elementos de <confirmed/>
<confirm-timeout>
tag.
Para obter mais informações sobre operações de confirmação de confirmação, consulte Comprometer a configuração do candidato somente após a confirmação usando o protocolo Junos XML.
Registrar uma mensagem sobre configurações sincronizadas
Para sincronizar configurações e registrar uma mensagem de log quando o commit for bem sucedido em cada Mecanismo de Roteamento, o aplicativo inclui os <synchronize/>
elementos <commit-configuration>
de tag e <log/>
<rpc>
elementos de tag:
<rpc> <commit-configuration> <synchronize/> <log>message</log> </commit-configuration> </rpc> <rpc> <commit-configuration> <force-synchronize/> <log>message</log> </commit-configuration> </rpc>
A operação de confirmação prossegue conforme descrito anteriormente nas descrições ou <synchronize/>
<force-synchronize/>
tags. A mensagem para cada mecanismo de roteamento é registrada no log de histórico de confirmação mantido pelo mecanismo de roteamento. Para obter mais informações sobre o registro, veja registrar uma mensagem sobre uma operação de confirmação usando o protocolo Junos XML.