网络可编程性和自动化之二：网络自动化

lewis 1年前 (2024-03-30) 阅读数 7 #技术

在本章中，我们着重于提供高级网络自动化概念的基线，以便您能够更好地从每一章中获得最大的收益。

为此，本章包括以下各节:

为什么网络自动化?

研究了采用自动化和提高网络操作效率的各种原因，同时证明了自动化远比更快地向网络设备交付配置有更多的意义。

网络自动化的类型

探索了各种类型的自动化，从传统的配置管理到自动化网络诊断和故障排除，再次证明了自动化不仅仅是减少进行更改所需的时间。

管理平面由SNMP向设备应用程序接口演进

简要介绍过去和现在的网络设备上的几种不同API类型。

开放网络的影响SDN时代的网络自动化

提供了一个简短的概要，说明为什么在部署SDN(特别是基于控制器的架构)解决方案时，网络自动化工具仍然有价值。

Note

本章节不打算是一个深入的技术章节，而是对网络自动化的思想和概念的介绍。它只是为后面的章节奠定基础和提供背景。

为什么网络自动化?

像大多数类型的自动化一样，网络自动化被认为是一种更快地完成事情的方法。对于许多IT组织来说，虽然工作得更快是件好事，但是减少部署和配置更改的时间并不总是一个需要解决的问题。

包括速度，我们将看看各种形式和规模的IT组织应该逐渐采用网络自动化的几个原因。您应该注意到，同样的原则也适用于其他类型的自动化(应用程序、系统、存储、电话等)。

1.1 简化架构

今天，大多数网络设备被配置成独特的碎片(有许多一次性的非标准配置)，网络工程师以解决传输和应用问题为傲，这些一次性的网络变化最终不仅使网络更难维护和管理，而且也更难自动化。

与其将网络自动化和管理视为次要项目或“附加项目”，不如在创建新架构时从一开始就将其包括在内。这包括确保对人员和/或工具有适当的预算。不幸的是，当预算短缺时，工具往往是第一个被削减的项目。

端到端架构和相关操作必须是相同的。在创建架构时，您需要考虑以下问题:

哪些特性可以跨供应商工作?哪些扩展可以跨平台工作?哪种类型的API或自动化工具适用于特定的网络设备平台?是否有可靠的API文档?对于给定的产品存在哪些库?

当这些问题在设计过程的早期得到解答时，得到的体系结构将变得更简单、可重复、更容易维护和自动化，而在整个网络中启用的供应商专有扩展则更少。

即使在使用正确的管理和自动化工具部署了简化的体系结构之后，记住仍然有必要最小化一次性更改，以确保网络配置不会再次变成雪花。

1.2 确定的结果

在企业组织中，召开变更审查会议，以审查网络上即将发生的变更、它们对外部系统的影响以及回滚计划。在需要通过触摸CLI来进行更改的环境中，键入错误命令的影响是灾难性的。想象一个拥有3个、4个、5个或50个工程师的团队。每个工程师都可能有他或她自己的方式来做出特定的即将到来的改变。此外，使用CLI甚至GUI的能力并不能消除或减少在更改的控制窗口期间发生错误的机会。

使用经过验证和测试的网络自动化来进行更改，与手动更改相比，有助于实现更可预测的行为，并为执行团队提供了更好的机会来实现确定的结果，从而进一步确保手头的任务将在没有人为错误的情况下第一次正确地完成。这可以是任何任务，从虚拟局域网(VLAN)更改到需要在整个网络中进行多次更改。

1.3 业务敏捷

自从服务器虚拟化出现以来，服务器和虚拟化管理员几乎可以在瞬间部署新的应用程序。部署应用程序的速度越快，提出的问题就越多:如果部署一个新的三层应用程序，为什么要花这么长时间配置网络资源，如vlan、路由、防火墙(FW)策略、负载平衡策略或上述所有的配置。

很明显，通过采用网络自动化，网络工程和运营团队可以在部署应用程序时更快地对IT接口人做出反应，但更重要的是，它有助于业务更加敏捷。从采用的角度来看，在尝试采用任何类型的自动化之前，理解现有的(通常是手动的)工作流是至关重要的，无论您的意图是如何使业务更加敏捷。

如果您不知道您想要自动化的是什么，这将使过程复杂化并延长。在您开始网络自动化之旅时，我们的首要建议是始终了解现有的手工工作流，记录它们，并了解它们对业务的影响。然后，部署自动化技术和工具的过程变得更加简单。

1.4 持续改良

在代码中描述与网络相关的工作流程会带来自动化的潜在好处。它捕获并记录了逐步的流程定义和分析，使每个人在任何时候都可以使用它。此外，随着您不断地使用和试验它，流程会在每次迭代中提供更好的结果，从而不断地改进。

在传统的网络操作中，任务的结果很大程度上取决于网络工程师执行任务的经验和可用的文档，而这些文档总是很难保持更新。然而，当相同的任务被自动化时，每次执行工作流时，它将应用所有参与其中的工程师的所有知识和最新版本。自动化可以在整个团队中分担责任，并使过程更有效。

然而，网络自动化不是一蹴而就的。很可能，意想不到的问题或遗漏点将被检测到，每次发生这种情况时，工作流代码将需要进行调整，变得比以前更好。随着时间的推移，这种持续改进的方法将在一个增量改进过程中合并来自之前和当前团队成员的所有贡献。

从简化的体系结构到持续改进，本节介绍了关于为什么应该考虑网络自动化的一些高级要点。在下一节中，我们将了解不同类型的网络自动化。

网络自动化的类型

自动化通常等同于速度，考虑到一些网络任务不需要速度，很容易理解为什么一些it团队看不到自动化的价值。VLAN配置是一个很好的例子，因为您可能会想，“创建VLAN到底需要多快?”每天增加多少个vlan ?我真的需要自动化吗?”这些都是有效的问题。

在本节中，我们将集中在自动化有意义的其他几个任务，如设备配置、数据收集和改进、故障排除、报告、配置遵从性和状态验证。但是请记住，正如我们前面所说的，自动化远不止是速度和敏捷;它还为个人、团队和业务提供了更可预测和更确定的结果。

2.1 设备服务开通

开始网络自动化的最简单和最快的方法之一是自动创建用于初始设备的配置文件，并将它们推送到网络设备。

如果我们把这个过程分成两个步骤，第一步是创建配置文件，第二步是将配置推到设备上。

为了使配置文件(或一般的配置数据)的创建自动化，我们首先需要将输入(配置参数)与配置的底层供应商专有语法(CLI)解耦。这意味着我们最终将得到一个单独的文件，其中包含配置参数的值，例如vlan、domain信息、接口、路由和正在配置的其他所有东西，当然，还有一个配置模板。这是我们在[即将到来的链接]中详细介绍的东西。

现在，可以把配置模板看作是一个标准的黄金模板，用于所有设备的部署。通过利用一种称为网络配置模板的技术，您能够快速地为您的网络生成一致的网络配置文件。这也意味着你再也不用使用记事本，从一个文件复制粘贴配置到另一个文件——这不是时候这样做了吗?

Ansible和Salt是两种可以简化配置模板和变量(数据输入)的工具。在不到几秒钟的时间内，这些工具可以生成数百个可预测且可靠的配置文件。

Note

从模板中构建和生成配置文件在[Link to Come]中有更详细的介绍，而使用Ansible和Salt执行模板过程在[Link to Come]中有介绍。本节仅展示一个高级的基本示例。

让我们来看一个示例，将当前配置分解为模板和单独的变量(输入)文件，以阐明我们的观点。

在例2-1中，我们观察到预期的CLI配置：

例2 - 1配置文件片段
！
hostname leaf1
ip domain-name ntc.com
!
vlan 10
   name web
!
vlan 20
   name app
!
vlan 30
   name db
!
If w

如果我们将数据从CLI命令中解耦，这个文件将被转换成两个文件:一个模板和一个数据(变量)文件。

首先让我们看看例子2-2中的YAML定义(我们在后面章节中深入介绍了YAML)变量文件:

Example 2-2. YAML Data

---
hostname: leaf1
domain_name: ntc.com
vlans:
  - id: 10
    name: web
  - id: 20
    name: app
  - id: 30
    name: db
Note the YAML file is only our data.

注意，YAML文件只是我们的数据。

Note

在这个例子中，我们使用的是基于python的Jinja模板语言。Jinja会在后面详细介绍。

Example 2-3. Jinja Template

Example 2-3. Jinja Template
!
hostname {{ inventory_hostname }}
ip domain-name {{ domain_name }}
!
{% for vlan in vlans %}
vlan {{ vlan.id }}
  name {{ vlan.name }}
{% endfor %}
!

本例中，双花括号表示一个Jinja变量。由于双花括号表示变量，我们看到这些值不在模板中，因此需要将它们存储在某个地方。同样，我们将它们存储在YAML文件中。除了使用YAML文件，还可以使用脚本从外部系统(如网络管理系统(NMS)或IP地址管理(IPAM)系统)获取这类信息。

在本例中，如果控制VLAN的团队希望将一个VLAN添加到网络设备，则没有问题。他们只需要在变量文件中更改它，并使用Ansible或其他转译引擎(Salt、纯Python等)重新生成一个新的配置文件。

Note

在后面章节中，我们还介绍了如何在Jinja模板中使用原生Python，展示了如何创建一个可以用作基本转译引擎的Python脚本。

在我们的示例中，一旦生成了配置，就需要将其推送到网络设备。这里不讨论推送和执行过程，因为有很多方法可以做到这一点，包括供应商专有的供应解决方案，以及我们后面章节中看到的其他一些方法。

此外，这只是对模板的一个高级介绍;如果不是100%清楚，也不用担心。正如我们所说的，使用模板在后面章节中有更详细的介绍。

除了构建配置并将其推向设备之外，可以说更重要的是数据收集，这恰好是我们的下一个主题。

2.2 数据收集和富集

监视工具通常使用简单网络管理协议(SNMP)—这些工具轮询某些管理信息库(mib)并将数据返回给监视工具。根据返回的数据，它可能比实际需要的多或少。如果正在轮询接口统计信息呢?你可能会得到show interface命令中显示的每个计数器，但如果你只需要接口重置而不需要CRC错误、超大帧、输出错误等，那该怎么办呢?此外，如果您希望看到与具有CDP/LLDP邻居的接口相关的接口重置，并且您希望现在就看到它们，而不是在下一个轮询周期中看到它们，该怎么办?网络自动化如何帮助实现这一点?

考虑到我们的重点是为您提供更多的权力和控制，您可以利用开源工具和技术来定制您所获得的内容、获取时间、如何格式化以及收集数据后如何使用数据，确保您从数据中获得最大的价值。

在例2-4中，有一个使用Python库netmiko从IOS设备收集数据的非常基本的例子。

例2-4，Netmiko脚本

from netmiko import ConnectHandler

device = ConnectHandler(
  device_type='cisco_ios',
  host='csr1',
  username='ntc',
  password='ntc123'
)

output = device.send_command('show version')
print(output)

最重要的是输出包含show version响应，您可以根据自己的需求对其进行解析。但是有一个不太好的部分，这个CLI命令的输出是非结构化数据，因此您最终将实现一些定制的屏幕抓取逻辑，这很难维护。小小的输出更改可能会破坏整个解析过程。现在大多数平台都提供结构化的数据格式，支持更健壮的自动化，而屏幕抓取的使用只是用作最后的手段。

Note

在给出的示例中，我们描述从设备上提取数据，这可能不是所有环境都理想的，但仍然适合许多环境。注意，较新的设备开始支持推（push）模型，通常称为流遥测，在这种模型中，设备本身将实时数据(如接口统计数据)流到您选择的应用服务器。我们将在后面章节中看到更多关于它的内容。

当然，任何这一切都可能需要一些预先的定制工作，但最终都是完全值得的，因为所收集的数据是您所需要的，而不是某个给定的工具或供应商所提供的。

网络设备内部有大量静态和短暂的数据，使用开源工具或构建自己的工具可以访问这些数据。这类数据的例子包括BGP表中的活动项、OSPF邻接、活动邻居、接口统计、特定的计数器和重置，甚至是来自平台上特定应用集成电路(asic)本身的计数器。此外，还可以收集设备的更多一般情况和特征，例如序列号、主机名、正常运行时间、操作系统版本和硬件平台等。这样的例子不胜枚举。

TIP

当您开始一个自动化项目时，请始终考虑这些问题:“构建、购买或定制是否有意义?以及“消费或运营有意义吗?”

但在数据收集中，最重要的是我们如何得到最好的数据。在我们收集了网络状态(指标、日志或流)之后，我们可以用元数据来丰富它们——比如为某个接口计数器来自的站点添加一个标签——因此，在分析或可视化工具中，我们可以将所有这些数据关联起来，以获得更多有意义的结果。显然，为了实现这一点，我们需要从一些地方获得这一信息，那里有一个设备(接口的所有者)和它被安装的站点之间的关系。这就是真理之源的作用，在这一章中有涉及。

2.3 迁移

从一个平台迁移到下一个平台从来不是一件容易的事情。这可能涉及来自同一供应商或不同供应商的平台。供应商可以提供脚本或工具来帮助迁移到他们的平台，但是可以使用各种形式的自动化来构建配置模板，就像我们前面的例子一样，针对所有类型的网络设备和操作系统，通过这样的方式，您可以为所有供应商生成配置文件，给定一组已定义的通用输入(通用数据模型)。

当然，如果有供应商专有的扩展，也需要考虑。很棒的是，这样的迁移工具自己构建要比让供应商来做要简单得多，因为供应商需要考虑设备支持的所有特性，而单个组织只需要有限数量的特性。在现实中，这是供应商不太关心的事情;他们关心的是他们的设备，而不是让您(网络运营商)更容易地管理多供应商的环境。

拥有这种类型的灵活性不仅有助于迁移，还有助于灾难恢复(DR)，因为在生产和灾备数据中心，甚至是不同的供应商中，使用不同的交换机模型是非常常见的。如果一个设备因为任何原因出现故障，而它的替代品必须是一个不同的平台，那么您将能够快速地利用您的公共数据模型(考虑参数输入)并立即生成一个新的配置。我们开始不严格地使用数据模型这个术语，但是请放心，我们会花更多的时间来描述和强调什么是数据模型。

因此，如果您正在执行迁移，请在更抽象的级别上考虑它，并考虑从一个平台迁移到下一个平台所需的任务。然后，看看可以做些什么来自动化这些任务，因为只有您，而不是大型网络供应商，有动力使多供应商自动化成为现实。例如，考虑将VLAN添加为抽象步骤—然后可以考虑每个平台的较低级别的命令。关键是，当您开始采用自动化时，在使用键盘输入CLI命令或编写代码(针对每个平台)之前，考虑任务并以与供应商无关的人类可读的格式记录它们是极其重要的。

2.4 配置管理

如前所述，配置管理是最常见的自动化类型，因此我们不打算在此花费太多时间。您应该知道，当我们提到配置管理时，我们指的是部署、推送和管理设备的配置状态。这包括对配置TOR交换机、防火墙、负载平衡器和高级安全基础设施的更复杂工作流的基本描述，以部署三层应用程序。

事实上，有很多方法可以开始网络自动化之旅，但是当您开始自动化配置管理时，请记住，能力越大，责任越大。更重要的是，在将新的自动化工具推出到生产环境之前，不要忘记对它们进行测试。您有几个选项可以通过仿真网络平台来测试您的自动化逻辑。

从网络自动化中断中得到的教训

2021年10月，由于网络自动化问题，世界上最大、自动化程度更高的网络之一瘫痪了。Facebook(现在是Meta)提供了一份宕机报告，解释说尽管他们的配置管理系统有一个审计控制，以防止推送有害的配置，但BGP配置更改导致了全球宕机。

我们不应该忘记，自动化会放大一切，无论是好的还是坏的。因此，在部署到生产之前，理解使用持续集成流程测试网络自动化系统的重要性是至关重要的。

现在，有一些选项可以进行分析网络验证，比如Batfish，它可以根据给定的配置创建一个网络模型来模拟网络的状态，但这只是一个近似。网络仿真工具可以帮助我们在按需环境中运行网络设备。所有这些工具都可以在CI管道中使用，在投入生产之前验证网络自动化工具如何与网络设备交互，预测潜在的问题和意想不到的附带影响。

正如预期的那样，Facebook有自己的审计控制工具，通过持续集成来验证更改，但总是有机会遇到意想不到的错误。为了减轻这一问题，我们建议您接受不确定性，并采用软件开发方法，例如Canary部署，在Canary部署中，更改将逐步扩展到机队中。这使我们有机会验证一小部分设备的结果，然后，逐渐地，继续向网络的其余部分发布。

下面我们介绍的几类网络自动化都来自于数据收集过程的自动化。为了提供更多的上下文，我们将其中的一些分解出来，首先是自动化遵从性检查。

2.4 配置遵从性检查

与许多形式的自动化一样，使用任何类型的自动化工具进行配置更改都被视为一种风险。虽然手动更改的风险可能更大，但正如您所阅读和亲身经历的那样，您可以选择从数据收集、监视和配置构建开始，这些都是只读和低风险的操作。使用正在收集的数据的一个低风险用例是配置遵从性检查和配置验证。部署的配置是否满足安全要求?是否配置了所需的网络?XYZ协议被禁用了吗?当您能够控制正在部署的工具时，就更有可能验证某些事情是真的还是假的。从一个遵从性检查开始，然后根据需要逐渐添加更多，这很容易。

根据所检查内容的遵从性，下一步将由您决定发生什么—可能只是被记录下来，也可能执行了一个复杂的操作，使您的应用程序能够自动修复。这些都是事件驱动自动化的形式，我们在讨论StackStorm和Salt时也会提到。我们的建议是，最好从简单的网络自动化开始，但也要意识到可能增加的价值。例如，如果您只是记录或打印消息来查看接口最大传输单元(MTU)是多少，那么如果它不是所需的MTU，您就已经准备好自动将其重新配置为正确的值。您只需要在现有的日志/打印消息下面多写几行即可。同样，重点是要从小处开始，但要想清楚未来还需要什么。

2.5 状态验证

比配置遵从性检查更进一步的一步(仍然是只读的，低风险的)是验证配置的结果，即网络的实际操作状态。显然，除了配置状态之外，还需要定义预期的操作状态。例如，对于BGP邻居的配置，配置遵从性验证配置状态、语法和数据:邻居IP地址、ASN和MD5验证密钥。另外，状态验证检查这些会话的状态，并期待一个Established状态。配置可能是正确的，但另一端的网络中断或错误配置可能会引发验证问题。

状态验证在自动化过程之上增加了一个额外的控制层。它可以用于验证所需配置更改的推出没有破坏所需的操作状态，或者不断验证网络状态。例如，结果可能是:使用相关状态数据发出通知警告，或触发缓解进程。按照BGP的例子，当检测到意外的BGP会话状态时，自动化将检索相关的BGP日志和统计信息，并将其附加到通知网络团队的通知中。

Note

一种常见的状态验证类型是变更前/变更后验证。在这种情况下，没有预定义的预期操作状态。预期状态只是从执行未来操作之前收集的快照中获取。例如，在操作系统升级工作流中，在升级之前收集操作状态，并定义所需状态。升级后，将根据实际状态验证此状态。如果最终状态不成功，则可能触发回滚过程，以使用以前的操作系统版本。

2.6 报告

一旦你开始自动收集数据，你可能还想开始构建自定义和动态报告。可能返回的数据成为其他配置管理任务的输入(再次事件驱动或更基本的条件配置)，或者可能您只是想创建报告。

由于可以很容易地从模板中结合设备上实际的临时数据生成报告，因此创建和使用报告模板的过程与创建本章前面提到的配置模板的过程是一样的。

由于使用基于文本的模板的简单性质，可以以任何您希望的格式生成报告，包括但不限于:

简单的文本文件可以在GitHub或其他Markdown查看器上轻松查看Markdown文件部署到web服务器以方便查看的HTML报表

这完全取决于你的要求。很棒的是，网络自动器有能力创建他们需要的确切类型的报告。实际上，您可以使用一组数据来生成不同类型的报告，可能是一些技术性的报告，也可能是用于管理的高级报告，然后选择最佳的用户界面来发送它们，可以通过电子邮件或即时消息传递。

接下来，我们来看看自动故障排除的价值。

2.7 故障排查

谁会喜欢总是被拉进中断/修复问题中，尤其是当你应该睡觉或专注于其他事情的时候?

一旦您能够访问实时数据，并且不需要对数据进行任何手动解析，自动故障排除就成为现实。

想想你是如何排除故障的。你有自己的方法论吗?这种方法在团队中的所有成员中都是一致的吗?在对第3层进行故障排除之前，每个人都检查第2层吗?您采取什么步骤来排除给定的问题?

下面以OSPF故障排除为例:

你知道在两台设备之间形成OSPF邻接需要什么吗?你能在凌晨2点或在海滩度假时快速地说出同样的答案吗?也许你记得一些设备需要在同一个子网中，有相同的MTU，有一致的定时器，但忘记了它们需要相同的OSPF网络类型。我们真的需要记住所有这些以及在CLI中运行的相关命令来获取每个数据吗?

这些问题只是需要匹配OSPF的一些事情。

在任何给定的环境中，都需要执行这些类型的兼容性检查。你能理解运行一个脚本或使用一个工具进行OSPF邻居验证与手动执行该过程的区别吗?你喜欢哪一种?

再说一次，OSPF只是冰山一角。想想其他的问题，仍然只是建议:

您可以将特定的日志消息与已知的网络条件相关联吗?BGP邻居邻接呢?邻居是如何形成的?你是否看到了路由表中所有你认为应该出现的路由?port-channels呢?有什么不一致的地方吗?邻居是否匹配端口通道配置(下行到vSwitch)?电缆呢?所有的电缆都插好了吗?

即使有了这些问题，当涉及到自动诊断和故障排除时，我们也只是触及了表面。

Note

当你开始考虑所有可能的自动化类型时，开始想象一个闭环系统，数据以自动化方式收集，然后以自动化方式处理和分析数据，然后使用高级分析工具以自动化方式进行故障排除。当这些工作以一种统一的方式一起发生时，这就变成了一个闭环，完全改变了组织内部管理运维的方式。

如果您是团队中的明星网络工程师，您可能需要考虑与开发人员合作，或者至少开始记录您的工作流程，这样可以更容易地分享您拥有的知识，也更容易编写代码。更好的是，开始你自己的自动化之旅，这样你就可以经常睡个懒觉，并授权其他人使用你的一些自动化诊断工作流程来排除故障。

如您所见，网络自动化的意义远不止更快地部署配置。在介绍了几种不同类型的自动化之后，我们将转移话题，看看自动化工具和应用程序与网络设备通信的几种不同方式，从SSH开始，到NETCONF、gNMI和基于http的RESTful API结束。

管理平面由SNMP向设备接口演进

如果你想改进网络日常管理和运行的方式，改进必须从如何与被管理的底层设备交互开始。这个接口是您和自动化工具(更重要的是)与设备通信的方式，以执行各种类型的网络自动化，如数据收集和配置管理。

在本节中，我们将概述连接到网络设备的管理平面的不同方法，首先是SNMP，然后是更现代的方法，如NETCONF、gNMI和RESTful API。然后我们看看开放网络运动对网络运营和自动化的影响。

3.1 应用程序编程接口(api)

作为一名网络工程师，你需要拥抱api，而不是害怕它们。请记住，API只是一种机制，用于让一个设备上的计算机软件与另一个设备上的计算机软件通信。如今，API在互联网上几乎无处不在，只是碰巧得到了网络供应商应有的关注。今天，我们看到API正在成为管理新网络设备的主要手段。

本节将简要概述目前在网络设备上可以找到的几种不同类型的API。

3.1.1 SNMP

SNMP已经在网络设备上广泛部署超过25年。对于阅读本书的任何人来说，这应该不是什么新鲜事，但SNMP是一种非常常用的协议，用于轮询网络设备的信息，如up/down状态、CPU、内存和接口利用率。

为了使用SNMP，必须在被管理设备上有一个SNMP代理和一个网络管理站(NMS)， NMS是作为监视和/或控制被管理设备的服务器设备。

被管理的每个网络设备都公开一组数据，可以通过SNMP代理收集和配置这些数据。通过SNMP管理的这组数据是通过管理信息库(mib)描述和建模的。只有存在暴露某个特性的MIB，才能对其进行监控或管理。这包括通过SNMP进行配置更改。经常被忽视的是，SNMP不仅支持用于监控的getrequest，还支持用于操作通过mib暴露的对象和变量的setrequest。问题是没有多少供应商通过SNMP提供对配置管理的全面支持;当他们这样做时，他们通常使用自定义mib，减慢了与网络管理平台的集成过程。

如前所述，SNMP已经存在了几十年，但它并不是为网络设备构建的实时编程接口。我们已经看到供应商声称SNMP逐渐死亡，因为它涉及下一代管理和自动化工具。也就是说，SNMP确实存在于几乎每个网络设备上，用于SNMP的Python库也存在——因此，如果您需要从大量设备类型中收集基本信息，使用SNMP仍然是有意义的。

就像SNMP多年来一直用于执行网络监控一样，SSH/Telnet和CLI也被用于配置管理(和获取状态)。现在我们来看看SSH/Telnet和CLI。

3.1.2 SSH/Telnet和命令行

如果你曾经管理过网络设备，那么你肯定使用过CLI来发出命令，在设备上执行某些操作。您可能通过控制台、Telnet和SSH会话输入命令。如第1章所述，从Telnet到SSH的迁移可以说是过去10年网络运营领域发生的最大转变，而这种转变与运营无关;它是关于安全的，确保与网络设备的通信是加密的。

在通过CLI管理设备时，最重要的是要意识到CLI是为人类构建的。它被放在设备上，以提高人类操作人员的可用性。CLI并不用于机器对机器通信(即网络脚本和自动化)。

如果你在设备的CLI上执行show命令，你会得到原始文本。它没有结构。解析响应的最佳选项是使用管道(|)和关键字(如grep、include)，并开始查找特定的配置行。例如，使用命令show interface Eth1 | include description检查接口的描述。这意味着，如果您需要知道在脚本中发出show interface后接口上有多少CRC错误，您将被迫使用某种类型的正则表达式或手动解析来弄清楚它。这是不可接受的。

然而，当我们只有CLI时，CLI就是我们要使用的。这就是为什么在过去20年里构建了大量网络管理平台和自定义脚本，它们使用CLI通过SSH处理expect脚本和手动解析来执行管理和自动化操作。并不是SSH/CLI让它无法自动化;相反，它使自动化极其容易出错和繁琐。

网络供应商开始意识到这一点，现在大多数较新的设备平台都有某种类型的API，可以简化机器对机器通信(许多API还不完整，所以请确保测试您喜欢的设备的API)，从而产生一种更简单的自动化方法，也更符合一般的软件开发原则。

在简要介绍了SSH和SNMP等常见协议之后，我们将介绍NETCONF，这是一种在网络自动化方面非常流行的API。

3.1.3 NETCONF

NETCONF是IETF (Internet Engineering Task Force)定义的网络管理层协议，与SNMP类似。在最高级别上，它可以与SNMP进行比较，因为它们都是用于进行配置更改和从网络设备检索数据的协议。

当然，区别在于细节。我们在这里只介绍了一些高层次的观点，但会在后面章节中花更多的时间介绍NETCONF。

NETCONF是一种面向连接的协议，通常利用SSH作为传输工具。NETCONF客户端(自动化工具/脚本)和NETCONF服务器(网络设备)之间发送的数据是用XML编码的。如果您不熟悉XML，也不用担心;我们会在后面章节中介绍它。远程过程调用(rpc)编码在发送给设备的XML文档中，设备处理这些rpc。 <rpc>元素用于封装从客户端发送到服务器的NETCONF请求。在这种情况下，可以认为这些远程过程调用是在设备上执行一个预先安排好的操作。rpc是一种客户端与服务器通信的方式，可以让服务器知道客户端请求的结构和类型。支持的rpc直接映射到支持的NETCONF操作和特定设备的功能。例如，如果你在设备上进行更改，你可以使用edit-config操作。如果要获取配置数据，可以使用get或get-config操作。这些操作被包装在XML文档的 <rpc>元素发送到设备。

此外，NETCONF还支持基于事务的更改，这一点很有价值。这意味着，如果在给定的NETCONF会话或单个XML文档中进行多个更改，并且其中一个更改失败，则不会将整个更改应用于设备(当然，这些类型的设置通常也可以覆盖)。这与顺序发送CLI命令，然后由于输入错误或命令无效而导致部分配置不同。

这是对NETCONF的简要介绍，如前所述，我们将在后面的章节中更详细地介绍NETCONF。

Note

值得指出的是，仅仅因为两个不同的设备平台支持NETCONF(或任何常见的传输方法)，并不意味着从工具和开发人员的角度来看它们是兼容的。即使假设两个设备支持相同的NETCONF特性和功能，数据的建模方式通常也取决于厂商。数据建模是指设备如何表示状态和配置数据。我们将在后面章节中了解更多关于JSON、XML和YANG(一种常用的数据建模语言)的数据表示。

3.1.4 gNMI

传统上，网络接口和协议是由标准化实体(如IETF)驱动的。然而，在2018年初，谷歌发布了“gNMI(gRPC Network Management Interface)”，这是一个基于gRPC的协议，用于通过遥测流处理配置管理和状态数据收集。

在谷歌的推动下，我们仍然必须在“OpenConfig联盟”的保护伞下理解它。OpenConfig联盟是一个网络运营商工作组，于2016年创建，以动态的、供应商中立的方式开发用于管理网络的编程接口和工具。Facebook、微软、Cloudflare、Netflix和AT&T等一些最大的网络以及谷歌都是它的一部分。他们最初的重点是根据用例和成员的实际操作需求编译一组供应商中立的数据模型(用YANG语言编写)。这项工作与其他标准化组织(如IETF)定义YANG数据模型同时开始，但由于其共识过程更简单，开发速度更快。

你可能想知道gNMI和NETCONF之间的区别。这两个协议都使用RPC方法和YANG数据模型，但在实际的数据模型定义、网络传输和其他一些关键特性上有所不同(例如，当NETCONF不支持流数据遥测时，gNMI很早就将重点放在实现流数据遥测上)。

3.1.5 RESTful APIs

REST代表表述性状态转移(REpresentational State Transfer)，是一种用于设计和开发网络应用程序的风格。因此，实现并遵循基于rest架构的系统称为RESTful。

从网络的角度来看，公开API并遵循REST架构风格的最常见设备是网络控制器。也就是说，也有网络设备公开RESTful和通用的基于http的API。

虽然从网络的角度来看，REST和RESTful API这两个术语是新的，但当你使用web浏览器浏览互联网时，你已经每天都在与许多RESTful系统交互。我们说过REST是一种用于开发网络应用程序的风格。这种风格依赖于无状态的客户端-服务器模型，在这种模型中，客户端跟踪会话，服务器上不保存任何客户端状态或上下文。最好的是，底层传输协议是最常用的HTTP。这听起来不像互联网上的大多数系统吗?

这意味着RESTful API的操作就像基于http的系统一样。首先，你需要一个可以通过URL访问的web服务器(即，用于通信的SDN控制器或网络设备)，其次，你需要向该URL发送相关的HTTP请求。

例如，如果您需要从SDN控制器检索设备列表，您只需要向设备的给定URL发送一个HTTP GET，该URL可能类似于:/news/upload/ueditor/image/202209/rcr33vnn5wa PUT/POST/PATCH)。由于本节只是对REST和RESTful API的简单介绍，我们会在后面章节中介绍更多细节，以及新的API类型，如GraphQL。

接下来是对开放网络对网络设备整体管理的影响的简要介绍。

开放网络的影响

开源、开放网络、开放API、OpenFlow、开放计算、开放vSwitch、OpenDaylight、OpenConfig都是一个不断增长的趋势，列表还在继续。虽然开放的定义还存在争议，但有一件事是肯定的:开放网络运动正在改善网络运营和自动化。

随着这场运动，我们看到了网络设备的巨大变化。

首先，许多设备现在支持安装Python。这意味着您能够进入Python动态解释器并在每个网络设备上本地执行Python脚本。我们会在第3章更详细地介绍Python，你会明白我们说的第一手资料是什么意思。

其次，许多设备现在支持比SNMP和SSH更强大的API。例如，我们刚刚介绍了NETCONF、gNMI和基于http的RESTful api。过去几年出现的许多较新的设备操作系统都支持其中一个或两个api。请记住，我们会在[链接]中更详细地介绍设备API。

最后，网络设备正在暴露更多过去对网络运营商隐藏的Linux内部机制。现在，大家可以在网络设备上使用bash shell，发出ifconfig等命令，编写bash脚本，并通过apt和yum等包管理器安装监控和配置管理工具。使用Linux，您还可以运行打包为容器的应用程序，改变我们对网络设备上可以实现的内容的理解。

虽然开放网络并不总是意味着互操作性，但很明显，网络设备和控制器正在开放自己，以一种更适合增强网络自动化的程序化方式操作。网络设备上有许多API几年前还不存在，从思科的NX-API、Arista的eAPI、思科的IOS-XE RESTCONF/NETCONF到任何具有api的新SDN控制器。对于运营商来说，最终的结果是，当您开始使用这些API时，您可以控制您的网络，并减少目前存在的操作效率低下的数量。

SDN时代的网络自动化

现在，我们来看看网络自动化的持续重要性，即使部署了控制器解决方案，如OpenDaylight，甚至是商业产品，如Cisco ACI或VMware NSX。控制器在网络中所做的操作，如作为控制平面、管理策略和配置等，在本节中不涉及。

事实上，控制器在下一代架构中变得越来越普遍。思科、Juniper、VMware、Arista Networks、NVIDIA等供应商都为他们的下一代解决方案提供控制器平台，更不用说OpenDaylight和OpenContrail等开源控制器了。

市场上几乎每个控制器都公开了北向的RESTful API，使得控制器非常容易自动化。虽然控制器本身通过单一的窗口简化了管理和可见性，但您仍然可以通过控制器的GUI进行手动和易出错的更改。如果部署了来自相同或不同供应商的多个pods或controller，则手动更改、故障排除和数据收集的问题不会消失。

在结束本章的时候，需要注意的是，即使在SDN架构和基于控制器的网络解决方案的新时代，对自动化、更好的运维和更可预测结果的需求也不会消失。

总结

本章概述了网络自动化的价值和各种类型的网络自动化;介绍常见的设备API，包括SNMP、CLI/SSH，更重要的是NETCONF、gNMI和RESTful;简要提到YANG，一种数据建模语言，我们将在后面章节中详细介绍。

本章最后简要介绍了开放网络运动对网络运维和自动化的影响。最后，我们谈到了即使部署了SDN控制器，网络自动化的价值。