1. 现在我们已经完成了对网络层的研究，在我们面前只有链路层，我们很清楚地意识到网络由许多复杂的、相互作用的硬件和软件组成——从链路、交换机、路由器、主机、和其他设备组成的物理组件的网络到许多协议，控制和协调这些设备。当组织将数百或数千个这样的组件组合在一起形成一个网络时，网络管理员的工作就是保持网络“正常运行”，这无疑是一个挑战。我们在第5.5节看到逻辑上集中的控制器可以在SDN上下文中帮助实现这个过程。但是网络管理的挑战早在SDN之前就已经存在了，它提供了一套丰富的网络管理工具和方法，帮助网络管理员监视、管理和控制网络。我们将在本节中研究这些工具和技术，以及与SDN共同发展的新工具和技术。<br />一个常见的问题是“什么是网络管理？”[Saydam 1996]对网络管理的一个构思良好的单句定义(尽管这是一个相当长的句子)是：

网络管理包括硬件、软件和人员元素的部署、集成和协调，以监控、测试、轮询、配置、分析、评估和控制网络和元素资源，以合理的成本满足实时、操作性能和服务质量要求。

  1. 根据这个宽泛的定义，我们将在本节中仅介绍网络管理的基础知识-网络管理员在执行其任务时使用的体系结构、协议和数据。我们不会讨论管理员的决策过程，在这些过程中需要考虑的主题包括故障识别[Labovitz 1997；Steinder 2002；Feamster 2005；Wu 2005；Teixeira 2006]、异常检测[Lakhina 2005；Barford 2009]、满足合同服务级别协议(SLA)的网络设计/工程[Huston 1999a]等。因此，我们的关注点是有意狭窄的；感兴趣的读者应该参考这些参考资料、[Subramanian 2000；Schonwalder 2010；Claise 2019]中的优秀概述，以及本书网站上提供的关于网络管理的更详细论述。

5.7.1 网络管理框架 The Network Management Framework

图5.20显示了网络管理的关键组件：
image.png
Figure 5.20 ♦ Elements of network management
图5.20♦网络管理的元素

  • 管理服务器（Managing server）。管理服务器是在网络运营中心(network operations center，NOC)的集中式网络管理站中运行的应用程序，通常环路中有网络管理员（network managers）(人)。管理服务器是网络管理的活动场所：它控制网络管理信息和命令的收集、处理、分析和调度。正是在这里，启动了配置、监控和控制网络受管设备的操作。实际上，一个网络可能有几个这样的管理服务器。
  • 托管设备（Managed device）。托管设备是驻留在托管网络上的一块网络设备(包括其软件)。托管设备可以是主机、路由器、交换机、中间盒、调制解调器、温度计或其他联网设备。设备本身将具有许多可管理的组件(例如，网络接口只是主机或路由器的一个组件)，以及这些硬件和软件组件的配置参数(例如，AS内路由协议，例如OSPF)。
  • 数据（Data）。每个被管理的设备都将具有与其相关联的数据，也称为“状态”。有几种不同类型的数据。配置数据（Configuration data）是由网络管理器明确配置的设备信息，例如，管理器为设备接口分配/配置的IP地址或接口速度。操作数据（Operational data ）是设备在操作时获取的信息，例如，OSPF协议中的直接邻居列表（the list of immediate neighbors）。设备统计数据（Device statistics）是随着设备操作员更新的状态指示符和计数(例如，接口上丢弃的数据包数量，或设备的冷却风扇速度)。网络管理器可以查询远程设备数据，并且在某些情况下，通过写入设备数据值来控制远程设备，如下所述。如图5.17所示，管理服务器还维护来自其被管理设备的配置、操作和统计数据以及网络范围的数据(例如，网络拓扑)的自己的副本。
  • 网络管理代理（Network management agent）。网络管理代理是在被管理设备中运行的软件进程，其与管理服务器通信，在管理服务器的命令和控制下在被管理设备处采取本地动作。网络管理代理类似于我们在图5.2中看到的路由代理。
  • 网络管理协议（Network management protocol）。网络管理框架的最后一个组件是网络管理协议。该协议运行在管理服务器和被管理设备之间，允许管理服务器查询被管理设备的状态，并通过其代理在这些设备上采取操作。代理可以使用网络管理协议向管理服务器通知异常事件(例如，组件故障或违反性能阈值)。需要注意的是，网络管理协议本身并不管理网络。相反，它提供了网络管理员可以用来管理(“监视、测试、轮询、配置、分析、评估和控制”)网络的功能。这是一个微妙但重要的区别。

实际上，网络运营商使用上述组件管理网络有三种常用方式：

  • CLI。网络运营商可以向设备发出直接命令行接口(direct Command Line Interface，CLI)命令。这些命令可以直接在受控设备的控制台上键入(如果操作员实际在设备上)，也可以通过管理服务器/控制器和受控设备之间的Telnet或安全外壳(SSH)连接(可能通过脚本)键入。CLI命令因供应商和设备而异，可能相当晦涩难懂。虽然经验丰富的网络向导可能能够使用CLI完美地配置网络设备，但CLI的使用容易出错，而且很难实现大型网络的自动化或高效扩展。面向消费者的网络设备(如您的无线家庭路由器)可能会导出您(网络管理员！)可以通过HTTP访问以配置该设备。虽然这种方法可能适用于单一、简单的设备，并且比CLI更不容易出错，但它也不能扩展到更大规模的网络。
  • SNMP/MIB。在此方法中，网络运营商可以使用简单网络管理协议(Simple Network Management Protocol，SNMP)查询/设置设备的管理信息库(Management Information Base，MIB)对象中包含的数据。一些MIB是特定于设备和供应商的，而其他MIB(例如，由于IP数据报头中的错误而在路由器处丢弃的IP数据报的数量，或者在主机处接收的UDP段的数量)是设备不可知的，从而提供抽象性和一般性。网络运营商通常会使用此方法来查询和监控操作状态和设备统计信息，然后使用CLI主动控制/配置设备。我们注意到，重要的是，这两种方法都单独管理设备。我们将在下面的5.7.2节中介绍自20世纪80年代末以来一直在使用的SNMP和MIB。互联网体系结构委员会在2002年召开的一次网络管理研讨会[RFC3535]不仅指出了SNMP/MIB方法在设备监控方面的价值，而且指出了它的缺点，特别是在大规模设备配置和网络管理方面。这导致了最新的网络管理方法，使用NETCONF和YANG。

  • NETCONF/YANG。NETCONF/YANG方法对网络管理采取了更抽象、更全网和更全面的观点，更加强调配置管理，包括指定正确性约束和在多个受控设备上提供原子管理操作。YANG[RFC6020]是一种用于对配置和操作数据建模的数据建模语言。NETCONF协议[RFC 6241]用于向/从远程设备传送与YANG兼容的操作和数据，或在远程设备之间传送与YANG兼容的操作和数据。在图5.17中的OpenDaylight Controller案例研究中，我们简要介绍了NETCONF和YANG，并将在下面的5.7.3节中对它们进行研究。

    5.7.2 简单网络管理协议(SNMP)和管理信息库(MIB) The Simple Network Management Protocol (SNMP) and the Management Information Base (MIB)

    简单网络管理协议版本3(SNMPv3)[RFC 3410]是用于在管理服务器和代表该管理服务器执行的代理之间传送网络管理控制和信息消息的应用层协议。SNMP最常见的用法是在请求-响应模式下，在该模式下，SNMP管理服务器向SNMP代理发送请求，SNMP代理接收该请求，执行某些操作，并发送对该请求的响应。通常，请求将用于查询(检索)或修改(设置)与被管理设备相关联的MIB对象值。SNMP的第二种常见用法是代理向管理服务器发送未经请求的消息(称为陷阱消息（trap message）)。陷阱消息用于通知管理服务器已导致MIB对象值改变的异常情况(例如，链路接口打开或关闭)。
    MIB对象以称为SMI(Structure of Management Information)[RFC 2578；RFC 2579；RFC 2580]的数据描述语言指定，这是网络管理框架的一个名称相当奇怪的组件，其名称没有给出其功能的任何提示。使用形式化的定义语言来确保网络管理数据的语法和语义被良好地定义并且没有歧义。相关的MIB对象被收集到MIB模块中。截至2019年末，与MIB相关的RFC超过400个，供应商特定(专用)MIB模块的数量要多得多。
    SNMPv3定义了七种类型的消息，通常称为协议数据单元(protocol data units，PDU)，如表5.2所示，如下所述。PDU的格式如图5.21所示。
    image.png
    Table 5.2 ♦ SNMPv3 PDU types
    表5.2♦SNMPv3 PDU类型
    image.png
    Figure 5.21 ♦ SNMP PDU format
    图5.21♦SNMP PDU格式

  • GetRequest、GetNextRequest和GetBulkRequest PDU都从管理服务器发送到代理，以请求代理的受管设备上的一个或多个MIB对象的值。其值被请求的MIB对象在PDU的变量绑定部分中指定。GetRequest、GetNextRequest和GetBulkRequest的数据请求粒度不同。GetRequest可以请求任意一组MIB值；可以使用多个GetNextRequest对MIB对象的列表或表进行排序；GetBulkRequest允许返回大块数据，避免了发送多个GetRequest或GetNextRequest消息时产生的开销。在这三种情况下，代理都会使用包含对象标识符及其关联值的响应PDU进行响应。

  • 管理服务器使用SetRequest PDU来设置受控设备中一个或多个MIB对象的值。代理回复带有“noError”错误状态的响应PDU，以确认该值确实已设置。
  • 管理服务器使用InformRequest PDU将接收服务器远程的MIB信息通知给另一个管理服务器。
  • Response PDU通常从被管理设备发送到管理服务器，以响应来自该服务器的请求消息，返回所请求的信息。
  • SNMPv3 PDU的最后一种类型是陷阱消息（trap message）。陷阱消息是异步生成的；也就是说，它们不是响应于接收到的请求而生成的，而是响应管理服务器需要通知的事件而生成的。RFC 3418定义了众所周知的陷阱类型，包括设备冷启动或热启动、链路接通或断开、邻居丢失或身份验证失败事件。接收到的陷阱请求不需要来自管理服务器的响应。

鉴于SNMP的请求-响应特性，这里值得注意的是，尽管SNMP PDU可以通过许多不同的传输协议来承载，但SNMP PDU通常在UDP数据报的有效载荷中承载。事实上，RFC 3417声明UDP是“首选的传输映射”。但是，由于UDP是一种不可靠的传输协议，因此不能保证在预定目的地接收到请求或其响应。管理服务器使用PDU的请求ID字段(参见图5.21)对其发送给代理的请求进行编号；代理的响应从接收到的请求中获取其请求ID。因此，管理服务器可以使用请求ID字段来检测丢失的请求或回复。如果在给定的时间量之后没有接收到相应的响应，则由管理服务器决定是否重发请求。具体地说，SNMP标准没有强制要求任何特定的重传过程，甚至在重传开始时也不强制重传。它只要求管理服务器“在重传的频率和持续时间方面采取负责任的行动”。当然，这会让人怀疑一个“负责任的”协议应该如何运作！
SNMP经历了三个版本的演变。SNMPv3的设计者说“SNMPv3可以被认为是具有额外安全和管理功能的SNMPv2”[RFC 3410]。当然，SNMPv3比SNMPv2有变化，但这些变化在管理和安全领域表现得最为明显。SNMPv3中安全性的核心作用尤为重要，因为缺乏足够的安全性导致SNMP主要用于监视而不是控制(例如，SetRequest很少在SNMPv1中使用)。我们再一次看到，安全性—我们将在第8章详细讨论的一个主题—是一个关键问题，但它的重要性再次被意识到可能有点晚，只是在那时才被“补充”。

管理信息库(MIB) The Management Information Base (MIB)

我们在前面了解到，在SNMP/MIB网络管理方法中，被管理设备的操作状态数据(在某种程度上还包括其配置数据)被表示为集合到该设备的MIB中的对象。MIB对象可以是计数器，例如由于IP数据报头中的错误而在路由器处丢弃的IP数据报的数量；或者以太网接口卡中的载波侦听错误的数量；描述性信息，例如在DNS服务器上运行的软件的版本；状态信息，例如特定设备是否正常工作；或者特定于协议的信息，例如到目的地的路由路径。相关的MIB对象被收集到MIB模块中。在各种IETC RFC中定义了400多个MIB模块；还有更多特定于设备和供应商的MIB。[RFC 4293]指定MIB模块，该模块定义用于管理Internet协议(IP)及其关联的Internet控制消息协议(ICMP)实现的托管对象(包括ipSystemStatsInDelivers)。[RFC 4022]指定TCP的MIB模块，[RFC 4113]指定UDP的MIB模块。
虽然与MIB相关的RFC会造成相当乏味和枯燥的阅读，但考虑MIB对象的示例仍然是有指导意义的(即，就像吃蔬菜一样，它“对您有好处”)，来自[RFC 4293]的ipSystem-StatsInDelivers对象类型定义定义了一个32位只读计数器，该计数器跟踪在被管理设备处接收并成功传递到上层协议的IP数据报的数量。在下面的示例中，Counter32是SMI中定义的基本数据类型之一。
image.png

5.7.3 网络配置协议(NETCONF)和YANG The Network Configuration Protocol (NETCONF) and YANG

NETCONF协议在管理服务器和被管理网络设备之间操作，提供消息传送以(i)检索、设置和修改被管理设备处的配置数据；(ii)查询被管理设备处的操作数据和统计数据；以及(iii)订阅由被管理设备生成的通知。管理服务器通过向被管理设备发送在结构化XML文档中指定的配置并激活被管理设备处的配置来主动控制被管理设备。NETCONF使用远程过程调用(RPC)范例，其中协议消息也以XML编码，并通过安全的、面向连接的会话(如TCP上的TLS(传输层安全)协议(在第8章中讨论)在管理服务器和受控设备之间进行交换)。
图5.22显示了NETCONF会话示例。首先，管理服务器建立到被管理设备的安全连接。(在NETCONF的说法中，管理服务器实际上被称为“客户端”，被管理设备被称为“服务器”，因为管理服务器建立到被管理设备的连接。但是，为了与图5.20中显示的长期存在的网络管理服务器/客户端术语保持一致，我们在这里将忽略这一点。)。一旦建立了安全连接，管理服务器和受控设备就交换消息，声明它们的“能力”-NETCONF功能，该功能补充了[RFC 6241]中的基本NETCONF规范。管理服务器和被管理设备之间的交互采用远程过程调用的形式，使用和消息。这些消息用于检索、设置、查询和修改设备配置、操作数据和统计信息，以及订阅设备通知。设备通知本身使用NETCONF消息从被管理设备主动发送到管理服务器。使用关闭会话。
image.png
Figure 5.22 ♦ NETCONF session between managing server/controller and managed device
图5.22♦管理服务器/控制器和被管理设备之间的NETCONF会话
表5.3显示了管理服务器可以在受控设备上执行的许多重要NETCONF操作。与SNMP的情况一样，我们可以看到用于检索操作状态数据()和事件通知的操作。然而，、、和操作展示了NETCONF对设备配置的特别重视。使用表5.3中所示的基本操作，还可以创建一组更复杂的网络管理事务，这些事务要么自动完成(即，作为一个组)并在一组设备上成功完成，要么完全反转并使设备处于事务前状态。这种多设备处理—“使运营商能够专注于整个网络的配置，而不是单个设备”是[RFC 3535]中提出的一个重要的运营商要求。

NETCONF 操作 描述
检索全部或部分给定配置。一台设备可以有多种配置。始终存在描述设备当前(运行)配置的running/配置。
检索全部或部分配置状态和操作状态数据。
更改受管设备上的全部或部分指定配置。如果指定了running/配置，则将更改设备的当前(运行)配置。如果被管理设备能够满足请求，则发送包含元素的；否则返回响应。出错时，设备的配置状态可以回滚到其以前的状态。
, ()操作允许管理服务器锁定(解锁)受控设备的整个配置数据存储系统。锁定是短暂的，允许客户端进行更改，而不必担心与来自其他来源的其他NETCONF、SNMP或CLIS命令交互。
, 该操作启动事件通知订阅，该事件通知订阅将针对指定的感兴趣的事件从被管理设备发送到管理服务器，直到订阅终止。

Table 5.3 ♦ Selected NETCONF operations
表5.3♦NetCONF精选操作
NETCONF的完整描述超出了我们的范围；[RFC 6241，RFC 5277，Claise 2019；Schonwalder 2010]提供了更深入的介绍。
但是，由于这是我们第一次看到协议消息格式化为XML文档(而不是带有报头字段和消息体的传统消息，例如，如图5.21所示的SNMP PDU)，让我们用两个示例来结束我们对NETCONF的简要学习。
在第一个示例中，从管理服务器发送到受控设备的XML文档是请求所有设备配置和操作数据的NETCONF命令。使用此命令，服务器可以了解设备的配置。

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <rpc message-id="101" 
  3.      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  4.     <get/>
  5. </rpc>
  1. 虽然很少有人能直接完全解析XML，但我们看到NETCONF命令相对容易读懂，而且比我们在图5.21中看到的SNMP PDU格式的协议消息格式更容易让人联想到HTTP和HTML。RPC消息本身跨越02-05行(出于教学目的，我们在这里添加了行号)。RPC的消息ID值为101，在第02行声明，并包含单个NETCONF<get>命令。来自设备的回复包含一个匹配的ID号(101)，以及所有设备的配置数据(当然是XML格式)，从第04行开始，最后以</rpc-reply>结尾。
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <rpc-reply message-id="101" 
  3.      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  4.     <!-- . . . all configuration data returned... -->
  5.   . . . 
  6. </rpc-reply>
  1. 在下面改编自[RFC 6241]的第二个示例中，从管理服务器发送到受控设备的XML文档将名为“Ethernet0/0”的接口的最大传输单位(MTU)设置为1500字节：
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <rpc message-id="101" 
  3.     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  4.   <edit-config>
  5.         <target>
  6.             <running/>
  7.         </target>
  8.         <config>
  9.             <top xmlns="http://example.com/schema/ 
  10.             1.2/config">
  11.                 <interface>
  12.                     <name>Ethernet0/0</name>
  13.                     <mtu>1500</mtu>
  14.                 </interface>
  15.             </top>
  16.         </config>
  17.     </edit-config>
  18. </rpc>
  1. RPC消息本身跨越第02-17行，消息ID值为101，并且包含跨越第04-15行的单个NETCONF<edit-config>命令。第06行表示将更改被管理设备的运行设备配置。第11行和第12行指定要设置的Ethernet0/0接口的MTU大小。<br />一旦受控设备在配置中更改了接口的MTU大小，它就会再次以XML文档形式向管理服务器返回OK回复(下面的第04行)：
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <rpc-reply message-id="101" 
  3.     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  4.         <ok/>
  5. </rpc-reply>

YANG

YANG是一种数据建模语言，用于精确指定NETCONF使用的网络管理数据的结构、语法和语义，其方式与在SNMP中使用SMI指定MIB的方式非常相似。所有YANG定义都包含在模块中，并且可以从YANG模块生成描述设备及其功能的XML文档。
YANG具有一小部分内置数据类型(如SMI)，还允许数据建模师表达有效的NETCONF配置必须满足的约束-这是帮助确保NETCONF配置满足指定的正确性和一致性约束的有力帮助。YANG还用于指定NETCONF通知。
关于YANG的更全面的讨论超出了我们的范围。欲了解更多信息，我们向感兴趣的读者推荐优秀的图书[Claise 2019]。