2.12　使用NETCONF管理网络

讨论管理协议时，对话很容易转到关于它的组件、客户端、服务器和协议细节。最重要的话题不知何故失去了。问题的核心是你真正想要实现的用例以及如何实现它们。首要目标是简化网络运维人员的生活。“从运维人员的角度来看，易用性是网络管理技术的关键要求”（RFC 3535，要求1）。

网络运维人员希望“专注于整个网络的配置而不是单个设备”（RFC 3535，要求#4）。由于构建网络的是设备和布线，确实无法避免管理设备。然而运维人员力图提出的一点是，在管理网络时提高抽象级别很方便。他们希望使用网络级概念而不是设备级命令进行管理。

这是网络管理系统（NMS）供应商一个好的范例，但是为了使NMS系统适当小巧、简单和廉价，管理协议责任重大。三十年的行业网管经验一次又一次地告诉我们，由于管理协议设计糟糕，网管供应商在这三个方面通常都会遭遇失败。

NETCONF如何支持NMS开发？让我们看看网络管理中的典型用例：如何在L3VPN上提供一个额外的分支。

典型的L3VPN至少包括以下内容：

• 位于VPN端点附近的用户边缘（CE）设备，如：商店位置、分支机构或住家
• 位于提供商核心网络外缘的提供商边缘（PE）设备
• 核心网络连接所有中枢，并绑定到所有PE设备
• 提供监控解决方案确保L3VPN按照预期和承诺执行
• 确保隐私和安全的安全解决方案

要将L3VPN分支（leg）添加到网络，NMS中运行的L3VPN应用至少须牵涉新站点上的CE设备、CE设备连接的PE设备、监控系统以及可能与安全相关的少数设备。CE可能是虚拟设备，在这种情况下，NMS可能需要与某个容器管理器或虚拟基础设施管理器（VIM）通话以启动虚拟机（VM）。有时必须牵涉大约20个设备才能启动一个L3VPN分支。所有这些都是分支功能化的要求。具有访问控制列表（ACL）的所有防火墙和路由器都需要获取更新，否则流量无法启动。需要在两端正确设置加密，否则流量将不安全。需要设置监控，否则无法检测到服务终端。

为了用NETCONF在网络中实现新的分支，管理器将在相关设备上运行一个网络范围的事务，更新其候选数据存储并进行验证；如果一切正常，管理器将认定该更改为运行中的数据存储。“区分配置的分布和特定配置的激活非常重要。设备应能够保持多个配置。”（RFC 3535，要求#13）。下面是管理器采取的更详细步骤：

第1步　根据拓扑结构和请求的端点，找出需要涉及哪些设备才能实现新的分支。

第2步　通过NETCONF连接到所有相关设备，然后在这些设备上锁定（<lock>）NETCONF数据存储:running和:candidate。

第3步　清除（<discard-chages>)设备上的:candidate数据存储。

第4步　计算每个设备所需的配置更改。

第5步　使用计算出的更改，编辑（<edit config>）每个设备的:candidate数据存储。

第6步　验证（<validate>）:candidate数据存储。

在事务理论中，事务在成功时有两个（或三个）阶段。到目前为止，所有的动作都处于事务的PREPARE（准备）阶段。PREPARE阶段结束时，所有设备都必须报告<ok>或<rpc-error>。这是一个关键的决策点，事务理论家通常称这是“不可返回点”。

如果该点前有任何参与设备报告<rpc-error>，事务已失败并进入ABORT（中止）阶段。网络上什么也没有发生。NMS安全地断开与所有设备的连接。这意味着更改从未激活，并且锁定现在已释放。

如果所有设备在此处报告<ok>，NMS将进入COMMIT（提交）阶段。

接下来，提交（<commit>）每台设备的:candidate（候选）数据存储。这将激活更改。

这个描述将工作分割成两阶段提交（验证介于两者之间）来激活更改听起来简单明了。同时必须认识到，在网络管理环境中，这是一种革命性的做法，不是因为它很难做到，而是因为它能够实现什么。

除非你有NMS解决方案编程经验，否则很难想象如果设备不支持单独的事务，NMS中检测和解决任一错误所需的代码量。本例甚至有整个网络范围的事务。在一个成熟的NMS中，大约一半的代码专门用于错误检测和从大量异常情况中恢复。恢复代码也是开发中最昂贵的部分，因为它涉及的是本不应发生的特殊案例和情况。这类情况很复杂，需要复现来进行测试，甚至需要重新构思。

软件项目的成本在很大程度上与编写的代码量成正比，这意味着当设备支持网络范围的事务时，传统NMS一半以上的成本将被消减。

刚才描述的两阶段、全网范围的事务在现在的NETCONF设备中广泛使用。节省了很多代码，但不包括故障保护。<commit>操作可能会失败，与设备的连接可能会丢失，或者设备在向所有设备发送<commit>时可能会崩溃或没有响应。这将导致一些设备激活更改，而其他设备则没有。为了进一步加强这一点，NETCONF还定义了一个管理器可能希望使用的三阶段全网事务。

通过在前面的<commit>阶段提供标志<confirmed>，事务进入第三个CONFIRM（确认）阶段（从PREPARE到COMMIT再到CONFIRM）。如果NMS发送此标志，则NMS必须在给定的时限内返回以重新确认更改。

如果在时限结束时未收到确认，或者与NMS的连接丢失，则每个设备将回滚到以前的配置状态。事务计时器运行时NMS会进行各种测试和测量，以验证它刚才创建的L3VPN分支是否按预期创建了功能。如果没有，只需关闭与事务中所涉及的所有设备的连接，让它们全部消失。如果一切正常，就提交并解锁，如下所示：

第1步　再给一次<commit>，这次没有<confirmed>标志。

第2步　解锁<unlock> :running和:candidate存储。

关于NETCONF网络范围内的事务有很多选项和细节可以在这里讨论，但是重要的一点已经提出来了，我们会做修改。有了这种底层技术，NMS开发人员就可以成为真正的懒汉。嗯，也不是真的懒汉，因为他们完成的用例数量是没有事务的情况下的两倍。这些用例运行更加可靠。这一讨论突出了网络范围事务的价值。“支持跨多个设备的配置事务将大大简化网络配置管理”（RFC 3535，要求5）。

再缩小一个级别，观察网络范围内的事务是如何融入全局的。从控制理论的角度看网络管理。任何机电工程师都知道，在复杂的环境中建立工作良好的控制系统的正确方法是在设计中加入一个反馈回路。传统的控制理论如图2-6所示。

将其转换为网络管理语境，图2-7显示了这幅原理图。

如图中所示，显然需要一种机制将配置推送到网络或从其中取出。“转储和还原配置的机制是运维人员所需的原语操作。从设备拉取/向设备推送配置的标准是他们想要的”（RFC 3535，要求7）。

网络事务是管理器控制网络的重要机制。如果没有网络事务，管理器将变得非常复杂，效率也会降低（换句话说，网络将在较少部分的时间内与意图保持一致）。然而，为了闭环，其他每个步骤都同样重要。当监视读取网络状态时，它利用NETCONF功能将配置与其他数据分离。“有必要明确区分配置数据、描述运行状态的数据和统计数据。有些设备很难确定哪些参数是管理配置的，哪些是通过其他机制（如路由协议）获得的”（RFC 3535，要求2）。

在NETCONF中使用标准化操作（<get>和<get-onfig>）传递数据，语义在设备之间保持一致。“必须能够从设备中分别获取配置数据、操作状态数据和统计数据，并能够在设备之间进行比较”（RFC 3535，要求3）。通过在设备上使用标准化的YANG模型数据结构保持一致。

随后，差分引擎将意图性能与原始意图进行比较，以查看当前实现意图的策略的工作情况（请记住第1章中基于意图的网络趋势），并将实际网络配置与所需的网络配置进行比较。如果需要或需要更改策略或更改策略比较理想（例如，由于对端故障，或者另外一个数据中心的计算价格较低），管理器将计算新的所需配置并将其发送到网络。“给定配置A和配置B，应该以最小的状态更改和最小的对网络和系统的影响生成从A到B所需的操作，将配置更改所造成的影响降到最低很重要”（RFC 3535，要求6）。

显然，要实现这一点，事务的定义必须非常严格。差分引擎不按特定顺序计算任意更改包。如果必须以某种特定的方式对所有差异进行排序，管理器的复杂性会急剧增加。除非网络中的每个设备都以机器可读的形式描述这种特殊方式，否则NMS只能是一个梦想，不可能实现。

因此，与NETCONF一起使用的事务定义必须描述一组更改，这些更改加在一起应用于当前配置时必须一致且有意义。这是关于一致的配置，而不是原子序列变化的配置。“超时和链路两端的配置必须易于进行一致性检查，以确定两个配置之间的更改以及这些配置是否一致”（RFC 3535，要求#8）。

这与按给定顺序执行的操作序列不同，其中每个中间步骤本身必须是有效的配置。如果正确的顺序来自管理器，那么服务器（设备）端显然更容易实现，就像SNMP中的传统做法一样，这就是为什么许多实现者倾向于采用这种方式。让我们清楚地说明NETCONF事务一致性是在事务的末尾。否则，反馈控制器用例将无法实现，而你将回去摸黑使用简单脚本来配置网络。

在允许或要求运维人员与管理器同时干预的网络中，同样的反馈能力必不可少。当前这是一个共同的运维现状，总是导致不可预见的情况。除非有一个反馈循环机制可以计算新的配置并适应不断变化的环境，否则更复杂的用例将永远不会出现。