1.1　SDN的兴起

如果非要将这些年网络产业的种种变革和某个人联系到一起，那么此人非 Martin Casado 莫属，他目前是 Andreessen Horowitz 公司的普通合伙人和风险投资家。Casado 曾担任过 VMware Fellow1、高级副总裁以及 VMware 网络和安全事业部的总经理。他对业内产生了深远的影响，不仅一手打造了像 OpenFlow 和 Nicira 这样的产品，而且让众多的网络从业者眼界大开，意识到网络运维、敏捷性和可管理性的变革迫在眉睫。下面听我们逐一道来。

1一个公司中工程师的最高荣誉。——译者注

1.1.1　OpenFlow

不管怎么说，OpenFlow 都是软件定义网络运动的第一个主要协议。OpenFlow 是 Martin Casado 于斯坦福大学攻读博士期间，在 Nick McKeown 指导下设计的协议。OpenFlow 只是一个将网络设备的控制平面（control plane）和数据平面（data plane）解耦的协议（参见图 1-1）。简而言之，控制平面可以被看作网络设备的大脑，数据平面则可以被看作负责转发数据包的硬件或者专用集成电路（Application-specific Integrated Circuit，ASIC）。

图 1-1：通过 OpenFlow 解耦控制平面和数据平面

在混合模式下运行 OpenFlow

图 1-1 中的网元没有控制平面。该图展示的是纯 OpenFlow（pure OpenFlow-only）的部署情形。很多设备也支持在混合模式下运行 OpenFlow，这意味着 OpenFlow 可以被部署在任意端口、虚拟局域网（Virtual Local Area Network，VLAN），甚至是一般的数据包转发流水线内。如果在 OpenFlow 表中找不到匹配项，那么就使用现有的转发表（MAC 表、路由表等），这使得 OpenFlow 更像是策略路由（Policy Based Routing，PBR）。

换句话说，OpenFlow 是一种低层协议，可作为与硬件表 [ 比如，转发信息库（Forwarding Information Base，FIB）] 之间的直接接口，指导设备如何转发流量（比如，“到目的地址 192.168.0.100 的流量应该使用出向端口 48”）。

　OpenFlow 是一种可以操纵流向表（flow table），从而直接影响数据包转发的低层协议。OpenFlow 不和管理平面属性（management plane attribute，比如认证或是 SNMP 参数）打交道。

与传统的路由协议相比，OpenFlow 使用多张表来支持更多目的地址，因而能够更精细地（匹配数据包的多个字段）决定转发路径，其效果与 PBR 不分伯仲。就像 OpenFlow 在多年之后所做的那样，PBR 允许网络管理员根据“非传统”属性转发流量，比如数据包的源地址。然而，网络厂商需要花费不少时间才能为通过 PBR 转发的流量实现同等的性能，而且最终的结果也非常依赖于厂商。OpenFlow 的出现意味着可以实现同样精细的流量转发决策，同时无须再依赖厂商。此外，它也使得增强网络基础设施的能力成为可能，无须等待制造商提供新版本的硬件。

可编程网络的历史

OpenFlow 并不是第一个解耦网络设备控制功能和数据功能的协议或技术。尽管 OpenFlow 是 SDN 革命的开启者，但在其之前，人们对此已经开展过长期的技术研究。当时的技术包括分离转发和控制元件（Forwarding and Control Element Separation， ForCES）、主动网络（Active Networks）、路由控制平台（Routing Control Platform， RCP）以及路径计算节点（Path Computation Element，PCE）。如果想进一步了解这段历史，可以参阅由 Jen Rexford、Nick Feamster 和 Ellen Zegura 合著的论文“The Road to SDN: An Intellectual History of Programmable Networks”。

为什么是 OpenFlow

尽管弄清楚 OpenFlow 是什么固然重要，但更重要的是理解 OpenFlow 规范最初的研发意图，恰恰是后者促成了软件定义网络的兴起。

Martin Casado 在斯坦福大学就读期间曾为美国联邦政府工作。在那段时间里，Casado 很快意识到他可以根据需要编写程序控制计算机和服务器。尽管实际做法从未公开，但正是这种对端点的控制使其有可能在需要时对一台或一组主机进行应对、分析和潜在的重新编程。

就网络而言，几乎不可能以简洁和程序化的方式做到这一点。毕竟，每个网络设备都是封闭的（比如说，不能安装第三方软件），而且只提供了命令行界面（Command Line Interface，CLI）。尽管 CLI 一直被网络管理员所熟知，甚至是偏爱，但 Casado 很清楚，这并不能真正提供管理、操作和保障网络安全所需要的灵活性。

实际上，在过去的二十多年间，除了为新功能添加的 CLI 命令，网络管理方式从未改变过。最大的变化也就是从 Telnet 迁移到 SSH，而这也是 SDN 公司 Big Switch Networks 经常放到幻灯片里面的玩笑，你可以在图 1-2 中看到。

玩笑归玩笑，网络管理已经被其他技术远远甩在身后了，这也是 Casado 在接下来的几年里最终想要改变的事情。在研究其他技术时，往往能够更好地理解这种可管理性的缺失。其他技术总是有更现代的方式来管理大量的设备，以便进行配置管理和数据采集及分析，例如，hypervisor2 管理器、无线控制器、IP PBX、PowerShell、DevOps 工具等，不一而足。这些技术中，有些技术作为商业软件与厂商紧密结合，另一些则比较松散，能够实现多平台的管理、运维和敏捷性。

2hypervisor 是一种运行在物理服务器和操作系统之间的中间软件层。——译者注

如果我们回到 Casado 为美国政府工作时的场景，能否根据应用程序来重定向流量？网络设备提供 API 吗？网络有单点通信吗？答案基本上是否定的。能不能就像在终端主机上运行所编写的程序那样，轻松地对网络进行编程，动态控制数据包的转发、策略和配置？

图 1-2：有什么变化？从 Telnet 变成了 SSH（来源：Big Switch Networks）

最初的 OpenFlow 规范正是 Martin Casado 亲身体验这些问题时的产物。随着业界将注意力从低层协议更多地转向用例和解决方案，围绕 OpenFlow 的炒作已然消散，当初的工作成果成了整个业界的催化剂，使其重新思考应该如何构建、管理和运维网络。谢谢你，Martin。

换句话说，如果不是因为 Martin Casado，可能也不会有这本书，不过如今永远都不可能知道答案了！

1.1.2　什么是软件定义网络

我们已经介绍了 OpenFlow，但什么是软件定义网络（SDN）呢？两者是同一个东西吗？说实话，SDN 就像差不多十多年前的“云”一样，我们知道有不同类型的“云”，比如基础设施即服务（Infrastructure as a Service，IaaS）、平台即服务（Platform as a Service，PaaS）以及软件即服务（Software as a Service，SaaS）。

使用参考示例和设计可以简化对于云的过去和现在的理解，但即使在这些术语出现之前，也可以争辩说，当看到云的时候，你就知道了。这就跟我们现在与软件定义网络所处的境况一样。尽管有很多定义，比如白盒网络就是 SDN，或者网络设备支持 API 就是 SDN，但真的如此吗？好像也不尽然。

我们不再尝试给 SDN 下定义，而是打算介绍一些经常被认为是 SDN 并出现在相关对话中的技术和趋势。

•OpenFlow

•网络功能虚拟化

•虚拟交换机

•网络虚拟化

•设备 API-网络自动化

•裸机交换

•数据中心网络 fabric 架构

•SD-WAN

•控制器联网

　本书特意没有给出 SDN 的定义。尽管本章提到了 SDN，但我们把重点放在了经常被归为 SDN 的发展趋势，确保你能更具体地了解这些趋势。

在这些趋势中，本书余下部分将侧重于网络自动化、API 和相关的外围技术，这对于理解各部分如何在网络设备中结合在一起至关重要，此类网络设备通过现代自动化工具和装置对外公开编程接口。

01.OpenFlow

尽管先前介绍过 OpenFlow，但我们还是想再强调你应该留意的几个 OpenFlow 重点。

在控制器和网络设备之间使用 OpenFlow 之类的协议的主要好处之一是，控制器软件 [ 有时称为网络操作系统（Network Operating System，NOS）] 和底层的虚拟及物理网络设备将真正独立于厂商。但实际情况是，由于标准的更新速度以及提供 OpenFlow 现成版本所不具备的独特增值功能的需求，在解决方案中使用 OpenFlow 的厂商（包括 Big Switch Networks、HP 和 NEC）都开发了自家的 OpenFlow 扩展。至于是否所有的扩展都会被纳入未来的 OpenFlow 标准还有待观察。

一旦使用了 OpenFlow，你就会体验到精细控制网络流量带来的好处。但是，能力越大，责任越大。如果你有开发团队，那自然是好事。例如，谷歌推出了基于 OpenFlow 的广域网 B4，将其广域网的效率提升到近 100%。但对大多数其他公司而言，整体解决方案能为支持业务提供什么要比使用 OpenFlow 或其他特定协议更加重要。

　尽管这部分名为 OpenFlow，但在架构上，它是关于控制平面与数据平面的解耦。OpenFlow 只是用来实现这一功能的主要协议。

 

02.网络功能虚拟化

网络功能虚拟化（Network Functions Virtualization，NFV）这个概念并不复杂，就是将传统上用硬件实现的功能改用软件实现。最常见的例子是虚拟机，比如路由器、防火墙、负载均衡器、IDS/IPS、VPN、应用程序防火墙，以及其他的服务 / 功能。

有了 NFV，就能将价值数万或数十万美元的需要通过数百到数千行命令来进行配置的一体化硬件拆分为 N 款软件，也就是 N 个虚拟设备。从单个设备的角度来看，这些更小的设备更方便管理。

　上面的例子使用的是虚拟设备作为配有 NFV 的设备的实现形式。这只是一个例子。以软件方式部署网络功能可以有很多形式，其中包括嵌入进 hypervisor、容器部署，或者应用程序部署。

如果网络需要使用 3~5 年，那么硬件部署的方式也不是不常见，但要注意不断升级过程中的复杂度以及后续投入。所以，硬件不仅需要高额的投入，而且需要在需求增加之后应对“如果……怎么样”的场合。如果是部署基于软件或者 NFV 的解决方案，那么可以使用用多少，付多少的价格模式来提供更好的横向扩展方式，并减少网络或特定应用程序的错误域（failure domain）。举个例子，比起购买一整个 Cisco ASA，可以选择逐步置入 Cisco ASAv 设备，并根据业务增长需求购买。也可以使用更先进的技术（比如来自 Avi Networks 的技术）来轻松地扩展负载均衡器。

既然 NFV 的好处如此之多，那为什么这种类型的解决方案和产品没有更多地部署到生产环境之中呢？有一些解释可以回答这个问题。一方面，它需要重新思考网络是如何架构的。如果有一个一体化防火墙，那么所有的数据流都会经过这个防火墙，也就是说需要包括所有的应用程序和用户。如果不是所有的，则需要定义一个子集。在现代 NFV 模型中，可以部署很多个虚拟防火墙，也就是一个应用程序或租户就有一个防火墙，而不是以往的单个防火墙。这样，每个防火墙或是其他服务设备的错误域就会变得小很多，如果需要做出修改或者发布新的应用程序，则无须对其他应用程序或租户的防火墙做修改。

另一方面，在一体化设备的传统世界里，基本上只有单一的安全策略管理平台（一个 CLI 或者 GUI）。这样做会扩大错误域，但它能让管理员更好地处理安全协议，而且也只需要维护一个设备。根据维护这些设备的人员状况，他们可能还是会选择一体化的方案。这就是现实，但我们也希望随着时间的发展，会有更好的工具来辅助使用这些以软件为中心的解决方案。那时，我们将看到业界越来越多的部署是通过这种技术来实现的。事实上，在这个已经实现网络现代自动化操作和管理的世界里，从操作效率的角度去选择硬件结构并不是那么重要了，因为不管是选择使用单一设备还是大量设备，都可以实现高效管理。

除了管理，另外一个重要因素是，很多厂商没有很积极地销售它们的虚拟设备方案。不是说它们不提供虚拟设备方案，而是那些传统设备制造商不倾向于这么做。如果厂商在此前的几年里一直有硬件业务，那么更换到以软件为主导的模型下将是一个很大的转变。因此，很多厂商会限制基于虚拟设备的技术的性能和特性。

从许多这些技术领域中可以看出，NFV 的主要价值在于灵活性。消除了硬件，也就不用再花时间把机架、堆叠、电缆集成到现有环境，从而减少了提供新服务所需的时间。利用软件方法，加入新硬件变得就像在环境中部署新虚拟机一样快。这种方法与生俱来的优点在于能够克隆和备份虚拟设备，以便做进一步的测试，比如在灾难恢复（Disaster Recovery，DR）环境中。

最后，只要部署了 NFV，就不用再通过特定的物理设备来路由流量以获得所需的服务。

 

03.虚拟交换机

如今市面上常见的虚拟交换机包括 VMware 标准交换机（VMware Standard Switch，VSS）、VMware 分布式交换机（VMware Distributed Switch，VDS）、Cisco Nexus 1000V、Cisco 应用程序虚拟交换机（Application Virtual Switch，AVS）以及开源的 Open vSwitch（OVS）。

这些交换机时常被卷入 SDN 的讨论中，但事实上，它们都是基于软件的交换机，位于 hypervisor 内核中，用于提供虚拟机（现在还包括容器）之间的本地网络连通性。它们提供的 MAC 学习、链路聚合、SPAN、sFlow 等功能和特性在作为对手的物理交换机身上早已出现多年了。尽管这些虚拟交换机经常出现在更加全面的 SDN 和网络虚拟化解决方案中，但就其本身而言，它们恰好是运行在软件中的交换机。虽然虚拟交换机本身并非解决方案，但在我们这个行业前进的过程中是极其重要的。虚拟交换机在数据中心内创建了一个新的访问层，或者说是新的边界。网络边缘不再是硬件定义的灵活性有限的（就功能 /特性开发而言）物理架顶式（Top-of-Rack，TOR）交换机。由于新边缘是基于软件的（通过使用虚拟交换机），因此能够更轻松地在全网分发策略。例如，可以将安全策略部署到最接近实际端点的虚拟交换机端口（可以是虚拟机或容器），以进一步增强网络的安全性。

 

04.网络虚拟化

被归类为网络虚拟化的解决方案已经变成了 SDN 解决方案的同义词。就这一部分而言，网络虚拟化指的是基于叠加（overlay-based）的纯软件解决方案。属于此类的流行解决方案是 VMware 的 NSX、Nuage 的虚拟服务平台（Virtual Service Platform，VSP）和 Juniper 的 Contrail。

这些解决方案的一个主要特点是基于叠加的协议，比如用于建立基于 hypervisor 的虚拟机之间连通性的 VxLAN（Virtual eXtensible LAN，虚拟可扩展局域网）。这种连通性和隧道技术为位于不同物理主机的虚拟机之间提供了独立于物理网络的 2 层邻接关系，也就是说物理网络可以是 2 层，也可以是 3 层，或者是两者的结合。其结果就是一个与物理网络解耦的虚拟网络，旨在提供选择性和灵活性。

　值得指出的是，“叠加网络”（overlay network）一词经常与“底层网络”（underlay network）一词连用。为明确起见，底层是指用线缆相连的底层物理网络。叠加网络是采用网络虚拟化技术构建的，能够在数据中心内的虚拟交换机之间动态创建隧道。同样，这是指在基于软件的网络虚拟化解决方案环境中。还要注意到，现在部署的很多纯硬件解决方案也使用 VxLAN 作为叠加协议，在 3 层数据中心内的架顶式设备之间建立 2 层隧道。

尽管叠加技术属于网络虚拟化解决方案的实现细节，但这些解决方案远非是通过叠加将虚拟交换机接合在一起那么简单。这些解决方案通常内容全面，提供了安全性、负载均衡以及与物理网络的集成，所有这些都只需要一个管理点（也就是控制器）。通常情况下，这些方案还提供与最佳的 4~7 层服务公司的集成，对在网络虚拟化平台中部署哪种技术给出了选择。

敏捷性的实现还得益于中央控制器平台，该平台用于动态配置每台虚拟交换机，并根据需要配置服务设备。回想一下，由于 CLI 遍及现实世界的所有厂商，网络运维已经因此而落后了。在网络虚拟化中，不再需要手动配置虚拟交换机，因为每种解决方案都通过提供集中式 GUI、CLI 以及 API（能够以编程方式进行改动）简化了配置过程。

 

05.设备 API

在过去的几年间，厂商开始意识到，仅仅提供一个标准的 CLI 已经无法满足需要，而且 CLI 严重拖累了运维。但凡曾经使用过任何一种编程语言或脚本语言，你应该就能理解这一点。如果你还没有体会到，第7章会对此进行详述。

在对遗留的或基于 CLI 的网络设备编写脚本时，主要痛点在于这些设备无法返回结构化数据。这意味着脚本从设备得到的数据都是原始文本格式（就是 show version 输出的那种），你得单独编写脚本来解析文本，从中提取正常运行时间或操作系统版本等属性。只要 show 命令的输出稍微有点儿变化，脚本就会因为解析错误而无法工作。尽管所有管理员都用过这种方法，在技术上也不是不能实现自动化，但现在厂商已经逐渐向 API 驱动的网络设备迁移。

有了 API，则无须再去解析原始文本，因为网络设备返回的就是结构化数据，这大大减少了编写脚本所花费的时间。无须解析文本来查找正常运行时间或其他属性，设备返回的对象已经提供了你所需要的一切。这样不仅减少了脚本编写时间，降低了网络工程师以及其他非程序员的入门门槛，还提供了更整洁的接口，使得专业软件开发人员能够快速开发和测试代码，就像他们在非网络设备上使用 API 操作那样。“测试代码”可能意味着测试新的拓扑结构、验证新的网络特性、核实特定网络配置，等等。这些事现在都得手动完成，既耗费时间又容易出错。

在网络场景中，最先流行起来的一个 API 是出自 Arista Networks 的 eAPI，这是一套基于 HTTP 的 API，使用 JSON 编码的数据。不用担心，从第5章开始，我们就会介绍基于 HTTP 的 API 和 JSON。从 Arista 开始，我们看到 Cisco 已经在特定平台宣布了 Nexus NX- API 和 NETCONF/RESTCONF 等 API。像 Juniper 这样的厂商，一直以来都拥有可扩展的 NETCONF 接口，但是尚未引起大众太多的关注。值得一提的是，如今大多数厂商配备了某种 API。

第7章会更详细地介绍该主题。

 

06.网络自动化

随着 API 在网络世界里继续演变，更多利用这项技术的有趣用例也会层出不穷。在短期内，网络自动化是利用提供 API 的现代网络设备所公开的编程接口的主要候选对象。

放到更大的环境中来说，网络自动化不仅仅是自动化网络设备配置。的确，这是对于网络自动化最常见的认知，但使用 API 和编程接口可以实现自动化，提供的功能远不止于推送配置参数。

可以借助 API 简化访问隐藏于网络设备中的所有数据。想想这些数据：流数据、路由表、FIB 表、接口统计信息、MAC 表、VLAN 表、序列号，这份清单可以一直写下去。通过运用了 API 的现代自动化技术，能够立竿见影地协助管理网络的日常运作，进行数据采集和自动诊断。最重要的是，由于使用了能够返回结构化数据的 API，管理员得以对所需的确切数据集，甚至是来自各种 show 命令的输出，进行显示和分析，最终减少了在网络调试和故障排除上花费的时间。无须再为了验证配置或排除故障，尝试连接 N 个运行着 BGP 的路由器，你可以使用自动化技术简化此过程。

除此之外，利用自动化技术可以使整个网络更具可预测性和统一性。这一点可以通过自动创建配置文件、自动创建 VLAN 或自动故障排除体现出来。它简化了为所有用户支持指定环境的过程，每个网络管理员无须再掌握一套自己的最佳实践。

第2章会更为深入地介绍各种类型的网络自动化。

 

07.裸机交换

裸机交换（bare-metal switching）的话题也经常被划归于 SDN，但其实不然。它真的不是 SDN! 只是我们在尝试介绍各种被认为是 SDN 的技术趋势时，需要涉及这个话题。如果把时间退后到 2014 年（甚至更早），那时用于描述裸机交换的术语是白盒或商品交换。这个词现在已经变了，而且有充分的理由。

在介绍从白盒到裸机的转变之前，必须从高层次上理解这意味着什么，因为这是网络设备思维方式的巨大变化。在过去 20 年间，网络设备始终被视为物理设备——以硬件装置的形式出现，配备有操作系统以及在其上运行的应用程序。这些组件全部来自同一厂商。

在白盒和裸机网络设备中，设备看起来更像是 x86 服务器（参见图 1-3）。它允许用户分解所需的各个组件，从一家厂商那里购买硬件，从另一家厂商那里购买操作系统，然后搭载来自其他厂商甚至是开源社区的特性 / 应用程序。

图 1-3：传统交换栈和裸机交换栈一览

在大肆宣传 OpenFlow 的那段时期，白盒交换可是当时的热门话题，因为其目的就是硬件商品化，将网络的大脑中枢集中于 OpenFlow 控制器，也就是现今所说的 SDN 控制器。2013 年，谷歌宣布已经搭建了自己的交换机并使用 OpenFlow 对其进行控制。这在当时一度成了不少业内会谈的主题，但事实上，并非所有的最终用户都是谷歌，所以也不是所有的最终用户都会去搭建自己的软硬件平台。

与此同时，涌现出了一批专注于围绕白盒交换提供解决方案的公司，其中包括 Big Switch Networks、Cumulus Networks 和 Pica8。每家公司只提供纯软件解决方案，因此仍然需要能运行其软件的硬件，以提供端到端解决方案。这些白盒硬件平台最初来自 Quanta、Super Micro、Accton 等源头制造商（Original Direct Manufacturer，ODM）。即便你一直从事网络行业，也很可能从未听说过这些厂商。

直到 Cumulus Networks 和 Big Switch Networks 宣布与包括 HP 和 Dell 在内的公司建立合作关系，业界才开始改口将白盒称为裸机，因为现在的品牌厂商在其硬件平台上都支持 Big Switch Networks 和 Cumulus Networks 等公司的第三方操作系统。

可能还有人困惑，为什么裸机在技术上不属于 SDN，因为像 Big Switch Networks 这样的厂商在两个领域均有所涉猎。答案很简单。如果解决方案中集成了控制器，使用了 OpenFlow（不一定必须是 OpenFlow）等协议，采用编程方式与网络设备通信，那么这就具备了软件定义网络的特点。这正是 Big Switch Networks 所做的事情——在运行 OpenFlow 代理的裸机 / 白盒硬件上加载软件，然后与作为其解决方案组成部分的控制器进行通信。

另外，Cumulus Networks 提供了专门为网络交换机构建的 Linux 发行版。这种发行版，或者说操作系统，运行传统协议（比如 LLDP、OSPF 和 BGP），不需要控制器，对非 SDN 网络架构而言，更具可比性和兼容性。

知道了这些，事情就显而易见了：Cumulus Networks 是一家网络操作系统公司，在裸机交换机上运行自己的软件；Big Switch Networks 则是一家基于裸机的 SDN 公司，要求使用该公司的 SDN 控制器，但同时也利用了第三方的裸机交换基础设施。

简而言之，裸机 / 白盒交换就是一种分离（disaggregation），如果你选择这种做法，那么用户就能从一家厂商那里购买网络硬件，从另一家厂商那里加载软件。在这种情况下，管理员可以灵活地修改设计、架构以及软件，除了底层操作系统，无须再更换硬件。

 

08.数据中心网络 fabric3 架构

你是否曾经面临过这样的情况：即使网络中的各种网络设备都运行着标准协议（比如生成树协议或 OSPF），你也无法轻松地进行互换？如果答案是肯定的，那你不是孤军奋战。想象一下，有一个采用了塌缩式核心层设计的数据中心网络，每个机架的顶部都有独立的交换机。如果需要升级，那么升级流程是怎样的？

像这样的网络有很多种升级方式，但如果只是 TOR 交换机需要升级，并且在评估新的 TOR 交换机的过程中，决定选用新的厂商或平台呢？这绝对属于正常现象，而且会一次又一次地出现。过程很简单：将新交换机连接到现有的核心层（当然，假定核心层有可用的端口）并正确配置 802.1Q trunk（如果是 2 层互联的话）或路由协议（如果是 3 层互联的话）。

该谈谈数据中心网络 fabric 架构了。这是围绕数据中心网络的相关思路必须改变的地方。

数据中心网络 fabric 架构旨在改变网络运营商的思维方式，从管理单个硬件到管理整个系统。如果还是沿用先前的场景，那么我们不会选择把 TOR 交换机换成其他厂商的产品，因为这只是数据中心网络的一个组成部分。相反，当按照系统来部署和管理网络时，就需要有系统的思维。这意味着升级过程将是从一个系统迁移到另一个系统，或者从一种 fabric 迁移到另一种 fabric。在 fabric 的世界里，当需要升级时，fabric 可以被替换，但其中的单个组件不能被替换，至少在大多数情况下是这样。当特定厂商提供迁移或升级路径并使用裸机交换（仅更换硬件）时，这也许有可能。数据中心网络 fabric 架构的一些例子包括 Cisco 的 Application Centric Infrastructure（ACI）、Big Switch Networks 的 Big Cloud Fabric（BCF）以及 Plexxi 的 fabric 与超融合网络。

除了将网络视为系统，数据中心网络 fabric 架构还有以下一些常见属性。

•提供了包括策略管理在内的单一接口来管理或配置 fabric。

•在整个 fabric 中提供了分布式默认网关。

•提供了多路径能力。

•使用某种形式的 SDN 控制器来管理系统。

 

09.SD-WAN

近两年来，软件定义网络最热门的趋势之一是软件定义广域网（Software Defined Wide Area Networking，SD-WAN）。在过去的几年间，涌现出了越来越多的公司，旨在解决广域网的问题，其中包括 Viptela（最近被 Cisco 收购）、CloudGenix、VeloCloud、Cisco IWAN、Glue Networks 和 Silverpeak。

从帧中继迁移到 MPLS 依赖，WAN 还没有出现什么根本性的技术转变。由于宽带和互联网的成本仅为同等专线电路成本的一小部分，因此这几年利用站到站 VPN 隧道的情况与日俱增，为 WAN 接下来的大事件奠定了基础。

远程办公室的常见设计通常包括一条私有（MPLS）电路和一个公共互联网连接。当两者皆有时，互联网往往只作备用，专门用于访客流量，或是通过 VPN 回传到企业的一般数据，而 MPLS 电路则用于语音或视频通信等低延迟应用程序。当流量开始在电路之间划分时，路由协议配置的复杂性也随之增加，同时也限制了路由到目的地址的粒度。在决定最佳路径时，通常不考虑源地址、应用程序和网络的实时性能。

许多现代解决方案所使用的常见 SD-WAN 架构与数据中心使用的网络虚拟化架构类似：使用叠加协议来实现 SD-WAN 边缘设备之间的互联。由于使用了叠加协议，该解决方案独立于底层物理传输，因此使得 SD-WAN 可以在互联网或私有 WAN 上正常工作。这些解决方案通常运行于分支站点的两条或更多条互联网电路，使用 IPSec 对流量进行完全加密。此外，其中很多解决方案还会不断测量在用电路的性能，在性能不足的时候，为特定应用程序在电路之间快速地进行切换。由于具备应用程序层可见性，因此管理员也可以轻松地选择哪些应用程序应该采取哪条路由。在使用传统路由协议（比如 OSPF 和 BGP）的基于目的地路由（destination-based routing）的 WAN 架构中通常是找不到这类特性的。

从架构的角度来看，先前提到的 Cisco、Viptela、CloudGenix 等厂商的 SD-WAN 解决方案通常还提供了某种形式的零接触配给（Zero Touch Provisioning，ZTP）和含有门户（portal）的集中式管理，以 SaaS 应用程序的形式存在于企业内部或云端，极大地简化了 WAN 未来的管理和运维。

SD-WAN 技术带来了一个有价值的副产品：为最终用户提供了更多的选择，因为基本上任何运营商或任何连接类型都可以在 WAN 和互联网上使用。这样一来，它就简化了运营商网络的配置和复杂性，这反过来又会简化运营商的内部设计和架构，有望降低其成本。从技术角度再进一步讲，所有的逻辑网络构造 [ 比如虚拟路由与转发（Virtual Routing and Forwarding，VRF）] 都可以通过 SD-WAN 厂商提供的控制器平台用户界面（User Interface，UI）进行管理，再次避免了在需要变更时，还要等待数周的时间才能得到运营商的回复。

 

010.控制器联网

你可能也意识到了，其中一些发展趋势存在重叠。当你尝试了解过去几年中出现的所有新技术和趋势时，这也是令人困惑的一点。

例如，流行的网络虚拟化平台使用了控制器，一些划归于数据中心网络 fabric 架构、SD-WAN 和裸机交换机的解决方案也用到了控制器。是不是很困惑？你也许好奇为什么基于控制器的联网自身也出现了分歧。实际上，这通常只是反映了现代解决方案的交付特点和机制，但并不是之前所有的趋势都涵盖了控制器在技术方面能够提供的方方面面。

图 1-4 所展示的 OpenDaylight（ODL）是一款非常流行的开源 SDN 控制器。和很多其他控制器一样，ODL 是一个平台，而不是产品。这类控制器平台既可以提供专门的应用程序（如网络虚拟化），也可以与平台之上的应用程序联合用于网络监视、可视性、TAP 聚合或任何其他功能。这就是为什么说关键是要了解控制器在传统应用程序（fabric、网络虚拟化和 SD-WAN）之外还能提供什么。

图 1-4：OpenDaylight 架构

3fabric 有时会被翻译为“交换网格”或“交换矩阵”，但目前绝大多数文档直接使用原词。故本书中也选择保留英文不译。——译者注