VMware-NSX-网络精要-全-

VMware NSX 网络精要（全）

原文：annas-archive.org/md5/324a6acaf459cb02c5f900425de6f382

译者：飞龙

协议：CC BY-NC-SA 4.0

序言

NSX 通过在软件定义数据中心（SDDC）中引入安全性和自动化，彻底改变了数据中心网络。软件定义网络具有高度动态性，帮助组织扩展其数据中心。通过利用 VMware NSX 中丰富的功能服务，组织可以提高其资本支出（CAPEX）和运营支出（OPEX）。本书全面覆盖了 VMware NSX 提供的各种软件定义网络功能。

本书内容

第一章，网络虚拟化简介，本章从虚拟化的演变及软件定义数据中心的介绍开始，接着讨论网络虚拟化。我们还将讨论网络虚拟化如何通过各种用例和 VMware NSX 的功能，改变了传统数据中心的网络架构。

第二章，NSX 架构，理解 NSX 架构是了解 NSX 特性和各种用例的关键。本章将主要讲解管理平面、控制平面和数据平面架构，接着是 VXLAN 架构，这对于理解逻辑网络的创建以及在后续模块中排查虚拟网络问题至关重要。

第三章，NSX Manager 安装与配置，本章开始时介绍了成功安装 NSX 所需的所有要求，并按照逐步指引进行 NSX Manager、NSX Controller 和数据平面软件模块的部署与配置，涉及逻辑交换、路由和微分段。

第四章，NSX 虚拟网络与逻辑路由器，在前几章对 Overlay 网络有基本理解后，本章将讨论逻辑交换和分布式逻辑路由。我们从配置开始，逐步讲解如何部署逻辑交换机并在虚拟化层内建立一个简单的路由环境。

第五章，NSX Edge 服务，本章以介绍 NSX Edge 服务及其不同形态开始，随后讨论了 NAT、DHCP、负载均衡和路由等内容。通过掌握这些知识，本章将为您提供 NSX 在软件定义数据中心中提供的完整网络服务包。

第六章，NSX 安全特性，端到端的安全性是任何网络拓扑成功的关键。本章将介绍传统的网络安全方法以及 NSX 如何帮助在虚拟空间中更好地控制网络。分布式防火墙、服务组合器是本章的重点内容之一。

第七章，NSX 跨 vCenter，NSX 最令人兴奋的功能之一就是跨 vCenter 服务器。能够管理多个 vSphere 环境并利用 NSX 功能，改变了现代数据中心的游戏规则。本章将深入探讨 NSX 跨 vCenter 的架构和部署，以及支持本章中讨论拓扑的设计。

第八章，NSX 故障排除，本章将我们迄今为止学到的内容应用于识别和解决 NSX 安装、注册和日志处理步骤。章节的编排顺序与我们最初学习 NSX 架构的顺序一致——管理平面、控制平面和数据平面故障排除，随后是升级场景。

本书所需的内容

首先，我们需要 NSX Manager、vCenter Server 和带有本地/远程存储的 ESXi 主机。

请注意，要让 NSX Manager 参与跨 vCenter 的 NSX 部署，必须满足以下条件。

上述配置可以在嵌套的 ESXi 环境中进行配置和测试，然而强烈不建议在生产环境中以这种方式进行部署。

有关硬件兼容性的矩阵，请参考 VMware HCL 指南：www.vmware.com/resources/compatibility/search.php

本书的目标读者

如果你是网络管理员，想要找到一个既简单又强大的网络虚拟化解决方案，那么这本快速而实用的指南将是你的不二选择。

约定

在本书中，您会发现多种文本样式，用以区分不同类型的信息。以下是这些样式的一些示例及其含义说明。

文本中的代码词汇、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入以及 Twitter 用户名均按如下方式显示：“它所做的就是一个传统的广播，ff:ff:ff:ff:ff:ff（目标 MAC）。”

任何命令行输入或输出均按如下方式书写：

net-vdr –-route –l default+edge-19

新术语和重要词汇以粗体显示。屏幕上显示的词语，例如在菜单或对话框中，文本中也会以这样的形式出现：“从 NSX Manager，导航到管理IP 池并点击+按钮。”

注意

警告或重要说明会以类似于此的框框形式出现。

小贴士

小贴士和技巧以这种形式出现。

读者反馈

我们始终欢迎读者的反馈。告诉我们您对本书的看法——您喜欢或不喜欢的地方。读者反馈对我们非常重要，因为它帮助我们开发您能真正从中受益的书籍。如果您有任何意见反馈，请通过电子邮件发送至 feedback@packtpub.com，并在邮件主题中注明书名。如果您在某个领域拥有专业知识，并且有兴趣编写或参与撰写书籍，请参阅我们的作者指南，网址为www.packtpub.com/authors。

客户支持

现在您已经成为一本 Packt 图书的骄傲拥有者，我们为您提供了一些帮助，帮助您充分利用您的购买。

下载本书的彩色图片

我们还为您提供了包含本书中使用的截图/图表的彩色图片的 PDF 文件。这些彩色图片将帮助您更好地理解输出中的变化。您可以从www.packtpub.com/sites/default/files/downloads/VMwareNSXNetworkEssentials_ColorImages.pdf下载该文件。

勘误表

尽管我们已经尽力确保内容的准确性，但错误有时仍会发生。如果您在我们的一本书中发现错误——可能是文本或代码中的错误——我们将非常感激您能向我们报告。通过这样做，您可以帮助其他读者避免困扰，并帮助我们改进本书的后续版本。如果您发现任何勘误，请访问www.packtpub.com/submit-errata，选择您的书籍，点击勘误提交表格链接，并填写勘误详情。一旦您的勘误得到验证，您的提交将被接受，勘误将上传到我们的网站或添加到该书籍的勘误列表中。

要查看之前提交的勘误，请访问www.packtpub.com/books/content/support，并在搜索框中输入书名。相关信息将显示在勘误表部分。

盗版

互联网上的版权材料盗版问题在所有媒体中都在持续存在。我们 Packt 公司对版权和许可保护非常重视。如果您在互联网上发现我们作品的任何非法复制品，请立即向我们提供相关的地址或网站名称，以便我们采取必要的措施。

如发现涉嫌盗版的材料，请通过邮件联系我们，邮箱地址为 copyright@packtpub.com，并附上相关链接。

我们感谢您在保护我们的作者和我们为您提供有价值内容方面的帮助。

问题

如果您在本书的任何方面遇到问题，请通过邮件联系我们，邮箱地址为 questions@packtpub.com，我们将尽力解决问题。

第一章：网络虚拟化简介

从主机时代开始，服务器虚拟化就有了悠久的历史。然而，今天的数据中心利用虚拟化特性将物理硬件抽象化，形成一个资源池，包含 CPU、存储和内存等，供最终用户以虚拟机的形式使用。提高服务器资源利用率的最简单方法是通过虚拟化技术。服务器虚拟化的成功被誉为数据中心的变革性事件，主要是因为一台物理机器可以运行多个操作系统，而每个操作系统可以像独立的物理机器一样进行管理。这是一个非常简单但强大的解决方案。虚拟化有不同类型，比如服务器虚拟化、存储虚拟化、应用虚拟化、桌面虚拟化，而行业最新的流行词就是网络虚拟化。网络虚拟化已经存在了很长时间，VLAN、VPN、MPLS、VPLS 和 VSS 都是网络虚拟化的广泛应用示例。如果你曾在数据中心工作，你会同意，网络总是很难操作。网络架构师被迫执行手动配置，这导致配置 VLAN、ACL、路由、防火墙规则、QoS、负载均衡等。该模型的缺点是复杂且速度慢，在动态的云环境中，复杂度将进一步增加。

本章将涵盖以下主题：

• 传统网络模型

• 软件定义数据中心（SDDC）的三大支柱

• 引入 NSX-V 网络虚拟化平台

• 服务器虚拟化和网络虚拟化的强大功能

• 如何利用 NSX

• VMware NSX 特性

传统网络模型

传统的架构是建立在经典的三层层次结构之上的。为了冗余和可用性，每一层都会有一个或多个网络设备：

• 数据中心核心层：核心层是骨干层，通过与多个提供高速交换的聚合层设备互联，提供更快的包传输。最好在此层不要配置任何流量过滤功能。

• 聚合层：聚合层是核心层和接入层之间的中介。最好在此层配置路由和过滤策略。

• 接入层：接入层通常是终端用户设备直接连接到机架顶部（ToR）交换机或机架末端（EoR）的地方，具体取决于网络设计。

以下截图是经典三层网络架构的示例：

现在，让我们问自己以下几个问题：

• 如果我的网络、存储和服务器团队之间存在性能瓶颈，如何协作？

• 需要多少个 VLAN、STP、LACP 和路由配置？

• 应用需求的变化是否需要更改物理网络？

• 我是否需要重复进行初始配置，比如 VLAN、STP、LACP 和路由？

• 我的所有功能是否都依赖于硬件设备？

• 租户/虚拟机的隔离是否与 VLAN 相关？

• 我需要在将应用迁移到公共云之前重新设计我的应用吗？

• 将虚拟机从服务器迁移（VMotion）到另一台服务器是否需要改变物理网络配置？

• 我是否能从一个统一的管理界面中获得端到端的网络可视性？

• 防火墙功能是放置在机架外部还是机架内部？

上面的问答列表很长，确实，网络技术仍停留在过去，解决方案只有一个——是时候虚拟化网络了！

软件定义数据中心的三大支柱

在SDDC中，所有基础设施元素，包括存储、网络和计算，都完全虚拟化并以服务的形式交付。VMware 将其描述为“一个统一的数据中心平台，提供前所未有的自动化、灵活性和效率，改变 IT 交付方式。计算、存储、网络、安全性和可用性服务被池化、聚合并作为软件交付，由智能、基于策略的软件进行管理”。SDDC 是通过云服务高效交付的机制。SDDC 的一个关键目标是构建基于云的数据中心。像 Amazon、Google、IBM 和 VMware 这样的厂商都拥有基于 SDDC 架构的公共云服务。是的，现如今我们拥有了下一代数据中心，在这里我们可以将所有物理服务器池化，并根据 IT 定义的策略运行应用。

如标题所示，以下截图展示了软件定义数据中心（SDDC）的三大支柱：

让我们一一了解每个问题：

• 在计算虚拟化中，CPU 和内存从物理硬件中解耦，每个应用程序都驻留在一个叫做虚拟机的软件对象中。VMware VSphere、Microsoft Hyper-V、Citrix XenServer、Oracle VM 是这一类虚拟化的几个例子。

• 存储虚拟化在软件定义存储（SDS）环境中，是一种基于虚拟化管理程序的存储抽象，将物理服务器的异构模型转化为统一管理。使能 SDS 的软件提供了大多数传统存储阵列的功能，如复制、去重、精简配置和快照。由于这是完全的软件定义存储，我们提高了灵活性、管理的便捷性和成本效率。通过这种方式，池化的存储资源可以在软件定义的数据中心环境中，自动且高效地映射到应用需求上。VMware VSAN 是 SDS 的经典示例，因为它是一个分布式的软件层，原生运行于 ESXi 虚拟化管理程序的一部分。

• 网络虚拟化是软件定义数据中心（SSDC）的第三个也是最关键的支柱，提供一整套第 2 层到第 7 层的网络服务，如路由、交换、防火墙、负载均衡和服务质量（QoS），这些都在软件层实现。网络虚拟化是通过软件和网络硬件对网络资源进行虚拟化，使得网络资源的配置和部署变得更快速。软件的创新速度远远快于硬件，未来的答案不是硬件定义的数据中心，而是软件定义的数据中心，这将使我们能够跨物理数据中心扩展虚拟化层。使得亚马逊和谷歌成为世界上最大的数据中心的是软件定义数据中心的卓越性。网络虚拟化通过有效解决所有传统网络挑战，为我们提供了一个强大的基础，以确保我们获得一个完整的软件定义数据中心（SDDC）堆栈。随着云消费模型在行业中的快速采用，对计算、存储和网络资源按需配置的需求比以往任何时候都更强烈。网络虚拟化将网络和安全功能从物理硬件中解耦，允许我们在逻辑网络中复制相似的网络拓扑。

介绍 NSX-V 网络虚拟化平台

既然我们已经定义了网络虚拟化的概念，接下来我们来讨论 VMware NSX 及其历史。Nicira（NSX）是一家专注于软件定义网络和网络虚拟化的公司，由 Martin Casado、Nic Mckeown 和 Scott Shenker 于 2007 年创立。2012 年 7 月 23 日，VMware 收购了 Nicira，NSX 是从 VMware 的vCloud 网络安全（vCNS）和 Nicira 的网络虚拟化平台中创建的产品。截至目前，VMware NSX-v 可以与 vSphere、vCloud Director 和 vCloud Automation Center 进行集成，提供完整的私有云网络自动化。多种虚拟机管理程序环境，如 Xen 服务器、KVM 或 VMware ESXi，以及选择的云管理解决方案，如 vCloud 自动化中心、OpenStack 和 CloudStack，也可以与 VMware NSX 进行集成。本书仅介绍NSX-VMware（NSX-V）版本的 NSX，后续内容中将统一称 NSX-V 为 NSX。

服务器虚拟化和网络虚拟化的强大功能

服务器虚拟化是 21 世纪的主框架。虚拟化在现代商业中的一个关键用途是将现有的基础设施整合到更少的物理机器中。所有公司已经虚拟化了他们的基础设施，因为这是一个潜在的游戏规则改变者，能够让我们整合服务器和管理，部署也变得更简单。一个虚拟机管理程序（hypervisor）是一种软件，它允许我们运行多个虚拟机。以下是两种类型的虚拟机管理程序：

• 裸金属：裸金属或类型-1 的虚拟化管理程序是直接在硬件上运行的软件，例如，VMware ESXi、KVM、Citrix XenServer 和 Microsoft Hyper-V。

• 托管：托管或类型-2 的虚拟化管理程序运行在现有操作系统上。基本上，它们将客户操作系统与主机操作系统分离，例如，VirtualBox、VMware 工作站和 VMware 播放器。

类似于虚拟机的创建、监控和删除，NSX for vSphere 提供逻辑交换、虚拟化管理程序级路由、虚拟 NIC 级防火墙保护和层 4 至层 7 的负载均衡服务，这些都可以从单一控制面板中配置、监控和删除。因此，虚拟化网络相比传统的物理网络部署和管理，具有更好的可扩展性和成本效益。由于其与其他 VMware 产品（如 VRealize Automation 和 VCloud Director）的原生集成，客户通常会在大多数 VMware 环境中使用 NSX。

下图展示了服务器虚拟化和网络虚拟化：

如何利用 NSX

在利用 NSX 功能时，客户有以下三种选择：

• 在私有云中安装 NSX 并利用 NSX 功能。

  VMware NSX 可以与 vSphere、vCloud Director、vCloud Automation Center 和 VMware Integrated Openstack 进行集成。一个多虚拟化管理程序环境，例如 Xen Server、KVM 或 VMware ESXi^™，并结合如 vCloud Automation Center 这样的云管理解决方案。

• VMware vCloud Air 作为公共云，提供由 NSX 驱动的先进网络服务和安全功能。

  客户可以在与 vSphere 相同平台上构建的公共云中保护网络安全。通过最小化设计和网络拓扑的变化，将本地网络镜像到云中。在网络安全管理员熟悉的控制和构造下进行大规模管理，从而最小化操作中断和减少再培训需求。

• 对于真正的网络混合性，客户可以在私有云中使用 NSX，并在公共云中使用 VMware vCloud Air。

  云网络是云计算的一个重要组成部分，是混合云的基础。每个 vCloud Air 服务都包括与互联网的连接、一个或多个公共 IP 地址以及关键的网络功能，如负载均衡、防火墙、网络地址转换（NAT）和通过 Edge Gateway 的 VPN 连接。vCloud Air 中的 NSX 支持边界网关协议（BGP）和开放最短路径优先（OSPF）路由，以简化客户公共云工作负载与本地应用程序和资源的集成。

下图描述了相同的内容：

在私有云和公有云中提供丰富的网络和安全服务，确保两个环境都得到保护，最重要的是，在工作负载进出时无需修改任何应用程序。私有云与 NSX 和 vCloud Air 之间的其他集成和设计超出了本书的范围。我们将快速了解 NSX 特性，以及它们如何适应我们当前的数据中心部署场景。

理解驱动任何数据中心环境中网络流量的应用程序特性非常重要。传统的网络架构基于一系列交换机和路由器，这些类型的网络架构非常适合客户端-服务器环境。今天的应用程序工作负载非常需要减少通信时的跳数。在现代应用需求中，虚拟机之间需要在同一机架或不同机架上进行通信，然后再向数据中心外部的客户端发送回复包。工作负载正在从服务器内存转移到服务器闪存驱动器进行分析。大数据、虚拟化和云计算对这种流量类型有很大的推动作用。因此，我们肯定需要为这种大规模应用工作负载提供智能网络。网络虚拟化特性帮助解决了网络速度和灵活性不足的问题。

话虽如此，让我们来看一下以下图表，该图解释了数据中心环境中的流量类型。数据中心环境中的网络流量流动有两种类型：东西向和南北向：

让我们来看一个例子。假设我们有一个私有数据中心，并且需要从数据中心外部访问一些托管在虚拟化服务器中的应用程序：

• 东西向流量：同一数据中心内虚拟机之间的流量

• 南北向流量：进出数据中心的流量

VMware NSX 特性

VMware NSX 是用于软件定义数据中心（SDDC）的网络虚拟化平台，它是一种完全无中断的解决方案，通过软件重现整个网络基础设施，包括 L2-L7 网络服务。NSX 允许虚拟网络通过根据虚拟网卡的安全性维持细粒度的安全性，与物理网络连接：

让我们讨论 NSX 特性：

• 逻辑交换：NSX 允许创建逻辑交换机，这实际上就是 vSphere 端口组，用于工作负载隔离和逻辑网络之间 IP 地址空间的分离。这意味着，你不再受到 4096 个物理广播域的限制，主要得益于 VXLAN 覆盖网络。我们将在逻辑交换机模块中更详细地讨论 VXLAN，具体内容请参考第四章，NSX 虚拟网络与逻辑路由器。

• 网关服务：Edge Gateway 服务将你的逻辑网络与物理网络互联。这意味着连接到逻辑网络的虚拟机可以通过网关直接向物理网络发送和接收流量。Edge Gateway 提供了边界服务，如 DHCP、VPN、动态/静态路由、NAT、防火墙、负载均衡、DNS 转发和高可用性。

• 逻辑路由：NSX 逻辑路由功能允许虚拟化管理程序通过限制传统数据中心路由的北南方向，学习并在不同的逻辑网络之间进行路由。逻辑路由器还可以提供北南连接，允许访问物理网络中的工作负载。NSX Edge 支持静态和动态路由（OSPF、BGP、ISIS）。

• 逻辑防火墙：在 NSX 引入之前，从以边界为中心的安全防护转向每个虚拟机级别的保护是不可能实现的。这对按需云和 VDI 环境产生了重大影响。与传统的每数据中心级别的防火墙保护不同，逻辑防火墙提供每个虚拟机级别的保护，且可以通过几个点击创建和删除策略，即使虚拟机从一个主机迁移到另一个主机，策略也会保持不变。VMware NSX 允许我们使用分布式逻辑防火墙和 Edge 防火墙，在你的软件定义网络架构中使用。分布式逻辑防火墙允许你根据多个属性（不仅仅是 IP 地址和 VLAN，还包括虚拟机名称和 vCenter 对象）构建规则。Edge Gateway 提供防火墙服务，可以用于对北南流量施加安全性和访问限制。

• 可扩展性：利用 NSX 的可扩展性功能，可以将第三方 VMware 合作伙伴解决方案直接集成到 NSX 平台中，从而在多种服务选项中实现供应商选择。有许多 VMware 合作伙伴提供解决方案，如防病毒保护、IPS/IDS 和下一代防火墙服务，这些解决方案可以直接集成到 NSX 中，例如 Palo-Alto。除此之外，NSX 管理员可以从单一界面管理安全策略和规则。

• 负载均衡器：NSX Edge 提供多种网络和安全服务，逻辑负载均衡器就是其中之一。NSX 支持两种类型的逻辑负载均衡器：

  • 代理模式负载均衡器

  • 内联模式负载均衡器

    逻辑负载均衡器将传入请求分配到多个服务器上，实现负载分配，同时将此功能对终端用户进行抽象。为了确保应用程序最大限度的正常运行，我们可以为 NSX Edge 配置高可用性特性，从而将其转变为一个高可用的负载均衡器。

• 动态主机配置协议（DHCP）：NSX Edge 提供 DHCP 服务，支持 IP 地址池化和静态 IP 分配。管理员现在可以依赖 DHCP 服务来管理环境中的所有 IP 地址，而不需要维护单独的 DHCP 服务。该 DHCP 服务还可以将 DHCP 请求转发到现有的 DHCP 服务器。NSX Edge DHCP 服务能够将来自虚拟机的 DHCP 请求转发到预先存在的物理或虚拟 DHCP 服务器，且不发生任何中断。

• 虚拟私人网络（VPN）：Edge 提供 VPN 服务，可以为终端用户创建加密的安全连接，使其访问托管在私有云和公有云中的应用和工作负载。Edge VPN 服务提供 SSL-VPN Plus，支持用户访问以及基于 IPSEC 策略的站点到站点连接，确保两个站点之间的安全互联。

• 域名系统中继（DNS）：NSX Edge 提供 DNS 服务，可以将任何 DNS 请求转发到外部 DNS 服务器。

• 服务编排器：服务编排器使您能够为虚拟化基础设施中托管的应用程序配置并分配网络安全特性。每当虚拟机添加到虚拟网络中时，网络策略会自动应用到这些虚拟机上。

• 数据安全：NSX 数据安全功能提供对敏感数据的可视化，并确保数据保护，报告任何合规性违规情况。对指定虚拟机进行数据安全扫描后，NSX 可以分析并报告这些虚拟机的安全策略违规情况。

• 流量跟踪：流量跟踪是 NSX 6.2 中新增的功能，允许我们跟踪数据包从源头到目的地的路径。通过使用流量跟踪功能，我们可以监控链路利用率并排查网络故障。

• 流量监控：流量监控是一项流量分析功能，提供了每个会话传输的包数量、使用的端口等详细信息，随后管理员可以根据输出结果和业务需求允许或阻止相关操作。

• 活动监控：为了更详细地查看每个应用程序的状态，活动监控提供了极大的价值。通过这种方式，管理员可以监控用户和应用程序级别的信息。

以下功能在下方的框图中得到了完美总结：

VMware NSX 包括一套逻辑网络服务库——逻辑交换机、逻辑路由器、逻辑防火墙、逻辑负载均衡器、逻辑 VPN 和分布式安全性。你可以在隔离的软件虚拟网络中创建这些服务的自定义组合，这些虚拟网络能够支持现有应用而无需修改，或满足新应用工作负载的独特需求。

注意

NSX 6.2.3 是本文写作时的当前 NSX 版本。

总结

本章开始时，我们介绍了网络虚拟化和软件定义网络的概念。我们讨论了网络虚拟化的基本概念，并介绍了 VMware 的 NSX 网络虚拟化平台。接着，我们讨论了不同的 NSX 特性和服务，包括逻辑交换、逻辑路由、Edge Gateway 服务、可扩展性、服务编排器和数据安全性。

在下一章，我们将讨论 NSX 架构。

第二章. NSX 架构

在本章中，我们将对 NSX 架构进行高层次的讨论。为了正确安装和配置 NSX，我们应该了解涉及到 NSX 解决方案的核心组件。到本章结束时，我们将对以下方面有一个较为清晰的理解：

• 网络平面

• NSX 核心组件

• 确定控制器角色

• 控制器集群

• VXLAN 架构

介绍网络平面

在传统的交换机/路由器中，路由和数据包转发通常是在同一设备上完成的。这意味着什么呢？我们可以举一个配置路由器的经典例子。我们可能会配置 SSH 来管理路由器，然后再配置路由协议与其邻居交换路由。这些常见任务都是在同一硬件设备上完成的。因此，简而言之，每个路由器都会根据路由器的配置做出转发决策。软件定义网络的优势在于将转发平面和控制平面功能解耦到一个集中式设备，称为控制器，最终的结果是控制器维护转发信息并做出决策，而不是像传统方式那样逐跳转发。如图所示，网络的三个功能平面分别是管理平面、控制平面和数据平面：

网络的三个功能平面解释如下：

• 管理平面：管理平面是一个直观的概念：通过这块软件切片，我们可以进行变更并配置网络设备，使用如 SSH 和 SNMP 等协议来访问和监控这些设备。

• 控制平面：控制平面的经典示例是学习路由并基于路由算法做出决策。然而，控制平面功能不仅限于学习路由。控制平面还帮助与特定厂商的设备进行配对，并保护控制平面的访问，如 SSH 和 Telnet。

• 数据平面：数据平面流量通常由专用硬件设备执行，消耗少量计算资源。数据平面主要关注数据转发任务。

我知道我们大多数人可能会想，为什么在这里讨论网络平面。网络平面是 NSX 世界中的 DNA，三种平面共同构成了网络虚拟化层。

NSX vSphere 组件

NSX 使用管理平面、控制平面和数据平面模型。组件在下图中以示意图的形式展示：

管理平面

管理平面包含 NSX Manager 和 vCenter Server。需要了解的是，每个 NSX Manager 应只注册一个 vCenter Server。NSX Manager 为 NSX 提供管理 UI 和 API。我们将在 NSX Manager 安装和配置模块中讨论 NSX Manager 与 vCenter Server 的集成。一旦集成完成，NSX Manager 可以通过 vSphere Web 客户端进行管理，vSphere Web 客户端作为一个单一的管理界面，用于配置和保护 vSphere 基础设施。即时的好处是，网络管理员不再需要在多个管理控制台之间切换。所有网络服务都可以通过单一界面进行配置和监控。

控制平面

控制平面主要由 NSX 控制器和控制虚拟机组成，允许我们执行分布式路由。控制平面还支持无组播的 VXLAN 网络，这是早期 vCloud 网络与安全版本的一个限制。控制器维护 ARP、VTEP（VXLAN 隧道端点）和 MAC 表。NSX 逻辑路由器控制虚拟机和 VMware NSX 控制器是由 VMware NSX Manager 部署的虚拟机。用户世界代理（UWA）由 ESXi 主机上的 ntcpad 和 vsfwd 守护进程组成。NSX Manager 实例或 NSX 控制器实例与 ESXi 主机之间的 NSX 相关通信通过 UWA 进行。NSX 控制器集群以奇数个方式部署，最大支持的控制器数量为三。由于控制集群中的每个控制器同时处于活动状态，它确保即使某个控制器发生故障，控制平面仍然完好。控制器之间通过安全的 SSL 通道进行同步通信。控制器使用切片技术在控制器之间分配工作负载。请看下面的图，它是一个三节点控制器集群，其中切片技术在控制器之间分配工作负载：

重要的是要理解在每个控制器上运行着两种类型的应用程序：

• VXLAN：使得可以在网络中任何地方扩展一个二层 IP 子网，而不受物理网络设计的限制。

• 逻辑路由器：在逻辑空间内可以进行 IP 子网之间的路由，而无需流量经过物理路由器。这种路由直接在虚拟机监控程序内核中执行，并且 CPU/内存开销最小。这一功能为在虚拟基础设施中路由流量提供了最佳的数据路径。

这些应用程序的功能是学习并填充控制器表格，同时将学习到的路由分发给底层的 ESXi 主机。最后，即使管理平面发生故障，控制平面和数据平面的配置仍然保持完整——这就是软件定义网络的真正力量。

三节点控制器集群

在一个大规模的分布式系统中，有 n 个服务器时，确保一个特定的服务器能够对数据库执行写操作，或确保只有一个服务器是处理所有写操作的主服务器，是极其困难的。根本问题在于我们没有一个简单的方式来执行进程。我们如何解决这个问题呢？我们只需要提升一个服务器为主服务器，并与其他服务器达成共识。Paxos 是一个分布式共识协议，发布于 1989 年。该算法还确保每当服务器发生故障时，我们会进行领导者选举。Paxos 区分了提议者、接受者和学习者的角色，其中一个进程（服务器/节点）可以同时扮演一个或多个角色。以下是一些广泛使用 Paxos 算法的厂商，原因相同：

• VMware NSX 控制器在 NSX 控制器集群中使用基于 Paxos 的算法

• 亚马逊 Web 服务广泛使用 Paxos 算法为其平台提供支持

• Nutanix 实现了 Paxos 算法，以确保在 Cassandra（用于存储集群元数据）中保持严格的一致性

• Apache Mesos 使用 Paxos 算法进行其复制日志协调

• Google 使用 Paxos 算法为松耦合的分布式系统提供 Chubby 锁服务

• 许多 Azure 服务使用的 Windows fabric 利用 Paxos 算法实现集群节点之间的复制

为确保获取最高级别的可靠性，NSX 控制器以三节点集群的方式进行部署，因为控制器运行的是一种容错的分布式共识算法，称为Paxos。

控制器角色

NSX 控制器提供路由和逻辑交换功能的控制平面功能。每个控制器节点运行一组角色，这些角色定义了控制器节点可以执行的任务类型。一个控制器节点总共运行五个角色，它们如下所示：

• API

• 持久化服务器

• 逻辑管理器

• 交换机管理器

• 目录服务器

虽然每个角色需要不同的主节点，但重要的是要理解领导者是负责将任务分配给其他控制器的控制器。

以下图示描述了各个角色的职责：

如我们所知，三个节点控制器组成一个控制集群。我们将查看每个控制器的角色选举。每个角色都有一个主控制器节点，只有当某个给定角色的主控制器节点失败时，才会进行全集群范围的选举来选出新的主角色。这是三节点集群在企业环境中必不可少的主要原因之一，以避免出现分脑情况，这可能最终导致数据不一致，从而破坏整个控制平面的目的。在下图中，我们有一个正在运行的三节点控制集群，每个控制器都在运行主角色：

• 控制器 1：目录服务器主角色正在运行

• 控制器 2：持久性服务器主角色正在运行

• 控制器 3：API 和交换机管理主角色正在运行

数据平面

NSX 逻辑交换机、ESXi 虚拟化服务器、分布式交换机和 NSX 边缘设备都是数据平面组件。一旦管理平面启动并运行，我们就可以部署控制平面和数据平面软件及组件。在幕后，这三个 VMware 安装包（VIB）会被推送到底层的 ESXi 虚拟化服务器上：

1. VXLAN VIB

2. 分布式路由 VIB

3. 分布式防火墙 VIB

到目前为止，我们已经讨论了 NSX 世界中的管理平面、控制平面和数据平面组件；在接下来的模块中，我们将更详细地了解每一层的安装部分和设计规范。

覆盖网络

在物理网络之上构建的虚拟网络称为覆盖网络。这听起来熟悉吗？大多数企业环境会使用 VPN 技术来保护私有或公共网络，这是一种 IP-over-IP 的覆盖技术。然而，重要的是要理解，并非所有的覆盖网络都是建立在 IP 网络之上的。真正的问题是，为什么我们需要覆盖网络？如以下图所示，我们有两个数据中心，每个数据中心都遵循一个 spine-leaf 拓扑结构。在虚拟化基础设施中，灵活的工作负载部署和虚拟机迁移能力，以及为每个租户提供强大的多租户性，都是常见的需求：

VXLAN、MPLS、NVGRE、VPN 和 OTV 是一些经典的基于网络的覆盖网络例子。让我们回到服务器虚拟化的根源。服务器虚拟化将一台物理服务器虚拟化，并允许多个虚拟机在其上运行，每个虚拟机拥有自己的计算和存储资源。现在，每个虚拟机可能拥有一个或多个 MAC 地址，这最终会增加网络中的 MAC 表。加之，虚拟机的迁移迫使广播域扩展。传统的网络划分方式通常依赖于 VLAN。根据 802.1q 标准，VLAN 标签是一个 12 位的空间，最多可以提供 4,096 个 VLAN。对于当前的多租户云环境来说，这并不是一个可行的解决方案，因为在这些环境中，多个虚拟机可能驻留在同一台服务器上，需要网络隔离，而工作负载不断波动，这要求为未来增长配置多个 VLAN，且 VLAN 蔓延问题会基于工作负载的迁移而持续发生。覆盖网络通过提供独立于物理网络的第二层连接来缓解这个问题。我们都知道，新技术解决了许多问题；然而，它们总是伴随挑战。你能想象一个网络管理员在排查覆盖网络时会遇到多大的困难吗？相信我，当覆盖网络和物理网络之间的映射非常清晰时，故障排除会变得异常简单。基于 NSX-VXLAN 的覆盖网络是一种基于主机的覆盖网络，使用基于 UDP 的 VXLAN 封装。

VLAN 数据包

在尝试理解 VXLAN 之前，让我们回到 VLAN 数据包的基本概念。VLAN 数据包中的标记是如何工作的？其实很简单：4 个字节被插入到以太网头字段（IEEE），这 4 个字节由 2 字节的标签协议标识符（TPID）和 2 字节的标签控制信息（TCI）组成。优先级字段是一个 3 位字段，允许信息的优先级被编码到整个数据帧中，0 表示最低优先级，8 表示最高优先级。CFI 通常是一个用于以太网和令牌环网络之间兼容性的位，如果值为 0，则说明是以太网交换机。最后但同样重要的是，我们有 VLAN 字段——VID：

在交换机上创建 VLAN 的过程涉及定义一组交换机端口，并将终端设备连接到这些端口。它们都会成为该 VLAN 域的一部分，最终会阻止广播转发到另一组 VLAN。到目前为止，我们讨论的内容应该是我们在每一门网络课程中都会听到的内容。这只是为了确保我们永远不会忘记这些基本知识。现在我们可以继续讨论 VXLAN 了。

VXLAN 概述

VXLAN 是由 Arista、VMware、Cisco 和 Broadcom 等厂商开发的一项技术。每个 VXLAN 网络称为逻辑交换机（在 vCloud 网络安全解决方案中为虚拟线路），它们通过 24 位的段-ID 进行标识。通过这种方式，客户可以创建最多 1600 万个 VXLAN 网络。虚拟隧道终端节点（VTEP）是封装和解封装 VXLAN 帧的端点。接下来我们将了解 VXLAN 中的一些关键术语；之后我们将讨论 VXLAN 帧：

• VXLAN VIB：VXLAN VIB 或 VMkernel 模块在 ESXi 主机准备过程中由 NSX Manager 推送到底层虚拟化管理程序。

• Vmknic 适配器：虚拟适配器负责发送 ARP、DHCP 和组播加入消息。是的，会从 VTEP IP 池分配一个 IP（静态或动态）给 vmknic，这是 VXLAN 配置的前提条件之一。NSX 支持每个主机多个 VXLAN vmknic 以实现上行链路负载均衡功能。

• VXLAN 端口组：VXLAN 端口组在主机准备过程中预先配置，包括 NIC 聚合策略、VLAN 和其他 NIC 详细信息等组件和功能。

• VTEP 代理：VTEP 代理是一个 VTEP，它将 VXLAN 流量从另一个 VTEP 在远程段转发到本地段。NSX 使用三种 VXLAN 模式：单播、组播和混合模式。在单播模式下，VXLAN VTEP 代理称为 UTEP，在混合模式下称为 MTEP。

• VNI：VXLAN 网络标识符（VNI）或段 ID 类似于 VLAN 位字段；然而，VNI 是一个 24 位的地址，添加到 VXLAN 帧中。VNI 是 VXLAN 帧中的关键元素之一，因为它像 VLAN ID 唯一标识 VLAN 网络一样，唯一标识 VXLAN 网络。VNI 的编号从 5000 开始。

• 传输区：传输区基本上是定义 VXLAN 边界或域的集群或集群组。根据 NSX 设计，传输区可以是本地的或是多 VC 部署的通用区域。

VXLAN 帧

以下是 VXLAN 帧的主要组成部分及其图示：

• 外部以太网头（L2 头）：外部以太网头中的目标 MAC 地址可以是下一个跳跃路由器的 MAC 地址或目标 VTEP 的 MAC 地址，而源外部 MAC 地址将是源 VTEP 的 MAC 地址。

• 外部 IP 头（L3 头）：相应的 VTEP 源 IP 和目标 IP 将被填充到外部 IP 头中。

• 外部 UDP 头（L4 头）：外部 UDP 头由源端口和目标端口组成。IANA 为 UDP 指定了值 4789，但 VMware NSX 默认的 UDP 端口是 8472。因此，允许在物理/虚拟防火墙设备中开放端口 8472 以支持 VXLAN 流量是非常重要的。

• VXLAN 头：这是一个 8 字节的字段，包含 VXLAN 标志位、段-ID 和保留字段：

既然我们已经讨论了 VXLAN 数据包格式，接下来让我们继续查看内部以太网帧。

内部以太网帧

以下是内层以太网帧的主要组成部分以及对应的图示：

1. 帧校验序列（FCS）：FCS 是帧末尾的一个字段，用于存储循环冗余检验（CRC）信息。CRC 是一种算法，每次构建帧时都会运行，根据帧中的数据进行计算。当接收主机接收到帧并运行 CRC 时，结果应该是相同的。如果不同，帧将被丢弃。

2. 以太网有效载荷：帧的长度非常重要，无论是最大帧还是最小帧大小。以太网有效载荷字段是一个长度字段，用于限定数据包的长度。

3. 内层源 MAC 地址：内层源 MAC 地址将是连接到 VXLAN 网络的虚拟机的 MAC 地址。

4. 外部目标 MAC 地址：外部目标 MAC 地址将是目标虚拟机的 MAC 地址。稍等一下：如果虚拟机不知道目标虚拟机的 MAC 地址该怎么办？这里并没有什么复杂的原理。它所做的只是一个传统的广播，ff:ff:ff:ff:ff:ff（目标 MAC），这是广播地址，会广播到网络中的每个网络适配器，稍后这个完整的 L2 帧会在离开虚拟化主机之前被封装上 VXLAN 帧。

VXLAN 数据包的生命周期

如果我们需要了解一系列数据包从源主机如何到达目的地，无论是在单播、多播还是广播域中，我们只需进行一个简单的数据包过程。在以下示例中，如果VM-A第一次在 VXLAN 域中与VM-B通信，封装和解封装过程是如何进行的？

下图展示了如何操作：

现在让我们逐步了解这些步骤：

1. VM A-192.168.1.1，MAC-A 在 ESXi 主机 A 上生成一个广播帧（Layer 2 广播帧）。

2. 主机 A 上的 VTEP A 将广播帧封装到 UDP 头部，目标 IP 根据 VXLAN 复制模式（单播/多播 IP）而定（Layer 2 头部被封装进 VXLAN 头部）。

   注意：

   我们将在第四章中详细讨论 VXLAN 复制模式，NSX 虚拟网络与逻辑路由。

3. 物理网络将数据包传递给主机，因为它是我们在 VXLAN 复制模式中定义的多播组或单播 IP 的一部分。

4. 主机 B 上的 VTEP B 将查看 VXLAN 头（24 位），如果与 VTEP 表条目匹配，则移除 VXLAN 封装头，并将 Layer 2 数据包传递给虚拟机。

上述四个步骤是一个简单的数据包过程，展示了虚拟机如何在 VXLAN 网络中通信。然而，我还没有解释 ARP 抑制和 VTEP 表学习的内容，因为我希望在 NSX 虚拟网络和逻辑路由器部分来进行讲解。

思考一下，检查在什么情况下，即使虚拟机连接到 VXLAN 网络，也不会发生任何封装和解封装。这里没有脑筋急转弯。如果两台虚拟机位于同一个 ESXi 主机和相同的 VXLAN 网络上，它所做的仅是传统的二层学习，并没有封装或解封装。这些是非常重要的点，因为当由于 VXLAN/物理网络问题导致虚拟机间无法通信时，能够帮助我们解决很多故障排除问题。我相信我们在 vSphere 环境中已经做过这样的故障排除。

总结

我们以简要介绍 NSX 核心组件开始本章，并查看了管理、控制和平面组件。接着，我们讨论了 NSX Manager 和 NSX Controller 集群，随后进行了 VXLAN 架构概述讨论，我们分析了 VLAN 和 VXLAN 数据包，并进行了简单的数据包步进。现在我们已经熟悉了核心组件及其功能。

在下一章，我们将讨论 NSX Manager 的安装和配置。

第三章：NSX Manager 安装与配置

本章介绍了 NSX Manager 安装的前提条件和安装步骤。以下是我们将讨论的关键点：

• NSX Manager 要求

• NSX Manager 安装

• NSX Manager 设计考虑

• 控制器要求

• NSX 控制器部署设计考虑

• NSX 数据平面安装

NSX Manager 要求

VMware NSX Manager 是一个预配置的虚拟设备，我们可以像下载任何其他 VMware 软件一样，从 VMware 网站上下载。这个预配置的虚拟机配备了 16 GB 内存、4 个 VCPU 和 60 GB 存储空间。

让我们快速查看 NSX Manager 6.2 安装的前提条件：

• VMware vCenter Server 6.0

• VMware ESXi 6.0

• 准备好 NSX 6.2 的主机集群

• 支持的 vSphere 分布式交换机，适用于相应版本的主机和虚拟中心

• 确保我们有共享数据存储，可以利用 vSphere HA/DRS 功能来防止 NSX Manager 虚拟机的停机时间

• 确认我们是否使用双栈或仅 IPV4/IPV6 网络

• 收集网关、DNS、Syslog 和 NTP 服务器配置

• 所有端口要求已在 VMware 公共知识库文章 kb.vmware.com/kb/2079386 中更新。

下载 NSX Manager OVA 后，我们将按照以下四个步骤进行管理软件的安装和配置：

1. 部署 NSX Manager OVA 文件

2. 登录到 NSX Manager

3. 建立 NSX Manager 和 vCenter Server 的连接

4. 配置备份选项

话虽如此，让我们开始安装过程。根据我的经验，我可以自信地说，部署任何虚拟设备都是一项非常简单的任务。然而，当事情变得奇怪时，我们不得不回头查看部署过程，结果发现大多数问题都是我们在安装过程中完全忽视的——我们只是点击了 下一步 和 完成 按钮。

NSX Manager 安装

安装 NSX Manager，请执行以下步骤：

1. 通过 VMware Web 客户端打开 vCenter。

2. 选择 虚拟机和模板，右键点击数据中心，选择 部署 OVF 模板。

3. 粘贴 VMware 下载 URL 或点击 浏览 选择计算机上的文件。

4. 点击复选框 接受额外配置选项。

   这允许你在安装过程中设置 IPv4 和 IPv6 地址、默认网关、DNS、NTP 和 SSH 属性。如果在部署过程中未设置这些配置，我们可以在部署后随时进行设置。

5. 接受 VMware 许可协议。

6. 编辑 NSX Manager 名称（如有需要）。选择部署 NSX Manager 的位置。

7. 该名称将出现在 vCenter Server 清单中。

8. 你选择的文件夹将用于为 NSX Manager 应用权限。

9. 选择一个主机或集群来部署 NSX Manager 设备。我更倾向于选择一个集群，然后让 DRS 决定将设备放置在哪个主机上。

10. 将虚拟磁盘格式更改为厚预配，并为虚拟机配置文件和虚拟磁盘选择目标数据存储。

11. 选择 NSX Manager 的管理端口组。

最后，在配置完所有选项后，检查屏幕，可以看到这是一个仅支持 IPV4 的部署。所以要集中注意力，再次检查屏幕，如果需要做任何修改，我们应该回到前一步进行修正。

现在我们已成功部署 NSX Manager，值得再次确认所有配置是否完好无损，并且管理设备能够与 DNS、NTP、网关、ESXi 主机和 VC 进行通信。这是一个非常重要的步骤，因为管理设备与这些组件之间的任何通信问题都会直接影响 VMware NSX 功能的正常运行/部署。

下图显示了 NSX Manager OVF 的详细信息：

我们先记录下前面图片中的关键配置细节，然后我会解释选择这些配置的设计决策。

理解关键配置细节

如我之前所说，在部署 NSX Manager 设备时，我们需要注意几个关键的设计因素。接下来我们详细讨论一下。

目标 - 管理和边缘集群

管理和边缘集群是 vSphere 中的专用集群，建议始终为所有管理组件部署一个独立的集群，这样可以在不影响计算集群的情况下轻松进行集群升级，计算集群是专门用于部署最终用户虚拟机的。在这个示例中，我们有一个预配置的 vSphere 集群。我们将利用这个集群来部署以下组件：

• NSX Manager

• NSX 控制器

• Vcenter Server

• 任何其他第三方或 VMware 管理软件

但请记住，NSX 可以与多种 VMware 产品集成，例如 Horizon View、SRM、vCloud Director、VRA、VIO 和 VCO。因此，根据产品集成类型和数据中心设计，某些情况可能要求有多个管理集群用于隔离。例如，如果在主站点有两个 vCenter Server，一个用于与 NSX 集成的 vSphere，另一个用于与 SRM 集成的 vCenter Server，那么创建两个独立的管理集群是可以的。再次强调，这是一种设计选择，取决于我们是否愿意将所有资源集中在一个集群中，或者是否愿意将它们分布在不同的集群（机架）中。

网络映射

我们已将 NSX Manager 连接到一个名为Mgmt_VDS_MGT的 vSphere 分布式交换机端口组。这些是预先配置的端口组，理想情况下会配置一个 VLAN 端口组。我们可以为管理和边缘集群创建一个单独的分布式交换机，或者可以使用一个跨多个集群的单一分布式交换机。首选的部署方法是使用独特的分布式交换机，因为这将成为管理虚拟机的 VMotion 边界。是的，我们不希望为这些虚拟机进行分布式资源调度器（DRS）或手动迁移，以便将其移动到任何其他计算集群，因为这样会违背为管理和计算机器创建独立集群的目的。此外，基于物理网络设计，假设如以下截图所示，我们为管理和边缘集群配置了一个位于单个机架上的顶层交换机。TOR 交换机中的任何网络级更改都不会影响计算集群。我们是计划使用 LACP、静态 EtherChannel 还是类似虚拟 PortChannel 的配置？需要注意的是，LACP 配置应该在来自同一分布式交换机的所有端口组中保持一致。下图展示了一个典型的 NSX 企业 vSphere 设计，具有单独的计算、管理和边缘集群：

带顶层交换机设计的计算和边缘集群

在确认所有初始配置完好无损后，我们可以通过支持的 Web 浏览器登录到 NSX Manager，如下方截图所示：

NSX Manager 初始屏幕

从前面的图片中，我们可以看到 NSX Manager 的初始页面，我认为 vCloud 网络安全和 NSX Manager 初始页面之间有显著的区别：所有选项都排列得井井有条，并有简明的解释。默认情况下，我们可以使用以下凭据登录到 NSX Manager。NSX Manager 的默认用户名和密码如下：

• 用户名：admin

• 密码：default

出于安全加固的目的，我们可以随时更改密码并创建多个用户进行管理访问。从前面的图片中，我们可以看到在右上角有 NSX Manager 的初始配置，以及 NSX 的版本号 6.2 和构建号。

NSX Manager 虚拟设备管理

让我们讨论在前面的 GUI 中列出的不同选项。所有这些都是 NSX 设备配置和集成的关键选项：

• 查看摘要：查看摘要页面为我们提供了 NSX Manager 的完整配置摘要。包括虚拟设备 DNS、IP、版本、运行时间/当前时间，以及常见的组件和管理服务，如下方截图所示：

  NSX Manager 摘要

  看一下前面的屏幕截图，我们可以解读出 vPostgres、RabbitMQ 和管理服务应该正在运行。RabbitMQ 服务器是一个托管在 NSX 管理器上的进程，它们通过消息总线与运行在 ESXi 主机上的防火墙守护进程 (vsfwd) 进行交互。我们将在第六章 配置和管理 NSX 网络服务 中更详细地讨论 vsfwd；不过，目前我们需要了解这个服务的重要性以及它们在 NSX 环境中的通信方式。Postgres 是 NSX 管理器数据库，它随设备一起提供。因此，需要特别注意通过任何方法编辑或更改数据库中的表将直接影响系统，强烈建议在 VMware 支持团队的帮助下执行此类操作。

• 管理设备设置：管理设置对于对 NSX 管理器进行任何配置更改将极为有用。例如，如果配置了一个新的 Syslog 服务器，并且我们希望将新的 Syslog 服务器与当前的 NSX 管理器一起配置，我们可以通过编辑Syslog 服务器标签轻松更新这些更改。在早期版本的 NSX 中，默认情况下禁用了 SSL。但是，从 NSX 6.1 版本开始，SSL 默认启用。所以让我们看一下以下屏幕截图，它显示了 NSX 管理器的常规设置：

  设置 NSX 管理器的时间设置、Syslog 服务器和区域设置

• 管理 vCenter 注册：NSX 管理器和 vCenter 服务器之间是一对一的关系。在跨 vCenter 服务器的 NSX 安装中，这是最容易混淆的主题之一，因为我们认为多个 vCenter 可以通过一个 NSX 实例来支持，这是完全错误的。NSX 6.2 允许你通过单个主 NSX 管理器来管理多个 vCenter NSX 环境。即使在跨 vCenter 服务器的 NSX 安装中，NSX 管理器与 vCenter 服务器之间的关系仍然是一对一的。关于跨 vCenter 安装的更多内容将会在第七章中讨论，NSX 跨 vCenter，NSX-v 跨 vCenter 功能和设计决策。

将 vCenter 服务器与 NSX 管理器注册

我们将快速进行将 NSX 管理器与 vCenter 服务器注册的操作，按照以下步骤进行。NSX 管理器注册的流程：

1. 首先，登录到 NSX 管理器虚拟设备。

2. 在设备管理下，点击管理设备设置。

3. 我们需要输入 vCenter 服务器的 IP 地址。

4. 输入 vCenter 服务器的用户名和密码。

5. 点击 OK。

6. 等待几秒钟以确保成功连接到 vCenter 服务器。

将 SSO 与 NSX 管理器注册

对于 单点登录（SSO）服务与 NSX 的集成，我们需要配置查找服务，这将增强 vCenter 用户身份验证的安全性，并使得 NSX 能够从身份服务（如 AD、NIS 和 LDA）进行身份验证。

查找服务注册过程：

1. 登录到 NSX Manager 虚拟设备。

2. 在 设备管理 下，点击 管理设置。

3. 点击 NSX 管理服务。

4. 点击 编辑，位于 查找服务 旁边。

5. 输入具有查找服务的主机的名称或 IP 地址。

6. 如有需要，更改端口号。默认端口为 7444。

7. 查找服务的 URL 会根据指定的主机和端口显示。输入 vCenter 管理员用户名和密码。

8. 这使得 NSX Manager 能够将自身注册到安全令牌服务服务器。

9. 点击 确定。

10. 确认查找服务状态已连接。

下图显示了查找服务成功注册以及 vCenter 服务器为 NSX Manager 注册的情况：

现在是时候探索其他 NSX Manager 设置，例如技术支持日志、升级和恢复管理设备：

• 下载技术支持日志：出于诊断目的，我们可以通过点击 下载 按钮下载 NSX Manager 日志，该按钮位于 NSX Manager 虚拟设备管理 下。

• 备份与恢复：NSX Manager 数据，包括系统配置、事件和审计日志表（存储在 Postgres 数据库中），可以随时通过在 NSX Manager 图形界面执行按需备份来进行备份。还可以安排定期备份（每小时、每天或每周）。

• 升级：根据 NSX Manager 或 vCloud 网络安全解决方案的版本，我们可能需要升级管理平面。下载升级包后，我们需要将其上传到 NSX Manager-Upgrade-Upload New Bundle 标签，然后点击 升级。请注意，升级 NSX Manager 不会升级控制平面或数据平面组件。

请记住，我们使用管理员角色账户将 vCenter 服务器注册到 NSX。另外，请注意，密码中的 ASCII 字符会导致与 NSX Manager 的同步问题。成功将 NSX Manager 注册到 vCenter 服务器后，我们可以通过 VMware Web 客户端管理 NSX Manager，并且在 Web 客户端的库存中会看到 网络与安全 解决方案，如下图所示：

最后，让我们为 NSX Manager 分配许可证。

使用 vSphere Web 客户端登录 vCenter 服务器，并执行以下步骤：

1. 在中间窗格中，点击 解决方案 标签。

2. 选择 NSX for vSphere 解决方案。

3. 点击 分配许可证密钥 链接。

4. 在 分配许可证密钥 面板中，从下拉菜单中选择 分配新许可证密钥。

5. 在许可证密钥文本框中，输入或粘贴您的 NSX for vSphere 许可证密钥。

6. 点击确定。

VMware NSX 的多虚拟化平台许可证密钥也可用于授权 VMware NSX for vSphere。

NSX 管理器部署注意事项

由于 NSX 在 vSphere 环境中扮演着关键角色，因此了解和实施 NSX 管理、控制平面和数据平面功能至关重要。NSX 管理由 NSX 管理器提供，它为配置所有 NSX 功能提供了一个单一的入口点。此外，我们还可以利用 REST-API 调用进行部署、配置及其他任务。那么，接下来我们来谈谈从管理平面到其他组件的通信渠道。

通信路径

以下列表展示了 NSX 管理器与各个组件之间的通信路径：

• NSX 管理器到 vCenter Server：管理器与 vCenter 之间的通信通过 vSphere API 实现。

• NSX 管理器到控制器：管理器与控制器之间的通信通过 HTTPS 实现。

• NSX 管理器到 ESXi 主机：管理器与底层 ESXi 主机之间的通信通过消息总线进行。

网络和端口要求

作为管理平面一部分的 NSX 管理器虚拟机，通常 NSX 管理器和 vCenter 会放置在同一个管理网络（vSphere PortGroup）中。我知道大多数架构师会好奇，是否可以将 NSX 管理器和 vCenter Server 放置在隔离的网络（不同子网）中？答案是可以，它们可以位于不同的网络中，甚至不同的 VLAN 中。

如下截图所示，NSX for vSphere 的协议和端口要求已更新：

确保网络中允许所有这些端口和协议。

用户角色和权限

首先，NSX 角色和权限与 vCenter Server 角色和权限完全不同。因此，确保用户访问安全是非常重要的。通过基于角色的访问控制（RBAC），我们可以保障用户访问的安全。除此之外，在正确配置 NSX 管理器的查找服务后，我们还可以利用 vCenter SSO 身份源的用户和组。NSX 提供了范围限制功能，用于限制用户可以访问的 NSX 系统区域：

• 全局：用户可以访问 NSX 的所有区域。

• 限制访问：用户仅能访问用户配置文件中定义的 NSX 区域。

各种用户角色如下：

• 企业管理员：NSX 操作和安全管理。

• NSX 管理员：仅限于 NSX 操作，例如安装虚拟设备、配置端口组等。

• 安全管理员：对 NSX 安全区域具有读写访问权限，例如定义数据安全策略、创建端口组和创建 NSX 模块的报告，并对其他区域具有只读访问权限。

• 审计员：对所有区域拥有只读访问权限。

用户在没有角色的情况下无法定义。为用户分配角色后，可以更改该角色。这些角色在为 NSX 用户授予权限时极其重要，确保我们只为非企业管理员帐户提供有限的访问权限。

控制器要求

既然我们已经明确了管理器部署和设计决策，让我们讨论一下控制器的要求。NSX 控制器也作为虚拟设备进行部署，每个控制器都有默认的计算资源。由于我们已经将 NSX 管理器与虚拟中心注册，并确保我们已打开端口和协议，我再次强调为什么需要控制器：

• VXLAN 单播和混合模式复制

• 分布式逻辑路由

由于 NSX 控制器是具有控制平面智能的虚拟机，从网络需求的角度来看，它们需要有一个 IP 地址。然而，我们并不依赖传统的手动或 DHCP 自动发现过程来分配 IP 地址。在部署控制器之前，让我们先配置 IP 池。

控制器 IP 池创建过程

IP 池用于为控制器和VXLAN 隧道端点（VTEP）分配 IP 地址。我特别喜欢这个功能，它减少了手动操作的过程。我们只需要创建一个 IP 池，控制器在创建时会从池中选择一个 IP 地址；而且，在删除时，它也会释放一个 IP 地址：

1. 从vCenter Server Web 客户端中，导航到网络安全，在管理下选择分组对象，如下图所示：

2. 点击+图标，我们需要配置一个静态 IP 池，以便各个控制器能够从这个池中选择一个 IP 地址，如下图所示：

3. 现在我们已经准备好 IP 池，可以返回到 NSX 主页面，并点击NSX 控制器节点下的+号，如下图所示：

4. 分别选择并更新vCenter 数据中心、集群/资源池、共享的数据存储位置、vSphere 网络组（PortGroup）以确保连通性，最后选择我们在步骤 2 中创建的IP 池名称。完成此任务后，您将看到以下截图：

5. 在第一个控制器部署完成后，我们可以通过相同的步骤再部署两个控制器，因为三节点控制集群是强制性的。

6. 成功部署的控制器将显示正常状态，并且会有一个绿色的勾选标记，如下图所示：

让我们记录下所有三个控制器的 IP 地址：

• 控制器 1：192.168.110.201

• 控制器 2：192.168.110.202

• 控制器 3：192.168.110.203

即使我们已经部署了控制器并且状态为绿色，仍然需要从命令行检查控制集群连接及其状态，这将提供更为详细的信息。SSH 到所有三个控制器并发出以下命令：

 Show Control-cluster status
    # Command to Check Controller Status and ID 

控制器类型及其状态解释如下：

• 加入状态：验证控制器节点是否报告加入完成

• 大多数状态：验证控制器是否已连接到集群的大多数节点

• 集群 ID：集群中的所有控制器节点应具有相同的集群 ID

记得我们在 第二章 讨论的控制器角色吗？NSX 架构？是的，这些就是五个角色，它们在这里填充，如下面的截图所示：api_provider、persistence_server、switch_manager、logical_manager 和 directory_server：

好的，这一切都很棒，但我知道我们还有一些问题。让我们逐一看一下这些问题。

我们如何检查哪些控制器是这些角色的主控？

以下命令将为我们显示该输出：

Show Control-Cluster roles

让我们对其中一个控制器进行随机检查，在这个例子中是 控制器 2，其 IP 地址为 192.168.110.202。从下面的截图可以看到，除了持久化服务器，所有角色在控制器 192.168.110.202 上都是主控：

SSH 会话 NSX 控制器

控制器集群的大多数领导者监听端口 2878，并在 listening 列中显示 Y。要检查这一点，我们在步骤 2 中检查的同一控制器 192.168.110.202 上发出以下命令：

 S**how Control-Cluster Connections** 

我们得到了以下输出：

这看起来有点奇怪吗？

我们知道控制器集群的大多数领导者监听端口 2878，并且对于控制器 192.168.110.202 的持久化服务器，在 listening 列中会显示 **-**。这里没有什么难度；根据我们在第 7 步中测试的 Show Control-Cluster roles 输出，除持久化服务器角色外，控制器集群 2 的其他所有角色都是主控，因此 Show Control-Cluster Connections 报告持久化服务器的状态为 -。我希望我们现在对控制器角色有了基本的了解。我们将在 第八章，NSX 故障排除 中讨论一些故障排除场景。

NSX 控制器设计考虑因素

NSX 控制器虚拟机是控制平面的核心，因此决定安装和连接控制器的位置非常重要。最后，我们不希望控制器暴露给利用 NSX 特性的用户；基本上，不允许控制平面受到攻击。

通信路径

了解 NSX Manager、控制器和 NSX Edge 之间使用的通信协议是很有帮助的：

• 控制器和 NSX Manager 之间的通信 - HTTPS

• Edge 和控制器之间的通信 - HTTPS

网络和端口要求

确保满足以下截图中提到的端口要求，以支持控制器之间的通信：

控制器部署注意事项

我知道，我一直在告诉你：NSX 的真正强大之处就在于控制器。我们如何部署控制器、实施哪些最佳实践，都在 NSX 设计中起着至关重要的作用。你现在应该明白，由于覆盖网络，我们可能需要在物理和虚拟环境中实施大量设计最佳实践。但在这里，我们将讨论控制器部署的注意事项：

• 首先，NSX 控制器应该部署在与 NSX Manager 注册的同一个 vCenter 中。唯一的例外是采用跨 vCenter 的 NSX 设计，我们将在第七章中讨论 跨 vCenter 的 NSX。

• 在部署控制器时，不要进行其他配置更改，也不要部署其他 NSX 功能。即使是在故障修复场景中删除一个控制器并部署新控制器时，这个规则依然适用。

• 对于控制器部署，建议使用单独的 vSphere Edge 集群。对于小规模部署，将控制器部署到管理集群中也是可以的。

• NSX 控制器应该能够与所有 ESXi 主机的 vmkernel 网络和 NSX Manager 管理网络进行通信。

• 由于控制器是虚拟机，大多数企业环境将启用 vSphere 分布式资源调度器（DRS）功能，它会将控制器视为普通虚拟机，并根据部署算法将其迁移或放置在同一 ESXi 主机上。为了确保控制器不会被部署或迁移到同一主机上，并避免主机故障时直接影响控制器及整个控制平面，我们需要利用 vSphere 的反亲和性规则，避免在同一 ESXi 主机上部署多个控制器。此外，我强烈建议从多个主机集群（至少三个）开始，并根据需要进行扩展。这样，我们就能轻松将控制器部署到不同的 ESXi 主机上并扩展规模。不要误解我的意思，我们是在三个不同的主机上部署三个控制器，而不是将剩余的主机作为备用主机。在任何环境中，我们都需要进行维护操作，有时是软件升级的一部分，或者是从服务器中添加或移除硬件设备。在这种情况下，当我们对某台主机进行停机维护时，其他主机依然存在，因此控制器会根据反亲和性规则部署到这些主机上。

• 集群中的所有主机应启用自动 VM 启动/关闭功能。

注意

部署控制器的第一个主机默认启用自动 VM 启动/关闭。

以上总结了控制器部署和关键设计方面。现在，我们来谈谈数据平面准备。是时候回顾我们目前为止所做的工作了吗？是的，让我们来回顾一下。我们已部署了 NSX 管理器（管理平面）并将解决方案注册到 vCenter Server。接着，我们部署了 NSX 控制器（控制平面），最后，我们进入了安装的最后阶段——数据平面。

NSX 数据平面

NSX 数据平面包括vSphere 分布式交换机（VDS）、内核模块、用户世界代理、NSX 边缘设备、分布式路由/防火墙及桥接模块。首先，让我们讨论如何为 NSX 准备 ESXi 集群。

什么是主机准备？它的作用就是安装内核模块，并构建一个管理和控制平面域。我们在这里提到的内核模块如下：

• 分布式路由

• 分布式防火墙

• VXLAN 桥接

在多集群环境中，我们需要在每个集群层级执行此安装。根据 vSphere 设计，我们始终可以将新主机添加到集群中，且对于新添加的主机，准备工作会自动完成，这使得架构师的工作更加轻松。

主机准备过程

让我们讨论如何准备 ESXi 主机以推送内核模块：

1. 在 vCenter 中，导航到主页|网络与安全|安装，并选择主机准备标签。

2. 选择相应的集群，点击齿轮图标并点击安装，如下图所示：

3. 监控安装过程。对其他集群重复相同步骤。

   现在，所有 vSphere 用户常有的一个问题是：安装了 VIBS 后，我们是否需要重启主机？答案是绝对不需要！只有在卸载场景下，我们才需要重启主机。我们人类总是容易忘记一些事情，不是吗？没问题，我们的 ESXi 主机图标旁会弹出提示，提醒需要重启。

4. 对于每个 vSphere 集群，我们将继续配置VXLAN 网络先决条件。

首先，我们将为VTEP IP 分配配置一个静态池，这类似于我们之前配置的控制器IP 池。当然，也可以使用DHCP池分配，但在这里，我展示的是通过静态池分配 IP 的方式。

从 NSX 管理器中，导航到管理IP 池并点击+号。更新以下内容：

• VTEP 名称

• 网关 地址

• 前缀长度

• 为 VTEP IP 分配配置静态 IP 池。

请参考下图：

选择一个 vSphere 集群，并点击 VXLAN 列中的配置链接：

1. 选择 vSphere 分布式交换机。

2. 更新VLAN编号。如果不使用 VLAN，请输入0，这将通过未标记的流量传递。

3. 确保MTU为**1600**（VXLAN 开销）

4. 对于 VMKnic IP 地址配置，我们需要利用先前配置的 VTEP IP 池。

VMKNic 聚合策略方法用于将 vmnic（物理 NIC）绑定到 VTEP 端口组。我选择了故障转移。其他选项包括静态 EtherChannel、LACP（主动）、LACP（被动）、按源 ID 负载平衡、按源 MAC 负载平衡以及增强型 LACP。以下截图更新了支持的 VXLAN NIC 聚合策略列表：

VTEP NIC 聚合设计在 NSX 环境中至关重要。大多数客户会选择单一 VTEP 配置，主要是因为设计的简单性。然而，如果我们的 VXLAN 流量超过 10G，LACP 或静态 EtherChannel 将是首选的负载均衡策略。

VTEP 值是每个主机的 VTEP 数量。为什么我们要选择多 VTEP 配置？如果我们有多个物理链路希望用于 VXLAN 流量，并且上游交换机不支持 LACP，使用多个 VTEP 可以使我们在物理链路之间平衡流量。

以下截图展示了前面的步骤：

根据需求，我们也可以对其他集群重复相同的步骤，每个这样的配置将在 vSphere 中创建一个 VXLAN 分布式端口组。

VXLAN 模块的成功安装将显示为已配置，如下图所示：

我知道我们大多数人对于 VXLAN 及其工作原理会有一些设计相关的疑问。保持专注：我们正在朝着正确的方向前进，并将在后续章节中讨论这一点。

概述

本章开始时，我们介绍了 NSX Manager 的要求，并覆盖了管理平面的所有设计方面。随后，我们讨论了 NSX Controller 的要求和关键设计决策。最后，我们进入了数据平面的安装。在下一章中，我们将讨论如何管理和部署 NSX 逻辑网络。

第四章. NSX 虚拟网络与逻辑路由器

可扩展性和灵活性是网络虚拟化的显著特点。无论是在任何 IP 网络、任何交换机/路由器上，还是任何物理网络设计中，NSX 都能完美工作。随着对覆盖网络（Overlay Network）的兴趣日益增长，目前市场上有多种封装技术。VXLAN、NVGRE、LISP 等是其中的一部分。在本章中，我们将讨论逻辑网络以及 NSX 如何简化数据中心的路由和交换。以下是关键点：

• NSX 逻辑交换机

• NSX 虚拟网络创建 - 组播、单播和混合复制模式

• NSX 虚拟网络最佳实践与部署考虑事项

• NSX 逻辑路由器

• NSX 逻辑路由与桥接最佳实践

NSX 逻辑交换机

使用 VMware NSX 虚拟网络，我们可以在任何 IP 网络之上创建逻辑网络。我们已经在前几章中讨论了 VXLAN 基础知识和主机安装过程。现在我们对基础知识有了较好的理解，是时候继续进行虚拟网络的创建了。在开始之前，理解每个逻辑网络都是一个独立的广播域非常重要。

逻辑网络先决条件

首先，让我们来看看逻辑网络创建的先决条件：

• 主机准备

• 段 ID (VNI) 池

• 全局传输区域

主机准备

我们已经在 第三章 NSX 管理器安装与配置 中详细讨论了如何通过 NSX 管理器准备底层 ESXi 主机。现在是回顾这些知识的时候了。

超级管理程序内核模块使 ESXi 主机能够支持 VXLAN、逻辑交换机、分布式路由器和分布式防火墙。

段 ID (VNI) 池

如我们所知，VXLAN 网络标识符是一个 24 位地址，它会被添加到 VXLAN 帧中，从而实现将每个 VXLAN 网络与其他 VXLAN 网络隔离。

配置 VNI 池的步骤

配置 VNI 池的步骤如下：

1. 在 逻辑网络准备 选项卡中，点击 段 ID 按钮。

2. 点击 编辑 打开 编辑段 ID 和组播地址分配 对话框，并配置给定的选项。

3. 点击 确定 如下图所示：

在这个示例中，我们并没有使用多播网络，而是希望利用单播网络。一个经典的多播 VXLAN 网络示例是，当客户已经有现有的 VXLAN 网络（在使用 vCloud 网络安全时创建）且管理软件升级到 NSX 后，很多人会在 NSX 中继续使用多播模式 VXLAN 网络。请注意，在这种情况下，我们甚至不需要控制器。不要使用 239.0.0.0/24 或 239.128.0.0/24 作为多播地址范围，因为这些网络用于本地子网控制，这意味着物理交换机会泛洪所有使用这些地址的流量。完整的列表已在 tools.ietf.org/html/draft-ietf-mboned-ipv4-mcast-unusable-01 中文档化。

传输区

传输区是 VNI 的边界。同一传输区中的所有集群共享相同的 VNI。一个传输区可以包含多个集群，一个集群也可以属于多个传输区，换句话说，一个主机可以属于多个传输区。在下图中，我们有三个集群：集群 A、集群 B 和 集群 C。集群 A 和 集群 B 属于 传输区 A，集群 C 属于 传输区 B。

配置全局传输区

以下步骤将帮助您配置传输区：

1. 在 逻辑网络准备 标签页中，点击 传输区。

2. 点击绿色加号打开 新建传输区 对话框，配置以下选项后点击 确定：

   • 在 名称 文本框中输入传输区名称。

   • 在 控制平面模式 下，选择 单播、多播 或 混合模式 按钮。

   • 在 选择要添加的集群 中，勾选列出的每个 vSphere 集群的复选框。同时，查看红色高亮的分布式交换机选择。我们遵循 NSX-DVS 设计最佳实践之一。两个计算集群运行在 Compute_VDS 上，管理集群运行在 Mgmt_Edge_VDS 上。

3. 更新后，验证传输区是否出现在传输区列表中，并根据前述选择设置控制平面模式为单播、多播或混合模式。参见下图：

我们现在已经完成了 NSX 逻辑网络的所有先决条件。在这个示例中，我们已经在 vSphere 中创建了以下虚拟机，但尚未建立网络连接。我们将继续创建四个逻辑网络，并将其连接到虚拟机，稍后进行连通性测试：

• 两个 Web 服务器：web-sv-01a 和 web-sv-02a

• 一个数据库服务器：DB-sv-01a

• 应用服务器：app-sv-01a

创建逻辑交换机

在传统的 vSphere 环境中，理想情况下，虚拟机将连接到预配置的 vSphere PortGroup，无论是否使用 VLAN 标记。但现在我们处于 NSX 世界，并且让我们利用 NSX 逻辑交换机来连接虚拟机。在左侧导航窗格中，选择Logical Switches，在中心窗格中点击绿色的加号打开New Logical Switch对话框。按照以下步骤配置逻辑交换机：

1. 在Name文本框中输入App-Tier。

2. 验证Transport Zone选择项是否为Transport。

3. 验证Control Plane Mode选择项是否为Unicast。

4. 点击确定：

以下是在New Logical Switch屏幕上显示的两个选项：

• 启用 IP 发现：另一个伟大的功能，能够最小化 VXLAN 网络中的 ARP 泛洪。当虚拟机发送 ARP 包时，交换机安全模块——即附加到 VNIC 的 dvfilter 模块——将查询 NSX 控制器，看看是否有目标 IP 的 MAC 条目。每个人都知道在这种情况下我们有两个选择：

  • 控制器有 MAC 条目

  • 控制器没有 MAC 条目

  • 在第一种情况下，由于控制器有 MAC 条目，它会回应 MAC 地址，从而减少 ARP 流量。在第二种情况下，控制器没有 MAC 回应，ARP 流量将以常规方式泛洪。

• 启用 MAC 学习：启用 MAC 学习时，会在每个 vNIC 上维护一个 VLAN/MAC 对表，该表由 dvfilter 数据使用。无论虚拟机从一个主机迁移到另一个主机，借助 dvfilter 数据，该表将保持不变。

等待更新完成并确认 app-network 显示状态为正常。重复步骤 1-4 并创建三个逻辑交换机，分别命名为Web-Tier、DB-Tier和Transit网络。成功创建逻辑交换机后，当它们在逻辑交换机下显示时，将呈现以下截图所示的相同结果：

通过之前的步骤，我们看到在 vSphere 网络选项中创建了四个端口组，它们的 VNI-ID 如下：

• 5000：Transit网络

• 5001：Web_Tier网络

• 5002：App_Tier网络

• 5003：DB_Tier网络

理解复制模式

让我们更详细地讨论复制模式，稍后我们将把逻辑交换机连接到虚拟机。随着 NSX 控制器的加入，VXLAN 对物理网络的多播协议支持要求完全消除。复制模式有三种：

• 组播：当为给定的逻辑交换机选择组播复制模式时，NSX 依赖于数据中心物理网络的第 2 层和第 3 层组播功能，以确保 VXLAN 封装的多目标流量能够发送到所有 VTEP。这种模式仅在从旧版本的 VXLAN 部署（如 vCloud 网络安全）升级时推荐使用。它需要物理网络上的 PIM/IGMP 支持。

• 单播：控制平面由 NSX 控制器处理。所有单播流量使用头端复制。无需组播 IP 地址或特殊的网络配置。在单播模式下，NSX 域中的 ESXi 主机根据其 VTEP 接口所属的 IP 子网被划分到不同的 VTEP 段中。每个段都会选择一个 UTEP 作为单播隧道端点（UTEP）。UTEP 负责复制从承载源流量的虚拟机的 ESXi 主机接收到的多目标流量，这些流量属于不同 VTEP 段，并且是该段内所有 ESXi 主机的一部分。

• 混合模式：优化的单播模式。将本地流量复制卸载到物理网络（L2 组播）。这需要在第一跳交换机上启用 IGMP 嗅探，但不需要 PIM。第一跳交换机负责子网的流量复制。

我们将把下面的截图视为网络拓扑，并解释所有三种复制模式，这将帮助我们精确了解复制是如何工作的：

首先，让我们理解一下配置。前面的截图显示了以下内容：

• 在这个设置中，有两个传输区，分别是传输区 A和传输区 B。

• 一个****分布式虚拟交换机（DVS）是两个传输区的组成部分。

• 所有虚拟机都连接到一个公共的 VXLAN 网络 —— VXLAN 5001。

我们将逐一讨论所有模式，并在接下来的章节中讨论它们的设计决策。

单播模式数据包行走

让我们讨论一下单播模式 VXLAN 数据包行走：

• VM-A 生成了广播、未知单播、组播（BUM）流量，通常是第 2 层流量。

• ESXi-A 将执行本地 VTEP 查找，并学习到数据包需要在本地进行复制（同一子网），在这种情况下是 ESXi-B。

• 除此之外，数据包还会被远程复制。由于我们有四台主机位于远程子网（ESXi E、F、G 和 H），它会将数据包发送到哪一台主机？这是组播模式 VXLAN 和单播模式之间的一个关键区别。在单播模式下，数据包将被发送到一个名为 UTEP 的代理模块，设置了本地复制位。为什么会这样？答案很简单：由于设置了本地复制位，UTEP 将数据包在本地复制到同一子网中的某一台 ESXi 主机。在这个例子中，我们有两个子网；根据网络拓扑，处理过程在每个子网中是相同的。

单播模式 VXLAN 的设计决策

关于单播模式 VXLAN 设计，没有太多需要讨论的内容。然而，了解以下几点很重要：

• 我们可以简单地沿用传统的 IP 网络设计，只需确保将 MTU 增加到 1,600。

• 让我们回过头来看一下单播模式下的 VXLAN 数据包处理流程，简而言之，它做了什么？它会在本地复制数据包，然后将一份发送到远程子网，再次在本地复制。谁来执行这个复制工作？ESXi 主机完成了所有这些智能化操作，当然，基于环境的大小或 BUM 流量的频率，它会给虚拟化管理程序带来一些轻微的开销。所以我建议单播模式作为开始使用 VXLAN 的最佳方式；然而，它并不是大型环境的理想选择。

• 在客户有组播限制的环境中，单播模式 VXLAN 是最佳选择。

组播模式数据包处理

每当我解释组播 VXLAN 网络时，总让我想起 VMware vCloud Networking and Security（vCNS）解决方案的时代。组播模式 VXLAN 是 VXLAN 实现在虚拟化 vSphere 环境和运行 vCloud director 软件的云环境中的初始阶段。这个解决方案非常强大；然而，物理网络的前提条件是所有架构师面临的困难之一，因为它确实违背了 NSX 可以在任何 IP 网络上运行的说法。残酷的现实是，IP 网络确实要求一些条件才能使技术无缝工作。话虽如此，让我们从数据包处理开始：

• VM-A 生成 BUM 流量。

• ESXi A 主机将数据包封装在一个 VXLAN 头部（5001）中。现在开始猜测它会将数据包发送到哪里。它会仅仅广播吗？二层帧是一个广播帧，并带有 VXLAN 头部；然而，主机会将其发送到某个组播组。我们如何确保组播只到达ESXi B、E、F、G 和 H，因为我们有一个虚拟机正在同一个 VXLAN 网络上运行？这就是为什么物理网络要求必须的原因。我们需要 IGMP snoop；如果没有，它将被视为一个未知的组播数据包。

• 路由器 将执行 L3 多播并将其发送到二层交换机，交换机会再次检查多播组，并将其发送到正确的主机。最终，目标主机上的虚拟机将在 VTEP 解封装后接收到该数据包。

多播模式 VXLAN 的设计决策

如我所提到的，我们确实需要在多播模式的 VXLAN 网络中处理物理网络的前提要求：

• IGMP snoop 和 IP 多播 在整个网络中的交换机和路由器上是必需的。

• 理想情况下，一个 VXLAN 段对应一个多播组是提供最佳多播转发的推荐方式，这也要求如果我们有较大的段，则需要增加多播组。这是我在云环境中看到的，VXLAN 网络是动态创建的，云提供商会确保为 1:1 映射提供足够的多播 IP；这样，转发给一个租户的数据包就不会被其他租户看到。

混合模式数据包转发

混合模式 VXLAN 推荐用于大多数大型环境，主要是因为其简便性和对网络中配置更改的限制要求。让我们来看一下混合模式 VXLAN 数据包的转发过程：

1. 虚拟机 A 生成 BUM 流量。

2. ESXi A 主机将 L2 头 封装为 VXLAN 头 5001，并将其发送到物理交换机。

3. 在这种情况下，一个封装的 L2 头将被发送到物理交换机上定义的多播组。我希望现在更加清晰了。物理交换机会将数据包传递到该多播组中的目标 ESXi 主机，在这个例子中是 ESXi B、C、D。除此之外，ESXi A 会将一个设置了 Locally_Replicate_BIT 的数据包发送到远程子网。这个数据包将由一个称为 Multicast Tunnel End Point（MTEP）的代理模块接收。同样，这是一个直接的答案，因为设置了本地复制位，MTEP（ESXi 主机）将把数据包本地复制到同一子网中其他 ESXi 主机。

4. MTEP 将再次将数据包发送到物理交换机，物理交换机会将数据包传递到同一多播组中所有的主机。

混合模式 VXLAN 的设计决策

混合模式 VXLAN 作为最广泛使用的复制模式之一，我相信我们都会对一些关键的设计决策感兴趣：

• IGMP snoop 需要在整个 VXLAN 网络中的物理交换机上进行配置。

• 在整个网络中的物理路由器不需要 IP 多播。我不确定我是否可以说得足够安全，因为可以根据每个逻辑交换机选择复制模式，这意味着我们可以在单播、多播或混合模式下部署逻辑交换机。如果我们在同一个 VXLAN 域中将逻辑交换机 A 部署为多播模式，逻辑交换机 B 部署为混合模式，那么这就需要物理网络中启用 IP 多播。但再次强调，对于混合模式的 VXLAN 网络，我们并不显式地需要 IP 多播。

强烈建议为每个 VLAN 定义一个IGMP Querier，以确保成功的 L2 多播传输并避免非确定性行为。为了让 IGMP 和 IGMP 嗅探功能正常工作，网络上必须存在一个多播路由器并生成 IGMP 查询。为嗅探（持有每个多播组成员端口的表格）创建的表格与查询器相关联。我相信我们已经在 VXLAN 及其复制模式方面打下了坚实的基础；接下来让我们继续讨论逻辑交换机和虚拟机的连接。

连接虚拟机到逻辑交换机

由于我们已经创建了逻辑交换机，接下来让我们将逻辑交换机连接到以下虚拟机：

• 两台 Web 服务器：web-sv-01a 和 web-sv-02a

• 一台数据库服务器：DB-sv-01a

• 应用服务器：app-sv-01a

让我们看看如何连接逻辑交换机：

1. 点击vSphere Web Client主页图标。

2. 在vSphere Web Client主页标签页中，点击库存 | 网络与安全。

3. 在左侧导航窗格中，选择逻辑交换机。在中间窗格中，选择应用层逻辑交换机。

4. 点击添加虚拟机图标，或者从操作下拉菜单中选择添加虚拟机。

5. 在应用层中，点击虚拟机对话框。

6. 在筛选器列表中，勾选app-01a复选框。

7. 点击下一步。在选择 VNICs列表中，勾选网络适配器 1（虚拟机网络）复选框。

8. 点击下一步，如以下截图所示：

9. 点击完成。

10. 重复步骤 1-7，连接两个 Web 服务器（web-sv-01a，web-sv-02a）和数据库服务器。

测试连接性

由于我们知道三层应用程序，web、app 和 DB，已连接到逻辑交换机，让我们做一些基本测试以确认它们的连接性：

1. 首先，启动这些虚拟机。

2. 点击vSphere Web Client主页图标。

3. 在vSphere Web Client主页标签页中，点击库存 | 虚拟机和模板图标。

4. 展开虚拟机和模板库存树，并启动在已发现的虚拟机文件夹中的以下虚拟机：

   • web-sv-01a

   • web-sv-02a

   • app-sv-01a

   • db-sv-01a

   

5. 要启动虚拟机，请在库存中选择虚拟机，然后从操作下拉菜单中选择开机。

6. 一旦虚拟机启动，我们将记录它们的 IP 地址：

   • web-01a：172.16.10.11

   • web-02a：172.16.10.12

   • app-01a：172.16.20.11

   • DB-01a：172.16.30.11

接下来，我们对web-01a和app-01a进行简单的 ping 测试，如以下截图所示：

为什么当我们 ping web-01a (172.16.10.11) 和 app-01a(172.16.20.11) 时会出现 100% 丢包？逻辑交换机会执行第三层路由吗？当然不会。传统的路由方式是通过物理路由器来执行，这意味着必须走出机架，将数据路由到正确的目的地。我们在此不使用传统的路由方式，而是利用 NSX 逻辑路由器功能。

分布式逻辑路由器

路由的主要目的是在两个不同的 IP 网络之间处理数据包。在深入了解逻辑路由器之前，让我们先讨论一下路由的基础知识。每个路由器都会构建一个路由表，其中包含 目标网络、下一跳路由器、度量值和管理距离 等信息。构建路由表有两种方法：

• 静态路由：静态路由是由网络管理员手动创建和更新的。根据网络拓扑，我们需要在每个路由器上配置静态路由，以实现端到端的网络连接。尽管这种方式可以完全控制路由，但在大型网络中配置路由将是一项非常繁琐的工作。

• 动态路由：动态路由是通过运行在路由器上的路由协议创建和更新的；路由信息协议 (RIP) 和 开放最短路径优先 (OSPF) 就是其中的一些例子。动态路由协议足够智能，能够在路由基础设施发生变化时选择更好的路径。

VMware NSX 分布式逻辑路由器支持静态路由、OSPF、ISIS 和 BGP 路由协议。需要注意的是，动态路由协议仅在 分布式逻辑路由器 (DLR) 的外部接口（上行链路）上受支持。DLR 允许 ESXi 超级管理程序在本地执行路由智能，从而优化东西向数据平面流量。

部署分布式逻辑路由器

DLR 是一种虚拟设备，具有控制平面智能，并依赖于 NSX 控制器将路由更新推送到 ESXi 内核模块。

部署逻辑路由器的步骤

让我们逐步配置分布式逻辑路由器：

1. 在 vSphere Web 客户端中，导航到 主页 | 网络与安全 | NSX 边缘。

   注意事项

   选择适当的 NSX 管理器，以便进行更改。如果您正在创建一个通用逻辑路由器，则必须选择主要的 NSX 管理器。我们将在 第七章 中讨论主要/次要 NSX 管理器的概念，NSX 跨 vCenter。

2. 选择您希望添加的路由器类型；在本例中，我们将添加 逻辑路由器。

3. 选择 逻辑（分布式）路由器 以将逻辑路由器添加到选定的 NSX 管理器本地。

   注意事项

   由于我们尚未讨论跨 vCenter 的 NSX 环境，本章不会使用通用逻辑分布式路由器（DLR）。

4. 为设备输入一个名称。此名称将出现在您的vCenter 库存中。该名称在单个租户的所有逻辑路由器中应唯一。您还可以选择输入主机名。该名称将显示在 CLI 中。如果没有指定主机名，自动创建的边缘 ID 将显示在 CLI 中。

5. 默认情况下选中了部署边缘设备选项。边缘设备（也称为逻辑路由器虚拟设备）用于动态路由和逻辑路由器设备的防火墙，适用于逻辑路由器的 ping、SSH 访问和动态路由流量。如果您只需要静态路由，并且不想部署边缘设备，您可以取消选中部署边缘设备选项。逻辑路由器创建后，无法再添加边缘设备。

6. 默认情况下，启用高可用性选项没有选中。选中启用高可用性复选框以启用并配置高可用性。如果您计划进行动态路由，则需要高可用性。我希望大家从云提供商的角度考虑：如果您的租户请求高可用性功能，您如何满足这个要求？NSX Edge 会为备用设备复制主设备的配置，并确保即使使用 DRS 和 vMotion，两个高可用性的 NSX Edge 虚拟机也不会部署在同一 ESXi 主机上。两个虚拟机被部署在 vCenter 中，与您配置的设备位于同一资源池和数据存储中。NSX Edge HA 为高可用性虚拟机分配本地链接 IP，以便它们能够相互通信。但请记住，我们现在有两个控制 VM，而不是一个控制 VM，因此肯定会消耗两倍的计算资源。

   以下截图展示了 NSX DLR-VM 的部署：

   

7. 为逻辑路由器输入并重新输入密码。密码必须为 12-255 个字符，并且必须包含以下内容：

   • 至少一个大写字母

   • 至少一个小写字母

   • 至少一个数字

   • 至少一个特殊字符

8. 启用SSH并设置日志级别（可选）。默认情况下，SSH是禁用的。如果您没有启用 SSH，仍然可以通过打开虚拟设备控制台访问逻辑路由器。在这里启用 SSH 会使 SSH 进程在逻辑路由器虚拟设备上运行，但您还需要手动调整逻辑路由器的防火墙配置，以允许 SSH 访问逻辑路由器的协议地址。协议地址是在您为逻辑路由器配置动态路由时配置的。默认情况下，日志级别为紧急。

   注意

   在逻辑路由器上，仅支持 IPv4 地址。

9. 配置接口。在配置接口下，向逻辑路由器添加四个逻辑接口（LIFs）：

   • 上行接口连接到Transit-Network-01 逻辑交换机，IP 地址为 192.168.10.2/29

   • 内部接口连接到Web-Tier-01 逻辑交换机，IP 地址为 172.16.10.1/24

   • 内部接口连接到App-Tier-01 逻辑交换机，IP 地址为 172.16.20.1/24

   • 内部接口连接到DB-Tier-01 逻辑交换机，IP 地址为 172.16.30.1/24

   以下截图显示了添加接口的界面：

   

10. 配置此 NSX Edge 的接口：内部接口用于连接逻辑交换机，允许虚拟机之间的通信（东西向）。内部接口是在逻辑路由器虚拟设备上创建的，我们称之为 LIF。上行接口用于南北向通信。逻辑路由器的上行接口可以连接到 NSX Edge 服务网关、第三方路由器虚拟机，或连接到 VLAN 支持的 dvPortgroup，从而直接将逻辑路由器与物理路由器连接。为了使动态路由正常工作，必须至少有一个上行接口。上行接口作为 vNIC 在逻辑路由器虚拟设备上创建。

    注意

    部署逻辑路由器后，我们可以添加、删除和修改接口。

以下截图显示了我们迄今为止执行的 DLR 配置：

现在我们已经成功部署了一个 DLR 并配置了逻辑接口，我们希望 DLR 能够执行基本的路由功能，使 Web、应用和数据库服务器可以互相通信，这在之前是无法实现的。

以下截图显示了没有路由的三层应用架构：

让我们进行一次快速的 ping 测试，测试web-01a (172.16.10.11)和app (172.16.20.11)之间的连通性。如下面的截图所示，Web 服务器和应用服务器能够互相通信，因为我们有一个分布式逻辑路由器，在此案例中负责路由。第一次 ping 测试结果是在添加分布式逻辑路由器之前：

到目前为止，我们已经讨论了分布式逻辑路由器（DLR），它使 ESXi 虚拟化平台能够在本地执行路由智能，从而优化东西向的数据平面流量。但我知道我们很期待查看 ESXi 主机中的 DLR 路由表。让我们聚焦于下面的截图，了解网络拓扑。

以下截图显示了连接了 DLR 的三层应用架构：

我们可能会有以下问题：

• 我们有多少个网络？

  • 172.16.10.0/24

  • 172.16.20.0/24

  • 172.16.30.0/24

  • 192.168.10.0/29

• 网络是否直接连接到路由器？

  • 是的，它们已连接到路由器。

我们将通过 SSH 登录到其中一台 ESXi 主机，检查逻辑路由器实例、MAC 地址、ARP 和路由表，这将为我们提供更详细的信息：

Net-vdr -I -l

上述命令将显示逻辑路由器实例，如下图所示。你可以看到以下参数：

• VDR 名称为default+edge-19

• LIF 数量为4

• 记得我们将四个逻辑网络连接到了分布式路由器吗？因此数量是4

• 路由数为4

由于我们已连接四个逻辑网络，因此路由器能够识别这些直接连接的网络：

以下命令将验证由 DLR 发现的网络路由：

net-vdr --route -l VDR Name

例如：

net-vdr --route -l default+edge-19

逻辑路由器的路由表由 NSX 控制器推送到 ESXi 主机，并且在所有 ESXi 主机之间保持一致。你将看到以下输出：

现在登录到控制器 CLI 查看逻辑路由器状态信息：

nvp-controller **# show control-cluster logical-routers instance all (List all LR instances)** 

你将看到以下输出：

另一个命令是：

nvp-controller **# show control-cluster logical-routers interface-summary 1460487509** 

我们连接到逻辑路由器的四个逻辑交换机（VXLAN 5000、5001、5002 和 5003）都显示在以下输出中，并带有它们各自的接口 IP，这些 IP 将作为 Web、应用和数据库机器的默认网关。再次强调，这里的目的是展示 NSX CLI 命令的强大功能，它们提供了细粒度的信息，在故障排除时非常有用：

理解逻辑接口

我相信我们现在对 NSX 环境中分布式路由的工作原理有了充分的理解。再次强调，NSX DLR 不仅限于 VXLAN 网络；我们完全可以利用 VXLAN 和 VLAN 网络之间的路由功能。接下来让我们更详细地讨论逻辑接口：

• 如果分布式逻辑路由器连接到 vSphere 分布式交换机端口组，则该接口称为VLAN LIF。VLAN LIF 使用指定实例（DI）来解析 ARP 查询。NSX 控制器会随机选择一个 ESXi 主机作为指定实例，以便处理 ARP 流量，这样该子网的任何 ARP 流量都会由其中一台 ESXi 主机处理，其他所有 ESXi 主机也会知道 DI 的运行位置。

• 如果分布式逻辑路由器连接到逻辑交换机，则该接口称为VXLAN LIF。

• 一个 LIF 可以是上行链路接口或内部接口。

• 可以在一个分布式逻辑路由器实例上配置多个 LIF。

• 每个 LIF 都有一个 ARP 表。

• 每个 LIF 都分配了一个 IP 地址，表示它连接的逻辑网络的默认 IP 网关，并且分配了一个 vMAC 地址。每个 LIF 的 IP 地址是唯一的，而所有定义的 LIF 都分配了相同的虚拟 MAC 地址。

• 我们最多可以配置 999 个接口，最多支持 8 个上行链路。

• 路由表可以通过多种方式填充：

  • 直接连接

  • 静态路由

  • OSPF

  • BGP

  • 路由重分发

我们将在 第五章 中讨论动态路由和路由重分发，NSX Edge 服务，这将清楚地展示租户如何访问公共网络（北南连接）。

逻辑路由器部署注意事项

分布式逻辑路由器 (DLR) 的部署在 NSX 环境中至关重要。让我们检查一些关键的决策因素：

• 在部署逻辑路由器之前，确保控制器已启动并正常运行。

• 在控制器部署期间不要部署逻辑路由器。这不仅限于 DLR 部署，适用于所有 NSX 功能。

• 如果逻辑路由器要连接到 VLAN dvPortgroups，请确保安装了逻辑路由器设备的所有虚拟化主机能够通过 UDP 端口 6999 互相访问，以便逻辑路由器 VLAN 基于 ARP 代理功能能正常工作。

• 如果两个网络位于同一 vSphere 分布式交换机上，则逻辑路由器接口不应创建在两个不同的分布式端口组（dvPortgroups）上，并且它们的 VLAN ID 应相同。

• 从 VMware NSX for vSphere 6.2 开始，L2 桥接功能现在可以参与分布式逻辑路由。桥接实例连接的 VXLAN 网络将用于连接路由实例和桥接实例。这个功能在早期版本中不支持。

• DLR 接口不支持中继；但是，每个 DLR 接口可以连接到支持中继的 NSX Edge 子接口。不过，我们在子接口上使用 IP-Sec、L2-VPN、BGP（动态路由）、DHCP 和 DNAT 功能时有所限制。

• DLR 支持 1,000 个逻辑接口。

• DLR 不支持 虚拟路由与转发 (VRF)。要实现真正的网络多租户功能，我们需要部署一个独特的 DLR，它可以连接到相同或不同的 NSX Edge。

• 等价成本多路径 (ECMP) 在 DLR 中受支持；然而，由于存在非对称路由行为，状态全防火墙不受支持。

  注意

  我们将在下一章讨论 ECMP 和非对称路由。

• DLR 控制虚拟机不应部署在计算集群中。如果主机失败，数据平面和控制平面将同时受到影响，特别是当控制虚拟机也位于相同的 ESXi 主机上时。因此，部署 DLR 控制虚拟机的正确位置应为管理集群，或者如果我们有一个单独的 vSphere Edge 集群，那将是最佳选择。

层 2 桥接

在 NSX 环境中，由于多种原因，可能需要将逻辑网络连接到物理网络：

• 在 物理到虚拟 (P2V) 迁移过程中，如果不更改 IP 地址

• 将虚拟服务扩展到逻辑交换机外部设备

• 将物理网络服务扩展到逻辑交换机中的虚拟机

• 访问现有的物理网络和安全资源

由于 Layer 2 桥接是 NSX Edge 分布式逻辑路由器功能的一部分，L2 桥接运行在与边缘逻辑路由器控制虚拟机相同的主机上。桥接完全在内核级别完成，就像分布式逻辑路由一样。使用了一种特殊的 dvPort 类型，称为接收端口，用于将数据包引导到桥接中。在以下截图中，我们有一个 VXLAN 环境，其中 VXLAN 网络 5006 中的虚拟机需要与 VLAN-100 中的物理站点进行通信：

NSX Layer 2 桥接

部署 L2 桥接

让我们来看一下 Layer 2 桥接的部署：

1. 登录 vSphere Web 客户端。

2. 点击网络与安全，然后点击NSX 边缘。

3. 双击逻辑路由器。

4. 点击管理，然后点击桥接。

5. 点击添加图标。

6. 输入桥接的名称。

7. 选择要为其创建桥接的逻辑交换机。

8. 选择要将逻辑交换机桥接到的分布式虚拟端口组。

9. 点击确定。

在以下示例中，我们将逻辑交换机bRANCH与启用 VLAN 的Mgmt_Edge_VDS端口组进行桥接：

L2 桥接的设计考虑

与任何其他 NSX 组件一样，L2 桥接是一个同样重要的设计决策因素。以下是关键要点：

• 不支持桥接 VLAN-ID 0。

• 每个逻辑路由器支持多个桥接实例；然而，我们不能在每个 VXLAN-VLAN 配对中拥有多个活动的桥接实例。

• 桥接不能用于 VLAN-VLAN 连接。

• 桥接不是数据中心互连技术。

• 从 NSX 6.2 开始，DLR 接口可以连接到与 VLAN 网络桥接的 VXLAN 网络。早期版本没有此功能。

• 不要将 DLR 和下跳路由器（NSX Edge）混合部署在同一主机上；主机故障会对这两个设备产生直接影响。

• 尽管 Layer 2 桥接是一个很好的功能，但请记住，所有的 ARP 解析都是由运行在与我们部署逻辑路由器相同主机上的桥接实例模块显式完成的。出于同样的原因，运行过多的桥接实例，尤其是它们都在同一主机上，再加上如果 UTEP 和 MTEP 也都在同一主机上运行，肯定会对性能产生影响。因此，尽量将桥接实例分布在不同的主机上，或者换句话说，跨管理集群分布逻辑路由器的部署。

概要

本章开始时，我们介绍了 NSX 分布式逻辑路由器，并讨论了 VXLAN 复制模式和一些数据包流程。接着，我们介绍了在部署 DLR 时的一些关键设计决策。我们还讨论了 DLR 的 Layer 2 桥接功能，并继续讲解了在利用桥接功能时需要注意的重要设计决策。

在前方有令人激动的时刻，我们将讨论越来越多的功能及其作用。

在下一章，我们将讨论 NSX Edge 路由，并通过动态路由协议与 DLR 建立连接。

第五章：NSX Edge 服务

NSX Edge 是一款功能丰富的网关虚拟机，提供 L3 到 L7 的服务。Edge 网关是连接所有逻辑网络的粘合剂，提供 DHCP、NAT、路由、VPN、防火墙、负载均衡和高可用性功能。理想情况下，这些设备会在 vSphere 数据中心的边缘层进行配置。

在本章中，我们将讨论以下主题：

• 介绍 Edge 服务

• 介绍 Edge 服务外形规格

• 介绍 OSPF、BGP 和 ISIS 协议

• DLR 与 NSX Edge 路由器之间的路由

• NSX Edge 服务使用案例

介绍 Edge 服务

NSX Edge 网关是一种虚拟机，提供如网络地址转换、动态主机配置协议、DNS 转发、虚拟专用网络、负载均衡和路由功能等服务。首先，并没有一条固定的规则说我们必须通过一个 Edge 来利用所有这些功能。为了实现真正的多租户，我们可以部署多个 Edge 来满足不同功能的需求。在我们开始路由和其他话题之前，让我们先来看看 Edge 网关的外形规格。

介绍 Edge 外形规格

我们曾无数次地部署虚拟机，假设某些特定的值足以满足计算和存储需求。然而，当我们开始面临性能问题时，我们不得不回过头来重新检查应用程序需求。就影响而言，这通常仅限于一个虚拟机，因此来回调整和修改是可行的。然而，这种方法不适用于 NSX Edge，主要因为它是一个边缘设备，影响要大得多。出于同样的原因，选择正确的外形规格至关重要，以确保获得最佳性能。以下截图展示了每个 Edge 外形规格所提供的默认计算能力：

需要注意的积极方面是，我们始终可以回过头来更改这些外形规格。例如，在初始部署时，我们选择部署了大规格的 NSX Edge。稍后，我们可以将外形规格从大规格改为任何更高版本。然而，负面影响是，在此过程中，NSX Edge 服务会出现中断。因此，推荐的部署选项是选择正确的 Edge 外形规格。对于负载均衡器等服务，其中有大量的 SSL 终止和卸载任务，这些任务会消耗大量的 vCPU 周期，首选的外形规格是 Edge X-Large。话虽如此，我们将从 NSX 世界中最激动人心的主题之一开始。路由的简便性和功能丰富的集成，使 NSX 成为所有 vSphere 架构师的理想平台。

介绍 OSPF、BGP 和 ISIS

正如我们所知，VMware NSX 中的分布式路由功能提供了一种优化且可扩展的方式来处理数据中心中的东西向流量。NSX Edge 服务路由器提供传统的集中式路由。我们在企业环境中还需要什么？这两个组件，分布式逻辑路由器（DLR）和 Edge，提供了企业路由架构中的前沿解决方案。在我们开始讨论这些解决方案之间的路由如何工作的之前，让我简单介绍一下在 NSX 环境中支持的路由协议，然后我们一起探讨 DLR 和 NSX Edge 之间的 OSPF 路由协议配置。听起来有趣吗？那我们开始吧。

探索开放最短路径优先

根据我的经验，在教学和实验室操作中，人们常常发现理解 开放最短路径优先（OSPF）协议非常困难。所以，让我们将这个缩写分解成它的组成部分：

• 开放：是的，这是一个开放标准协议，由广泛的网络厂商开发。这意味着它在任何支持动态路由协议的路由器上都是公开可用的。同样，我们不仅仅局限于在 CISCO、Juniper 或其他厂商的路由器上运行 OSPF，在 OSPF 路由环境中，任何厂商的路由器都可以使用。对于多厂商部署场景，这肯定是可以配置的。

• 最短路径优先：最短路径优先（SPF）使用 Dijkstra 算法找到通往目标网络的唯一最短路径。

简而言之，我们有一个开放标准的路由协议，它计算到达目的地的最短路径。现在，我们将暂停一下，理解路由协议的分类，然后再回到 OSPF 的话题。路由协议有三种分类，分别是：

• 距离矢量：距离矢量协议通过判断距离找到通往远程网络的最佳路径。RIP 是一种距离矢量路由协议。在 RIP 路由中，路由器会选择经过最少跳数的路径来到达目标网络。矢量这个术语指的是到目标网络的方向。

• 链路状态：链路状态协议也叫做最短路径优先协议。在链路状态协议环境中，路由器创建三个独立的表：

  • 直接连接的邻居

  • 整个网络的拓扑

  • 路由表

  • 在后台，链路状态协议会将自己链路的状态更新发送到网络中所有其他直接连接的路由器。

• 混合型：混合协议是距离矢量协议和链路状态协议的结合，增强型内部网关路由协议（EIGRP）就是一个很好的例子。

理解基本的 OSPF 术语

为了理解 OSPF 的基础知识，让我们先澄清一些基本的 OSPF 术语：

• Link: 链路是分配给任何给定网络的网络或 OSPF 路由器接口。是的，了解我们是否有多个运行状态的接口是很重要的；OSPF 不会将它们视为链路。只有当接口添加到 OSPF 进程时，它才被视为链路。

• Router ID: 路由器 ID（RID）是用于标识 OSPF 路由器的 IP 地址。

• Neighbor: 邻居是在共同网络上拥有接口的两个或多个 OSPF 路由器：

  • 区域 ID

  • Stub 区域标志

  • 认证密码

  • Hello 和死亡间隔

  注意

  所有上述参数应匹配以形成邻居关系。

• Adjacency: 邻接关系是允许两个 OSPF 路由器直接交换路由更新的关系。这完全取决于网络类型和路由器的配置：

  • Designated Router: 每当 OSPF 路由器连接到同一广播网络时，都会选举一个指定路由器（DR），以减少形成的邻接数。选择可以是手动的或基于优先级值作为第一个参数的自动化选择。同一网络上的所有路由器都将与 DR 和 BDR 建立邻接关系，从而确保所有路由器的拓扑表同步。

  • Backup Designated Router: 备份指定路由器（BDR）是指 DR 路由器的备份。

  • Hello protocol: OSPF Hello 协议提供动态邻居发现并维护邻居关系。Hello 数据包发送到组播地址224.0.0.5。Hello 数据包和链路状态广告（LSAs）构建拓扑数据库。

  • Neighborship database: 邻居数据库是所有可见 Hello 数据包的 OSPF 路由器列表。让我们讨论一下 OSPF 数据库如何更新。

更新拓扑数据库

我们知道 OSPF 路由器直接教授直连邻居，整个互联网络的拓扑，最后是路由表。让我们讨论一下 OSPF 路由器如何更新拓扑数据库：

• Link state advertisement: 我简单地称之为 OSPF 语言；OSPF 路由器通信的方式。LSA 是包含链路状态和路由信息的 OSPF 数据包，这些信息在 OSPF 路由器之间共享。

• Areas: OSPF 区域是连续网络和路由器的分组。同一区域中的所有路由器共享相同的区域 ID。以下图展示了一个简单的 OSPF 拓扑：

在 OSPF 中总共有八种重要的 LSA 类型：

• LSA Type 1: Router LSA: 区域内的每个路由器都会向区域内传播类型 1 的路由器 LSA。

• LSA Type 2: Network LSA: 网络 LSA 或类型 2 是为每个多接入网络创建的。网络 LSA 是由指定路由器生成的。

• LSA Type 3: Summary LSA: 区域边界路由器（ABR）将创建 LSA 3 摘要，并将 LSA 信息传递给其他区域。

• LSA 类型 4：汇总 ASBR LSA：路由器需要知道在哪里找到 ASBR。在这种情况下，ABR 将生成汇总。

• LSA 类型 5：自治系统外部 LSA：类型 5 LSA 将由边界路由器发送，以通知其他路由器如何通过内部网络到达边界路由器。

• LSA 类型 7：非截断区域 LSA：这不允许外部 LSA（类型 5）。它所做的只是生成类型 7 LSA。

那么，类型 6 和类型 8 呢？类型 6 在 OSPF v2 中不再受支持，而类型 8 LSA 是 OSPF v3 的链路本地 LSA。类型 8 LSA 用于提供关于链路本地地址的信息以及链路上 IPv6 地址的列表。在本模块中，我们将通过在 NSX Edge 和 DLR 之间建立动态路由，讨论在 NSX 世界中应用 OSPF 的实际案例。

现在，咱们继续讨论 ISIS 协议。

探索中间系统到中间系统

中间系统路由协议是一种与 OSPF 类似的链路状态协议。它也被称为 ISP 规模协议，主要是因为它支持比 OSPF 更多的区域。中间系统是一个 路由器，而 中间系统到中间系统（IS-IS）是将数据包在中间系统之间路由的协议。IS-IS 路由器有三种类型：Level 1（区域内）、Level 2（区域间）或 Level 1-2（两者）。Level 1 路由器与同一区域的其他 Level 1 路由器交换路由信息，Level 2 路由器只能与其他 Level 2 路由器建立关系并交换信息。Level 1-2 路由器与两个级别的路由器交换信息，用于连接区域间路由器和区域内路由器，如下图所示：

简要了解 ISIS 协议后，让我们现在来理解 边界网关协议（BGP）。

探索边界网关协议

首先，最重要的是，这是一种外部网关协议。BGP 主要由互联网服务提供商（ISP）和大型企业公司在与多个 ISP 连接时使用。它的作用就是将较小的自治（互联网络）绑定在一起，以确保无论位置如何，都能够实现高效的路由。BGP 本质上是由一组自治系统组成的。这就引出了另一个问题：什么是自治系统？自治系统（AS）是由共同管理的网络组成的群体。就像私有和公有 IP 的概念一样，AS 也有私有和公有的编号。公有 AS 编号的范围是 1 到 64511，私有 AS 编号的范围是 64512 到 65535。当我们在一个 AS 内进行路由时，它被称为 iBGP 路由，而 eBGP 则是指在两个不同的自治系统之间进行路由。形成 BGP 对等连接的过程非常简单。需要建立一个 TCP 会话，BGP 的源端口是临时端口，目标端口为 TCP 端口 179。下图展示了 iBGP 和 eBGP 的拓扑结构：

我对 BGP、ISIS 和 OSPF 的解释有所限制，主要是因为要覆盖所有的路由协议方面内容，就需要写一本不同的书。话已说完——让我们通过配置 OSPF 路由来完成网络拓扑。在我们开始配置分布式逻辑路由器和 NSX Edge 网关之间的路由之前，让我们回到第四章中使用的实验拓扑，NSX 虚拟网络与逻辑路由器，理解我们现在的位置以及接下来的要求。从下图可以清楚地看到，我们已经在 web、app 和 DB 网络之间建立了路由。现在是时候提出一些问题了。我们需要让这些网络通过一个中继网络与另一个网络（192.168.100.0/24）通信。我们该如何做到呢？我们能否将中继网络连接到 NSX Edge 并利用动态路由功能，使得应用、Web 和数据库能够与外部网络通信？

下图展示了利用 DLR 功能的三层应用：

部署 NSX Edge 网关

NSX Edge 网关是一个边缘设备，因此，网络虚拟化数据中心中的所有入口和出口流量必须通过 Edge 设备，并最终到达上游路由器。在我们的例子中，三层应用需要与外部网络（192.168.100.0/24）通信，因此需要部署一个 Edge 网关。让我们部署一个 NSX Edge 网关并与分布式逻辑路由器（DLR）连接。简而言之，我们所做的就是将两个路由器连接起来，为它们创建一个动态路由环境，以便交换网络，从而最终使得我们的三层应用能够与网络 192.168.100.0/24 进行通信。

步骤如下：

1. 在 vSphere Web 客户端首页标签中，点击库存 | 网络与安全。

2. 在左侧导航窗格中，选择NSX Edge。

3. 在中间窗格中，点击绿色加号打开新建 NSX Edge对话框。

4. 在名称和描述页面，保持选择Edge Services Gateway。

5. 在名称文本框中输入Perimeter Gateway并点击下一步。

   以下截图显示了 NSX Edge：

   

6. 在 CLI 凭证页面，在密码文本框中输入密码。

7. 正确输入密码，因为没有提供验证框：

8. 在配置部署页面，确认数据中心选择的是我们在初始 vSphere 集群设计阶段创建的 Edge 集群。

9. 确认设备大小选择为Compact。

10. 确认启用自动规则生成复选框已选中。

    注意

    NSX Edge 添加防火墙、NAT 和路由，以便控制流量通过这些服务。如果此选项被禁用，我们需要手动创建防火墙规则，这是繁琐的工作。

11. 在NSX Edge 设备下，点击绿色加号，如下截图所示，打开添加 NSX Edge 设备对话框，并执行以下操作：

    1. 从集群/资源池下拉菜单中选择管理和 Edge 集群。

    2. 从数据存储下拉菜单中选择共享数据存储。

    3. 保持其他字段为默认值并点击确定。

    4. 点击下一步，如以下截图所示：

    

12. 在配置接口页面，点击绿色加号打开添加 NSX Edge 接口对话框，并执行以下操作配置两个接口中的第一个：

    1. 在名称文本框中输入Uplink-Interface。

    2. 对于类型，保持选择上行链路。

    3. 点击连接到 | 选择链接。

    4. 点击分布式端口组。

    5. 点击Mgmt-Edge-VDS-HQ 上行链路按钮并点击确定。

    6. 点击配置子网下方的绿色加号。

    7. 在添加子网对话框中，点击绿色加号添加一个 IP 地址字段。

    8. 在IP 地址文本框中输入192.168.100.3并点击确定确认输入。

    9. 在子网前缀长度文本框中输入24。

    10. 点击确定关闭添加子网对话框。

    11. 保持其他设置为默认值并点击确定。

13. 点击绿色加号打开添加 NSX Edge 接口对话框，并执行以下操作配置第二个接口：

    1. 在名称文本框中输入Transit-Interface。

    2. 对于类型，点击内部。

    3. 点击连接到 | 选择链接。

    4. 点击Transit-Network按钮并点击确定。

    以下截图显示了 NSX Edge 接口选择：

    

14. 点击下一步。

15. 在默认网关设置页面上，勾选配置默认网关复选框。

16. 验证vNIC选择是否为上行链路接口。

17. 在网关 IP文本框中输入192.168.100.2。

18. 此值是一个路由器的 IP 地址，该路由器可在 HQ 上行链路端口组中使用。

19. 保留其他所有设置为默认值并点击下一步，如下图所示：

20. 在防火墙和高可用性页面上，勾选配置防火墙默认策略复选框。

21. 对于默认流量策略，点击接受。

    注意

    这是一个非常重要的步骤，因为默认情况下，所有流量都被阻止。

    配置高可用性参数。高可用性（HA）确保通过在虚拟化基础架构上安装一对活动的 Edge 设备，使 NSX Edge 设备始终可用，关于 Edge 高可用性模块的详细内容将进一步讨论。因此，目前我们将其余设置保持不变。以下截图展示了 Edge 防火墙和 HA 设置：

    

22. 在准备完成页面上，查看配置报告并点击完成。

所以，我们已部署了分布式逻辑路由器，然后是NSX Edge 网关。再一次，主要目的是让我们的 Web、应用和数据库服务器与网络 192.168.100.0/24 通信，而且我们确信这些网络不是直接连接的网络。在继续配置路由之前，让我们快速查看以下图示，看看当前的拓扑结构。

下图展示了连接到 DLR 的三层应用程序和 DLR 与 Edge 的连接：

现在我们已完成 NSX Edge 部署，接下来将继续配置 NSX Edge 上的 OSPF。

配置 NSX Edge 上的 OSPF

在 NSX Edge（边缘防火墙）上配置 OSPF 路由允许逻辑网络通过逻辑路由器进行学习，并通过传输网络进行分发。具体步骤如下：

1. 在路由类别列表中，选择全局配置。

2. 在动态路由配置面板中，点击编辑以打开编辑动态路由，如下图所示：

3. 在动态路由配置对话框中，执行以下操作：

   • 从路由器 ID下拉菜单中选择上行链路 - 192.168.100.3。

   • 勾选启用 OSPF复选框。

   • 保留所有其他字段为默认值，并点击保存，如下图所示：

   

4. 在全局配置页面顶部，点击发布更改。

5. 在路由类别面板中，选择OSPF。

6. 在区域定义列表中，验证是否出现具有以下属性的区域，如下图所示：

   • 区域 ID：0

   • 类型：正常

   • 身份验证：无

   

   注意

   区域 0 是 OSPF 中的默认区域，所有其他区域将连接到区域 0。

7. 在区域定义列表的上方，点击绿色加号以打开新建区域定义对话框，并执行以下操作：

   • 在区域 ID文本框中输入10。

   • 保留所有其他设置为默认值，并点击确定。

8. 在区域接口映射下，页面底部点击绿色加号以打开新建区域到接口映射对话框，并执行以下操作：

   • 确认vNIC选择为上行接口。

   • 从区域下拉菜单中选择0。

   • 保留所有其他字段为默认值，并点击确定。

9. 在区域接口映射下，页面底部点击绿色加号以打开新建区域到接口映射对话框，并执行以下操作，如下图所示：

   • 从下拉菜单中选择过境-接口。

   • 从区域下拉菜单中选择10。

   • 保留所有其他字段为默认值，并点击确定：

   

10. 在 OSPF 页面顶部，点击发布更改。

    注意

    我们可以通过 OSPF 配置 Perimeter Gateway 发布的子网类型。

11. 在路由类别面板中，选择路由重分发状态。

12. 在路由重分发表下，页面底部点击绿色加号以打开新建重分发标准对话框，并执行以下操作：

    • 在允许学习自下，选中已连接复选框。

    • 现在可以学习连接到 Perimeter Gateway 的子网。

    • 保留所有其他设置为默认值，并点击确定，如下图所示：

    

13. 在路由重分发状态面板的页面顶部，查看 OSPF 旁边是否出现绿色勾选标记。此时没有，如下图所示：

14. 如果没有出现绿色勾选标记，请执行以下操作：

    • 在路由重分发状态面板的右侧，点击更改。

    • 在更改重分发设置对话框中，选中OSPF复选框，如下图所示：

    • 点击保存。

    • 在路由重分发状态面板的页面顶部，确认 OSPF 旁边出现绿色勾选标记：

    

15. 在页面顶部，点击发布更改：

通过上述步骤，我们已成功在外围网关上配置了 OSPF。到目前为止，我们所做的只是为外围网关选择了一个路由器 ID并启用了 OSPF。随后，我们创建了 Area-10，并进行了区域到接口的映射，最后启用了路由重分发。接下来，让我们回顾一下在 NSX Edge 部署过程中选择的防火墙策略；我们已经允许了流量并选中了启用自动规则生成复选框。在本示例中，我们已经在 NSX Edge 上配置了 OSPF，并且我们期望防火墙表中自动配置 OSPF 规则。让我们通过切换到外围网关 | 管理 | 防火墙标签来验证这一点，如下图所示：

如我们所见，已经自动配置了三条防火墙规则：两条内部规则和一条默认规则。现在，OSPF 进程已在 NSX Edge 上运行，并且防火墙规则已自动配置，接下来我们继续在分布式逻辑路由器上配置 OSPF。

在分布式逻辑路由器上配置 OSPF 路由

让我再次强调分布式逻辑路由器的使用案例。DLR 的核心目的是实现智能的东西向路由，这允许虚拟机之间的通信无需通过传统的数据中心逐跳路由。接下来，让我们在 DLR 上配置 OSPF：

1. 在路由类别面板中，选择全局配置。

2. 在动态路由配置面板的右侧，点击编辑。

3. 在编辑动态路由配置对话框中，从路由器 ID下拉菜单中选择接口为Transit 和 192.168.10.2，如下面的截图所示：

4. 在配置 OSPF 之前，必须指定此设置。

5. 保留其他字段的默认值并点击保存。

6. 在全局配置页面的顶部，点击发布更改。

7. 在路由类别面板中，选择OSPF。

8. 在OSPF 配置面板的右侧，点击编辑以打开OSPF 配置对话框，并执行以下操作：

   1. 选择启用 OSPF复选框。

   2. 在协议地址文本框中输入192.168.10.3。

   3. 在转发地址文本框中输入192.168.10.2。

      注意

      协议地址：与其他路由器建立路由协议会话。在我们的示例中，该地址将用于与 NSX Edge 外围网关建立路由协议会话。转发地址：用于路由器数据路径模块在主机中转发数据路径包的 IP 地址。

9. 点击确定：

10. 在区域定义面板中，点击绿色加号打开新建区域定义对话框。

11. 在区域 ID文本框中输入10。

12. 将所有其他字段保留为默认值，然后点击确定。

13. 在区域到接口映射面板中，点击绿色加号以打开新的区域到接口映射对话框。

14. 确认接口选择为传输。

15. 从区域下拉菜单中选择10。

16. 将所有其他字段保留为默认值，然后点击确定。

17. 在OSPF 配置页面顶部，点击发布更改。

18. 更改发布后，请验证OSPF 配置状态是否为已启用，如下截图所示:

19. 我们可以通过 OSPF 配置广播的分布式路由器的子网类型：

    • 在路由类别面板中，选择路由重分发。

    • 在路由重分发表中，选择出现的单个条目，点击铅笔图标以打开编辑重分发标准对话框，并验证以下设置：

      • 前缀名称: 任意

      • 学习协议: OSPF

      • 允许学习来自: 连接

      • 动作: 允许

20. 点击取消。

21. 如果默认路由重分发条目未出现在列表中或未按指定配置进行配置，请点击绿色加号并配置第 13 步指定的标准创建新的路由重分发。下图显示了 OSPF 路由重分发表:

让我们验证分布式路由器防火墙策略，确认我们是否有必要的 OSPF 学习规则。我们当然已经填充了 OSPF 自动规则；然而，唯一的区别是默认规则是拒绝，如下截图所示。 我们当然会检查该规则是否在我们的示例中阻止了任何流量。目前，我们不会更改该规则:

即使 NSX GUI 很好，我们无法查看路由表；我们只能运行 CLI 命令进行检查，我们有两种方法可以做到这一点:

• 直接控制台到 NSX Edge 和逻辑路由器

• SSH 会话到 NSX Edge 和逻辑路由器。

让我们 SSH 到 NSX Edge。我们正在使用 IP 地址192.168.100.3连接到 NSX Edge。从此输出中可以注意到一些有趣的事情，如下截图所示：

名称被标注为vShield Edge。不要因为这个输出而感到尴尬。正如在第一章中所解释的，网络虚拟化介绍，NSX 是一个由 VMware vCloud Networking Security（vCNS）创建的产品。不管我们是进行 NSX 的绿地部署，还是在旧的 VCNS 升级为 NSX 的棕地部署中，边缘设备仍然会显示为 vShield Edge。然而，根据 VCNS/NSX 管理版本的不同，版本号肯定会有所不同。我们列出一些显示命令，并记下几项配置：

• Show IP OSPF interface：此命令将显示运行 OSPF 协议的接口。例如，如果一个路由器有 10 个接口，其中只有两个接口连接到 OSPF 区域，则只会列出这两个接口：

  我们在 OSPF 配置中有两个接口：

  192.168.10.1（传输接口）

  192.168.100.3（上行）

• Show IP OSPF neighbor：此命令显示我们 OSPF 邻居的 IP 地址，如下图所示的输出：

  邻居 ID 是192.168.10.2。NSX Edge 的传输接口（192.168.10.1）连接到邻居 DLR，DLR 的 IP 地址为192.168.10.2，它们的 OSPF 状态为Full（在此状态下，NSX Edge 和 DLR 已经完全邻接）。当 OSPF 邻接关系建立时，路由器会经历几个状态变化，直到与邻居完全邻接。状态包括Down、Attempt、Init、2-Way、Exstart、Exchange、Loading和Full。我花了很多时间和练习才能理解 OSPF 的基础。我使用 GNS3 进行过无数次实验，并进行了很多 Wireshark 捕获，Wireshark 能提供有关 LSA 包的详细信息，精确展示通信如何进行。对于那些觉得跟不上我步骤的人，我的建议是记录下所有步骤，并不断绘制拓扑图。

• Show IP route：Show IP route命令将显示该路由器的完整路由表：

  从上面的截图中，我们可以看到：

  总共有 8 条路由，其中有三条 OSPF 路由，分别对应网络 172.16.10.0、172.16.20.0 和 172.16.30.0/24

  请查看黄色高亮的列，以了解 NSX Edge 周边网关是通过哪个 IP 地址进行学习的—192.168.10.2（DLR 传输接口）

• Show IP OSPF database：此命令显示 IPv4 OSPF 数据库。故障排除 OSPF 的最糟糕方式就是不查看数据库。我见过的根本问题是，我们发现输出内容非常冗长，不确定从哪里开始以及该看什么。请看以下从 NSX Edge 捕获的 OSPF 数据库输出。即使在一个简单的网络中，拓扑表也看起来非常冗长且令人困惑，假设一个企业网络的 OSPF 数据库呢？以下截图展示了一个 OSPF 数据库：

目前，我们将记录一些配置细节：

• OSPF 是一种链路状态路由协议。根据网络和区域的类型，它将有一个唯一的链路状态表。因此，我们在输出中看到了相同的内容。

• 在我们的例子中，我们有两个区域：

  • 链路 ID - 这是 L1 的 OSPF 路由器 ID，类型为 L2。不过，对于 L3，一个 L5 类型的 LSA 中，链路 ID 是一个网络地址。

  • 区域 10 的链路状态类型：

    • 路由器链路状态

    • 网络链路状态

    • 汇总链路状态

    • 不透明区域链路状态

  • 区域 0（骨干区域）

  • 区域 10（我们创建的普通区域）

这是另一个令人费解的问题：为什么我们在区域 10 中有网络链路状态 LSA？我们所做的只是将 DLR OSPF 路由器通过传输网络连接到 NSX Edge，而传输网络是一个点对点连接。好吧，这就是我需要大家更加集中注意力的地方。传输网络是一个逻辑交换机，它实际上只是一个 vSphere 端口组（L2 段）。这是我们在区域 10 中有网络 LSA 的主要原因。路由器不是点对点连接的；它们是连接到一个逻辑交换机，指定路由器（DR）会发送类型 2 LSA。汇总 LSA 将帮助路由器从一个区域到另一个区域到达前缀。不透明 LSA 在路由平台（MPLS 流量工程）中的实际应用中使用。

够了，解释这张图的目的就是，理想情况下，当 OSPF 路由表被填充后，我们通过做一个简单的 ping 测试来验证，之后我们从不考虑它们实际是如何工作的。关于 OSPF，我们还有很多可以讨论的内容；不过，这些内容超出了本书的范围。让我们看一下以下图示，它展示了整个拓扑以及 OSPF 路由表：

在 DLR 和 NSX Edge 之间具有动态路由能力，我们的三层应用应该能够访问192.168.110.10机器，反之亦然。让我们登录到应用服务器，确认是否能够访问192.168.110.10。

以下截图显示了从应用服务器（172.16.20.11）到外部网络 192.168.110.0/24 的连接成功，这在之前是无法实现的：

这就是我们的路由模块的总结。我知道很难回忆起到目前为止为建立虚拟化路由环境所做的一切。为了便于记忆，我将它总结为六个步骤：

1. 创建了三个逻辑交换机。

2. 从 NSX Manager 部署了一个分布式逻辑路由器。

3. NSX 控制器将 DLR 配置推送到底层的 ESXi 主机。

4. 部署了一个 NSX Edge 设备，并在 Edge 和 DLR 上配置了 OSPF。

5. 所有学习到的路由都会推送到 NSX 控制器。

6. NSX 控制器更新 ESXi 主机 DLR 路由表。

我们现在将进入下一个部分。

NSX 路由设计决策

假设我们已经决定了某个特定用例所需的路由协议。设计因素是确保它们完美运行的关键：

• 如果我们是服务提供商，并且需要为 DLR 控制 VM 和 边缘服务网关 (ESG) 提供多租户支持，我们应该部署一个单独的实例，这将简化管理。我们还可以实现租户之间的真正隔离。

• 区域边界路由器 (ABR) 应该是物理路由器。

• 如果我们没有为 ESG 和 DLR 使用 高可用性 (HA) 功能，请确保租户 ESG 和 DLR VM 不在同一 ESXi 主机上。然而，推荐的做法是为 DLR 控制 VM 和 ESG 启用 vSphere HA。

• 如果 ESG 中接口不足，我们应利用 trunk 接口，使多个 DLR 可以连接到同一个 ESG。

• DLR 与 DLR 之间的对等连接不可行。

• 不支持 IPsec 与动态路由配合使用。

• 在可能的地方使用路由汇总。

• DLR 控制 VM 不支持 ABR 配置；然而，它支持正常和 NSSA 区域。

根据我们选择的物理网络类型和供应商，有很多其他设计参数，我们需要明确遵循这些参数，以确保我们能够兼得两全。我强烈建议在实施 NSX 之前阅读供应商设计指南。我不指望每个人都进行 Google 搜索。在第八章，NSX 故障排除 中，我将提供所有外部指南链接，届时我们应该在部署 NSX 设置之前参考这些链接。

NSX Edge NAT

我们如何合并两个具有重复地址的内部网，并确保分配了私有 IP 的主机能够通过互联网与其他主机通信？只有一个解决方案：网络地址转换 (NAT）。

NSX Edge NAT 支持两种类型的 NAT 服务：

• 源 NAT (SNAT)：将内部私有 IP 地址转换为公共地址以进行出站访问

• 目标 NAT (DNAT)：将公共 IP 地址转换为内部私有地址以进行入站访问

好的，让我们来看看这个功能是如何工作的。在下图中，我们的一个应用服务器需要与公网进行通信。我们可以看到应用服务器172.16.20.1向 NSX Edge 发送了一个外发数据包。根据 NSX 管理员之前配置的 NAT 条目，Edge 会进行 NAT 表查找。由于我们配置了源 NAT，并且该配置是针对172.16.20.1的，因此它会将 IP 地址转换为170.168.2.1，即公网 IP。这是一个非常简单的 1:1 NAT 配置示例，用于外向访问。但请记住，Edge 还具有防火墙功能，默认情况下，它会阻止所有流量。因此，仅进行 NAT 是不够的；我们需要在防火墙表中允许相应的源和目的 IP：

现在让我们继续检查一下在 NSX Edge 中的 NAT 表配置是什么样的：

1. 登录到 VMware vSphere Web 客户端，切换到网络与安全解决方案页面。

2. 在NSX Edge 管理页面，双击处理 NAT 的 NSX Edge 实例。下图展示了 NSX Edge 的 NAT 配置：

   由于目前我们没有创建任何规则，所以此时表中没有任何内容。让我们进一步探讨 DNAT 和 SNAT 选项：

点击添加图标，选择添加 DNAT 规则，并根据业务用例配置以下设置：

• 应用于：应用目标 NAT 规则的接口，例如，外部链接。下拉菜单将显示该 NSX Edge 实例的所有 10 个接口的名称。

• 原始 IP：原始（公网）IP 地址，格式如下：

  • IP 地址 172.168.2.1

  • IP 地址范围 172.168.2.1-172.168.2.3

  • IP 地址/子网 172.168.2.1/24

• 协议：应用程序使用的协议（我们可以简单地更新为任何）

• 原始端口/范围：原始端口、端口范围或任何端口

• 翻译后的 IP/范围：由于这是一个 DNAT 规则，翻译后的 IP 将是内部/私有 IP 范围

• 翻译后的端口/范围：在内部/私有网络中的翻译后端口或端口范围

如果所有前述参数都配置正确，并且防火墙规则已启用相同配置，那么我们的内部机器将可以从公网访问。在我们的示例中，我们进行了 1:1 DNAT 配置。如下图所示：

NAT 是 NSX 负载均衡器功能的一个组成部分，我们需要了解 NAT 如何工作，才能理解这一功能。最后但同样重要的是，我们生活在一个没有完美的世界；当出现问题时，我们需要开始排查。一个常见的问题是，并不是 NAT 配置错误，而是中间的罪魁祸首——防火墙，它阻止了所有流量，人们可能会困惑，我在这个设置中到底错过了什么？ 好吧，不再废话了，让我们继续讨论 NSX Edge 逻辑负载均衡器。

NSX Edge 逻辑负载均衡器

当我们谈论负载均衡器时，传统的负载均衡器通常放置在汇聚层。负载均衡可以通过硬件、软件或两者的组合来实现。负载均衡的早期方法之一是轮询 DNS。在当前的云时代，我们的应用程序运行在多租户环境中，负载均衡的需求也随之增加。简而言之，如果每个应用层都需要一个负载均衡器，那么获得最佳性能将变得极为困难。这就是虚拟负载均衡器相比物理负载均衡器发挥重要作用的地方。

NSX Edge 负载均衡器使得网络流量可以通过多个路径到达特定目标。负载均衡器将传入的服务请求均匀地分配给多个服务器（虚拟机）。因此，负载均衡有助于实现资源的最佳利用，最大化吞吐量，最小化响应时间，并避免过载。NSX Edge 提供最多至第 7 层的负载均衡功能。让我们熟悉一些在所有负载均衡器中都非常常见的负载均衡术语。

服务器池

运行相似应用程序的机器组会被添加到这个池中。这是部署负载均衡器时需要规划的一个关键设计决策。首先，识别需要加入服务器池的虚拟机集。

虚拟服务器

这是服务器池中的机器将从负载均衡器接收会话的地址。每个虚拟服务器将拥有一个唯一的虚拟 IP（vIP）。vIP 是一个 IP 地址，并且还包含服务端口号。

应用配置文件

应用配置文件是我们配置访问协议类型（TCP、HTTP 和 HTTPS）以及需要使用哪种负载均衡算法的地方。NSX 负载均衡器支持多种负载均衡算法。

NSX 负载均衡器有两种模式：

• 代理模式：单臂负载均衡模式也称为代理模式。NSX Edge 网关使用一个接口来发布 vIP 地址并连接到 Web 服务器。

• 内联模式：内联负载均衡模式也称为透明模式。NSX Edge 网关使用以下接口：

  • 用于发布 vIP 地址的接口

  • 用于连接到 Web 服务器的接口

  • Web 服务器必须将 NSX 边缘网关设置为默认网关

负载均衡设计考虑因素

在设置 NSX 负载均衡器时应遵循一些最佳实践。让我们在进行实验之前仔细阅读以下几点：

• 根据服务器池的数量，负载均衡器的数量也会增加。然而，正因为每个租户都有自己的负载均衡器，管理和配置的变更不会影响其他租户的负载均衡器。

• 在 HA 模式下部署负载均衡器以实现高可用性。

• 确保不要在与基础负载均衡机器相同的机器上部署负载均衡器。遵循最佳实践，将其部署在不同的 ESXi 主机或单独的管理边缘集群中。

• 根据应用程序特性选择正确的负载均衡协议。例如，轮询、最少连接、哈希和最少负载是一些常见的算法。

• 一个常见的问题是，我们需要端到端的 SSL 连接，还是需要终止或卸载 SSL 流量？

• 注意负载均衡器的带宽和每秒连接数（CPS）。

• 一个经验法则是在投入生产环境之前测试负载均衡器的功能，特别是如果这是我们第一次在 NSX 环境中对应用请求进行负载均衡的话。

• 最后，我们需要决定是否愿意把所有鸡蛋放在一个篮子里。这与 NSX 负载均衡器有什么关系呢？嗯，请记住，没有任何东西阻止我们在同一个 Edge/DLR 上配置路由/NAT/VPN/DHCP 等 Edge/DLR 服务功能。因此，仔细规划 Edge/DLR 上需要运行的服务类型。

现在是时候回顾我们到目前为止讨论的所有与 NSX 负载均衡器相关的内容了，我们的目标是对 Web 服务器进行 SSL 负载均衡。然而，在本实验中，我不会使用 SSL 证书来配置 Web 服务器；因此，我们将坚持使用客户端到负载均衡器的 SSL 配置。让我们开始吧。首先，我们目前还没有生成任何 SSL 证书。在这个示例中，我们将使用自签名证书并利用它。

生成证书

我们将生成证书请求，并指示 VMware NSX Edge 实例从该请求创建自签名证书：

1. 在左侧导航窗格中，选择NSX 边缘。

2. 在边缘列表中，双击边界网关条目以管理该对象。

3. 点击管理标签并点击设置。

4. 在设置类别面板中，选择证书。

5. 从操作下拉菜单中选择生成 CSR以打开生成 CSR对话框，并执行以下操作：

   • 在通用名称文本框中输入Webload。

   • 在组织名称文本框中输入Loadbalancer。

   • 验证是否选择了RSA作为消息算法。

   • 验证是否选择了2048作为密钥大小。

   • 保留所有其他设置为默认值，然后点击确定。

6. 在证书列表中，选择新生成的签名请求，然后从操作下拉菜单中选择自签名证书。

7. 在提示时，在天数文本框中输入365，然后点击确定。

以下截图展示了生成 CSR界面，我们需要更新到目前为止讨论的所有步骤：

现在我们已经创建了证书，接下来将进行自签名并在负载均衡器配置中使用。以下截图展示了自签名证书的步骤：

设置负载均衡器

我们将按以下步骤顺序设置和测试负载均衡器。

• 设置负载均衡器的全局选项

• 创建一个应用配置文件

• 创建服务监视器以定义健康检查性能

• 创建一个服务器池

• 测试负载均衡器

设置全局选项

设置负载均衡器全局选项的过程如下：

1. 登录到 vSphere Web 客户端。

2. 点击网络与安全，然后点击NSX Edges。

3. 双击一个 NSX Edge。

4. 点击管理，然后点击负载均衡器选项卡。

5. 点击编辑。

6. 选中你希望启用的选项旁边的复选框：

   • 启用负载均衡器：允许 NSX Edge 负载均衡器将流量分配到内部服务器进行负载均衡。

   • 启用服务插入：允许负载均衡器与第三方供应商设备配合使用。

   • 启用加速：启用时，NSX Edge 负载均衡器使用更快的 L4 LB 引擎，而不是 L7 LB 引擎。

   • 日志记录：NSX Edge 负载均衡器收集流量日志。你还可以选择日志级别。

7. 点击确定。

创建应用配置文件

由于我们已启用负载均衡器服务，因此在此步骤中，我们将配置 HTTPS 流量：

1. 在管理选项卡下，点击负载均衡器。

2. 在负载均衡器类别面板中，选择全局配置。

3. 点击右侧全局配置页面上的编辑。

4. 在编辑负载均衡器全局配置页面上，选中启用负载均衡器复选框并点击确定。选择我们之前创建的证书，并将所有其他字段保留为默认值。

5. 插入 X-Forwarded-For HTTP 头帮助你识别使用 HTTP 负载均衡器时客户端的 IP 地址。

6. 在负载均衡器类别面板中，选择应用配置文件。

7. 在顶部面板上方，点击绿色加号以打开新配置文件对话框，并执行以下操作：

   1. 在名称文本框中输入Web-Server。

   2. 点击HTTPS。

   3. 保留所有其他字段为默认值，然后点击确定。

以下截图展示了负载均衡器的应用配置文件配置：

创建服务监视器

我们可以创建一个服务监控器，定义特定类型网络流量的健康检查参数。当你将服务监控器与池关联时，池成员将根据服务监控器的参数进行监控。以下截图显示了默认的服务监控池：

创建服务器池

在此步骤中，我们将创建一个轮询服务器池，该池包含两个 web 服务器虚拟机作为成员：

1. 在顶部面板上，点击绿色加号以打开新建池对话框，并执行以下操作：

2. 在负载均衡器类别面板中，选择池。

   1. 在名称文本框中输入Web-Pool。

   2. 确认算法选择为ROUND-ROBIN。

   3. 在监控选择中，我们可以选择NONE，一个默认的监控池，或我们手动创建的监控池。

   4. 在成员下，点击绿色加号以打开新建成员对话框，并添加第一个服务器。

   5. 点击确定以关闭新建成员对话框。

   6. 在成员下，点击绿色加号以打开新建成员对话框，并添加第二个服务器。

   7. 点击确定以关闭新建成员对话框。

   8. 点击确定以关闭新建池对话框。

3. 在名称字段中输入Web -01a。

4. 在 IP 地址字段中输入172.16.10.11。

5. 在端口字段中，在文本框中输入443。

6. 保留所有其他设置为默认值。

7. 重复相同的步骤，添加我们的第二个 web 服务器，172.16.20.11。以下截图显示了我们配置的池设置：

创建虚拟服务器

虚拟服务器位于连接到外部网络的上行接口：

1. 在负载均衡器类别面板中，选择虚拟服务器。

2. 在顶部面板上，点击绿色加号以打开新建虚拟服务器对话框，并执行以下操作：

   1. 确认已选择启用复选框。

   2. 在名称文本框中输入VIP。

   3. 在IP 地址文本框中输入192.168.100.9。

   4. 从协议下拉菜单中选择HTTPS。

   5. 确认端口设置已更改为 443。

   6. 从默认池下拉菜单中选择Web-Pool。

   7. 确认应用程序配置文件选择为Web-Server。

   8. 保留所有其他设置为默认值，并点击确定。

以下截图展示了我们正在尝试负载均衡的 web-pool 的虚拟服务器配置：

我们在负载均衡设置中没有使用 应用程序 规则。使用应用程序规则时，我们可以灵活地指定 HTTP/HTTPS 重定向；无论 URL 如何，流量都将根据规则始终进行重定向。现在我们只需在浏览器中输入 VIP 192.168.100.9，就能看到流量被重定向到其中一台 Web 服务器。

以下截图显示了针对 web-sv-02a 进行的负载均衡：

我个人讨厌通过查看 GUI 来学习东西。CLI 是我最好的朋友，我已经捕获了实验室拓扑下负载均衡场景的调试输出，以确保每个人都能清楚地理解这些概念：

这就结束了负载均衡的主题，我们都知道，要实现负载均衡，肯定需要一个可用的 NSX Edge 实例来平衡任何流量。

虚拟私人网络

NSX Edge 支持多种类型的 VPN 服务，如 SSL-VPN、L2-VPN 和 IPsec VPN。具体如下：

• SSL VPN-plus：选择 SSL VPN 连接的主要原因是为了那些需要访问位于边界设备后面的私有网络的用户（漫游配置文件）。

• IPsec VPN：NSX 支持 NSX Edge 网关与大多数第三方 IPsec VPN 设备之间的站点对站点 VPN。

• L2 VPN：在当前的云时代，我们有很多场景需要将本地网络扩展到其他站点，这些站点可以是私有云或任何其他公共云服务，如 vCloud Air、AWS 和 Azure。请不要将其与直连解决方案混淆。L2 VPN 中的虚拟机将处于同一子网，无论是否在不同站点之间迁移。

让我们更深入地讨论这些话题，了解它们的特性以及 NSX 在其中的适用位置，最后我们将集中讨论一些设计决策。

SSL VPN

NSX SSL VPN 功能为远程用户提供了一个安全的连接，可以连接到位于 NSX Edge 网关后面的私有网络。我们可以选择基于 Web 的连接方式，或者需要安装 SSL 客户端来访问私有网络。在后台，流量将通过隧道安全地定向到私有网络。以下步骤将按相同的顺序配置 SSL VPN 连接：

1. 配置 SSL VPN 服务器设置。

2. 添加一个 IP 池。

3. 添加一个私有网络。

4. 添加认证。

5. 添加安装包。

6. 添加用户。

7. 验证所有配置并启用 SSL VPN。

以下图示显示了三个站点（A、B、C），它们需要通过 SSL-VPN、IPSEC 和 L2 VPN 设置连接到其他站点：

我们将从 SITE-A 的 SSL VPN 配置开始。

配置 SSL VPN 服务器设置

如前所述，我们需要按照步骤 1 到 7 配置 SSL-VPN 设置：

1. 在 SSL VPN-Plus 标签页中，从左侧面板选择 服务器设置。

2. 点击更改。

3. 选择IPv4 地址或IPv6 地址。

4. 如有需要，编辑端口号。该端口号是配置安装包所必需的。

5. 选择加密方式。

6. 从服务器证书表中，选择要添加的服务器证书。这是一个可选步骤；此外，请不要觉得尴尬，因为我们看到的是一个 Web 负载的 SSL 证书。这个证书是我们在 SSL 负载均衡话题中早些时候创建的。

7. 点击确定。

以下截图展示了 SSL VPN 服务器设置：

添加 ID 池

添加这个池的目的是将虚拟 IP（VIP）从 IP 地址池分配给远程用户。以下截图展示了 IP 池页面：

在我们的示例中，我们选择的范围是192.168.170.2至192.168.170.254，网关是192.168.170.1。DNS/WINS 设置是可选的，因此我们跳过该配置。

私有网络

私有网络是我们希望远程用户连接并访问的网络。以下截图显示了私有网络配置。我们将 192.168.1.0/24 作为 SSL VPN 访问的网络：

请查看以下步骤：

1. 添加认证：支持外部认证服务器，如 AD、LDAP、Radius 或 RSA，或者我们可以简单地创建一个本地用户，使用相同的本地用户名和密码连接到私有网络。

2. 添加安装包：我们可以根据需要访问私有网络的操作系统类型，为远程用户创建 SSL-VPN 客户端安装包。在选择安装包时，有几项登录设置可供选择。

3. 添加用户：由于我们已经添加了认证方式，现在可以继续添加用户来访问私有网络。

4. 启用 SSL VPN 服务：验证完整的配置后，我们需要通过切换到SSL VPN-Plus标签来启用 SSL VPN 服务。选择左侧面板中的仪表板。以下截图显示了服务已成功启用的消息：

现在我们已经成功启用了 SSL 服务，远程用户（192.168.7.1）可以在身份验证后，基于我们之前选择的认证方式，发起 SSL-VPN 连接到私有网络（192.168.1.0/24）。有几种方式可以检查 SSL 会话。最好的也是最简单的方法是直接在客户端机器（192.168.7.1）上，通过在本地操作系统上执行路由查找，我们可以看到一条新的路由已添加至私有网络。完成这一点后，我们将继续进行Site-B的 IPsec VPN 配置。

IPsec VPN

NSX Edge Gateway 支持 NSX Edge 与远程站点之间的站点对站点 VPN。简而言之，原始数据包将进行认证和加密，并将通过Encapsulation Security Payload（ESP）头、尾部和认证数据进行封装。以下截图展示了初始的 IPsec VPN 配置：

由于我们之前已经共享了拓扑，当前的要求是建立 Site-B 与远程站点（192.168.5.0/24）之间的 IPsec 隧道。让我们开始吧。

以下是配置 IPsec 的步骤：

1. 登录到 vSphere Web 客户端。

2. 点击Networking & Security，然后点击NSX Edges。

3. 双击 NSX Edge。

4. 点击Monitor（监控）选项卡，然后点击VPN选项卡。

5. 点击IPSec VPN。

6. 点击添加图标。

7. 为 IPsec VPN 输入一个名称。

8. 在Local Id中输入 NSX Edge 实例的 IP 地址。这将是远程站点的Peer Id。

9. 输入本地端点的 IP 地址。

   提示

   如果您正在使用预共享密钥添加 IP-to-IP 隧道，本地 ID 和本地端点 IP 可以相同。

10. 输入要在站点间共享的子网，使用 CIDR 格式。若要输入多个子网，请使用逗号分隔。

11. 输入Peer Id以唯一标识对等站点。对于使用证书认证的对等设备，必须使用对等设备证书中的常用名称作为该 ID。对于使用 PSK（预共享密钥）的对等设备，ID 可以是任何字符串。VMware 推荐使用 VPN 的公共 IP 地址或 VPN 服务的 FQDN 作为对等 ID。

12. 在Peer Endpoint中输入对等站点的 IP 地址。如果您留空此项，NSX Edge 将等待对等设备请求连接。

13. 输入对等子网的内部 IP 地址，使用 CIDR 格式。若要输入多个子网，请使用逗号分隔。

14. 选择Encryption Algorithm（加密算法）。

    注意

    Pre-Shared Key (PSK)：这表示 NSX Edge 与对等站点之间共享的秘密密钥将用于认证。该秘密密钥可以是最大长度为 128 字节的字符串。NSX IPsec VPN 支持对称密钥。Certificate（证书）：这表示将在全局级别定义的证书用于认证。

15. 如果匿名站点要连接到 VPN 服务，请输入共享密钥。

16. 点击Display Shared Key以显示对等站点的密钥。

17. 在Diffie-Hellman (DH) Group中，选择加密方案，使对等站点和 NSX Edge 可以通过不安全的通信通道建立共享密钥。

18. 如果需要，编辑默认的 MTU。

19. 选择是否启用或禁用Perfect Forward Secrecy（PFS）阈值。在 IPsec 协商中，PFS 确保每个新的加密密钥与任何先前的密钥无关。

20. 点击OK。

21. 启用 VPN。

22. 根据我们的拓扑，我们已经在 Edge 中更新了 IPsec 配置。一旦我们配置好合作设备，IPsec 隧道将建立：

NSX Edge 使用的 IKE 阶段 1 参数包括：

• 主模式

• AES / AES 256 优先 / TripleDES /

• SHA-1

• MODP (DH) 组 2（MODP1024 位）

• 预共享密钥 [可配置]

• SA 生命周期为 28800 秒（八小时），无千字节重新密钥交换。

• 禁用 ISAKMP 攻击模式

NSX Edge 支持的 IKE 阶段 2 参数包括：

• AES / AES 256 优先 / TripleDES / [将与第 1 阶段设置匹配]

• SHA-1

• ESP 隧道模式

• MODP (DH) 组 2（MODP1024 位）

• 完美转发保密性用于重新密钥交换。

• SA 生命周期为 3600 秒（一小时），无千字节重新密钥交换。

• 使用 IPv4 子网选择两个网络之间所有 IP 协议和所有端口的选择器。

L2 VPN

L2 VPN 允许我们在两个站点之间配置隧道。如前所述，虚拟机将处于相同的子网，不管它们在哪个位置移动。根据我们的拓扑，我们需要在 Site-C 和远程站点 192.168.5.0/24 之间建立 L2-VPN。在我们的示例中，我们将 Site-C 作为 L2 VPN 服务器，远程站点作为 L2 VPN 客户端。L2 VPN 服务器是源 NSX Edge 服务器，目标 L2 VPN 客户端将连接到该服务器。

前提条件

分配给 L2 VPN 服务器和客户端的内部 IP 地址必须不同，它们可以在同一子网内。

以下是 L2 VPN 服务器的配置过程：

1. 登录 vSphere Web 客户端。

2. 点击网络与安全性，然后点击NSX Edge。

3. 双击一个 NSX Edge。

4. 点击管理选项卡，然后点击VPN选项卡。

5. 点击L2 VPN，选择服务器，然后点击更改。

6. 展开服务器详细信息。

7. 在监听器 IP中，输入 NSX Edge 外部接口的主 IP 或次 IP 地址。在我们的示例中，IP 地址为 192.168.9.1。

8. L2 VPN 服务的默认端口为443。如有需要，可以编辑此端口。

9. 选择加密方法。

10. 选择正在延伸的 NSX Edge 的内部接口。此接口必须连接到 DV 端口组或逻辑交换机。

11. 输入描述。

12. 展开用户详细信息并输入用户名和密码。

13. 在服务器证书中，执行以下操作：

    1. 选择使用系统生成的证书，以便使用自签名证书进行认证。

    2. 选择用于认证的签名证书。

14. 点击确定：

监听器 IP：192.168.9.1

监听器端口：443

加密算法：AES256-SHA

内部接口：内部接口-A

用户 ID：vpn-user

服务器证书：TEST.LOCAL

配置 L2-VPN 客户端时，我们只需要更新客户端应连接的服务器地址和需要延伸的内部接口。除了这些细节，其他配置相同，L2 隧道之后会启动并运行。

• L2VPN 服务状态：启用

• 服务器地址：192.168.9.1

• 服务器端口：443

• 内部接口：内部接口-B

• 用户 ID：vpn-user

配置 VPN 时的设计决策

配置 VPN 时我们需要注意的几点：

• 不支持基于路由的 VPN，NSX Edge 仅支持基于策略的 VPN

• 我们最多可以在 10 个站点之间建立 64 个隧道

• 在 VPN 配置中支持 NAT 穿越

• 不允许子网重叠

• 路由汇总支持对等端和本地子网。

• 不支持通过 IPsec 隧道进行动态路由

• NSX Edge 支持基于预共享密钥和证书的认证。

• 我曾在一些第三方供应商那里看到预共享密钥中存在特殊字符的问题，因此需要注意特殊字符。

这就结束了 VPN 密钥设计决策，通常建议不要偏离产品不支持的配置方式来设置 VPN。

DHCP 中继

动态主机配置协议（DHCP）自动分配 IP 地址。这是我们都知道的。然而，这种模型确实有一个缺点：DHCP 服务器和客户端必须在同一个广播域内。简而言之，DHCP 中继代理在不同网络之间转发 DHCP 消息。这是一个新功能，已在 NSX 6.1 中加入，可以应用于 DLR 或 NSX Edge。在早期版本的 NSX 和 VCNS 中，我们只能配置传统的 DHCP 服务器。需要注意的是，我们不能有重叠的子网。但如果我们希望每次虚拟机启动时获得相同的 IP 呢？在这种情况下，NSX DHCP 静态绑定可以解决问题。我们可以简单地将 IP 地址绑定到虚拟机的 MAC 地址。

总结

本章开始时，我们介绍了 NSX Edge，随后涵盖了路由协议、NSX Edge 服务、使用案例和一些设计考虑事项。这无疑是一个较长的话题，解释这些内容的目的就是通过几个实验和拓扑尽可能提供有价值的信息。我坚信，在不久的将来，我们会看到更多新功能添加到 NSX Edge 服务中。例如，作为边界设备的 NSX Edge，我们非常期待看到 WAN 加速功能或基于策略的路由。

通过目前所获得的技能，我们已经可以开始进入下一章，讨论 NSX 安全功能和设计决策。我们将仔细研究 NSX 安全策略、组以及一些使用案例。

第六章：NSX 安全特性

传统上，隔离和保护网络是在任何数据中心的边界层面完成的，这是一项容易出错且耗时的活动。在当前的软件定义数据中心（SDDC）环境中，大多数工作负载是动态的，我们需要更好的安全控制功能，同时希望这些任务的配置和管理能够实现自动化，而不影响任何安全特性。如果虚拟机从一台服务器迁移到另一台服务器，我的所有策略应当随之移动，而不受第 2 层和第 3 层边界的限制。但真正的问题是，这真的可能吗？在本章中，我们将讨论 NSX 如何改变现代数据中心安全的视角。我们将通过一些经典示例来讨论以下主题：

• NSX 分布式防火墙

• NSX 服务编排器

• NSX 分布式防火墙监控

• NSX SpoofGuard

• DFW 要点总结

NSX 分布式防火墙

NSX 分布式防火墙 (DFW) 关注东西向流量，NSX Edge 防火墙关注南北向流量。那些还记得 vCloud 网络安全时代的朋友会觉得这像是 vShield 应用的增强版。好吧！现在，我当然同意这一点；它无疑是 vShield 应用防火墙的功能增强版。但该应用要求你为每个主机运行一个专用的防火墙虚拟机，并且无论虚拟机移动到哪里，都能保持保护。除了它需要一个特定于虚拟化平台的防火墙（FW）虚拟机外，它还是一个功能单一的防火墙，安装和故障排除也稍显繁琐。NSX 分布式防火墙是一个内嵌在虚拟化内核中的防火墙，策略完全与虚拟化环境兼容。这意味着什么？我们可以在 vCenter 对象上应用策略，如数据中心、集群、虚拟机名称和标签，以及网络构件，如 IP/VLAN/VXLAN 地址。如果我们在 NSX Edge 和分布式防火墙中添加了相同的防火墙规则，会发生什么？哪个策略会首先被执行？这个问题有两个答案。如果流量是从虚拟机流出的，显然会首先检查分布式防火墙规则，主要是因为它是基于虚拟网卡（VNIC）的防火墙策略。然而，如果流量是进入虚拟数据中心，NSX Edge（我们的边界设备）将是防火墙规则表检查的第一点，之后还会进行 VNIC 级别的过滤。是时候提出几个问题并证明为什么它是一个功能丰富的防火墙了：

• 我们能否基于虚拟机名称或操作系统名称动态创建防火墙规则？

• 我有一个域用户A，我们需要基于用户访问A来允许和阻止一些规则。这能实现吗？

• 我有两个租户，并且分别使用 IPv4 和 IPv6；我们能否不受 IP 栈限制，利用分布式防火墙功能？

• 我们是否可以基于防火墙规则监控两台虚拟机之间的网络活动？这样可以确保我们的规则按预期工作，或者在需要时我们可以采取主动措施。

• 我正在将虚拟机从集群 A 迁移到集群 B；它会保留安全/防火墙策略吗？我需要在物理网络中添加/删除任何安全/防火墙设置吗？

• 我们是否可以在不更改/影响现有物理网络拓扑的情况下，实施一些网络安全策略？

前面的问题并不是完整的清单。然而，除了想了解当我们使用 NSX 分布式防火墙时是否具备某些安全特性 X 之外，根本性的问题是，是否可以将我的传统物理网络安全控制迁移到 NSX 环境中，使我的功能和策略更具虚拟化感知？或者，另一个问题是，它们是否是具有应用感知的策略，能够查看用户、进程、使用情况等？别误会，我们并不是要取代/删除所有物理网络的安全设置并将其复制到 NSX 环境中。我们需要的是一个更安全的网络虚拟化平台。NSX 分布式防火墙提供了一种微分段功能，可以解决许多网络安全挑战。由于防火墙模块运行在 ESXi 主机内部，我们将始终获得更好的吞吐量，策略配置、删除和监控都可以通过一个单一的管理控制台——vSphere Web 客户端来完成。在讨论防火墙规则及其工作方式之前，让我们了解涉及的组件及它们如何相互通信。正如下图所示，我们有 vSphere Web 客户端、NSX 管理器和加载了所有 VIBS 的 vSphere 集群。通过 Web 客户端连接到 vCenter 服务器后，我们可以创建安全策略，NSX 管理器将把这些策略推送到 vSphere 服务器。VMware 服务插入平台（VSIP），这是 DFW 内的一个模块，将把策略应用于底层的虚拟机。任何新一代或传统的基于端口的防火墙都会拥有一个智能规则表，而 NSX DFW 也不例外。与 DFW 相关联的有两个表：

• 规则表

• 连接表

虽然规则表维护着所有规则，但连接表将根据我们创建的规则类型跟踪活动连接：

既然我们已经对分布式防火墙有了基本的了解，那么同样重要的是要知道，DFW 是完全虚拟化感知的防火墙，我们可以在以下 vCenter 服务器对象上设置防火墙规则：

• 数据中心

• 集群

• vSwitch 端口组

• 分布式交换机端口组

• 虚拟应用（vAPP）

• 资源池

• 虚拟机

• vNIC

• 逻辑交换机

• 安全组

• IP 集合

• NSX 服务组合器

NSX Service Composer 是一个内置功能，允许你在安全组和安全策略的帮助下配置安全服务、防火墙规则和安全策略。我们可以创建安全组和安全策略，并可以使用 NSX Service Composer 应用安全组和安全策略的组合，这无疑是自动化规则/策略创建任务的一个极好方法。简而言之，我们正在执行两项任务，最终的结果是实现 NSX 世界中网络安全的自动化：

部署 + 应用 = 网络安全自动化

但问题是，我们要部署什么，并且要在哪里应用它？为此，我们需要了解什么是安全组和安全策略。

安全组

安全组是我们定义要保护的资产类型的地方，我们可以通过动态方式选择资产来定义该组，或者我们可以简单地创建一个静态成员组。我们将回过头去阅读本章中的问卷部分：

我们能否基于虚拟名称或操作系统名称动态创建规则？

这使我们更清晰地理解了为什么动态成员在创建安全组时会成为一个关键因素。简而言之，当我们创建一个动态成员组，并选择包含所有 Windows 系统版本并应用安全组和安全策略时，这将是我们使用 DFW 防火墙智能创建和保护虚拟机的最简单方法。

安全策略

安全策略是安全服务和防火墙规则的组合。策略可以是防病毒、数据安全、漏洞、网络内省和防火墙规则的组合。

好的！但如果我们需要创建一个动态组，同时排除运行在特定逻辑交换机上的虚拟机，并且所有这些配置都应该是同一个安全组的一部分，那么该怎么办呢？这就是安全组的真正力量：所有这些配置都可以作为一个安全组的一部分，在这种情况下，我们的安全组将是这样的：

动态包含 + 静态包含（如果需要，我们仍然可以有静态包含列表） - 静态排除 = 安全组。

创建服务组

在对安全组和安全策略有了基本了解后，我们将继续讨论其中一个安全需求，以展示该功能的强大。让我们看看利用 DFW 功能保护流量的一个网络需求，并讨论实验练习。根据以下拓扑图，我们的三层应用程序运行在三个逻辑交换机和一个传输网络上：

• App-Tier-01

• Web-Tier-01

• DB-Tier-01

• 传输网络

在下图中，通过利用 NSX DFW，我们将在 Web-Tier 逻辑交换机中禁用 ICMP 流量，最终的结果将是 Web-Tier-01 逻辑交换机中的 Web 服务器将阻止 ICMP 流量：

在开始之前，让我们做一个简单的 ping 测试，以确认是否允许 ICMP。以下截图显示了连接到同一逻辑交换机 Web Tier-01 的 web-01a 和 web-02a 之间的 ICMP 流量成功：

配置分布式防火墙规则时，我们有两种方法：

• 通过选择 Firewall | Networking & Security | Firewall

• 通过选择 Service Composer | Networking & Security | Service Composer

在这个示例中，我正在使用 Service Composer。让我们创建一个名为 Web Security-Group 的安全组：

在动态成员列表中，我们没有选择任何选项。然而，值得关注的是 Criteria Details 选项，以便清楚地了解可用于定义动态成员组的选项，如下图所示。例如，如果我们在下面的条件列表中选择虚拟机名称，并在白色文本框中输入 Windows 并创建安全组，则任何在 vCenter 服务器中部署的现有/未来虚拟机都会应用 DFW 策略。这是一个非常强大的功能，它可以简化很多重复任务，当一组虚拟机需要相同的策略时，此外，之后对同一组虚拟机的策略添加和删除只需要一步操作：

在静态包含列表中，我们将 Object Type 设置为 Logical Switch，这样我们就可以在下面的截图所示的 Web-Tier-01 逻辑交换机上应用策略：

接下来做什么？我故意将一台 Linux VM 连接到我们的 Web-Tier，目的是排除我们正在创建的安全组策略中的 Linux。尽管我们是在逻辑交换机级别创建安全组，但我们仍然可以通过指定排除条件来以这种方式过滤我们的策略。简而言之，策略是在逻辑交换机级别应用的，但并不是应用于连接到同一逻辑交换机的所有虚拟机。正如我们从以下截图所看到的，我们将 Object Type 设置为 Virtual Machine，并排除了 Linux-01a：

完成此步骤后，我们就完成了安全组的创建，并且可以在 Service Composer | Networking & Security | Service Composer 中看到创建的 web 安全组。我已经特别标出虚拟机，因为我希望大家关注虚拟机编号，它显示为 1。通过相同的步骤，我们将创建另一个名为 Web2Security 的安全组，并在静态包含中包括 Web-02a 虚拟机。

那么让我们回顾一下我们的示例中的两个安全组规则：

• 安全组（Web Security-Group）= 动态包含（未选择任何项）+ 静态包含（选择了 Web-Tier 逻辑交换机） - 静态排除（排除了 Linux 虚拟机）

• 安全组（Web2Security）= 动态包含（未选择任何项）+ 静态包含（Web-02a） - 静态排除（未选择任何项）

以下截图展示了我们创建的两个安全组，我们还可以看到虚拟机数量也显示在那里：

创建安全策略

正如我们之前讨论的，策略是安全服务的集合，如防病毒、IPS/IDS 解决方案和 DFW 规则。

在创建策略之前，如果需要，我们需要通过权重属性来确定策略的优先级。此功能的主要目的是，在某些情况下，某些对象（在我们的示例中，我们将虚拟机作为对象）会属于多个策略。根据哪个策略的权重属性较高，较高权重的策略将优先于较低权重的策略。除此之外，如果我们正在创建的策略从另一个安全策略中获取服务，我们需要选择父策略。

以下截图展示了一个安全策略正在被创建；我们将其命名为 Web Security-Group：

由于在本示例中我们没有使用来宾内省和网络内省服务，我将跳过这些配置，直接进入防火墙规则。这两种配置在以下场景中非常有用：

• 数据安全或第三方解决方案提供商服务（如防病毒或漏洞管理服务）需要端点服务。

• 为了在我们的环境中检测敏感数据，如 支付卡行业（PCI）、受保护的健康信息（PHI）和 个人身份信息（PII），我们可以创建数据安全策略。当我们运行扫描时，数据安全会识别违反您策略的规定的数据，并且会被防火墙策略阻止。

• 监控网络的网络内省服务，例如 IPS。

让我们更仔细地查看防火墙源和目标规则：

• 源：策略安全组

• 目标：Web2Security Group

• 服务：我们正在阻止所有 ICMP 流量（选择了总共 4 种 ICMP 流量，我们很快会看到这些）

以下截图展示了前面的规则：

现在我们的安全策略和安全组已经创建完毕，我们可以通过点击以下截图中展示的 应用策略 选项，将策略应用到我们之前创建的 安全组：

在应用安全策略时，NSX 将向我们展示已创建的所有安全组，我们需要确保将其应用于正确的安全组。选择错误的安全组将严重影响网络流量。此外，我们可以看到应用策略下方有一个同步防火墙配置选项。建议在修改策略时同步防火墙配置。NSX 6.2.3 的最新版本有一个很好的迹象，即如果安全策略不同步，将生成一个不同步安全策略的告警。但是，请注意 NSX Manager 的早期版本，除非报告问题并在故障排除后隔离问题，否则我们永远不会知道策略是否不同步。

测试防火墙规则

接下来呢？如果我们到目前为止一直都很警惕，我们将会看到这些规则在防火墙 | 网络与安全 | 防火墙中得到填充。以下屏幕截图描述了我们为以下目的创建的 Web 安全规则：

• 来源：Web 安全组（Web-01a）

• 目标：Web2 安全（Web-02a）

• 服务：4 个 ICMP 协议，操作为阻止

现在是时候测试我们迄今配置的内容，并且我将向您展示 ESXi 主机上详细的防火墙摘要。正如我们从以下屏幕截图中可以看到的那样，我们正在web-02a机器上有一个 SSH 会话，并且我们能够 ping 通 172.16.10.11（web-01a）：

现在，如果我们从web-01a到web-02a进行 ping 测试，如下面的屏幕截图所示，结果将会失败，主要是因为我们创建的ICMP DROP规则：

我坚信我们的 DFW 基础知识是非常清晰的。尽管我们即将进行故障排除章节，我非常兴奋地向您展示一个信息丰富的输出，我们可以从底层主机中检查和查看。我们所需做的就是对我们的 Web 服务器正在运行的 ESXi 主机进行 SSH 会话，并发出以下命令：

summarize-dvfilter

分布式虚拟过滤器是监控由 NSX DFW 保护的出站和入站流量的模块。因此，这个命令会显示相同的输出。以下命令输出适用于 Web-02a 虚拟机，让我们记下与VM - nic-60841-eth0-vmware-sfw.2相关联的 vNic 插槽 2 的名称：

正如我们可以看到的，前述命令和输出并没有提供关于与该虚拟机相关的所有 DFW 规则的任何信息，让我们在同一主机中发出以下命令：

Vsipioctl getfwrules -f nic-60841-eth0-vmware-sfw.2

以下屏幕截图清楚地显示了所有规则。我已标记了DROP规则，我们总共有四条规则，这些仅仅是我们几分钟前创建的 ICMP 规则：

如我之前所说，分布式防火墙的完整集中管理是通过 vSphere web 客户端完成的，至于规则，我们将提供名称、源和目标实体、服务类型、所需的动作以及规则生效的位置。除了常规规则创建，DFW 还支持基于身份的防火墙。

理解基于身份的防火墙规则

让我重申我们在讨论 DFW 时遇到的第二个问题：

我有一个域用户 A，我们需要根据用户 A 的访问权限允许和阻止一些规则。这可以实现吗？

使用基于身份的防火墙，我们可以根据Active Directory（AD）组定义防火墙规则。显然，使用基于身份的防火墙时有一些前提条件和限制，我们稍后将讨论。首先，我们需要在 NSX Manager 中注册 AD。

AD 注册过程

我们将按照以下步骤在 NSX Manager 上注册 AD：

1. 首先，我们将登录到 vSphere web 客户端。

2. 点击网络与安全，然后点击NSX 管理器。

3. 在名称列中点击一个 NSX Manager，然后点击管理标签页。

4. 点击域标签页，然后点击添加域图标。

5. 在添加域对话框中，输入完全限定的域名和域的 netBIOS 名称。下图展示了上述步骤：

6. 在LDAP 选项页面中，指定域控制器与域同步，并选择协议。

7. 如有需要，编辑端口号。

8. 输入域账户的用户凭据。该用户必须能够访问目录树结构。

   下图显示了配置期间需要填写的 LDAP 配置：

   

9. 在安全事件日志访问页面中，选择连接方法以访问指定 LDAP 服务器上的安全事件日志。如有需要，可更改端口号。

10. 选择使用域凭据来使用 LDAP 服务器用户凭据。如需指定备用域账户进行日志访问，请取消选中使用域凭据，并指定用户名和密码。指定的账户必须能够读取域控制器上的安全事件日志。

11. 点击下一步。

12. 在准备完成页面中，检查您输入的设置。

13. 点击完成。

一旦按照上述步骤配置了所需的 AD 详细信息，NSX 管理器与 AD 的同步将开始。只有在同步正确完成后，我们才应开始使用身份防火墙（IDFW）。这是一次性任务，后续的同步是自动进行的。接下来怎么办？我们可以简单地创建安全组（AD 组）和安全策略（防火墙策略），并根据业务需求允许/拒绝服务。下图展示了 AD 与 NSX 管理器的集成，AD 组 MG 作为源，目标是允许 http 和 icmp 服务的 Windows 机器组：

NSX 流量监控

网络监控工具总是很难设置、配置和分析。到目前为止，大多数人可能已经配置了第三方监控工具来分析网络流量，并根据情况采取相应的行动。也许我们可以在几个点捕获数据包，并使用 Wireshark 进行分析。在这种情况下，我们真的喜欢从一个管理控制台切换到另一个管理控制台吗？我们是否满意第三方监控软件，并期望它展示所有类型的流量集成？我知道大多数人都不喜欢这种依赖供应商的工具。我们需要一种能够帮助我们快速分析情况并采取积极措施的工具。NSX 流量监控是一个内置功能，可以提供对任何流量的可视化和控制。简而言之，它配置分布式防火墙以捕获流量，我们可以分析流量流动。流量监控数据包括每个会话传输的会话数和数据包数。会话详情包括源、目标、应用程序和使用的端口，之后我们可以根据会话详情创建防火墙允许或阻止规则。默认情况下，显示的是过去 24 小时的数据，最短时间跨度为 1 小时，最长为 2 周。

启用流量监控：

1. 登录到 vSphere Web 客户端。

2. 从左侧导航窗格中选择网络与安全，然后选择流量监控。

3. 选择配置选项卡。

4. 确保全局流量收集状态已设置为启用，并且我们没有更改详细收集策略。

以下截图显示了全局流连接状态设置为启用：

好的！我们已经启用了流量监控，并且应该能看到一些流量统计数据。在我们的例子中，我们将快速检查来自 Windows 2008 机器（192.168.2.2）的实时流量。

捕获实时流量：

1. 登录到 vSphere Web 客户端。

2. 从左侧导航窗格中选择网络与安全，然后选择流量监控。

3. 点击实时流量选项卡。

4. 点击浏览并选择windows-2008（IPSEC）NIC。

5. 点击开始以开始查看实时流量。

下图展示了实时流量统计，我已突出显示了当源主机 windows-2008 192.168.2.2 尝试与目标 IP 192.168.4.2 通信时应用的阻塞规则：

如我们所见，这是一个很棒的功能，我们不仅可以轻松了解哪些流量是被允许的，哪些是被阻止的，还可以查看进出字节数，这对于我们想了解哪个源发送了更多字节，或是我们从哪里接收到更多入站字节非常重要。在我们的案例中，TCP-SYNC 数据包被发送，但没有收到回复，因为我创建了一个 DFW 规则，阻止了 192.168.2.2 和 192.168.4.2 之间的流量。

NSX SpoofGuard

NSX 的另一个强大功能是 SpoofGuard。SpoofGuard 功能将监控和管理虚拟机的 IP 地址。好吧！我们为什么需要这样一个功能呢？如果虚拟机被不小心攻破，会发生什么？黑客肯定可以更改 IP 并绕过所有防火墙策略，后果不堪设想。SpoofGuard 为我们提供了更细致的控制，确保所有 IP 地址更改都经过批准，直到流量被阻止。只要我们安装并运行了 VMware 工具，NSX 管理器就会收集虚拟机的 IP 地址。

SpoofGuard 支持以下方法：

• 首次使用时自动信任 IP 分配：此模式允许所有来自虚拟机的流量通过；此外，它会建立一个 vNIC 到 IP 地址分配的表格。这样，我们可以查看此表并进行 IP 地址更改。IPv4 和 IPv6 都受支持。

• 手动检查并在使用前批准所有 IP 分配：此模式在您批准每个 vNIC 到 IP 地址的分配之前，阻止所有流量。

这引出了另一个问题。使用 DHCP IP 的虚拟机会怎么样？它们会获得 IP 分配吗？我们需要批准它们的 DHCP IP 分配吗？

如果我们了解了支持的 SpoofGuard 方法，答案就非常简单了。只有在 手动检查 中，DHCP 流量才不会被允许，直到我们批准请求；此规则同样适用于 DHCP。如果我们正在手动检查 IP 分配，那么 DHCP 将被阻止。话虽如此，基于以下场景，让我们进行实验测试：

运行在 Web 服务器逻辑交换机上的虚拟机应检查所有 IP 分配。

SpoofGuard 配置过程

我们需要执行以下步骤来配置 SpoofGuard：

1. 首先，登录到 vSphere Web 客户端。

2. 点击 Networking & Security，然后点击 SpoofGuard。

3. 点击添加图标。

4. 为 SpoofGuard 策略输入一个名称。

5. 我们可以根据业务需求立即启用或禁用。

6. 对于 操作模式，我们选择 手动检查并在使用前批准所有 IP 分配。以下截图展示了 SpoofGuard 的初始配置：

7. 要指定需要应用 SpoofGuard 策略的位置，请点击 添加 并选择此策略应该应用的网络、分布式端口组或逻辑交换机。在我们的示例中，我们正在配置 Web-Tier 逻辑交换机，如下图所示：

8. 由于我们已将 SpoofGuard 设置为需要手动批准所有 IP 地址，让我们检查一下该分配。

在下面的截图中，我们查看的是 虚拟网卡 IP 需要批准屏幕，这是在流量可以进出这些虚拟机之前，需要批准的 IP 地址更改。其他可用选项如下：

• 活动虚拟网卡

• 自上次发布以来的活动虚拟网卡

• 具有重复 IP 的虚拟网卡

• 非活动虚拟网卡

未发布的虚拟网卡 IP：

要批准一个 IP 地址，我们需要点击 批准，位于 IP 地址选项旁边。这就总结了我们对 NSX 安全性和监控的详细讨论。确实可以与 NSX 进行更多集成，例如与 vRealize 操作管理（之前的 VROPS）、vCloud Director 集成、与 NSX 的 vRealize Automation、NSX 与第三方软件（如 Palo Alto 网络、Check Point 等）集成。考虑到 NSX 在市场上所带来的积极动力，越来越多的集成将不断涌现，这使得所有架构师的工作更加轻松。了解这些集成绝对值得；请阅读我将在 第八章中提供的链接，NSX 故障排除。最后，让我们快速看一下需要注意的几个关键点。

分布式防火墙要点

分布式防火墙是功能丰富的防火墙。但在安装和创建规则时，我们必须格外小心。过去使用巨型物理防火墙进行流量过滤和其他安全措施的时代已经过去。应用程序要求防火墙更靠近它们，而不是运行在 机架顶部 (TOR)的位置。我们所需要的仅仅是一个更具应用感知的有状态防火墙。当我们在近线速率处理下检查流量，特别是对于东西向流量时，这将为我们提供更好的流量可见性并减少虚拟化数据中心中的攻击漏洞，我们可以称 NSX DFW 防火墙为 微分段的基础支柱。担心瓶颈问题？没问题！DFW 是新来的小伙伴。让我们快速浏览一下本章的一些关键要点。

DFW 不需要任何物理网络拓扑更改。

请注意 vSphere 环境中安装的所有管理虚拟机（VMware 设备、第三方设备、AD、DNS 和 Exchange 等），并决定哪些应该成为 DFW 保护的一部分。

VSphere 交换机不支持策略执行；仅支持逻辑交换机和分布式交换机端口组。DFW 完全支持 IPv4 和 IPv6。

从 NSX 6.2 开始，DFW 规则即使没有 VMware 工具也支持利用 vCenter 服务器对象。NSX 6.1 及以上版本在防火墙操作中新增了一个名为 拒绝（reject）的选项。这个操作在 NSX Edge 上也可用。

NSX 6.2.3 支持 简单文件传输协议（TFTP）-ALG 分布式防火墙规则。

基于身份的防火墙仅支持 Windows 客户端，非常适合东西向数据中心流量。然而，我们可以将其与 NSX Edge 防火墙和物理防火墙一起配置，从而为整个数据中心提供端到端的安全性。

从 vCenter 删除或添加 vSphere 虚拟机不会删除任何 DFW 规则。如果你想完全排除某个虚拟机免受 DFW 保护，请使用 排除列表 功能。关于排除列表的详细内容，我将在 第八章，NSX 故障排除 中讨论。

如果我们利用身份防火墙功能，并且由于某些原因，NSX 管理器与 Active Directory 之间存在同步问题，这将直接影响 DFW 规则。因此，这是一个管理平面（NSX 管理器）故障导致数据平面流量问题的场景，因为防火墙受到影响。

如果我们需要识别应用程序并允许/阻止流量，无论端口和协议信息如何，对于这种使用场景，最佳的防火墙方案是将像 Palo Alto 这样的下一代防火墙与 DFW 集成。

在 vSphere 管理集群中安装 DFW 功能不是强制的；如果我们想安装 DFW，请注意 VCenter 服务器机器。确保该机器从列表中排除。如果在同一集群中运行其他第三方管理软件，DFW 无法智能地将其排除在保护之外。我在 VCNS 时代就遇到过这个错误：突然间，VC 无法访问所有管理组件。点击 安装 按钮就可能导致重大生产中断。

总结

我们以介绍 NSX 安全性开始了本章，随后讲解了 DFW 架构、使用案例和功能。我们还讨论了 NSX 中可用的监控选项，最后，我们总结了在安装 NSX 安全功能之前需要注意的要点。

在下一章，我们将讨论跨 VC 的 NSX，涉及多站点解决方案，包括逻辑交换机、分布式逻辑路由器及跨多个 vCenter 域的 DFW 安装和配置。

第七章：NSX 跨 vCenter

在本章中，我们将详细讨论 NSX 跨 vCenter 的功能。从 NSX 6.2 开始，我们可以通过跨 vCenter 环境利用 NSX 功能，从一个统一的界面管理多个 vCenter Servers。我们将主要覆盖以下主题：

• 理解 NSX 跨 vCenter Server

• NSX 跨 vCenter Server 组件

• 跨 vCenter 通用逻辑交换机

• 跨 vCenter 通用逻辑路由器

• NSX 跨 vCenter Server 的网络瓶颈

理解 NSX 跨 vCenter Server

早期版本的 NSX 与 vCenter Server 存在 1:1 的关系，这意味着 NSX 功能仅限于特定的 vCenter Server。因此，每当我们扩展 vCenter Server 时，需要单独安装和配置 NSX Manager，并且每个环境都必须单独管理。当 VMware 在 2015 年 8 月发布 NSX 6.2 时，安全性和跨 vCenter Server 网络功能成为了令人兴奋的新增功能。通过跨 vCenter 的网络和安全功能，我们可以在 vCenter 边界之间扩展逻辑交换机，此外，我们可以无缝地跨 VCs 扩展分布式路由和分布式防火墙，为两个站点提供真正的网络混合性。客户可以通过这一跨 VC NSX 集成功能受益的使用案例有很多，以下是其中的一些：

• 通过利用跨 vCenter Server，我们可以拥有一个主 vSphere 环境和一个备份 vSphere 环境，并且可以轻松配置灾难恢复站点。

• 无缝地将工作负载从一个 vSphere 环境迁移到另一个环境。

• 简化的跨 vCenter Server 站点数据中心路由；集中式安全策略管理；防火墙规则可以从一个集中位置进行管理。

• NSX 功能可以在本地部署（单个 vCenter Server）；也可以跨 vCenter Server 部署（跨 vCenter Server）。这样，本地对象可以在本地管理，而全局对象可以在全球管理。

下图描述了一个跨 vCenter Server 的 NSX 环境：

我知道大家都很想了解 NSX 跨 VC 的工作原理。但在讨论此功能之前，让我们先明确一些前提条件和几个要点：

• vSphere 环境应该是 6.0 版本。

• 每个 vCenter Server 应该与一个唯一的 NSX Manager 注册。好吧！这个点很有趣，不是吗？当我第一次听说跨 VC NSX 架构时，我以为我们将来只需要一个 NSX Manager。但通过进一步的阅读和实验，证明我的理解是错误的。

• 我们必须将一个 NSX Manager 提升为 主，其他的将是 备。

• 我们当然可以根据业务需求降级 NSX 角色。例如，一个次级 NSX Manager 可以降级为独立的 NSX Manager，这样我们就回到了 NSX 最初开始时的状态（6.2 版本之前的 NSX）。

• 尽管跨 VC NSX 是一个很好的架构，但我仍然认为它是一个新兴的解决方案，并且缺乏独立 NSX Manager 实例中可能具有的所有功能。抛开这些负面看法，我坚信 NSX 的新版本将会开始支持跨 vCenter 服务器的所有功能。

• 仔细规划并集成跨 VC 的 NSX 环境；具体来说，关注我们在主站点和次站点中需要的功能，以及如何管理这些功能。例如，如果我们仅在次站点需要分布式防火墙功能，我不建议进行跨 VC 的 NSX 集成，除非我们希望从一个统一界面管理这些防火墙策略。

NSX 跨 vCenter 服务器的组件

跨 vCenter NSX 包括以下组件：

• 通用控制器集群

• 通用传输区域

• 通用逻辑交换机

• 通用分布式逻辑路由器

• 通用 IP 集合

• 通用 MAC 集合

• 通用安全组

下表展示了 NSX 跨 vCenter 服务器部署选项；基于这些要点，我们将进行详细解释：

在上表中，我已更新了客户理想情况下会在跨 vCenter NSX 环境中配置的关键 NSX 功能。其他功能，如负载均衡和 L2 桥接，在 NSX 站点之间没有全局级别的适配，因此它们始终局限于 vCenter Server 环境。 在探讨通用 NSX 功能之前，我们需要了解 NSX Manager 可用的角色。

NSX Manager 实例具有以下角色，并且在主 NSX Manager 上将运行同步模块，以确保通用对象能够同步到次级 NSX Manager。NSX Manager 实例具有以下角色：

• 独立：在配置 NSX 角色之前，所有的 NSX Manager 都是独立的 NSX Manager。NSX Manager 的全新安装或从 VCNS 升级的 NSX Manager 都是独立 NSX Manager 的典型例子。

• 主级：在跨 vCenter NSX 环境中，只有一个主级 NSX Manager，我们将在主 NSX Manager 中创建所有通用对象。更具体地说，任何部署、修改或删除任务都将在主 NSX Manager 上进行。

• 次级：当一个独立的 NSX Manager 被添加到主 NSX Manager 实例时，它称为次级 NSX Manager。在次级 NSX Manager 实例中，所有的通用对象都是只读的。次级 NSX Manager 实例不能拥有自己的控制器。我们最多可以拥有七个次级 NSX Manager。

• 中转：有时我们需要移除或更改 NSX Manager 的主节点和次节点角色，这时中转角色就显得很重要。然而，如果 NSX Manager 实例拥有通用对象，它就不能被定义为独立角色。在这种情况下，NSX Manager 实例将被分配为中转角色。在中转角色下，通用对象只能被删除。当所有通用对象被删除后，NSX Manager 实例可以被分配为次节点角色。

以下图示解释了我们迄今为止讲解的各种 NSX 角色以及根据通用对象提升和降级 NSX 角色的过程：

在继续讨论跨 vCenter 之前，我们需要了解通用同步服务的重要性。通用同步服务是跨 vCenter NSX 通信的核心。

通用同步服务

通用同步服务负责将主 NSX Manager 实例的配置更改同步到所有次 NSX Manager 实例。这些是内建服务，运行在主 NSX Manager 中，通过 REST API 调用次 NSX Manager 进行同步。好了，让我们做一些快速测试，看看在我们开始分配角色之前，服务的状态如何。

以下图示显示了与 NSX 6.2 的 GUI 连接，在高亮列中我们可以看到 NSX 通用同步服务的状态：

在我们的设置中，我们有两个 NSX Manager 和与之注册的 vCenter Server，它们使用一个共同的平台服务控制器（PSC）。PSC 是在 vSphere 6 中引入的，负责处理如 vCenter 单点登录、许可证、证书管理和服务器预留等功能。控制器已经在 NSX Manager 192.168.110.15 上部署，这将在短时间内成为我们的主 NSX Manager。我们都知道如何将 NSX Manager 与单独的 vCenter Server 注册，因为我们在第三章中已经讨论过，NSX Manager 安装与配置。假设我们已经成功完成了注册，现在是时候将192.168.110.15的 NSX Manager 提升为主节点，并将192.168.210.15设为次节点：

1. 选择管理选项卡并高亮显示NSX Manager。

2. 选择操作图标。

3. 选择分配主角色：

你猜，当我们将 NSX Manager 提升为主节点时会发生什么？如果你的想法与结果一致，我马上就展示这个结果。如果你的答案正确，恭喜你。

以下图示展示了 NSX Manager 主节点角色注册；复制服务正在自动启动：

上面的截图是来自主 NSX Manager 的 NSX Manager 日志。正如我们在 GUI 中看到的，复制服务已自动启动，因为注册成功。以下图示显示了通用同步服务的运行状态：

所以请留意这个输出，并在 GUI 中验证输出是否与日志中的输出匹配。这对于故障排除来说极其重要和有用。

通用段 ID

通用段 ID 池用于将 VNI 分配给通用逻辑交换机，以确保我们不会为本地和全局逻辑交换机使用相同的段 ID 池；否则最终会出现段 ID 重叠的情况。

以下图示展示了通用段 ID 池的创建：

创建通用逻辑交换机的整个目的是为了在 vCenter 站点之间跨越逻辑网络，而不需要进行传统的复杂路由和交换。这样，通用逻辑交换机将可以在跨域的所有 vCenter 服务器上使用，我们可以简单地将虚拟机连接到这些逻辑交换机。虚拟机的逻辑交换机将始终保持为端口组，NSX 将处理跨 vCenter 的交换。难道我们没有配置比这更简化的第二层交换吗？首先，以前是否能够像这样进行第二层交换？我坚信，在本书中我们所增加的意识量足以让我们远离传统网络设计思维。

接下来，我们为第二个 NSX Manager 添加一个次级角色，以便我们可以开始创建通用传输区域和通用逻辑交换机。

添加次级 NSX Manager 的步骤如下：

1. 登录到与主 NSX Manager 链接的 vCenter。

2. 导航到主页 | 网络与安全 | 安装，然后选择管理选项卡。

3. 点击主 NSX Manager。然后选择操作 | 添加次级 NSX Manager。

4. 输入次级 NSX Manager 的 IP 地址、用户名和密码。

5. 点击确定。

以下图示展示了添加次级 NSX Manager选项：

成功添加次级 NSX Manager 后，角色会显示为次级，正如以下截图所示：

通用传输区域

由于我们有主要和次要 NSX 管理器，接下来让我们创建一个通用传输区域。首先，在跨 vCenter NSX 环境中只能有一个通用传输区域。在本章中关于 NSX 管理器角色的内容中，我们已经讨论了主要、次要和传输角色的区别，创建通用传输区域时也没有例外。通用对象始终从主要 NSX 管理器中创建。

下图显示了通用逻辑交换机的创建，并且我们已经添加了一个主要 NSX-VC 配对 vSphere 集群：

要从次要 NSX-VC 配对 vSphere 站点添加集群，我们需要将管理器设置更改为次要，并点击连接集群选项，这样会显示次要 NSX-VC 站点中的所有集群。每当我们添加新的集群时，我们所需要做的就是将这些新添加的集群连接到通用传输区域，在我看来，这也是我们扩展软件定义数据中心最简单的方法：

让我们做个快速测试：我们将创建一个通用逻辑交换机，并检查逻辑交换机是否在主要和次要 NSX 站点中被填充。听起来不错吗？那就开始吧。

跨 vCenter 通用逻辑交换机创建

好的！我们需要检查几个前提条件，以确保我们能够同时创建逻辑交换机并确保其按预期工作。创建通用逻辑交换机时应遵循以下关键点：

• 应配置 VSphere 分布式交换机

• 控制器必须部署在主要 NSX 管理器中

• 必须为 NSX 准备 VSphere 主机集群

• 必须配置 VXLAN

• 必须配置通用段 ID 池（不应与本地段 ID 重叠）

• 必须创建一个通用传输区域

现在让我们创建一个通用逻辑交换机：

1. 在 vSphere Web 客户端中，导航到首页|网络与安全|逻辑交换机。

2. 选择你希望在其上创建逻辑交换机的 NSX 管理器（这应该是主要 NSX 管理器；如果选择了次要 NSX 管理器，将无法选择通用对象）。

3. 点击新建逻辑交换机图标。

作为一个通用逻辑交换机，我们当然需要创建一个通用传输区域和段 ID；不过我们已经创建了这些。假设我们已经满足所有前提条件，接下来我们继续：

1. 输入通用逻辑交换机的名称；在我们的例子中，我们将其命名为Universal交换机。

2. 选择传输区域；这应该是本章之前创建的通用传输区域。

下图表示通用逻辑交换机的创建：

将虚拟机添加到通用逻辑交换机

由于我们已经创建了通用逻辑交换机，我们将继续将两个 vCenter 站点的两台虚拟机连接，并执行基本的 ping 测试。考虑到我们到目前为止所掌握的知识，这个实验任务对我们所有人来说都将是轻松的。让我们开始吧：

1. 在逻辑交换机中，我们需要选择您要添加虚拟机的逻辑交换机。

2. 点击添加虚拟机图标。

3. 选择您要添加到逻辑交换机的虚拟机。在我们的例子中，我们选择的是Web-Site A虚拟机，它已经预配置了 IP 172.17.10.11，如下面的图所示：

4. 选择您要连接的 vNIC，如下图所示：

5. 点击下一步并完成对Web-Site A的连接配置任务。

   以下截图显示了Web-Site A虚拟机及其 IP 详细信息：

   

   如果我们在可用对象部分看不到正确的虚拟机，很有可能是我们处于错误的 NSX Manager 中。我们必须在正确的 NSX Manager（主/次）中，以查看 VC 虚拟机的库存列表。

6. 由于我们已经完成了 Site-A，虚拟机已被添加到通用逻辑交换机中，我们需要将 NSX Manager 角色切换到次要角色，这样我们就可以从次要 NSX Manager 的 VC 库存中将虚拟机添加到同一通用逻辑交换机中。我们该如何操作？这只是一个简单的切换，下面的截图演示了这一过程：

7. 我们需要重复步骤 1、2 和 3，并从第二个 vCenter 服务器添加虚拟机Web-Site B，它预配置了 IP 172.17.10.12。

8. 点击添加虚拟机图标。

9. 选择您要添加到逻辑交换机的虚拟机。在我们的例子中，我们选择的是Web-Site B虚拟机。

以下截图显示了Web-Site B虚拟机及其 IP 详细信息：

现在我们已经创建了一个通用逻辑交换机，并连接了位于两个 vCenter 服务器中的Web-Site A和Web-Site B虚拟机。传统上，在这种情况下我们需要一个二层交换机，因为虚拟机位于两个 vCenter 服务器上并且在相同的子网中。然而，跨 vCenter 的 NSX 通用逻辑交换机改变了数据中心二层交换的游戏规则。这无疑是一个很好的使用案例，不仅是为了跨 vCenter 虚拟机连接，我们还可以轻松设计一个活动-活动、活动-被动的 vSphere 数据中心用于灾难恢复配置，并与 VMware SRM 一起使用。

让我们做一个简单的 ping 测试，以确认这些 Web 服务器是否按预期进行通信。以下截图显示了Web-Site B虚拟机与Web-Site A的连接：

好的！通过利用通用逻辑交换机，我们已经在两个 vCenter 站点之间建立了二层连接。如果整个网络流看起来复杂或令人困惑，请让我们关注以下图示，它展示了我们迄今为止为了建立通用逻辑交换所做的全部配置：

跨 vCenter Server 通用逻辑路由器

通用逻辑路由器提供了东-西数据中心流量之间的 vCenter Server 站点优化路由。目前，我们可以将此路由器称为全球 NSX 路由器，它将简化管理任务，如从单一管理界面配置和创建路由（静态/动态）和防火墙规则。我再次强调：与通用逻辑路由器相关的创建/删除以及所有管理活动只能在主 NSX 管理器上进行。接下来，我们将配置一个跨 vCenter Server 的通用逻辑路由器，并在两个 vCenter Server 站点之间建立路由。我们将使用在通用逻辑交换中使用的相同虚拟机进行此配置；然而，我已更改了Web-Site B的 IP/子网，这需要在Web-Site A和Web-Site B之间进行路由。让我们开始吧：

部署通用逻辑路由器的步骤如下：

1. 登录到 vSphere Web 客户端。

2. 点击网络与安全，然后点击NSX 边缘。

3. 选择通用逻辑（分布式）路由器（我们将在本章的网络瓶颈部分讨论本地出口）：

4. 输入用户名称和密码，用于通用分布式逻辑路由器（UDLR），如以下图所示：

5. 选择数据中心和NSX Edge Appliance详细信息，如以下截图所示：

   注意

   请注意，如果仅使用静态路由，则NSX Edge Appliance不是强制性的。然而，Appliance 部署对于动态路由和防火墙是必须的。

   

6. 对于高可用性接口配置，我们将接口连接到 vSphere 分布式端口组，并且它们将通过 APIPA 范围（169.250.0.0/26）IP 地址进行通信，如以下截图所示：

7. 最后，我们将向 UDLR 添加逻辑接口。

   以下截图展示了从 Site-A 到通用逻辑路由器（UDLR）的连接，目的是将 Web-Site-A 虚拟机连接到 UDLR：

   

8. 我们需要重复步骤 7，将 Web-Site-B（位于第二个 vCenter 的虚拟机）添加到 UDLR，如下截图所示：

现在我们已经将两个通用交换机连接到 UDLR，让我们继续验证路由表。没有什么高深的技术，如果我们迄今为止都按照步骤认真操作，UDLR 应该会显示那两个逻辑网络作为直接连接的网络。以下截图展示了执行以下命令的输出结果：

Net-vdr -route -l UDLR-ID

由于 UDLR 显示连接了 172.16.20.0 和 172.17.10.0 网络，我们应该能够在这些机器之间执行简单的 ICMP Ping 操作，前提是我们在路由器中添加了适当的防火墙规则。在我们的例子中，默认规则是允许所有流量，因此这里不应该存在任何瓶颈。

以下截图展示了从 Web-Site-B（172.16.10.11）到 Web-Site-A（172.17.10.11）的 ICMP Ping 成功：

为了明确整体学习过程，让我们通过一个例子来看清楚路由是如何推送到底层 ESXi 主机的；我们以一个多租户拓扑为例，如下图所示：

1. 动态路由协议（OSPF）在 Site-A 和 B 边缘设备之间以及它们各自的数据中心路由器之间运行。

2. Site-A 和 Site-B 的 NSX 边缘设备与通用分布式逻辑路由器（UDLR）连接。

3. 静态路由在 NSX 边缘设备上创建，用于到达 172.16.10.0 系列网络（根据业务需求，我们当然也可以利用动态路由协议）。

4. UDLR 控制的虚拟机将把学习到的路由发送到 NSX 控制器集群进行分发。重申一下，由于这是跨 vCenter 的 NSX 解决方案，控制器只在主 NSX 管理器中运行，并且所有 NSX 管理器都通过通用同步服务充分了解通用 NSX 对象。

5. 主 NSX 控制器将把这些路由发送到底层的 ESXi 主机。

6. ESXi 主机的内核路由模块将更新其路由表，并负责处理它从控制器学习到的那些网络的数据路径流量。

7. 前面提到的六个步骤是 NSX 环境中基本的路由学习过程：

网络瓶颈

让我从一句话开始：除非你非常清楚设计能够满足客户所有需求，否则绝不要提供或实施任何设计。

这条规则并不限于市场营销或销售人员，它是给所有与技术打交道的人的通用建议。如果没有遵循，我们会听到这样的反馈：我遇到了噩梦般的情况；所有问题都是在那次设计变更后开始的。你能把这个去掉吗？ 我们设计过或见过各种类型的 vSphere 网络。每种网络拓扑都会有一个漏洞。这个世界上没有完美的东西，我们能做的就是确保自己更好地为故障做好准备，这更像是一种优势而非失败？我希望大家暂停一分钟，看看前面的拓扑图；记录下可能中断数据流量的所有故障场景。再者，如果我们仔细观察拓扑图，会发现通用控制 VM 和边缘设备运行在两个不同的站点。那么，UDLR 控制 VM 如何确保它从特定的 NSX Edge 学到的路由是该站点下的 ESXi 主机所学习的唯一路由呢？我知道这个说法有点困惑。没关系，我们需要的只是，站点 A 的设备（边缘设备/控制 VM）学到的路由会发送到站点 A 的 ESXi 主机，站点 B 则反之亦然。好吧！那么我们开始吧，继续阅读以下有用的要点，确保我们的设计满足客户需求，避免引发任何进一步的问题：

1. 两个数据中心都运行着两台 NSX 设备，我们需要确保它们以 HA 模式运行，并且 vSphere HA 已配置。这样，单个设备/主机故障的影响会更小：

   • NSX Edge

   • UDLR 控制 VM

2. 确保我们使用 LOCALE-ID（默认情况下，该值设置为 NSX 管理器的 UUID）。通过 Locale-ID 配置，NSX 控制器会将路由发送到匹配 Locale-ID 的 ESXi 主机。在我们的拓扑中，每个站点的 ESXi 主机会维护一个特定站点的本地路由表。我们可以在每个集群、主机级别和 UDLR 级别设置 Locale-ID。这非常适合多租户网络/云环境，其中每个租户都希望维护特定于该租户的路由。

3. 所有 南北向 流量由 站点 A NSX Edge 和 站点 B NSX Edge 在各自的站点中处理。从 NSX 6.1 开始，等价多路径（ECMP）得到了支持。因此，我们可以部署多个 NSX Edge，ECMP 算法会基于源和目标 IP 对流量进行哈希处理。ECMP 可以在边缘设备和 DLR 上启用。这样，如果发生故障，它会重新计算哈希，并将流量路由到活动的边缘设备/DLR。此外，某些设计可能需要连续的 ECMP 配置，分布式逻辑路由器到 NSX Edge，以及 NSX Edge 到物理路由器。

4. 我们绝不应该设计会破坏现有拓扑的方案。当我们处理 ECMP 时，需要注意的是，NSX Edge 拥有有状态防火墙。我们很可能会遇到非对称路由问题；基本上，从源到目标的包使用一条路径，而回复时则走另一条路径，因为任何时候只有一个 Edge 会知道流量路径。别担心：当我们在 NSX 6.1 中启用 ECMP 时，会收到一条消息，提示启用此功能将禁用 Edge 防火墙。别担心，我们并没有在这种设计中妥协防火墙规则。我们可以在 NSX Edge 和上游路由器之间部署任何第三方物理防火墙（如图所示），或者我们需要利用分布式防火墙，在 VNIC 层过滤流量。然而，从 NSX 6.1.3 开始，ECMP 和逻辑防火墙可以共同工作，且出于同样的原因，在启用 ECMP 时，逻辑防火墙默认不会被禁用（主动/备用 NSX Edge）。下图展示了同一拓扑中添加 ECMP 配置后的情况：

5. 由于每个站点都有运行中的 NSX Edge，因此通过在特定站点的 Edge 上配置 NAT，支持重叠的 IP 地址。再次强调，这是一个需求非常高的使用场景，尤其是对于云服务提供商。

6. 我们可以同时让八个 NSX Edge 参与 ECMP 配置；在我们的情况下，每个站点有八个 ECMP 边缘，总共有 16 个 Edge 可以以这种方式运行。

7. 如果发生 Site A 或 Site B 完全故障的最坏情况会怎么样？当然，任何问题都有解决方案，但在这种情况下，解决方案会稍显繁琐，并且取决于物理网络设计。在另一个站点重新配置所有 NSX 组件可能不起作用。

8. Site-B 是我们拥有主 NSX Manager 的地方，而 Site-B 完全故障。从 NSX Manager 角色更改开始，我们需要部署 Edges 和设备，并且只有在物理网络设计在两个站点之间完全匹配时，才能将环境恢复到正常状态。我知道这是一个繁琐的过程，因此如果我们想自动化这些任务，我们需要利用 NSX API 和 VRO 工作流，以便简化大量手动操作。在极少数情况下，我们可能需要重新配置物理网络，以便 Site-B 的机器在故障期间能够与物理网络通信，尽管它们当时处于 Site-A。

关于故障类型有很多内容可以讨论，比如网络站点中的 NSX 组件同时发生故障，或者虚拟环境与物理网络部分/完全故障的场景。还有一些路由协议（OSPF/BGP）特定的故障场景，这些问题也引发了一些值得讨论的要点。要在一本书中涵盖所有这样的故障场景并根据设计类型采取预防措施是非常困难的。幸运的是，VMware 的 NSX 产品文档并不限于安装、配置和一般设计内容。他们发布了一些专门针对厂商集成的设计指南，比如 NSX+UCS 设计、NSX+CISCO ACI 等。等我们掌握了基础知识后，读一读这些文档是很有价值的。希望到目前为止，我们在七章中学到的内容已经为登上网络虚拟化的阶梯奠定了基础。到目前为止，我们对 VMware NSX 拓扑的讨论非常精彩，乐观地说，到现在为止，我们都已经清楚了 VMware NSX 是如何重塑数据中心网络的。

总结

我们从介绍 NSX 跨 vCenter Server 开始，接着讨论了跨 vCenter Server 组件和通用对象创建，最后讨论了一些在跨 vCenter Server 部署 NSX 时需要特别注意的设计决策。早些时候，网络故障排除主要由网络架构师和支持工程师单独完成，这让 vSphere 用户的生活变得更加轻松。由于 NSX 是运行在 vSphere 上的网络软件层，人们通常认为它可能会让他们的生活变得有些复杂，因为他们需要清晰地了解超管和网络虚拟化层的情况。

对我来说，故障排除是一门艺术；如果我们遵循一个系统的检查流程，解决问题简直是小菜一碟。没有任何秘密或简单的自动化可以帮助我们分析和修复网络虚拟化中的问题。

在下一章中，我们将详细讨论 NSX 故障排除。因此，让我们确保回顾一下所学内容，并通过根据具体情况应用这些知识来实践。

第八章. NSX 故障排除

让我从安提斯滕尼斯的名言开始本章：

“不忘记你已经学到的，才是最必要的学习。”

我找不到比这更合适的名言来提醒大家，确保我们回顾前面章节中学习到的关于如何处理问题的知识，找出最佳解决方案是多么重要。为了让最佳解决方案也是最快的，我们真的需要知道如何处理一个场景，从哪里开始寻找，哪些日志有用，最后，何时需要联系供应商进一步排查。正如我们所知道的，我们的课程集中于 NSX 与 vSphere 的结合。NSX 与 vSphere 紧密集成。

以一个实际例子来说，即使是结构坚固的建筑也无法建立在薄弱的基础上。糟糕的 vSphere 设计将直接影响 NSX 组件，无论 NSX 设计多么优秀。这条经验法则适用于任何基于 vSphere 运行的 VMware 解决方案。在本章中，我们将讨论以下主题：

• NSX 安装和注册问题

• 日志收集过程和步骤

• VXLAN 故障排除

NSX Manager 安装和注册问题

安装 NSX Manager 是最简单的任务之一，残酷的事实是，任何熟悉 vSphere OVA/OVF 部署的人都可以轻松部署 NSX Manager，而无需任何 NSX 产品的先验知识。我们确信，在生产环境中，没有人会采用这种方法。然而，我仍然想让大家了解 NSX 安装的重要性。让我们仔细阅读以下几点：

• 在我们尝试注册 NSX Manager 时，不能与同一 vCenter 注册任何 vCloud 网络安全（VCNS/vShield Manager）。如果我们发现有这样的环境，我们必须确保取消注册其中一个解决方案；肯定是 VCNS/vShield，因为与 NSX Manager 相比，它是一个过时的解决方案。这并不意味着我们可以在同一 vCenter Server 上注册两个 NSX Manager。然而，我们可以将 VCNS 升级到 NSX，升级指南的链接将在本章的最后部分分享。

• 永远不要将以前使用过的 NSX Manager 实例导入新环境并注册为新 vCenter 的解决方案。

• 始终检查 NSX Manager 是否与多少个 vSphere 解决方案注册。例如，我们可能已经将vCloudAutomation Center（VCAC）和vCloud Director（VCD）注册到 NSX Manager A，而 NSX Manager A 还与 vCenter Server 环境注册。我之所以对这些解决方案更感兴趣，是因为不仅在安装过程中需要仔细规划和设计，在故障修复时，NSX 产品的卸载也需要特别的考虑。每个解决方案的集成都需要在取消注册 NSX Manager 时采取独立的步骤。

• 在 NSX Manager 初次部署后，始终备份 NSX Manager。绝不要依赖 vSphere 快照功能来进行此备份活动。

• NSX Manager 可以作为普通的 vSphere 虚拟机来排查任何与网络相关的问题。例如，我们可以将 NSX Manager 从一个主机迁移到另一个主机，或者使用 ESXTOP 命令查看 Tx 和 Rx 计数，以便隔离网络问题。

• 在注册 vCenter Server 时，我们有两个选项：

  • 查找服务注册：查找服务注册是导入 SSO 用户的可选功能。然而，如果我们与 SSO 身份源集成，必须遵循所有供应商特定的最佳实践，以确保身份源的可用性。但值得记住的是，除登录到 NSX Manager 外，SSO 出现故障对 NSX 组件及其功能没有任何影响。

  • vCenter Server 注册：vCenter Server 的注册是第一步，也是最关键的集成。因此，我们需要确保以下几点的连接性和配置正确：

    • NSX Manager和vCenter Server之间应配置 DNS 解析。

    • NTP应该正确配置；这个点对于大多数专家来说可能非常熟悉，但我还是要重申：错误的 NTP 配置在我们集成查找服务（SSO）并尝试利用基于 SSO 的认证时，影响非常大。

    • 防火墙端口应在 NSX Manager 和 vCenter Server 之间打开。始终检查 VMware 知识库（KB）文章以了解端口要求。以下链接指向一篇 VMware KB 文章，讨论了所有端口要求：

      • https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2079386

      • 在注册到 NSX Manager 时，确保我们使用的是 vCenter Server 的管理员权限。我们当然可以使用 administrator@vsphere.local 账户将 NSX 注册到 vCenter、vCloud Director 和 vRealize Automation 产品中。

故障排除 NSX Manager

根据情况，我们可能需要为 VMware 支持收集 NSX Manager 的诊断信息。在此类情况下，请牢记以下步骤。

通过 GUI 收集 NSX Manager 日志

通过 GUI 收集 NSX Manager 日志的步骤如下：

1. 通过网页浏览器登录到NSX Manager虚拟设备。

2. 在NSX Manager 虚拟设备管理中，点击下载技术支持日志。

3. 点击下载 | 保存。以下截图显示了 NSX Manager 日志下载：

通过 CLI 收集 NSX Manager 日志

可能会出现 NSX Manager GUI 无法正常工作，我们可能需要依赖 CLI 来收集日志。对于不喜欢 CLI 的用户，这次没有逃避的机会；我们需要通过以下步骤捕获 NSX Manager 日志：

1. 通过 SSH 会话登录到NSX Manager虚拟设备。

2. 通过输入enable进入启用模式。

3. 在 启用模式 下执行以下命令，命令会根据我们选择的主机名将 NSX Manager 日志保存到远程位置：

export tech-support scp USERNAME@HOSTNAME:FILENAME

以下截图展示了 NSX CLI 日志捕获：

VMware 安装包

虚拟化主机本质上是网络虚拟化的骨干。虚拟机能够利用 NSX 特性，主要是因为 ESXi 主机是一个网络虚拟化主机。NSX 安装的一个关键支柱是 ESXi 主机的准备。如果 ESXi 主机上没有运行正确的模块，那么利用 NSX 特性的目的就会失效。可能的症状是我们可能无法安装特性 X，或者可以配置特性 X，但功能会受到影响。请注意以下在 ESXi 主机中的 VIB：

• esx-vxlan

• esx-vsip

• esx-dvfilter-switch-security（从 NSX 6.2.0 开始，esx-dvfilter-switch-security 成为 esx-vxlan vibs 的一部分）

这是检查 VIB 是否已安装在 ESXi 主机中的命令：

esxcli software vib list | grep vibname

由于这些是 VIB，我们可以在修复场景中手动卸载并重新安装相同的 VIB。但真正的问题是，谁在推送这些 VIB？我在这里看到的大多数问题都是出自这个原因。幕后，vCenter Server ESX Agent Managers (EAM) 负责安装这些 VIB。因此，首要任务是确保 EAM 服务正在运行。以下步骤对于根据操作系统和 vCenter Server 版本收集 EAM 日志非常有用。

EAM 日志位置

以下是各版本 vCenter Server 和操作系统对应的 EAM 日志位置：

• VMware vSphere 5.1.x/5.5.x（EAM 是通用 Tomcat 服务器的一部分）：

  • Windows 2003: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs\eam.log

  • Windows 2008: 与 Windows 2003 相同，VC 日志目录位于 C:\ProgramData\VMware\VMware VirtualCenter\Logs\

  • vCenter Server 虚拟设备 (VCVA): /storage/log/vmware/vpx/eam.log

• VMware vSphere 6.x（EAM 是独立服务，并嵌入了 tcserver）：

  • Windows 2003: C:\Documents and Settings\All Users\Application Data\VMware\CIS\logs\eam\eam.log

  • Windows 2008: 与 Windows 2003 相同，VC 日志目录位于 C:\ProgramData\VMware\VMware VirtualCenter\Logs\

  • CloudVM: /storage/log/vmware/eam/eam.log

我见过很多问题，特别是当 vCenter Server 安装是基于 Windows 时，EAM 尝试使用端口80下载 VIB 时。此时，VC 中可能有其他应用程序或服务正在使用端口80，这会导致 VIB 下载失败，因此我们必须更改默认的 EAM 端口。然而，从 VMware vSphere 6.0 开始，支持通过端口443（而不是端口80）下载 VIB。这个端口是动态开启和关闭的。ESXi 主机与 vCenter Server 之间的中间设备（防火墙）必须允许通过该端口的流量。这样，我们将进入下一个主题：控制平面和数据平面日志收集。

控制平面和数据平面日志收集

日志收集对于主动预警和根本原因分析至关重要。有多少次我们最终收集了错误的日志集，或者收到了反馈，说我们必须启用或提高某些日志级别，以确保我们收集了合适的日志来分析根本原因？从技术上讲，这类反馈是可以理解的。然而，当涉及到生产影响时，如果在查看日志后发现没有得出结论，那将是令人失望的。解决此问题的唯一方法是：我们应该清楚需要收集哪些日志，最重要的是，应该从哪个位置收集。首先，我们需要了解以下几个背景知识：

理解物理拓扑

理解物理拓扑不仅对于整体 NSX 设计和功能配置至关重要，还同样重要的是在发现有更好的设计方式时能够提供有效的反馈。以下是我们需要时刻注意的几个要点：

• 物理网络设计 - 脊叶/层 2 架构

• 现有的防火墙部署和规则

• 整体数据中心路由和交换拓扑

• vSphere 集群设计（机架放置）和拓扑。除此之外，还需要了解当前或未来配置所需的集群数量（单站点、多站点）、数据中心以及主动-主动或主动-被动的物理数据中心设计。

• vSphere 分布式交换机上行链路策略

以下是基于上述几点的建议：

• 物理网络设计 - 脊叶/层 2 架构：脊叶架构是如今最好的也是最广泛使用的连接方式，因其具备完全网状连接、低延迟、高带宽、ECMP 路由，最重要的是，网络扩展非常容易实现。

• 现有防火墙部署和规则：这是一个重要的检查，主要是因为 NSX Edge 防火墙和微分段能力。我的建议是尝试集成 vRealize Network-insight 软件，以便了解南北向和东西向流量的总体增长，然后决定在哪些点配置哪些防火墙策略。在本章的结尾部分，我对 vRealize Network-insight 软件做了简要总结。

• 整体数据中心路由和交换拓扑：

  • 在这里，我们主要关注物理网络中使用的路由协议——例如 OSPF、BGP、ISIS。

  • 例如，基于 OSPF 配置的区域类型，假设上游路由器是 区域边界路由器（ABR），我们需要知道哪些路由应该从 NSX Edge 注入到上游路由器，以及允许流量的适当防火墙策略。

  • 在二层方面，理想情况下，ESXi 和 VXLAN 流量是我们需要了解的最重要参数，以便为 VLAN-ID（管理、VMotion、存储、VXLAN）分配/配置。

• vSphere 集群设计（机架中的部署位置）和拓扑：

  • 集群设计应该理想地将管理和边缘集群与计算集群分开，管理和边缘集群至少有 4 台主机，而计算集群最多有 64 台主机（仅在环境运行 vSphere 6.0 时）。

  • 对于配置了 SRM 和 NSX 的灾难恢复环境，建议在灾难恢复站点保持类似的物理和虚拟设计。某些情况下，可能要求工作负载长时间运行在灾难恢复站点，因此我们需要遵循这一严格规则。

• vSphere 分布式交换机上行链路策略：这是我们在 第三章中讨论过的相同主题，NSX 管理器安装与配置：

  • 在这里，我们需要选择并配置 NIC 集群和故障转移策略。例如，如果选择 LACP 配置，我们将受到单一 VTEP 配置的限制，而基于端口和源 MAC 哈希的路由支持多 VTEP 配置。防患于未然，建议通过所有可用上行链路负载均衡 VXLAN 流量，而不是因性能问题而遭遇麻烦。

这些小点讨论背后的目的是确保所有配置/设计方面提前得到妥善处理，而不是后期花费时间进行配置和性能调优。

NSX 控制器日志收集

控制器是 NSX 整体架构中的真正变革性组件。正因如此，在故障排除时它仍然是一个至关重要的部分。正如我们所知，控制器是通过 开放虚拟化设备（OVA）从 NSX 管理器部署的。在最坏的情况下，甚至控制器的部署可能会失败，这将成为任何 NSX 实施的拦路虎。这类故障大多数发生的原因有以下两个：

• DNS

• NTP

在 ESXi 主机、vCenter Server 和 NSX Manager 之间应进行适当的 DNS/NTP 配置，以确保 NSX Controller 部署成功。除此之外，vSphere 中任何虚拟机的成功部署都需要足够的计算和存储容量，NSX Controller 也不例外，主要因为这些都是从 ESXi 主机的角度来看是虚拟机。对于收集 NSX Controller 日志，我们需要完成以下步骤：

1. 首先，我们需要使用 vSphere Web 客户端登录到 vCenter Server。

2. 点击网络与安全。

3. 点击左侧面板上的安装。

4. 在管理选项卡下，选择你想要下载日志的控制器。

5. 点击下载技术支持日志。

6. 以下截图展示了 NSX Controller 日志收集过程：

如果 Web 客户端无法使用，或者我们无法访问 Web 客户端怎么办？在这种情况下，我们可以采用两种方法来收集日志：

1. 使用 vSphere 客户端会话，我们可以连接到运行控制器的 vCenter Server 或 ESXi 主机，并且我们可以通过虚拟机控制台会话访问控制器，利用 CLI 命令进行日志收集。

2. 直接通过 SSH 会话连接到控制器并执行 CLI 命令进行日志收集。

使用 CLI 步骤收集 NSX Controller 日志

首先，使用之前的任何步骤登录到你想要收集日志的 NSX Controller，并执行如下命令，如截图所示：

save status-report filename

控制器日志收集完成后，我们可以将这组日志复制到任何与控制器具有 IP 连接的机器上。

在以下示例中，我将控制器日志复制到了其中一台管理 ESXi 主机的 TMP 位置：

接下来，我们将转到 NSX Edge 和 DLR 日志收集，最后会结束于数据平面日志收集和一些重要的服务状态。

收集 Edge 和 DLR 日志的过程几乎相同。

通过 Web 客户端收集 Edge 和分布式逻辑路由器日志

以下是收集分布式逻辑路由器日志的步骤：

1. 首先，使用 vSphere Web 客户端登录到 vCenter Server。

2. 点击网络与安全图标。

3. 点击左侧面板上的边缘。

4. 在右侧面板中，选择我们想要下载日志的边缘设备（DLR/EDGE）。

5. 点击操作并选择下载技术支持日志。

在下图中，我们可以看到下载技术支持日志已被高亮显示在分布式逻辑路由器（DLR）上，我之前提到过，这与收集 NSX Edge 日志的过程相同：

要通过 CLI 收集日志，我们需要执行以下命令，可以通过以下任一步骤来执行：

1. 使用 vSphere 客户端会话，我们可以连接到 vCenter Server 或运行控制器的 ESXi 主机，并可以通过 VM 控制台会话连接到控制器，以利用 CLI 命令进行日志收集。

2. 直接通过 SSH 会话连接到控制器并执行 CLI 命令以收集日志：

 export tech-support scp user@scpserver:file

我们已经讨论了什么是 EAM 以及它在 NSX 环境中的作用。除了 vSphere 故障排除部分，我们还需要检查两个在 NSX 准备的 ESXi 主机上运行的用户世界代理的状态和日志级别。

NSX 用户世界代理

NSX Manager 负责部署 NSX 控制器集群，推送 vSphere 安装包（VIBs）以启用 VXLAN、分布式路由、分布式防火墙，并且用于与控制平面级别通信的用户世界代理。用户世界代理的功能至关重要，任何故障都会直接影响控制平面的学习，最终影响数据平面流量。因此，让我们来讨论这些代理及其基本健康检查和日志位置。

netcpa

它是与 NSX 控制平面通信的用户世界代理，netcpa 服务应在已准备的 NSX ESXi 主机上运行。如果功能受到影响，我们肯定会在 NSX 环境中遇到路由和交换问题，并且自从 netcpa 服务停止运行以来，ESXi 主机将无法学习新路由。因此，这一点非常重要：仅在 NSX Edge 虚拟机上创建路由是无法解决问题的；除非 netcpa 服务已正常运行，否则 ESXi 主机无法学习这些路由。请按以下步骤检查与 netcpa 相关的问题：

1. 检查 netcpa 服务是否在主机上运行（此操作需要在我们遇到网络或控制平面相关问题的主机上进行检查）。

2. 使用以下命令检查 netcpa 服务：

 **/etc/init.d/netcpad status** 

以下截图显示了 netcpa 代理的状态：

检查 netcpa 配置文件是否显示所有控制器。使用以下命令检查配置文件中的控制器详情：

cat  /etc/vmare/netcpa/config-by-vsm.xml

以下截图显示了配置文件输出，其中包括控制器 IP 和 SSL 证书指纹信息：

在 ESXi 主机的 /var/log/netcpa.log 文件中，我们可以查看完整的 netcpa 日志。以下截图显示了控制器注册信息，这些信息已被填充到 netcpa 日志中：

每当我们遇到 netcpa 服务问题时，我强烈建议重启该服务，以确认是否能解决问题。要重启 netcpa 服务，我们需要按照以下步骤操作：

1. 通过 SSH 或通过 DCUI 控制台以 root 身份登录到 ESXi 主机。

2. 运行/etc/init.d/netcpad restart命令以重启 ESXi 主机上的 netcpa 代理。

Vsfwd

NSX 分布式防火墙是一个集成于虚拟化平台的防火墙，除了主机需要安装防火墙vib外，还需要有一个 vsfwd 守护进程在运行，以确保与 NSX 管理器之间的消息总线通信正常。

以下命令和截图显示了 ESXi 主机上的有状态防火墙状态：

etc/init.d/vShield-Stateful-Firewall status

要检查与 NSX 管理器的活动消息总线会话，可以使用以下命令和截图来查看与 NSX 管理器（172.16.1.5）的活动会话：

esxcli network ip connection list | grep 5671

如果端口**5671**在 ESXi 主机和 NSX 管理器之间未打开，可能会发生潜在的故障。

Vsfwd 日志位置和收集过程

NSX 分布式防火墙是 vSphere 环境中的新一代防火墙，主要因其能够在虚拟机 NIC 级别过滤流量而广泛使用。因此，理解日志收集和相关的故障排除步骤非常重要。那么，让我们开始吧。

首先，我们需要了解运行分布式防火墙（DFW）的前提条件。即使以下要求未满足，也无需进行日志收集。运行 DFW 的前提条件如下：

• VMware vCenter Server 的最低版本应为 5.5

• VMware ESXi 版本应为 5.1、5.5、6.0

• VMware NSX for vSphere 6.0 及更高版本

所有与 vsfwd 相关的日志都将位于以下位置，并且其表示方式如下图所示：

/var/log/vsfwd.log file on the ESXi host

从 NSX 管理器收集集中日志

首先，我们需要使用管理员凭据登录到 NSX 管理器并执行以下命令：

export host-tech-support host-id scp uid@ip:/path

随着 NSX 6.2.3 的推出，VMware 推出了一个导出主机技术支持命令，可以在 NSX 管理器上执行以收集以下信息。我坚信他们将会增加更多的日志收集选项，因为这是集中式的日志收集方式，但很多情况取决于故障类型。如果遇到 NSX 管理器故障，集中式日志功能也会受到影响，因此了解这种情况的下一步计划非常重要，这也是我迄今为止解释日志收集过程的目的。以下是当前集中式日志中包含的日志列表：

• vmkernel 和 vsfwd 日志文件

• 过滤器列表

• DFW 规则列表

• 容器列表

• Spoofguard 详细信息

• 主机相关信息

• ipdiscovery 相关信息

• RMQ 命令输出

• 安全组和服务配置文件及实例详细信息

• esxcli 相关输出

VXLAN 故障排除

VXLAN 是 VMware NSX 环境中用于首次测试和实施的覆盖技术，最有可能出现一些连接问题。由于虚拟和物理网络配置错误，我们可能会遇到以下一些常见问题：

• 虚拟机没有网络连接，无论是同一 VXLAN 网络中的其他机器之间，还是没有与物理网络的出口连接。

• 经常出现数据包丢失，并且应用团队面临性能差的问题。

• 虚拟机在一些 ESXi 主机上具有正常的网络连接，但当它们被放置在另一组主机上时，则没有网络连接。

• 普通的 ping 测试正常，但当检查 VXLAN 数据包时，会出现数据包丢失。

• VLAN 网络中的虚拟机具有正常的网络连接；然而，VXLAN 网络无法正常工作。

与 VXLAN 相关的大多数网络问题将集中在上述问题列表中；然而，只有通过应用我们的知识，我们才能清楚地了解客户的网络类型以及他们面临的网络问题。因此，让我们开始了解这些问题的可能症状以及解决问题所需的必要行动。

在实施 VXLAN 解决方案后，我强烈建议在所有 NSX 配置好的 ESXi 主机之间检查 GUI 层面的 PING 和 VXLAN 测试，这是确认是否满足初步要求的最佳方式，这些初步要求是为了从一个虚拟化主机向另一个虚拟化主机发送 VXLAN 数据包。

我们需要选择一个逻辑交换机。进入 监控 页面，我们将看到两个选项：

• Ping

• 广播

以下截图展示了 Ping 和 广播 测试选项：

首先，我们将对 172.16.1.94 和 172.16.1.96 之间的 ESXi 主机进行 Ping 测试，然后进行 VXLAN 测试。以下截图展示了成功的 Ping 测试：

以下截图展示了同一 ESXi 主机之间的 VXLAN 测试，我们可以确认，从主机 172.16.1.94 发送的 VXLAN 数据包已被 172.16.1.96 成功接收：

除了前面的测试外，我们还可以通过 SSH 会话执行 VXLAN ping 测试，我已经捕获了在两台 ESXi 主机之间进行此测试的输出。执行此测试的命令如下：

ping ++netstack=vxlan -d -s MTU VTEP-IP

以下截图展示了通过 SSH 会话对主机 172.16.1.94 进行的 VXLAN 测试：

上述输出清楚地表明 VXLAN 环境中的 MTU 设置正确，因此我们能够支持大于 1500 的 MTU。如果存在 MTU 配置错误问题，此测试将会失败，正如以下截图所示。我故意将分布式虚拟交换机中的 MTU 从 1600 改为 1500，以展示失败的场景：

网络故障排除离不开数据包捕获。这是本章的最后一个话题，我将展示如何收集 VXLAN 数据包。我们还将快速浏览一下数据包中的信息。考虑到我们迄今为止获得的知识，对于每个人来说，这应该是轻而易举的。

数据包捕获与分析

从 ESXi 5.5 开始，pktcap-uw 工具被嵌入到虚拟化管理程序中。你们中的一些人可能已经熟悉 tcpdump 工具，它在 ESXi 中已有提供；pktcap 是其替代工具。集成 pktcap 工具的主要原因是，它能够捕获每一层的所有数据包，这在 NSX 环境中至关重要。因此，我们不再仅限于捕获 vmkernel 层的数据包。从 vCloud Networking 和 Security 时代起，我就一直是这个工具的忠实粉丝，我坚信我们大多数人都会喜欢这个工具。在开始数据包捕获之前，让我们明确以下几点：

• 默认情况下，Pktcap只捕获入站数据包，且是单向的。因此，如果我们想要捕获入站和出站流量，我们需要添加一些特定的参数。如果不这样做，捕获数据包的目的就会落空。

• 流量方向标记为-dir 0用于入站数据包。

• 流量方向标记为-dir 1用于出站数据包。

• 我们可以在 vmkernel、vmnic 和交换机端口级别（DVS）捕获数据包。

• 如果在 ESXi 主机上输入以下命令，可以查看详细的命令语法：

Pktcap-uw -h 

够多的理论了；让我们通过捕获数据包来分析 VXLAN 字段。在此之前，先让我解释一下我的实验室设置和虚拟机详情，以便我们可以验证这些输出是否与捕获的数据包详情相匹配。

实验室环境详情

在这个实验室中，我有两个 vSphere 集群，并且有一个跨越这两个集群的 VXLAN 网络 5001。两个集群都有各自的分布式交换机。

集群 A 中的虚拟机 IP 是192.16.10.12，其 VTEP IP 为172.16.1.32，运行在 ESXi 172.16.1.97上。

集群 B 中的虚拟机 IP 是192.16.10.14，其 VTEP IP 为172.16.1.33，运行在 ESXi 172.16.1.94上。

VNIC 数据包捕获用于出站流量

要开始数据包捕获，我们需要通过 SSH 连接到主机172.16.1.97，并确定虚拟机运行在哪个 VNIC 上：

1. 输入 ESXTOP 命令并按 n 键显示网络参数。以下截图展示了 ESXTOP 屏幕。我们已经识别出我们的源虚拟机 192.16.10.12 正在 vmnic0 上运行：

2. 输入以下命令以捕获出站流量。输出将保存到 ESXi 主机的 tmp 目录中：

   pktcap-uw --uplink vmnic0 --dir 1 --stage 1 -o /tmp/webAvxlan.pcap
   
   

3. 从源虚拟机发起 ping 请求到目标虚拟机，如下图所示：

4. 在一段时间后，通过按 Ctrl + C 停止数据包捕获，在 ESXi putty 会话中看到以下输出：

5. 保存的数据包 webAvxlan.pcap 需要导入到 Wireshark 工具中。我相信大家都知道如何从 ESXi 主机复制或下载文件。

6. 将文件导入到 Wireshark 后，我们将获得以下输出：

7. 展开 虚拟可扩展局域网（Virtual eXentsible Local Area Network） 选项，将显示完整的 VXLAN 头字段，如下图所示：

从高亮区域可以看出，我们得到了以下输出，完美匹配我们之前提到的实验环境详情：

• 内部 IP Src 是 192.16.10.12，Dst 是 192.16.10.14（我们已测试过的两个 ping 命令的机器）

• VXLAN 网络是 5001（我们的虚拟机所在的逻辑交换机）

• VXLAN UDP 端口是 4789

• 外部 IP SRC: 172.16.1.32 和 DST: 172.16.1.33（VXLAN 隧道端点 IP 地址）

我坚信这是最精确的 VXLAN 输出，它将帮助我们在许多场景中，而 pktcap-uw 是一个伟大的工具，虽然很多人没有使用它，主要是因为缺乏相关知识。通过将捕获的输出导入 Wireshark 工具，它能提供所有字段的细节级信息。所以，保持这些步骤在手，我敢打赌在生产环境中它将非常有用。

NSX 升级检查清单和规划顺序

在初期就阻止某些事情发生总比事后修复损坏要好。每次产品升级都应该遵循一步步的流程并进行适当的规划，NSX 升级也不例外。以下步骤是升级 NSX 环境时需要遵循的正确顺序：

1. 升级 NSX Manager

2. 升级 NSX 控制器

3. 升级由 NSX 准备的 ESXi 集群

4. 升级分布式逻辑路由器和边缘服务网关

5. 升级数据安全性和来宾内省服务

首先，在进行任何升级之前，我们需要确保满足以下前置检查条件。

以下是 NSX 升级前检查清单：

• 对 NSX Manager 进行备份。在跨 VC NSX 环境中，我们需要为所有 NSX Manager 进行备份，并对所有 NSX Manager 完成以下过程。

• 对所有 NSX Manager 进行快照。这仅用于在正常备份不可用或因人为错误或灾难性事件而损坏时提供额外保护。

• 登录 NSX Manager 并运行 show filesystems 命令来显示 /dev/sda2 文件系统的使用情况。如果文件系统使用率为 100%，升级过程肯定会失败，针对这种情况，我们需要清除管理器日志和 NSX 系统命令，并在开始升级之前重新启动 NSX Manager。

• 在 NSX Manager 中发出以下命令来清理 NSX 日志和系统命令：

  • 清理日志管理器

  • 清理日志系统

• 重新启动 NSX Manager 设备以便日志清理生效。

• 在升级 NSX Manager 之前，应卸载 NSX 数据安全。

• 确保所有控制器已连接，并且在现有控制器升级阶段不计划部署任何新控制器。

• 将 vSphere 集群的 ESXi 主机置于维护模式，并执行升级和重新启动主机。对准备好的 NSX ESXi 主机执行相同操作，以便将新的 VIB 推送到所有 ESXi 主机，最后将主机退出维护模式。

• 从 NSX Manager 6.2.3 版本开始，默认的 VXLAN 端口是 4789。在 NSX 6.2.3 之前，默认的 VXLAN UDP 端口号是 8472。因此，如果我们打算继续使用新的 VXLAN 端口 4789，请确保您的防火墙允许该端口通过。

• NSX Edge 和 NSX 分布式逻辑路由器控制 VM 可以按任意顺序进行升级，并且对于启用 HA 的 NSX Edge 和控制 VM，不需要重复升级过程。这两个设备同时进行升级。

• 最后，我们可以继续升级客户端内省虚拟机和相应的伙伴设备。

• 升级完成后，应删除为 NSX Manager 拍摄的所有快照，确认所有组件和服务均已启动运行。

以下截图显示了各个 NSX 组件升级阶段期间受到操作影响的任务和未受影响的任务和服务：

NSX 组件	操作影响	无影响
NSX Manager	阻止 NSX Manager GUI 和 API 相关的新任务	控制平面和数据平面继续工作
NSX 控制器	逻辑网络不接受修改，也不接受新的逻辑网络创建	管理平面和数据平面
vSphere 集群	在此阶段不接受特定 vSphere 集群的新 VM 配置	其他 vSphere 集群的管理平面、控制平面和数据平面相关任务将继续工作（如果我们一次只对一个 vSphere 集群进行升级）
NSX 边缘和控制虚拟机	在此操作期间，所有边缘和控制虚拟机服务将受到影响。	管理平面、新的边缘和控制虚拟机可以部署。所有旧边缘的现有配置将被保留。
访客自我检查和数据安全	在此阶段，虚拟机将没有保护	所有其他与 NSX 相关的任务和服务将保持完整。

这就是我们最后一章的内容，我相信这段网络虚拟化的旅程到目前为止非常精彩。

NSX 的未来

当前和未来的 IT 选择肯定是软件定义数据中心，毫无疑问。我相信这个产品和技术之所以是 VMware 产品组合中的“点睛之笔”，其中一个主要原因就是 VMware 拥有成熟且庞大的生态系统，客户可以在私有云、公有云（vCloud Air）以及两者混合的环境中，充分利用 NSX，构建一个真正的混合云平台。数百万个工作负载被 vCloud Air 灾难恢复数据中心保护，而在幕后，这些工作负载都是完全通过 NSX 进行网络虚拟化的 vSphere 环境。最近，Gartner 已经认可 vCloud Air 灾难恢复解决方案是公共云市场中最好的解决方案之一，这一点也不奇怪。VMware NSX 的方式非常简单：跟随虚拟机的脚步，无论它们是走向私有云、公有云，还是混合云，始终保持安全。从跨厂商的角度来看，VMware 确实做出了一些艰难的决策，尤其是像 NEXUS 1000V 这样的产品，已经不再支持 VMware NSX。然而，在一个全新的部署场景中，唯一可能提出的问题是：如果要将 NSX 集成，开发或重构现有应用程序的成本和人力是多少？这是否需要对网络架构进行全面更改？是否需要特定型号的交换机或路由器？我们现在都知道答案：NSX 并不要求在整体物理网络上做任何重大更改。作为软件定义网络的公认领导者，VMware 通过于 2016 年 6 月 13 日收购 Arkin，做出了又一个明智的决策，这将进一步简化许多 NSX 操作任务。Arkin 的跨域可视化将帮助客户更细致地了解物理到覆盖层的映射及其他安全参数，通过这种方法和输出，日常操作任务将变得更加简化。我们多久收到过关于虚拟机如何连接到网络的问题？传统的检查方式是通过多个产品之间的连接，获取端到端的连接视图。我坚信，像这样的任务，通过将 Arkin 与 NSX 集成后，将会大大简化，并且，借此，我们能够精确了解数据中心中的流量类型，以及东-西流量、南-北流量、互联网流量等的总体流量百分比，以上只是一些例子。

VMware vRealize 网络洞察（Arkin）是一个智能安全和运营管理解决方案，适用于网络，提供通过网络流量分析的虚拟和物理网络的 360 度可视化。该解决方案自 2016 年 8 月 1 日起可供下载。VMware 最近还宣布了 NSX 多虚拟化平台的新版本 NSX transformers，它支持 KVM 和 vSphere 等虚拟化平台，用户可以将它们放置在一个共同的 NSX 传输区中。目前对于 transformers 的未来发展还言之过早，因此目前我们只能观察并等待。NSX 无疑是软件定义网络（SDN）的进化，它具备了达到更高水平所需的所有组成部分，能够极大地帮助各类企业。我感谢大家成为这个旅程的一部分，鼓励大家开始测试并实现这一伟大解决方案。让我们一起成为这款改变游戏规则的软件的一部分。根据你们的技术背景以及我们理解和学习技术的速度，我相信会有一些问题，如果你们能通过 LinkedIn 与我联系，我将不胜感激。请放心，我会尽早处理所有问题。

摘要

本章以故障排除的介绍开始，接着是 NSX 管理器、控制器和数据平面的日志收集，以及当问题出现时的主要关注点。最后，我们以 NSX 的未来作为本章的结尾，并附上了一些文档阅读的链接。

参考文献

最后，正如之前承诺的，我将发布我们所有人都应该阅读的所有文章。你可以相信我，攀登 NSX 阶梯的正确方式就是阅读每一篇可用的文档；这将成倍增加我们的知识：

• 《CISCO NEXUS 9000 设计指南》讨论了与 UCS 服务器相关的一些设计场景。这是一本非常适合理解 NSX 物理网络设计的好指南：www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/products/nsx/design-guide-for-nsx-with-cisco-nexus-9000-and-ucs-white-paper.pdf

• 通过 vCloud Air 提供的高级网络服务。阅读这篇文档值得一看，了解 NSX 如何帮助 vCloud Air 客户，并通过在公共云中提供零信任安全性来提供哪些服务：vcloud.vmware.com/service-offering/advanced-networking-services

• VMware NSX 设计指南 for vSphere 是另一个关于在 vSphere 环境中设计 NSX 的知识库：www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf

• 如果我们真的想保持技术更新，我们都应该阅读这个博客。这是来自 VMware 的网络虚拟化博客，讨论了大量的视频和使用案例：blogs.vmware.com/networkvirtualization/#.V5NU0Pl95QI

• VMware 集成 OpenStack 与 NSX 配置指南。此文档要求具备一定的 VIO 知识；然而，读者将能够了解 NSX 在 VIO 环境中的工作原理：communities.vmware.com/docs/DOC-30985

• 完整的 VCNS 升级到 NSX 的指南。本指南包含了逐步的说明，帮助将所有 vCloud 网络安全解决方案升级到 NSX：pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_upgrade.pdf

• 我要大声喊：“练习，练习，再练习！” 练习成就完美，因此请继续练习免费的 VMware HOL 实验室。我强烈建议在开始 NSX 实验室之前，从 vSphere 分布式交换机的 A 到 Z 实验开始：labs.hol.vmware.com/HOL/catalogs/catalog/130

• 这份文档是关于实现 VMware NSX 与 Brocade VCS 部署的指南：www.brocade.com/content/html/en/deployment-guide/brocade-vcs-gateway-vmware-dp/GUID-329954A2-A957-4864-A0E0-FD29262D3352.html