本节书摘来自异步社区《Cisco IOS XR技术精要》一书中的第4章，第4.4节，作者 【美】Mobeen Tahir , Mark Ghattas , Dawit Birhanu , Syed Natif Nawaz，更多章节内容可以访问云栖社区“异步社区”公众号查看
4.4 理解二级提交模型
Cisco IOS XR技术精要
Cisco IOS XR中使用了二级提交模型的思想。在单级提交模型中，输入到路由器中的每条命令都会立刻生效。这种配置模型存在一些弊端，首先是用户无法对输入的命令进行审核确认，如果不小心输入了错误的命令，错误命令将会当即生效，造成业务影响。其次是当用户使用脚本或整段配置“刷”配置时，可能大多数的配置都是重复或无用的配置，而且，重复配置可能会导致系统处于不稳定的状态。
在二级提交模型中。在一级配置阶段，用户输入的配置放入target config中，而不会影响路由器的running config。在这一阶段，系统可以检查命令的语法，用户可以检验配置的命令是否正确，从而保证target config的正确性。在二级配置阶段（又叫提交［commit］阶段）中，所有target config将被提交，合并成为路由器running config的一部分。
二级提交进程有助于应用大量配置；并帮助完成大量配置生效后的后续操作如命令验证、检查点、日志等。二级提交进程减少了进程间通信（IPC）的负载，从而提高了系统性能。
图4-5说明了二级配置模型的结构。
4.4.1 生成target config
实际上，running config中的配置是用户输入的target config多次累积下来的结果。换句话说，用户想要对当前配置做修改所执行的命令会存放在target config中。每个用户都有自己唯一的target config，对其他用户不可见。不过，基于每个用户的target config实例生成的路由器running config，对每个用户都是可见的。
用户可以在不影响当前路由器配置的条件下，查看或修改target config，或是将target config以文件形式备份出来1，IOS XR中的running config是无法直接编辑的。所有对running config的配置变更都必须将target config提交之后才能生效。
当用户进入配置模式之后，系统会隐式地生成一个唯一的target config。这个target config不是running config的一个副本，而是在running config基础上用户新配置的、仍未提交的配置。用户可以通过show configuration命令查看当前会话的target config。还可以使用show configuration merge命令查看当前会话的target config与running config合并后的结果。
例4-3给出了生成target config所必须的步骤。
例4-3 生成target config
4.4.2 commit操作
提交（commit）操作是指使用commit命令提交target config并生成新running config的过程，如图4-6所示。默认情况下的commit命令是不对配置做任何检验的，换句话说，commit操作可能会因为配置语义的问题导致提交失败。
每次成功commit操作将触发以下动作。
1．执行commit之前，首先会锁住配置会话。
2．将配置变更保存到commit变更数据库中，创建回退点。
3．向配置历史中添加commit变更条目。
4．使用Syslog生成配置变更通告。
5．最后将target config合并到running config中，commit操作完成。
6．解锁配置会话。
每次输入并提交新配置后，Cisco IOS XR会向配置历史中添加一条commit变更条目，并使用Syslog生成一条配置变更通告，如例4-4所示。
例4-4 Commit阶段的日志通告信息
commit操作默认会分配一份commit变更ID，允许用户基于此ID查看配置变更细节。例4-4中的1000000057就是最后一次配置commit所生成的commit变更ID。通过这一ID，可以查看某次commit操作中所执行的配置变更。
例4-5中，使用命令show configuration commit changes < commit-change-id >基于ID查看例4-4中commit的配置变更。
例4-5 查看例4-4中commit操作的配置变更
target config的提交方式既可以是“一意孤行”的，也可以是“尽力而为”的。前文介绍过，使用“一意孤行”这种默认commit方式（commit命令不加任何选项），会将所有变更的配置一并提交上去。如果某条命令验证失败，commit操作将会回退，并向配置代理返回一条错误消息。
使用“尽力而为”方式（commit best-effort），系统仅会将验证通过的配置变更提交。当然，如果某条命令验证失败，也会向配置代理返回一条错误消息，不过commit操作不会回退。用户可以使用许多commit命令选项，如例4-6所示。
例4-6 commit操作可用选项
commit操作阶段，配置管理器会在后台锁住配置会话，以防其他配置代理对配置进行变更。路由器会在commit操作结束后，对running config配置会话解锁。关于commit命令的可用选项后文可能不会一一进行介绍，更多命令配置信息请登录Cisco.com进行查询。
例4-7给出了commit操作中comment选项（对配置变更添加描述信息）和label选项（为commit手动分配一个ID）的用法。这两个选项可使回退操作更加方便 2。
例4-7 使用label和comment选项的commit操作
1．commit操作confirmed选项
命令commit confirmed可使target config试验性地提交，而不是作为永久配置。用户可以在commit confirmed后添加一个回退计时器，在配置提交一段时间后，使系统配置自动回退到提交前的系统状态。也可以在回退计时器到期之前，再次输入commit confirmed，将配置提交成永久配置。配置模式支持confirmed提交操作，回退计时器单位可以是秒或分钟。admin模式下不支持confirmed提交。
在例4-8中，用户将系统主机名临时从R1修改成CRS1-3，持续时间30秒。30秒后，配置将自动回退到先前的主机名R1。
例4-8 使用confirmed选项的commit操作
2．commit失败
配置可能会由于配置语义验证不通过而导致配置提交失败。如果在默认提交操作中发生提交失败，target config不会应用到running config上。在IOS XR中，提交失败的信息可以通过show configuration failed命令查看，如例4-9所示。通过命令输入可以查看提交失败的原因及应对办法（如提示的话）。
例4-9 未定义class sample_class所导致的提交失败
3．启动阶段的配置失败
在系统启动时，用户可能也会遇到一些配置失败的情况。尤其是在对路由器的IOS XR软件版本进行升级或降级操作之后。
可能的配置失败有以下几种原因。
语法错误（Syntax Errors）：语法错误是由parser（分析程序）检验出来的，会提示CLI命令不支持。这种错误通常是由于命令输入错误或是当前的软件版本支持不支持该命令所导致。
语义错误（Semantic Errors）：语义错误是启动阶段由系统后台检验出来的。例4-9就是语义错误的一例。语义错误是某个配置组件不能正常工作所导致的，常见原因是配置不一致或配置元素无法调用。
应用错误（Apply Errors）：当配置通过了语义检查并确认成为running config的一部分之后，有可能后台组件无法更新其工作状态，这种问题被称为应用错误。
用户可以使用命令show configuration failed startup来查看启动阶段的失败配置，如例4-10所示。
例4-10 启动阶段的配置失败
1译者注：备份target config的命令为save configuration device:directory-path，或showconfiguration | file filename。
2译者注：IOS XR中有一种向配置文件中添加注释（comment）的方法，用法是在配置之前先输入一行以感叹号!开头的注释信息，例如：
RP/0/RP0/CPU0:CRS(config)#!this is a test configuration-20130512-by-powerfoo
RP/0/RP0/CPU0:CRS(config)#hostname TEST
RP/0/RP0/CPU0:CRS(config)#commit
提交配置后，命令show run可以看到添加的注释信息。尽管注释需要commit才能生效，但这个注释信息是不会显示在show configuration commit list detail命令中的，请读者区分这个“配置注释”与本节介绍的“commit注释”的区别。此外，删除配置注释的命令为clear comment，而不是传统的no方式。
