你是软件定义网络(SDN)的新手吗?你是不是被困在过去几年的SDN热潮?无论你属于哪一类，都不要担心。
网络可编程性和自动化系列将带您通过基础的主题，开始您的网络可编程性和自动化之旅，从SDN的兴起开始。本章提供了围绕SDN的网络行业趋势的洞察，它的相关性，以及它在当今网络世界的影响。我们将从回顾如何开始软件定义网络使其成为主流，并最终导致了围绕网络可编程性和自动化的趋势。
1.软件定义网络的兴起
如果说有一个人可以为网络行业正在发生的所有变化做出贡献的话，那就是马丁·卡萨多，他目前是安德森·霍洛维茨基金(Andreessen Horowitz)的普通合伙人和风险投资家。之前，Casado是VMware
网络和安全部门的高级副总裁兼总经理在VMware的业务部门。他对行业产生了深远的影响，不仅仅是因为他的直接贡献(包括OpenFlow和Nicira)，还因为他打开了大型网络公司的眼界，表明网络运营、敏捷性和可管理性必须改变。让我们更详细地看看这个。
1.1 OpenFlow
无论好坏，OpenFlow都是软件定义网络(SDN)发展的第一个主要协议。OpenFlow是Martin Casado在斯坦福大学攻读博士学位时在Nick McKeown的指导下研究的协议。OpenFlow只是一种允许网络设备的控制平面与数据平面分离的协议(见图1-1)。用最简单的术语来说，控制平面可以被认为是网络设备的大脑，数据平面可以被认为是起作用的硬件或特定于应用程序的集成电路(asic)。
图1-1 使用OpenFlow分离控制平面和数据平面
以混合模式运行openflow
如图1-1描述没有控制平面的网元。这代表了纯openflow的部署。许多设备还支持以混合模式运行OpenFlow，这意味着OpenFlow可以部署在给定的端口、虚拟本地网络(VLAN)，甚至在一个正常的包转发管道中，如果在OpenFlow表中没有匹配，则使用现有的转发表(MAC、路由等)，使其更类似于基于策略的路由(Policy Based Routing，策略路由)。
这意味着OpenFlow是一种底层协议，用于直接与硬件表(如转发信息库或FIB)连接，指示网络设备如何转发流量(例如，“到达目的地192.168.0.100的流量应该从48端口出口”)。
Note：
OpenFlow是一种操作流表的底层协议，因此直接影响包转发。OpenFlow并不打算与管理平面属性交互，比如身份验证或SNMP参数。
由于与传统路由协议相比，OpenFlow使用的表支持更多的目的地址，因此有更多的粒度(匹配数据包中的字段)来确定转发路径。这与基于策略的路由所提供的粒度没有什么不同。就像OpenFlow多年后所做的那样，策略路由允许网络管理员基于“非传统”属性(如包的源地址)转发流量。然而，网络供应商为通过PBR转发的流量提供等价的性能需要相当长的时间，而且最终结果仍然非常特定于供应商。OpenFlow的出现意味着我们现在可以在流量转发决策上实现同样的粒度，但是以一种厂商中立的方式。增强网络基础设施的功能成为可能，而无需等待制造商的下一个硬件版本。
可编程网络的历史
OpenFlow并不是第一个将控制功能和智能与网络设备分离的协议或技术。尽管OpenFlow是开启SDN革命的技术，但技术和研究在OpenFlow之前已经有很长的历史了。在OpenFlow之前出现的一些技术包括转发和控制元素分离(ForCES)、主动网络、路由控制平台(RCP)和路径计算元素(PCE)。想要更深入地了解这段历史，请参阅Jen Rexford、Nick Feamster和Ellen Zegura撰写的论文《SDN之路:可编程网络的思想史》。
虽然理解OpenFlow是什么很重要，但更重要的是理解最初的OpenFlow规范的研究和开发工作背后的原因，这导致了软件定义网络的兴起。
Martin Casado多在斯坦福读书时曾为国家政府工作。在他为政府工作期间，有必要对IT系统的安全做出反应(毕竟这是美国政府)。Martin Casado多很快意识到，他可以根据需要编程和操作计算机和服务器。实际的用例从未公开过，但正是这种对端点的控制使得在需要时能够对主机或主机组进行反应、分析和重新编程成为可能。
当涉及到网络时，几乎不可能以一种干净和程序化的方式来实现这一点。毕竟，每个网络设备都是关闭的(例如，禁止安装第三方软件)，并且只有一个命令行界面(CLI)。尽管CLI在过去和现在都为网络管理员所熟知，甚至是他们的首选，但对马丁·卡萨多来说，它显然不能提供真正管理、操作和保护网络所需的灵活性。
实际上，除了为新功能添加了CLI命令外，网络管理的方式在20多年里从未改变过。最大的变化是从Telnet迁移到SSH，这是SDN公司Big Switch Networks在他们的幻灯片中经常使用的一个笑话，如图1-2所示。
玩笑归玩笑，网络管理已经大大落后于其他技术，这也是Casado在未来几年里最终打算改变的。当检查其他技术时，通常可以更好地理解这种可管理性的缺乏。其他技术几乎总是有更现代的方法来管理许多设备，用于配置管理和数据收集和分析。例如，hypervisor管理器、无线控制器、IP PBX、PowerShell、DevOps工具，等等。其中一些是作为商业软件从供应商那里紧密耦合的，但另一些则是松散的，以支持多平台管理、操作和敏捷性。
如果我们回到Martin Casado在为政府工作时遇到的场景，在寻找答案时出现了什么样的问题?是否可以基于应用程序重定向流量?网络设备有API吗?是否有一个与网络通信的单一点?答案基本上都是否定的。怎么可能编程网络来动态控制数据包转发、策略和配置，就像编写程序并在终端主机上运行一样容易呢?
最初的OpenFlow规范是Martin Casado亲身经历这些类型的问题的结果。随着业界最终开始更多地关注用例和解决方案，而不是底层协议，围绕OpenFlow的炒作已经逐渐平息，这一最初的工作是整个行业重新思考网络如何构建、管理和运行的催化剂。谢谢你,马丁。
这也意味着，如果没有马丁·卡萨多，这本书可能就不会被写出来，但我们现在永远不会知道!
1.2 软件定义网络
我们已经介绍了OpenFlow，但什么是软件定义网络(SDN)?它们是相同的东西，不同的东西，还是都不是? 说实话，SDN就像十多年前的云一样，当时我们还不知道云的不同类型，比如基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)。
参考示例和设计简化了对云是什么和现在是什么的理解，但即使在这些术语存在之前，也可能存在这样的争论:当你看到云时，你就知道它。这就是我们软件定义网络所处的位置。有一些公开的定义，认为白盒网络是SDN，或者在网络设备上拥有API是SDN。它们真的是SDN吗?不是真的。
与其试图提供SDN的定义，我们将涵盖经常被认为是SDN的技术和趋势，并包括在SDN对话中。它们包括:
- 开放的转发平面（Opening up the forwarding plane ）
- 网络功能虚拟化（Network Functions Virtualization ）
- 虚拟交换（Virtual switching ）
- 网络虚拟化（Network virtualization ）
- 设备应用程序接口（Device APIs ）
- 网络自动化（Network automation ）
- 裸金属交换（Bare-metal switching ）
- 数据中心网络矩阵（Data center network fabrics ）
- 软件定义广域网（SD-WAN）
- 控制器网络（Controller networking ）
- 基于意向网络（Intent-based networking ）
- 基础设施即代码（Infrastructure as Code ）
Note：
我们有意不在本书中提供SDN的定义。虽然在本章中提到了SDN，但我们主要关注的是通常被分类为SDN的一般趋势，以确保您更具体地了解每一个这些趋势。
在这些趋势中，本书的其余部分将专注于网络自动化、api和外围技术，这些技术对于理解网络设备如何通过现代自动化工具和仪器将编程接口暴露在一起至关重要。
1.2.1 开放的转发平面（Opening up the forwarding plane ）
尽管我们在前面介绍了OpenFlow作为主要颠覆者，开放转发平面，允许外部软件控制平面对其进行控制。在控制器和网络设备之间使用像OpenFlow这样的协议的主要好处之一是真正独立于控制器软件和底层虚拟和物理网络设备的供应商。然而，在OpenFlow开发过程中所看到的现实是，标准的OpenFlow总是落后于供应商的扩展。
此外，OpenFlow的设计受到其自身抽象建模(没有覆盖ASIC sdk的所有功能)和ASIC中可用的预定义包处理管道(定义包将遍历的步骤)的限制，使用预定义的数据结构(表)，OpenFlow可以在运行时更改转发状态。
Note：
自2017年以来，OpenFlow标准开发没有任何变化，它的采用仅限于特定的用例。
了解了OpenFlow的一些局限性，新的问题:
- 为什么这些包处理管道是固定的?
- 为什么我们不能定义自己的数据结构?
Barefoot Networks公司(现在是英特尔的一部分)响应了这一号召，创建了一个全新的高性能芯片家族(Tofino)，拥有完整的可编程执行管道，以及一种新的编程语言“独立于协议的分组处理器(P4)”。
Note：
P4和OpenFlow协议规范是由同一个组织“Open Network Foundation(ONF)”驱动的。
这种颠覆性的新方法挑战了硅谷市场现状。游戏中的最大玩家博通(Broadcom)推出了一种替代可编程解决方案(“网络编程语言(NPL)”)(具有有限的可配置选项)，并在2020年通过开放其SDK(“OpenBCM”)，提供了一种更简单的方式来编程他们的芯片。其他玩家也采用了某种程度的可编程性。例如，Cisco Silicon One或Juniper Trio/Penta解决方案支持P4可编程性。
Note：
传统上，ASICs是通过芯片供应商的sdk编程的(在固定处理管道的约束下)，sdk公开了预先创建的数据结构和方法，以便定义如何执行分组转发(考虑到转发状态数据)。
从几年前开始，芯片厂商已经开始开放他们的sdk，这些sdk之前是根据请求和保密协议共享的，以便于他们的解决方案的第三方可编程性。很可能，这种变化是由业界推动ASICs的低级可编程性所引起的。
由于更高的成本和一些技术限制，这些高度可定制的asic今天的市场有限——一些市场预测显示，在未来几年，ASICs的采用将显著增加。时间将告诉我们这个市场将如何发展，以及哪些用例将从这些可编程管道提供的灵活性中获益最大。
在图1-3中，我们看到了OpenFlow、P4和ASIC SDK的组合场景。这只是为了说明这些不同解决方案之间的潜在相互作用。每种情况下只使用其中一个。例如，如果您有一个底层应用程序编程SDK，您将公开自己的API。
对转发平面进行编程，有利于更细粒度地了解流量如何穿过网络，但能力越大，责任越大。如果你有一个开发团队(如谷歌、亚马逊等大公司)，或者这是你的核心业务(NOS供应商和集成商)，这是很好的。但是，对于大多数组织来说，OpenFlow、P4或任何其他固定协议的使用都不如一个整体解决方案为所支持的业务提供什么重要。
1.2.2 网络功能虚拟化（Network Functions Virtualization）
网络功能虚拟化(NFV)并不是一个复杂的概念。它指的是采用传统上作为硬件部署的功能，而不是将它们部署为软件。最常见的例子是作为路由器、防火墙、负载平衡器、IDS/IPS、VPN、应用程序防火墙和任何其他服务/功能运行的虚拟机。
WARNING:
请不要混淆我们对NFV概念的描述和具体的ETSI NFV规范，用于电信行业。这里，我们从抽象的角度来处理NFV，没有具体的实现细节。
使用NFV，可以将可能花费数万或数十万美元的单体硬件(具有数百到数千行命令)分解为N个软件(即虚拟设备)。从单个设备的角度来看，这些更小的设备变得更易于管理。
Note:
上述场景使用虚拟设备作为支持NFV的设备的形式因素。这仅仅是一个例子。将网络功能部署为软件的形式有很多种，包括嵌入到管理程序(称为虚拟网络功能，VNF)、作为容器(称为容器网络功能，CNF)或作为运行在x86服务器上的应用程序。
为了以防万一，部署三到五年后才会用到的硬件并不罕见，因为逐步升级太复杂，成本甚至更高。因此，硬件不仅是一项密集的资本成本，它只用于如果增长发生时的假设场景。部署基于软件或NFV的解决方案提供了一种更好的方法，可以在使用随增长付费模型时扩展并最小化网络或特定应用程序的故障域。例如，您可以逐步部署Cisco ASAv设备，并随着您的增长支付费用，而不是购买单个大型的Cisco ASA。您还可以使用Avi Networks等公司的新技术轻松扩展负载平衡器，该公司现在是VMware的一部分。
尽管NFV提供了如此多的好处，但行业需要一段时间才能在生产中采用这些解决方案。实际上有几个不同的原因。首先，它需要重新思考网络的架构。在一个单一的单体式防火墙中(例如)，所有的东西都要经过这个防火墙——意味着所有的应用程序和所有的用户，或者如果不是全部，也就是你所知道的一个定义集。在NFV范例中，可以部署许多虚拟防火墙，每个应用程序或租户都有一个防火墙，而不是单一的大型防火墙。这使得每个防火墙或任何其他服务设备的故障域相当小，并且如果正在进行更改或正在推出新应用程序，则不需要对其他基于每个应用程序(每个租户)的防火墙进行更改。
另一方面，在拥有单体设备的更传统的世界中，本质上只有一个管理安全策略的窗口——一个CLI或GUI。这可能使故障域变得巨大，但它确实为管理员提供了简化的策略管理，因为它只管理一个设备。对于一些支持这些设备的团队或工作人员来说，这个原因可能会导致他们保持整体式方法。
然而，在过去的几年里，随着IT向基于云的环境(私有和公共)的加速过渡，客户对更动态架构的需求促使网络团队构建需要使用不同类型NFV解决方案的混合网络。在这一过程中，消费和管理以软件为中心的解决方案的新工具的出现，以及对来自传统和新供应商的呼吁的响应，普及了NFV解决方案的使用。
Note：
在开始阶段，延迟采用NFV的一个因素是，一些供应商没有以与其产品组合的其他部分相同的决心销售他们的虚拟设备版本。我们并不是说他们没有虚拟选项，但它们通常不是许多传统设备制造商的首选选择。如果一个供应商从事硬件业务已经有一段时间了，从销售和薪酬的角度来看，这是向软件主导模式的重大转变。相反，现在，供应商正在投资并行发展他们的硬件和软件解决方案。
正如将在许多这些技术领域中看到的那样，NFV的一个主要价值也在于敏捷性。消除硬件通过消除机架、堆叠、电缆和集成到现有环境所需的时间，减少了提供新服务的时间。利用软件方法，它可以像部署新的虚拟机一样快，这种方法的一个固有好处是能够克隆和备份虚拟设备以进行进一步的测试，例如在灾难恢复(DR)环境中或模拟虚拟实验室中，我们将在[即将到来的链接]中看到。此外，这种灵活性在支持新技术方面发挥着关键作用，如边缘计算或5G网络。
最后，当部署NFV时，它消除了通过特定物理设备路由流量以获得所需服务的需要，从而增加了根据特定服务更改网络架构和创建服务链(如分段路由启用的服务链)的灵活性。
1.2.3 虚拟交换（Virtual switching）
目前市场上比较常见的虚拟交换机包括VMware标准交换机(VSS)、VMware分布式交换机(VDS)、Cisco Nexus 1000V和开源的open vSwitch (OVS)。
这些交换机经常被卷入到SDN的讨论中，但实际上它们是基于软件的交换机，驻留在管理程序内核中，提供虚拟机(以及现在的容器)之间的本地网络连接。它们提供MAC学习等功能，以及链路聚合、SPAN和sFlow等特性，就像物理交换机多年来一直在做的那样。虽然这些虚拟交换机经常出现在更全面的SDN和网络虚拟化解决方案中，但它们本身只是碰巧在软件中运行的交换机。虽然虚拟交换机本身并不是一个解决方案，但在我们作为一个行业向前发展的过程中，它们极其重要。他们在数据中心内创建了一个新的访问层或新边缘。网络边缘不再是物理机架顶部(TOR)交换机，由硬件定义，但灵活性有限(在特性/功能开发方面)。由于新边缘通过使用虚拟交换机以软件为基础，它提供了在软件中更快地创建新网络功能的能力，因此可以更容易地在整个网络中分发策略。以虚拟机或容器为例，在离实际终端最近的虚拟交换机端口上部署安全策略，进一步增强网络的安全性。
1.2.4 网路虚拟化（Network virtualization）
被归类为网络虚拟化的解决方案已经成为SDN解决方案的同义词。在本节中，网络虚拟化指的是仅基于软件的覆盖解决方案。VMware的NSX、诺基亚的Nuage虚拟服务平台(VSP)和Juniper的Contrail都属于这一类。
这些解决方案的一个关键特征是使用一种基于覆盖的协议，如虚拟可扩展局域网(VxLAN)，在基于管理程序的虚拟交换机之间建立连接。这种连接和隧道方法在独立于物理网络的不同物理主机上的虚拟机之间提供了第2层邻接，这意味着物理网络可以是第2层、第3层或两者的结合。其结果是一个与物理网络解耦的虚拟网络，旨在提供选择和灵活性。
Note：
值得指出的是，ovenlay网络经常与underlay一起使用。为了清晰起见，underlay是您通过物理电缆连接起来的底层物理网络。overlay网络采用网络虚拟化解决方案，在数据中心内的虚拟交换机之间动态创建隧道。同样，这是基于软件的网络虚拟化解决方案。还要注意，许多纯硬件解决方案现在都部署了VxLAN作为overlay协议，以便在基于Layer 3数据中心内的机架顶部设备之间建立第2层隧道。
虽然overlay是网络虚拟化解决方案的实现细节，但这些解决方案不仅仅是由overlay拼接在一起的虚拟交换机。这些解决方案通常是全面的，提供安全性、负载平衡和集成到物理网络中，所有这些都是通过单一管理点(即控制器)实现的。通常，这些解决方案还提供了与最好的第4-7层服务集成，提供了可以在网络虚拟化平台中部署哪种技术的选择。
敏捷性还得益于中央控制器平台，该平台用于动态配置每个虚拟交换机，并按需服务设备。如果你回忆一下，由于CLI在物理世界中无处不在，网络在操作上已经落后了。在网络虚拟化中，不需要手动配置虚拟交换机，因为每个解决方案都提供了一个中央GUI、CLI和一个API，可以通过编程方式进行更改，从而简化了这个过程。
1.2.5 设备应用程序接口（Device APIs）
在过去的几年中，供应商已经开始意识到仅仅提供一个标准的CLI已经不能解决问题了，使用CLI已经严重阻碍了操作。如果您曾经使用过任何编程或脚本语言，您可能会理解这一点。对于那些还没有的人，我们将在[即将到来的链接]中讨论更多。
主要的痛点是，使用遗留或基于cli的网络设备的脚本不能返回结构化数据。这意味着数据将以原始文本格式(即show版本的输出)从设备返回给脚本，然后编写脚本的人需要解析该文本以提取诸如正常运行时间或操作系统版本等属性。当show命令的输出稍有变化时，脚本就会由于不正确的解析规则而中断。虽然只有管理员才使用这种方法，但自动化在技术上是可行的，但现在供应商正在逐步迁移到api驱动的网络设备。
提供API无需解析原始文本，因为网络设备返回结构化数据，大大减少了编写脚本所需的时间。它不会通过解析文本来查找正常运行时间或任何其他属性，而是返回一个对象，提供所需的信息。它不仅减少了编写脚本的时间，降低了网络工程师(和其他非程序员)的入门门槛，而且还提供了一个更干净的界面，以便专业软件开发人员可以快速开发和测试代码，就像他们在非网络设备上使用api一样。“测试代码”可以是测试新的拓扑、验证新的网络特性、验证特定的网络配置，等等。这些都是现在手工完成的事情，非常耗时且容易出错。
然而，这并不是一个新想法，NETCONF于2006年通过RFC4741发布，但在一段时间内它仍然是相对较少的选择之一，Juniper是推广它的主要供应商。最近，其他供应商也提供了自己的API，如Arista的eAPI，这是一种基于http的API，使用json编码的数据。思科也在特定平台上提供了API，如Nexus NX-API、NETCONF/RESTCONF和gNMI。值得注意的是，如今几乎每家供应商都有某种类型的API，消费者需求在一定程度上推动了这种转变。我们将在[即将到来的链接]中详细介绍API，并在[即将到来的链接]中介绍它们使用的数据格式。
Note：
尽管使用NETCONF的Juniper或使用eAPI的Arista Networks都是API优先的，但它们还提供了CLI(在这些API之上)，因为网络运营商仍然习惯于使用这种接口进行操作。
目前的超大规模网络，就像那些支持大型公共云提供商的网络一样，无法手动操作(仍然匹配所需的卓越运营)。因此，用于管理网络基础设施的API(即gNMI或NETCONF)的存在一直是这些公司的硬性要求。众所周知，像这样的大型网络运营商可以用这样的请求来塑造网络供应商的路线图:“如果这个模型XYZ不支持接口ABC，我不会考虑它”或“如果这个功能仅通过CLI可用，它不是我们的功能”。当我们谈论潜在的大额购买时，你可以想象这些句子的影响力有多大;这就是为什么供应商近年来加强对可编程性的支持的一个重要原因。
1.2.6 网络自动化（Network automation）
随着API在网络世界中的不断发展，更多利用它们的有趣用例也会不断出现。在短期内，网络自动化是利用提供API的现代网络设备公开的编程接口的主要候选者。
从更大的背景来看，网络自动化不仅仅是自动化网络设备的配置。的确，这是网络自动化最常见的感知，但使用api和编程接口可以自动化，并提供比推送配置参数多得多的功能。
利用API简化了对存储在网络设备中的所有数据的访问。考虑流级数据、路由表、FIB表、接口统计数据、MAC表、VLAN表、序列号等数据，这个列表可以无穷无尽。使用现代自动化技术(反过来利用API)可以快速帮助管理网络的日常操作，以进行数据收集以及自动化诊断和修复。最重要的是，由于正在使用返回结构化数据的API，作为管理员，您将有能力显示和分析您想要和需要的确切数据集，甚至来自各种show命令，最终减少调试和排除网络问题所需的时间。你可以使用自动化技术来简化这个过程，甚至可以在睡眠时定期运行它，而不是连接到N个运行BGP的路由器来验证配置或排除问题。
此外，利用自动化技术可以使整个网络更加可预测和统一。您可以看到它是通过自动创建配置文件、自动创建VLAN或自动处理故障。它简化了特定环境的所有用户的处理过程，而不是让每个网络管理员拥有自己的最佳实践。
第二章将更深入地介绍各种类型的网络自动化。
1.2.7 裸金属交换（Bare-metal switching）
裸金属交换的话题也经常被认为是SDN，但事实并非如此。真的,不是!也就是说，在我们介绍被认为是SDN的各种技术趋势的努力中，需要涵盖它。如果我们回到2014年(甚至更早)，用来描述裸金属交换的术语是白盒。这个词变了，而且不是没有充分的理由。
在我们介绍从白盒到裸金属的变化之前，重要的是要理解这在高层次上意味着什么，因为这是人们如何看待网络设备的一个巨大变化。在过去的20年里，网络设备总是作为物理设备购买的，这些物理设备以硬件设备、操作系统和可以在系统上使用的功能/应用程序的形式出现。这些组件都来自同一个供应商。
在白盒和裸机网络设备中，设备看起来更像一个x86服务器(见图1-4)。它允许用户分解每个必需的组件，使从一个供应商购买硬件，从另一个供应商购买操作系统，然后从其他供应商甚至开源社区加载功能/应用程序成为可能。
在OpenFlow大肆宣传的一段时间里，白盒交换是一个热门话题，因为其目的是将硬件商品化，并将网络的大脑集中在OpenFlow控制器(现在也称为SDN控制器)中。在2013年，谷歌宣布他们已经构建了自己的交换机，并使用OpenFlow来控制它们!这是当时许多行业讨论的主题，但实际上，并不是每个最终用户都是谷歌，因此并不是每个用户都会构建自己的硬件和软件平台。
在这些努力的同时，我们看到了一些公司的出现，它们只专注于围绕白盒转换提供解决方案。它们包括Big Switch Networks(现在是Arista Networks的一部分)、Cumulus Networks(现在是NVIDIA的一部分)和Pica8。它们都提供了纯软件解决方案，因此它们仍然需要运行其软件的硬件来提供端到端的解决方案。最初，这些白盒硬件平台来自原始直接制造商(ODM)，如Quanta、Super Micro和Accton。如果你从事网络行业，很可能从未听说过这些供应商。
直到Cumulus和Big Switch宣布与惠普和戴尔等公司建立合作关系，业界才开始将这一趋势从白盒(white-box)转向裸机(bare-metal)，因为现在知名厂商已经开始在自己的硬件平台上支持Big Switch和Cumulus Networks等第三方操作系统。
为什么裸金属在技术上不是SDN，这可能仍然是一个困惑，因为像Big Switch这样的解决方案在两个世界都可以发挥作用。答案很简单。如果有一个控制器使用OpenFlow(不一定是OpenFlow)这样的协议与解决方案集成在一起，并且它以编程方式与网络设备通信，那么它就具有软件定义网络的特性。这就是Big Switch所做的——他们在裸机/白盒硬件上加载软件，运行OpenFlow代理，然后作为解决方案的一部分与控制器通信。
另一方面，像NVIDIA Cumulus这样的NOS提供了专门为网络交换机构建的Linux发行版。该发行版或操作系统运行传统协议，如LLDP、OSPF和BGP，不需要任何控制器，使其与基于非sdn的网络架构更具可比性和兼容性。
通过这个描述，可以明显看出Cumulus是一家网络操作系统公司，他们的软件运行在裸金属交换机上，而Big Switch是一家基于裸金属的SDN公司，需要使用他们的SDN控制器，但也利用了第三方裸金属交换基础设施。
目前，几乎所有的NOS都以Linux为基础操作系统。操作系统运行在用户空间，负责运行控制平面和管理平面协议。由于用户空间内固有的包转发性能限制(内核接收到的每个包都会引起软CPU中断，网络设备将处理大量的包!)，NOS将包转发转移到交换硅（switch silicon）通过其特定的驱动程序，绕过内核。
快速数据路径(xdp)
在Linux中改善网络性能的另一项重要的新技术是快速数据路径(XDP)。这是一个框架，允许自定义程序很早就注入到分组处理路径中，并纯粹在内核空间中执行。这些程序由eBPF(从4.8版开始在Linux内核中提供)提供支持，它是已经存在一段时间的伯克利分组过滤器(BPF)的发展(例如，由tcpdump使用)。由于XDP程序涉及处理分组的阶段，与流经内核其余处理步骤和从用户空间复制内存相关的大部分开销可以避免，从而可能带来更高的性能。XDP和eBPF将在[即将到来的链接]中详细介绍。
在所有这些网络操作系统中，根据与内核交互的方式以及其他应用程序与之交互的方式，可以划分为三类。
纯用户空间
NOS独立于内核实现整个网络堆栈，例如在基于dpdk的网络操作系统(例如FD.io)和Cisco NX-OS中。
混合Linux内核
NOS和内核网络数据结构之间使用Netlink进行部分交互，Netlink是Linux内核中用于同步其网络状态的套接字族。有不同层次的交互，但在大多数情况下，关键的NOS的应用程序(即路由协议栈)保持状态在用户空间，只使用一些来自内核空间的数据，例如，ARP/ND状态。这个群体现在是最拥挤的:微软的SONiC /Open Compute Project, Arista Networks的EOS等等。
完整的Linux内核
这类完全依赖Linux的网络状态数据结构和API。Cumulus Linux是这一类中的主要例子，它与DentOS等其他例子一起成长。
在图1-5中，描述了三种不同的方法，显示了应用程序、NOS堆栈和Linux内核之间的交互级别。
使用内核API为插入做同样事情的其他Linux应用程序打开了大门，这样您就可以选择一个更好地解决您的需求而无需重新发明轮子。例如，如果你需要一个路由守护进程，你可以使用“FRR路由”(来自Quagga项目)。此外，大家可以使用新的内核特性，如XDP或switchdev，这是一个新的设备抽象模型，用于与交换硅（switch silicon）通信。
TIP
关于这个主题的一个很好的参考是Dinesh G. Dutt的《云原生数据中心网络》一书中的“第四章—网络操作系统选择”
简而言之，裸金属/白盒交换是关于分解和从一个供应商购买网络硬件和从另一个供应商加载软件的能力，如果您选择这样做的话。在这种情况下，管理员可以灵活地更改设计、体系结构和软件，而无需更换硬件，只需要更换底层操作系统。
1.2.8 数据中心网络矩阵（Data center network fabrics）
你是否曾经遇到过这样的情况:即使网络中所有的网络设备都运行着标准的协议，例如生成树或OSPF，你也不能轻易地交换它们?如果你有，你并不孤单。想象一下，有一个数据中心网络，其中有一个折叠的核心，每个机架顶部都有独立的交换机。现在想想升级时需要发生的过程。
有很多这样的方式来升级网络，但如果只是需要升级的TOR交换机，并且在对新的TOR交换机进行评估的过程中，决定使用新的供应商或平台，怎么办?这是100%正常的，而且已经做了一次又一次。这个过程很简单——将新交换机连接到现有的核心(当然，我们假设核心中有可用的端口)，如果是二层互连，则正确配置802.1Q集群，如果是三层互连，则配置您喜欢的路由协议。
进入数据中心网络矩阵。这就是关于数据中心网络的思考过程必须改变的地方。
数据中心网络矩阵旨在改变网络运营商从“一次管理单个盒子”到“整体管理整个系统”的思维方式。如果我们使用前面的场景，就不可能将TOR交换机换为另一个供应商，这只是数据中心网络的一个组件。相反，当网络作为一个系统被部署和管理时，需要将其视为一个系统。这意味着升级过程是从一个系统迁移到另一个系统，或者从一个矩阵迁移到另一个矩阵。在矩阵的世界里，当需要升级的时候，矩阵是可以更换的，但矩阵中的单个组件不能更换——至少在大多数情况下是这样。当特定供应商提供迁移或升级路径以及使用裸金属交换(仅替换硬件)时，这是可能的。数据中心网络矩阵的几个例子是思科的应用中心基础设施(ACI)、Big Switch的大云网络(BCF)(现在是Arista网络的一部分)，或者Plexxi的Fabric(现在是Aruba的一部分)和超融合网络。
除了将网络视为一个系统，数据中心网络矩阵还有以下几个共同属性。
- 它们提供了管理或配置矩阵(包括策略管理)的单一接口。
- 它们在整个架构中提供分布式默认网关。
- 它们提供多路径功能。
- 他们使用某种形式的SDN控制器来管理系统。
1.2.9 软件定义广域网（SD-WAN）
过去几年软件定义网络中最热门的趋势之一是软件定义广域网络(SD-WAN)。在过去的几年里，越来越多的公司成立来解决广域网络的问题。
NOTE
其中很多初创公司都被主流的网络和安全供应商收购，例如Cisco的Viptela、PaloAlto Networks的CloudGenix、VMWare的VeloCloud、Aruba的Silverpeak以及Juniper的128 Technology，这表明了这些解决方案对所有供应商的投资组合的重要性。
自从从帧中继迁移到多协议标记交换(MPLS)之后，广域网还没有看到技术上的重大转变。由于宽带和因特网的成本只是相当于专用线路成本的一小部分，近年来利用点对点VPN隧道的成本有所增加，为广域网的下一个大事件奠定了基础。
远程办公室的常见设计通常包括专用(MPLS)电路和/或公共互联网连接。当两者都存在时，internet通常只用于备份(特别是客户流量)，或通过VPN返回到企业的一般数据，而MPLS电路用于低延迟应用程序，如语音或视频通信。当流量开始在电路之间分配时，这增加了路由协议配置的复杂性，也限制了如何路由到目的地址的粒度。在选择最佳路径时，通常不会考虑网络的源地址、应用和实时性能。
许多现代解决方案使用的通用SD-WAN架构类似于数据中心中使用的网络虚拟化，因为overlay协议用于连接SD-WAN边缘设备。由于使用了overlay层，该解决方案与底层的物理传输无关，因此SD-WAN可以在互联网或专用广域网上运行。这些解决方案通常在分支站点上通过两个或多个internet电路，使用IPSec对流量进行完全加密。此外，许多这些解决方案不断测量每个正在使用的电路的性能，即使在停电期间，也能够快速地在特定应用的电路之间进行故障转移。由于应用层可见，管理员也可以轻松地选择哪个应用程序应该采用特定的路由。这些类型的特性通常在仅依赖于使用传统路由协议(如OSPF和BGP)的基于目的路由的广域网架构中是找不到的。
从体系结构的角度来看，前面提到的供应商的SD-WAN解决方案通常还提供某种形式的零接触供应(ZTP)和集中式管理，其中门户作为基于saas的应用程序存在于场所或云中，从而大大简化了未来WAN的管理和操作。
使用SD-WAN技术的一个有价值的副产品是，它为最终用户提供了更多的选择，因为基本上任何运营商或类型的连接都可以在WAN上和跨internet使用。这样做可以简化运营商网络的配置和复杂性，从而使运营商简化其内部设计和架构，有望降低成本。再进一步，从技术角度来看，所有逻辑网络结构(如虚拟路由和转发(VRFs))都将通过SD-WAN供应商提供的控制器平台用户界面(UI)进行管理，这样当需要更改时，就不需要等待数周才能得到运营商的响应。
1.2.10 控制器网络（Controller networking）
正如你可能已经意识到的，当涉及到这些趋势时，有一些重叠。当你试图理解过去几年出现的所有新技术和新趋势时，这是令人困惑的一点。
例如，流行的网络虚拟化平台使用控制器，属于数据中心网络矩阵、SD-WAN和裸金属交换机类别的几种解决方案也是如此。困惑吗? 您可能想知道为什么基于控制器的网络被单独打破。实际上，它通常只是提供现代解决方案的特征和机制，但从技术角度来看，并非所有之前的趋势都涵盖了控制器可以提供的所有内容。
例如，一个非常流行的开源SDN控制器是OpenDaylight (ODL)，如图1-6所示。与许多其他控制器一样，ODL是一个平台，而不是产品。这些平台可以提供专门的应用程序，如网络虚拟化，但它们也可以用于网络监控、可见性、tap聚合或与位于控制器平台之上的应用程序一起使用的任何其他功能。这就是为什么理解控制器除了用于更传统的应用程序(如fabric、网络虚拟化和SD-WAN)之外还能提供什么很重要的核心原因。
1.2.11 基于意向网络（Intent-based Network）
与SDN相关的另一个流行词是基于意图的网络(IBN)，这是一个抽象的概念，不同的人有不同的理解方式。试图从几个描述中阐明关键的公共方面，我们可以总结:使用业务语言管理网络的能力(目的)，而不关注低级细节，以及利用这种更高的抽象级别将复杂性从一边转移到另一边。
在幕后，IBN解决方案是由几个组件(前面提到的一些技术)组成的，用于将用户意图转化为实际的网络操作任务。在大多数解决方案中可以看到的一个常见模式是遵循以下工作流程(参见图1-7):闭环编排的自主操作，能够对事件做出反应(类似于事件驱动的自动化)。
- 将抽象的意图定义从业务需求转换为实际的网络变化。这是最难的部分，因为对于“在应用程序a和应用程序B之间建立安全连接”这样的简单请求，需要解决许多开放性问题，“这些应用程序在网络数据(IP地址和端口)方面的细节是什么?”，“在这种情况下，安全连接是什么意思?”，“哪些是路由路径中涉及的网络设备或VNFs ?””等。最后，这些详细数据将存储在一个位置，该位置将定义网络的预期状态。这也被称为真理之源，我们将在后面的链接中谈到它。
- 一旦预期的状态被正确地转换并存储到适当的数据模型中，自动化编排过程将利用自动化引擎在网络中执行所需的状态。这个阶段的主要挑战是将一个网络服务分解成多个网络元素，每个网络元素具有不同的管理接口和数据模型，执行原子性更改(我们不希望部分部署网络更改)。
- 在实际/观察到的网络状态与预期的匹配之后，工作还没有结束。网络是动态的，因此对网络状态(包括度量、日志和网络流)的持续观察将有助于做出决策，使网络恢复到预期的状态。在[即将到来的链接]中，我们将了解一些趋势，比如流式遥测技术，它可以帮助我们改善状态数据收集。
- 为了关闭循环，将分析所有收集到的数据(适当地使用相关业务数据)，以确定观察到的状态和预期的状态是否匹配，如果不匹配，则在步骤2中触发必要的操作来纠正它。
由于其内在的复杂性，这一领域的大多数解决方案都是封闭的专有平台(通常以控制器的形式)，这些平台在上述循环中执行前面的所有步骤。不幸的是，由于这些解决方案的封闭性质，它们不容易扩展和适应受支持用例之外的定制需求，这使得管理异构环境非常复杂。然而，也可以构建您自己的基于意图的解决方案，正如我们将在[即将到来的链接]中看到的，理解功能需求并确定正确的组件和交互，根据需要结合开源和专有解决方案。你可以从供应商那里购买组装好的个人电脑，也可以购买不同的组件(主板、磁盘、内存等)并将它们组装在一起。这个选项并不容易，但它使您有机会根据自己的特定需求对其进行定制。
1.2.12 基础设施即代码 （Infrastructure as Code）
在软件开发和系统基础设施团队中，与网络世界的SDN革命并行的是一种消费IT服务的新方式。在采用配置管理方法(见[即将到来的链接])之后，公共云服务和容器化的兴起导致了IT基础设施服务的动态供应，直接来自代码库。这种趋势被称为代码式的基础架构，包括在文本文件中描述所需的基础架构状态，这些文本文件稍后将被解释为采取必要的行动使它们成为现实。这种模式与DevOps文化完美匹配，在DevOps文化中，开发人员和操作工程师在同一个项目上一起工作，使用相同的代码库开发应用程序，并定义这些应用程序将在哪里运行的基础设施。在图1-8中，我们观察到，在通过API提供基础设施定义之后，如何返回结果状态，并创建动态基础设施资源的实际标识符。
TIP
要更全面地理解这个概念，请查阅Kief Morris的《基础设施作为代码》一书。
与此同时，这种做法也被习惯于从公共云提供商、容器运行时环境(即Kubernetes)或其他提供商(如用于多云环境的Alkira和Aviatrix或用于动态网络连接的PacketFabric)启动网络基础设施服务的网络工程师所采用。
Note
云中的网络已经改变了今天企业网络的面貌，增加了新的挑战，如在集群之间协调覆盖网络或与本地的云网络互连。为了在本地环境和云环境之间构建一致的端到端网络服务，我们需要了解云网络服务的组网特征和限制。我们将在[[即将到来的链接]中深入讨论这个话题。
有几种将文本文件转换为动态基础设施的替代方案，但是Hashicorp开发的Terraform非常受欢迎。它是一个开源工具，由供应商或社区创建的多个提供者(成千上万个)组成。你将在[即将到来的链接]中了解更多。然而，也有其他的选项，具体到每个提供商(例如AWS的CloudFormation或GCP中的谷歌部署管理器)和其他的，而不是使用DSL(领域特定语言)，允许你直接使用编码语言，如Python或Go(例如Pulumi)。
采用基础设施作为代码给网络操作带来了新的挑战。正如每个人都会理解的那样，一旦有人在几秒钟内准备好了一个服务，就会开始询问其他服务，比如创建一个简单的ACL条目或一个新的VLAN，这可能需要几天的时间，因为这在一些网络中仍然是常见的事情。这个问题的答案是采用网络作为服务的思维方式，提供正确的用户界面和自动化编排，以提供当前业务操作所需的敏捷性。
Note
构建网络即服务的应用程序与构建任何软件即服务的应用程序类似，“the Twelve-Factor App”是一个很好的参考，它解释了一个应用程序为了适合在现代云平台上运行应该坚持的特征。
这些建议中的一个关键思想是打包代码、其依赖项和配置(针对每个运行时环境)。充分利用容器(如Docker, Podman)和不可预知的运行时环境，如Kubernetes项目或由Hashicorp的Nomad。我们将在[[即将到来的链接]中讨论这些话题。
一开始，将传统网络服务转换为这种范式似乎有些吓人，但您可以通过将所有必要的构建块(我们将在本书中介绍的那些)组合在一起的策略来实现它，并一步一步地改变您的网络可以如何操作和使用。
2. 总结
现在你有了它:一个关于最常被归类为软件定义网络的趋势和技术的介绍，通过网络可编程性和自动化为更好的网络操作铺平了道路。在过去的7年里，数十家SDN初创公司诞生了，VC投资了数百万美元，并花费了数十亿美元来收购这些公司。这是不真实的，如果我们进一步分解它，它的共同目标是利用软件原则和技术，在提高操作效率的同时，为技术用户提供更强大的功能、控制、敏捷性和选择。
在下个章节中，我们将看一看网络自动化，并深入研究各种类型的自动化、一些通用协议和API，以及自动化在过去几年是如何开始发展的。