使用 NETCONF 或 Junos XML 协议提交和同步临时配置数据
提交临时实例概述
临时数据库是一个备用配置数据库,它使 NETCONF 和 Junos XML 协议客户端应用程序能够同时在 Junos 设备上加载和提交配置更改,并且具有比将数据提交到候选配置数据库时更高的吞吐量。客户端应用程序可以在临时配置数据库的打开实例中提交配置数据,以便它成为设备上活动配置的一部分。在设备上提交临时配置数据时,设备的活动配置是静态和临时配置数据库的合并视图。
临时提交模型验证提交到临时数据库的配置数据的语法,但不验证语义或约束。必须先验证所有配置数据,然后再将其加载到临时数据库中并将其提交到设备上。提交无效的配置数据可能会导致 Junos 进程重新启动甚至崩溃,并导致系统或网络中断。
客户端应用程序提交临时实例后,设备会将配置数据合并到临时数据库中。受影响的系统进程会解析配置并将临时数据与活动配置中的数据合并。如果静态和临时配置数据库中存在冲突的语句,则会根据特定的优先级规则合并数据。数据库优先级(从最高到最低)如下所示:
-
临时配置数据库的用户定义实例中的语句。
如果有多个用户定义的临时实例,则优先级由在层次结构级别配置
[edit system configuration-database ephemeral]
实例的顺序(从最高优先级到最低优先级)确定。 -
默认临时数据库实例中的语句。
-
静态配置数据库中的语句。
除了静态配置数据库之外,应用程序还可以同时将数据加载和提交到不同的临时数据库实例。但是,设备会按顺序处理提交。因此,对特定数据库的提交可能会延迟,具体取决于处理顺序。
如果提交的临时配置数据无效或导致不希望的网络中断,则必须从数据库中删除有问题的数据,或者在必要时重新启动设备,这将删除临时配置数据库的所有实例中的配置数据。
活动设备配置是静态和临时配置数据库的合并视图。但是,当您使用操作模式命令在 show configuration
CLI 中显示配置时,输出不包括临时配置数据。在 CLI 中,可以在临时数据库的特定实例中显示数据,也可以使用命令的 show ephemeral-configuration
变体显示静态和临时配置数据库的合并视图。
如何提交临时实例
客户端应用程序可以在临时配置数据库的打开实例中提交配置数据,以便它成为设备上活动配置的一部分。要提交配置,请使用 <commit-configuration/>
Junos XML 协议会话中的操作或 <commit-configuration/>
NETCONF 会话中的或 <commit/>
操作。
在 Junos XML 协议会话中,客户端应用程序通过将标记包含在 <commit-configuration/>
标记元素中 <rpc>
来提交临时配置数据库的打开实例中的配置数据(与候选配置一样)。
<rpc> <commit-configuration/> </rpc>
Junos XML 协议服务器在 、 <commit-results>
和<routing-engine>
标记元素中<rpc-reply>
报告提交操作的结果。如果提交操作成功,<routing-engine>
则标记元素将<commit-success/>
标记和<name>
指定目标路由引擎的标记元素括起来。
<rpc-reply xmlns:junos="URL"> <commit-results> <routing-engine> <name>routing-engine-name</name> <commit-success/> </routing-engine> </commit-results> </rpc-reply>
在 NETCONF 会话中,客户端应用程序通过将 or <commit/>
<commit-configuration/>
标记括在标记元素中 <rpc>
来提交临时配置数据库的打开实例中的配置数据(与候选配置一样)。
<rpc> <commit/> </rpc> ]]> ]]>
<rpc> <commit-configuration/> </rpc> ]]> ]]>
NETCONF 服务器通过在标记元素中<rpc-reply>
返回<ok/>
标记来确认提交操作是否成功。
<rpc-reply xmlns="URN" xmlns:junos="URL"> <ok/> </rpc-reply> ]]> ]]>
如果提交操作失败,NETCONF 服务器将返回 <rpc-reply>
元素和 <rpc-error>
子元素,这解释了失败的原因。
临时数据库支持的唯一提交操作变体是同步配置,如 同步临时实例概述中所述。
同步临时实例概述
当您在临时实例上发出提交操作时,双路由引擎设备和虚拟机箱系统不会自动同步临时配置数据。您可以每次提交或按会话同步临时实例中的数据,也可以将临时实例配置为每次提交实例时同步其数据。环境确定数据的同步位置,例如:
-
在具有双路由引擎的设备上,设备会将临时实例同步到备份路由引擎。
-
MX 系列虚拟机箱仅将临时实例同步到备份设备的主路由引擎。
-
EX 系列虚拟机箱将临时实例同步到所有成员交换机。
多机箱环境不支持将临时配置数据库同步到相应虚拟机箱成员上的备份路由引擎。
有关同步临时实例的说明,请参阅以下部分:
默认情况下,临时提交模型异步执行提交同步操作。NETCONF 或 Junos XML 协议服务器在本地路由引擎上提交配置,然后在远程路由引擎或虚拟机箱成员上提交配置。请求路由引擎提交临时配置并发出提交完成通知,而无需等待其他路由引擎或虚拟机箱成员首先同步并提交配置。
在受支持的设备上,还可以将临时数据库配置为使用同步提交模型进行提交同步操作。同步提交操作比异步提交操作速度较慢,但更可靠。要使用同步模型,请在静态配置数据库中的层次结构级别配置commit-synchronize-model synchronous
[edit system configuration-database ephemeral]
语句。
同步临时实例时,Junos XML 协议服务器会在 、 <commit-results>
和<routing-engine>
标记元素中<rpc-reply>
报告本地路由引擎的提交操作结果。如果提交操作成功,<routing-engine>
则标记元素将<commit-success/>
标记和<name>
指定目标路由引擎的标记元素括起来。
服务器回复包括依赖于数据库使用的提交同步模型的其他标记。
-
如果临时数据库使用同步模型,则服务器回复将包含用于其他路由引擎上提交操作的第二个
<routing-engine>
元素。 -
如果临时数据库使用异步模型,服务器将包含
<commit-synchronize-server-success>
tag 元素,该元素指示在其他路由引擎或虚拟机箱成员上安排同步操作,并提供完成操作所需的估计时间(以秒为单位)。
例如:
<rpc-reply xmlns:junos="URL"> <commit-results> <routing-engine> <name>re0</name> <commit-success/> </routing-engine> </commit-results> <commit-synchronize-server-success> <current-job-id>0</current-job-id> <number-of-jobs>1</number-of-jobs> <estimated-time>60</estimated-time> </commit-synchronize-server-success> </rpc-reply>
同步提交同步操作的 RPC 回复指示其他路由引擎或虚拟机箱成员上的提交操作是成功还是失败。如果设备配置为记录给定设施和严重性级别的事件,则设备会将异步提交同步操作的成功或失败记录在系统日志文件中。有关各种临时数据库事件以及记录这些事件所需的设施和严重性级别,请参阅 系统日志资源管理器 。
同样,在 NETCONF 会话中,服务器通过在标记元素中<rpc-reply>
返回<ok/>
标记来确认提交操作是否成功。根据设备配置,响应还可能包括用于同步提交同步操作的<commit-results>
元素或<commit-synchronize-server-success>
用于异步提交同步操作的元素。例如:
<rpc-reply xmlns="URN" xmlns:junos="URL"> <ok/> <commit-synchronize-server-success> <current-job-id>0</current-job-id> <number-of-jobs>1</number-of-jobs> <estimated-time>60</estimated-time> </commit-synchronize-server-success> </rpc-reply> ]]>]]>
在静态配置数据库上发出命令时, commit synchronize
设备不会将临时配置数据库同步到其他路由引擎或虚拟机箱成员。
如何配置启用 GRES 的设备以同步临时配置数据
默认情况下,启用平稳路由引擎切换 (GRES) 时,临时数据库会异步执行提交同步操作,并且不会将临时配置数据同步到备份路由引擎或其他虚拟机箱成员。如果临时数据库使用异步提交同步模型,则必须将该 allow-commit-synchronize-with-gres
语句配置为允许启用 GRES 的设备执行提交同步操作。
或者,在受支持的设备上,您可以改为将临时数据库配置为使用同步提交模型来执行提交同步操作。同步提交操作比异步提交操作速度较慢,但更可靠。建议在启用了 GRES 的设备上使用同步提交模型。
要启用已将 GRES 配置为同步临时配置数据的设备,请执行以下操作:
如何在每次提交的基础上同步临时实例
您可以跨路由引擎或虚拟机箱成员同步临时实例,以便对该实例执行给定提交操作。
要基于每次提交同步临时实例,请执行以下操作:
如何基于每个会话同步临时实例
对于在临时实例打开期间执行的所有提交操作,您可以在路由引擎或虚拟机箱成员之间同步临时实例,我们将其大致称为会话。这不应与 NETCONF 或 Junos XML 协议会话混淆。通过按会话同步实例,您可以执行多个加载和提交操作,并确保每个提交操作自动同步实例,直到您将其关闭。
要为临时实例在实例打开期间执行的所有提交操作同步该实例,请执行以下操作:
如何在提交时自动同步临时实例
在运行 Junos OS 版本 22.1R1 或更高版本的设备上以及运行 Junos OS 演化版的设备上,您可以配置临时实例,以便在您每次提交实例时跨路由引擎或虚拟机箱成员同步其配置。
要将临时实例配置为每次提交实例时同步,请执行以下操作:
在临时实例配置的层次结构级别添加 synchronize
语句 [edit system commit]
后,只要设备满足同步数据库的必要要求,设备就会自动将实例同步到其他路由引擎或虚拟机箱成员。
如何为临时数据库配置故障转移配置同步
MX 系列虚拟机箱和双路由引擎设备支持临时数据库的故障切换配置同步,这有助于确保在路由引擎切换时在路由引擎之间同步配置数据库。在静态配置数据库中的层次结构级别配置commit synchronize
[edit system]
语句时,可以实现此目的。
如果在静态配置数据库中配置该 commit synchronize
语句,它将产生以下影响:
-
在提交操作期间,设备将其静态配置数据库同步到备份路由引擎或 MX 虚拟机箱备份设备。
注意:在静态配置数据库中配置
commit synchronize
语句不会在提交静态配置数据库或提交实例时将临时实例同步到备份设备。 -
从 Junos OS 20.2R1 版开始,备份路由引擎和 MX 虚拟机箱备份设备在与主设备同步时会同步静态和临时配置数据库。在早期版本中,备份路由引擎仅同步静态配置数据库。
注意:对于故障切换同步,仅当备份设备和主设备运行相同的软件版本时,备份路由引擎和 MX 虚拟机箱备份设备才会将临时配置数据库与主设备同步。
在主路由引擎和备份路由引擎上配置 commit synchronize
语句时,在以下情况下,备份路由引擎会将其配置与主路由引擎同步:
-
备份路由引擎已卸下并重新插入
-
备份路由引擎重新启动
-
设备执行平稳的路由引擎切换
-
需要手动更改角色
-
将插入配置语句
commit synchronize
的新备份路由引擎
在双路由引擎系统上,备份路由引擎将其配置数据库与主路由引擎同步。在 MX 系列虚拟机箱中,备份设备上的主路由引擎将其配置数据库与主设备上的主路由引擎同步。
要为运行 Junos OS 20.2R1 或更高版本的受支持设备或运行 Junos OS 演化版的设备上的静态和临时数据库启用故障转移配置同步:
更改历史记录表
功能支持由您使用的平台和版本决定。使用 功能资源管理器 确定您的平台是否支持某个功能。
synchronize
语句
[edit system commit]
时,备份路由引擎在与主路由引擎同步时会同步静态和临时配置数据库。在早期版本中,备份路由引擎仅同步静态配置数据库。