无法启动iis web服务器 指定的网络名格式无效_网络自动化与可编程11

从Python、数据格式到Jinja的配置模板，我们探讨了一些关键的基础技术，这些技术将使您成为一名更好的网络工程师。现在，我们将把这些技术进行实际应用，并开始使用不同类型的网络设备api与之通信。为更好地开始网络自动化，我们分为三个部分：

• 理解网络API，研究各种API的体系结构，包括基于RESTful HTTP的API、非RESTful HTTP的API和NETCONF。

• 探索网络API，介绍用于测试和学习如何使用每种API类型的工具。

• 使用网络API实现自动化，查看一下Python库，这些库允许您开始网络自动化。我们将研究Python请求库，用于使用基于HTTP的api，ncclient用于与NETCONF设备交互，netmiko用于使用SSH自动化设备。

注意：本篇不是关于任何指定API的全面指南。仅提供使用指定API的不同设备商实现的示例，因为在多设备商环境中非常常见。同样重要的是，看到相同API类型的不同实现间的对比。

理解网络API 我们的重点是网络设备上最常见的两种API，基于HTTP和基于NETCONF的API。我们将从每种类型API的基本概念开始，一旦结束这些概念，将通过使用指定设备商的实际示例来探讨这些API的使用情况。 熟悉基于HTTP的API RESful API在网络行业越来越流行，也越来越常用，尽管它们从21世纪初就已经出现。 目前存在于网络基础设施中的大多数API都是基于HTTP的RESTful API。这意味，当您听说网络设备或SDN控制器上的RESTful API时，它是一个在客户端和服务器间通信的API。 客户端是一个应用程序，如Python脚本或Web UI应用程序，服务器将是网络设备或控制器。 因为HTTP被用作传输，所以您将使用url执行一些操作，就像在浏览万维网时所做的那样。 因此，如果您了解当浏览一个网站时，会执行HTTP GET，当填写web表单并单击完成时，将执行HTTP POST，那么您已经了解使用RESTful API的基本知识。

让我们看看从网站检索数据和通过RESTful API从网络设备检索数据的示例。这两种情况，HTTP GET请求都被发送到web服务器。

在上图，主要的区别是发送到web服务器和从web服务器收到的数据。当浏览互联网时，你会收到被浏览器解释的HTML数据，这样就能够正确地显示网站。另一方面，当向公开RESTful API的web服务器发出HTTP GET请求时(它是通过URL公开的)，将接收大部分使用JSON或XML编码的数据。因为接收到的数据是JSON/XML格式的，所以客户端应用程序必须理解如何解释JSON或XML。让我们继续，以便在开始探索RESTful HTTP API的使用之前有一个更完整的画面。

现代基于Web的RESTful API的诞生和结构来自Roy Fielding在2000年的博士学位论文。在这篇题为《体系结构样式和基于网络的软件体系结构设计》的论文中，他定义了在internet上使用REST的体系结构的复杂细节。接口必须遵守体系结构中的6个约束才能被视为RESTful。我们研究其中的三个。

Client-Server：这是在简化服务器需求的同时提高系统可用性的要求。客户端-服务器体系结构允许客户端应用程序的可移植性和可更改性，而无需更改服务器组件。这意味您可以拥有不同的API客户端(webui、CLI)，它们使用相同的服务器资源(后端API)。

Stateless：客户端和服务器间的通信必须是无状态的，使用无状态通信形式的客户端必须在单个请求中发送服务器理解和执行请求操作所需的所有数据。这与SSH等接口不同，后者在和服务器之间存在持久连接。

Uniform interface：API调用的各个资源在HTTP请求消息中标识。例如，在基于HTTP RESTful的系统中，使用URL引用指定的资源。在网络环境中，资源映射到网络设备结构，如主机名、接口、路由协议配置或设备上存在的其它资源。统一接口还声明客户端应该有足够的资源信息来创建、修改或删除资源。

这只是REST架构中六个核心约束中的三个，但是我们已经可以看到RESTful系统之间的相似性，以及我们如何通过每天的web浏览来消费互联网。请记住，HTTP是实现RESTful API的主要方法，尽管理论上传输类型可能是其它。为了真正理解RESTful API，还必须了解HTTP的基础。

理解HTTP请求类型

虽然我们看到的每个RESTful API都基于HTTP，但我们最终将看到基于HTTP的API，这些API不遵循REST原则，因此不是RESTful。然而，无论哪种情况，API都需要了解HTTP。由于这些API使用HTTP进行传输，因此我们将使用已经在互联网上使用的相同HTTP请求类型和响应代码。例如，常见的HTTP请求类型包括GET、POST、PATCH、PUT和DELETE。GET请求用于从服务器请求数据，DELETE请求用于删除服务器上的资源，三个P(POST、PATCH、PUT)用于在服务器上进行更改。在网络，我们可以看成：GET(获取配置或操作数据)，PUT、POST、PATCH(进行配置更改)，DELETE(删除指定配置)。

理解HTTP响应代码

正如在internet上使用web浏览器或使用RESTful API时，请求类型是相同的，响应代码也是如此。当您试图登录一个网站并使用无效的凭证时，有没看到“401 Unauthorized”的消息？如果您试图使用RESTful登录到一个系统，但发送了错误的凭证，那么您将收到相同的响应代码。对于成功的消息或服务器本身有错误，也是如此。

总之，基于HTTP的API响应代码类型与标准HTTP响应代码没有区别。既然已经了解REST和HTTP的原理，那么还需要注意基于HTTP的非RESTFul API。

理解基于HTTP的非RESTful API

虽然RESTFul API是首选，但也可能遇到基于HTTP的非RESTful API。在网络行业，这在位于cli上的API最常见，这意味API调用实际上是向设备发送命令，而不是发送结构化数据。首选的方法是让任何现代网络平台的CLI或WEB UI使用底层API，但对于使用命令构建的“遗留”或预先存在的系统，使用非RESTful API是很常见的，因为这样添加API比重新构建底层系统更容易。

基于RESTful HTTP的API与基于非RESTful HTTP的API有两个主要区别。我们先前介绍了HTTP请求类型，如GET、POST、PATCH、PUT和DELETE。RESTful使用这些动词来指示目标服务器请求的更改类型。例如，在网络环境，如果执行HTTP GET，配置更改永远不会发生，因为您只是在检索数据。但基于HTTP但不遵循RESTful原则的系统可以对每个API调用使用相同的HTTP动词。这意味，如果您正在检索数据或进行配置更改，则所有API调用可能都使用POST请求。

另一个需要注意的共同点是单个API调用中使用的URL。如果您使用的是基于HTTP的API，该API始终使用相同的URL，并且不允许通过URL更改访问指定的资源，则该API是基于HTTP RESTful的API。

在网络基础设施上使用基于HTTP的API是朝着正确方向迈出的一大步，但理想情况下，所有HTTP API都将遵循REST的原则。虽然您确实使用相同的工具来使用RESTful和非RESTful基于HTTP的API，但是必须注意这些网络API的差异，因为基于非RESTful HTTP的API通常不如RESTful的API灵活。

NETCONF

NETCONF是一种网络管理协议，定义在RFC 6241，设计用于配置管理和从网络设备检索配置以及操作状态数据。NETCONF在配置和操作状态之间有明确的划分；API请求用于执行不同的操作，例如检索配置状态、检索操作状态和进行配置更改。

我们已了解，RESTful API并不是一个新技术，它只是网络设备和SDN控制器的新特性。当我们过渡到NETCONF API时，值得注意的是NETCONF也不是什么新鲜事物。NETCONF已经有十多年的历史。事实上，它是一个行业标准协议，它的原始RFC是在2005年编写的。它甚至已经在各种网络设备上使用了很多年，尽管很少被使用。

NETCONF的核心特性之一是能够利用不同的配置数据存储。网络工程师都熟悉运行配置和启动配置。它们被认为是两个配置文件，但它们是NETCONF中的两个配置数据存储。NETCONF实现通常倾向于使用称为候选配置的第三个数据存储。候选配置数据存储包含尚未应用于设备的配置对象(如果使用CLI进行配置，则为CLI命令)。例如，如果在支持候选配置的设备上输入配置，则它们不会立即执行操作。相反，它们保存在候选配置中，仅在执行commit操作时应用于设备。执行commit时，候选配置将写入正在运行的配置。

候选配置数据存储库作为NETCONF RFC的原始定义已经存在很多年。业界所面临的一个问题是，NETCONF的可用实现提供了这种功能。然而，并不是所有的实现都没有被使用，事实上，都是成功的实现。Juniper的Junos多年来一直有一个健壮的NETCONF实现，以及候选配置的能力；最近，Cisco IOS-XR增加了对NETCONF的支持以及对候选配置的支持。像HPE的Comware 7和Cisco IOS-XE这样的操作系统支持NETCONF，但还不支持候选配置数据存储。

检查您的硬件和软件平台，即使来自同一设备商。它们之间支持的功能可能不同。支持候选配置只是其中一个例子。

我们说过，对于候选配置，您可以输入各种配置，并且在执行commit之前不会应用这些配置。这使我们想到了启用NETCONF设备的另一个核心属性——配置作为事务进行更改。这意味在我们之前的所有示例，所有命令都会成功，否则将不会应用。这与常见的情况相反，输入一系列命令，在中间某处出现命令失败，从而产生部分配置。对候选配置的支持只是NETCONF的一个属性，现在让我们更深入地研究底层NETCONF协议栈。

学习NETCONF协议栈

我们已经讨论了NETCONF的几个属性，是时候深入研究NETCONF用于客户端和服务器之间进行通信的协议栈了。在我们的示例中，客户端将是Python应用程序或SSH Client，而服务器是我们要自动化的目标网络设备。

NETCONF协议栈有四个核心层。如下：

NETCONF只支持XML进行数据编码。RESTful API能支持JSON或XML。

Transport

NETCONF通常使用SSH作为传输，它是它自己的SSH子系统。虽然我们的所有示例都使用SSH上的NETCONF，但在技术上可以通过SOAP、TLS或其它满足NETCONF要求的协议来实现NETCONF。随着SOAP向RESTful API的迁移，NETCONF over SOAP的进一步开发受到了限制，尽管可以通过TLS实现NETCONF，但目前没有平台支持它。

其中一些要求是：

• 必须是面向连接的会话，因此客户端和服务器之间必须有一致的连接。

• NETCONF会话必须提供身份验证、数据完整性、机密性和重放保护的方法。

• 尽管NETCONF可以与其它传输协议一起实现，但每个实现至少必须支持SSH。

Messages

NETCONF消息基于基于远程过程调用(RPC)的通信模型，每个消息用XML编码。使用基于RPC的模型可以独立于传输类型使用XML消息。NETCONF支持两种消息类型，即和。查看实际的XML编码对象有助于说明NETCONF，所以让我们看看NETCONF RPC请求。

简单地说，消息类型始终是和，它们始终是编码对象中最外层的XML标记。

"101">     

每个NETCONF都包含一个名为message-id的必需属性。它是客户端发送到服务器的任意字符串。服务器在响应头中重用这个ID，以便客户端知道服务器正在响应哪个消息。

另一个消息类型是。NETCONF服务器使用message-id和从客户端接收的任何其它属性(例如XML名称空间)进行响应。

"101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">   

上面的这个示例假定XML名称空间位于客户端发送的中。注意，来自NETCONF服务器的实际数据响应嵌入在标记中。接下来，我们将展示NETCONF请求如何指示它向服务器请求哪个指定的NETCONF操作(RPC)。

Operations

最外层的XML元素是要发送的消息类型(即，或)。从客户端向服务器发送NETCONF请求时，下一个元素或消息类型的子元素是请求的NETCONF(RPC)操作。现在我们来看看每种操作。

我们展示两个主要操作和。操作检索正在运行的配置和设备状态信息。

"101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">       

由于是消息中的子元素，这意味客户端正在请求一个NETCONF操作。

在层次结构中，有可选的过滤器类型，允许您有选择地检索正在运行的配置的一部分，即subtree和xpath过滤器。我们的重点是subtree过滤器，它允许您提供一个XML文档，它是您希望在给定请求中检索的完整XML树层次结构的子树。

在下一个示例，我们使用元素和http://cisco.com/ns/yang/ned/ios URL引用指定的XML数据对象。这个XML数据对象是存在于目标设备上的指定数据模型的XML表示。这个数据模型以XML的形式表示一个完整的运行配置，但是我们只请求配置。

如示例所示，在客户端和服务器之间发送的实际JSON和XML对象在很大程度上依赖于设备商和操作系统。

下面显示的操作的两个示例来自运行16.3+代码的Cisco IOS-XE设备的XML请求。

"101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">"subtree">"http://cisco.com/ns/yang/ned/ios">

我们可以向过滤器的XML树中添加更多元素，以缩小从NETCONF服务器返回的响应。现在，我们将向过滤器添加两个元素，这样就不再接收所有接口的配置对象，而是只接收GigabitEthernet1的配置。

"101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">"subtree">"http://cisco.com/ns/yang/ned/ios">1

下一个最常见的NETCONF操作是操作。此操作用于进行配置改变。具体来说，此操作将配置加载到指定的配置数据存储：运行、启动或候选。当使用操作时，使用标记设置目标配置数据存储。如果没有指定，它将默认为正在运行的配置。同样在层次结构中，要加载到目标数据存储的配置元素通常包含在元素中。中的XML元素映射回指定的数据模型。

"101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

   0.0.0.0/010.1.0.1

使用操作时，元素不是必需的。中可以使用的是基于指定设备上支持的NETCONF功能。如果支持：url功能，则可以使用标记指定包含配置数据的文件的位置。

此外，设备商可以实现指定于平台的选项。一个例子是Juniper的Junos为提供的功能。上个示例使用并需要XML配置对象来向Juniper Junos设备添加静态路由。Juniper的Junos还支持中的，这允许您使用文本格式(大括号或set语法)包含配置元素。

操作还支持一个名为operation的属性，该属性为设备如何应用配置对象提供了更大的灵活性。使用operation属性时，可以将其设置为以下五个值之一：merge、replace、create、delete或remove。默认值为merge。如果您想从前面的示例中删除路由，可以使用delete或remove；区别在于，如果在对象不存在时使用delete，则会发生错误。可以选择使用create，但如果对象已经存在，则会引发错误。通常，merge用于为此原因进行配置更改。

最后，如果要替换配置数据对象中的指定XML层次结构，可以使用replace操作。在静态路由示例中，如果希望在设备上只使用默认静态路由，则可以使用replace，它将自动删除所有其它配置的静态路由。

如果这看起来还有点混乱，不用担心。在接下来的两个部分，一旦我们开始研究并自动化使用NETCONF的设备，您将看到更多例子，这些示例使用诸如NETCONF合并和替换操作之类的操作跨不同的设备类型使用各种XML对象。

我们展示了使用和操作时的XML文档。下面描述了其它基本NETCONF操作：

：检索指定配置的全部或部分(例如，运行、候选或启动)。

：使用另一个配置数据存储的内容创建或替换配置数据存储。使用此操作需要使用完整配置。

：删除配置数据存储(注意，无法删除正在运行的配置数据存储)。 ：锁定正在更新的设备的配置数据存储系统，确保其它系统(NETCONF客户端)不能同时进行更改。 ：解锁配置数据存储。 ：请求终止NETCONF会话。

：强制立即终止NETCONF会话。

上述列表不是NETCONF操作的详尽列表，而是每个设备在NETCONF实现中必须支持的核心操作。NETCONF服务器还可以支持扩展操作，如和。为了支持这样的扩展操作，设备必须支持称为NETCONF功能的所需依赖项。

操作将候选配置提交为设备的新运行配置。为了支持操作，设备必须支持：candidate功能。操作验证指定配置(running、candidate、startup)的内容。验证包括在将配置应用到设备之前检查配置的语法和语义。

我们已两次提到NETCONF功能。如您所知，NETCONF支持一组基本的NETCONF RPC操作。但是，这些都是由支持NETCONF基本功能的设备实现的。NETCONF功能在连接设置期间在客户端和服务器之间交换，支持的功能由URL/URI表示。例如，每个支持NETCONF的设备都应该支持基本操作，并且该URL表示为urn:ietf:params:xml:ns:netconf:base:1.0。其它功能使用格式urn:ietf:params:netconf:capability:{name}:1.x，其中name是功能的名称，特定功能通常被引用为：name，正如我们通过引用：candidate功能所示。当我们开始从实际操作的角度探索NETCONF的使用时，您将看到指定设备支持的所有功能。

Content

NETCONF协议栈要理解的最后一层是内容。这个内容是指嵌入到RPC操作标记元素中的实际XML文档。我们已经展示了指定NETCONF操作的内容示例。在第一个示例，我们有选择地查看了Cisco IOS-XE设备上的接口配置内容：

"http://cisco.com/ns/yang/ned/ios">

理解内容最重要的一点是，它是设备支持的指定模式或数据模型的XML表示。

在我们的示例中使用的IOS-XE设备支持用YANG建模语言编写的模型，其中一个模型是表示完整运行配置的模型。虽然模型是用YANG编写的，但是它必须在NETCONF客户端和NETCONF服务器间用XML表示，因为NETCONF只支持XML编码。

下个示例突出显示了向运行Junos的Juniper设备添加静态路由的内容。同样，关键的部分是理解如何构造设备操作系统所需的适当的XML文档；理解模型或模式所使用的语言(如YANG或xmlschema Definitions，XSD)就不那么重要了。例如，我们是否知道这个juniper xml文档映射到以XSD编写的模式还是用YANG编写的模型？我们把它留给读者作为练习。

0.0.0.0/010.1.0.1

待续....

网络自动化与可编程-09

网络自动化与可编程-10