NSXスタティックルーティングおよび制御プレーンの更新処理1

最後の年で、NSXの議論を通じて、ファイアウォールの実装の原則を配布し、我々は簡単に見過ごすことができコンポーネント-vsfwd NSX管理面に精通しています。

今日、我々はNSXコントロールプレーンのコンポーネントとプロセスが簡単な実験を通じて、静的ルーティングアップデートを確認するために議論します。

NSX制御プレーンは、三つの重要な構成要素それぞれ含むNSXコントローラクラスタコントローラクラスタ、NSX論理制御ルータのルータ制御ロジックVM仮想マシンを、容易に見落とさすることができるnetcpaを。

NSXのベストプラクティスは、勧告は、データセンターのクラスタ3を展開する、すなわちのvCenter、NSXマネージャー、NSXコントローラコンポーネントなどベアラクラスタ管理クラスタ管理、運搬エッジ、DLR-CVM 境界クラスターエッジクラスタとベアラトラフィック計算します計算クラスタのクラスタ。

ホストが動作する準備ができているためNSXコントローラ管理プレーンは、一般的にインストールされ、管理のESXiクラスタ上で実行されている、クラスタ管理仮想マシンは、論理スイッチングまたは論理ルーティング機能を実行するために必要としない、それは必要ではないが、ESX-nsxv VIBインストールする必要がありません。しかし、国境やクラスタコンピューティングクラスタのために、あなたがしなければならない準備段階をホストロジックのスイッチングおよびルーティングを実現するためには、ESX-nsxv VIBインストールし、。

アクセスESXiのコマンドライン、コマンドを使用します。＃のesxcliソフトウェアVIBリストを| grepをNSX、あなたはNSX-nsxv VIBのインストールを確認することができます

还记得上一篇我们讲过，NSX分布式防火墙的实现，与ESXi内核空间中运行的vsip module息息相关吗？同样，ESXi内核空间中还运行了2个关键module，与逻辑路由和逻辑交换关系密切。

我们可以使用命令找到它们：vmkload_mod -l | grep nsx

nsx-vdl2：负责逻辑交换

nsx-vdrb：负责逻辑路由和桥接，vdr代表分布式路由，b代表桥接

与管理平面组件vsfwd相类似，控制平面组件netcpa同样运行在ESXi的用户空间

我们可以使用命令查看netcpa当前的运行状态：

# /etc/init.d/netcpad status

一般来说，根据VMware NSX最佳实践，工程师会部署3台NSX Controller，在本篇讨论的系统环境中，三台控制器分别是：

UCC-1 172.20.5.102
UCC-2 172.20.5.100
UCC-3 172.20.5.103

那么Controller控制器与netcap之间，又有什么联系呢？还记得之前我们验证vsfwd与NSX Manager之间保持连接的命令么？

# esxcli network ip connection list | grep 1234

命令行可以看到netcpa是和所有NSX Controller的TCP1234端口保持通信

由于netcpa是运行在边界和计算集群ESXi用户空间的一个组件，因此ESXi的管理地址将会作为显性IP，与Controller Cluster的每一台控制器保持连接，如下图中的172.20.1.211，就是ESXi的管理地址

本次讨论暂不涉及动态路由协议，我们首先通过静态路由的实验来验证我们静态路由更新的流程

如果在部署DLR-Instance操作时，管理员没有一同部署DLR-CVM的情况下：

管理员通过vCenter Web Client配置静态路由，通过NSX Manager将静态路由配置推送给NSX控制器(Internal API)
NSX控制器将Routing Information Base (RIB)转发到集群每一台ESXi的netcpa
netcpa通过vmkIink，将更新的路由表FIB写入到DLR-Instance内核中

如果在部署DLR-Instance操作时，管理员一同部署了DLR-CVM的情况下：

管理员通过vCenter Web Client配置静态路由，通过NSX Manager将静态路由配置推送给DLR-CVM所在ESXi的vsfwd
vsfwd通过VMCI，将静态路由配置推送给DLR-CVM
DLR-CVM通过VMCI，将Routing Information Base (RIB)报告给netcpa
netcpa通过TCP1234连接，将Routing Information Base (RIB)报告给Controller控制器集群
NSX控制器将Routing Information Base (RIB)转发到集群每一台ESXi的netcpa
netcpa通过vmkIink，将更新的路由表FIB写入到DLR-Instance内核中

下面我们来一起做一个简单的实验：

注：本篇只验证没有DLR-CVM控制虚拟机的情况，下一篇我将介绍拥有DLR-CVM控制虚拟机的情况。

1.部署一台DLR逻辑路由器，接口定义如下：

Dev-Web-Tier-0118:172.18.10.1/24（Internal）
Dev-App-Tier-0118:172.18.20.1/24（Internal）
Dev-DB-Tier-0118:172.18.30.1/24（Internal）
Dev-Transit-0118:172.18.0.2/29（Uplink）

2.选择新部署的Edge类型是逻辑路由器DLR，取消勾选“部署Edge设备”，即不部署DLR-CVM控制虚拟机

3.由于不选择部署DLR-CVM，因此无法在配置部署页面，点击“+”创建DLR-CVM虚拟机

4.根据拓扑规划，配置DLR直连的网络

5.为了验证静态路由流程，不配置默认网关

6.确认各项参数设置无误后，开始部署DLR；同时由于没有配置DLR-CVM，系统会自动发出警报，点击“是”确认并开始部署操作

7. 等待DLR部署完成，SSH访问ESXi命令行，查看ESXi内核空间中，创建的逻辑路由器实例DLR-Instance

在ESXi主机使用命令：# net-vdr -l --instance

该命令可以看到ESXi内核空间所有运行的DLR实例，以及这些实例的VDR Name和VDR ID，Lif端口统计，路由条目统计，邻居数等。由于每一台ESXi主机用户空间运行的netcpad是控制层面，因此我们可以看到Control Plane IP地址是ESXi主机的管理地址。另外，Edge Active，Yes表示该DLR-Instance至少有一台DLR-CVM，No表示该DLR-Instance没有DLR-CVM

8.在Edge界面，对于没有安装DLR-CVM的DLR-Instance实例，Edge状态是Active活动；对于安装了DLR-CVM的DLR-Instance实例，Edge状态是Deployed已部署

9.配置Edge边界服务网关，用于转发南北向流量，并添加一条静态路由，用于访问DLR直连的3个逻辑交换网络

10.配置一台JUMP虚拟机，连接到Dev-Web-Tier-0118这个逻辑交换网络，分配IP地址：172.18.10.10/24用于测试

11.在没有配置静态路由的情况下，Dev-Web-Tier-0118是没有办法PING通172.20.5.180，即Edge的Uplink地址的

12.通过Web Client，为DLR配置一条静态路由，声明172.20.5.0/24的下一跳地址为172.18.0.1

注：千万不要忘记“发布更改”

13.可以看到，在添加了静态路由后，JUMP虚拟机可以PING通172.20.5.180

14.此时我们回到ESXi底层，查看DLR Instance实例的变化；可以看到DLR多了一条路由计数，4->5

15.我们可以进一步查看DLR-Instance更加详细的信息，还记得之前我们特别记录的VDR Name这个字段么？

使用命令：# net-vdr -l -R default+edge-30(VDR Name)

以172.18.10.0为例，UCI分别代表，DLR的一个Interface接口连接到了这个网络，当前的状态是Connected已连接并且Up

以172.20.5.0为例，UG分别代表，DLR没有和这个网络直连，但是下一跳的地址是172.18.0.1

16.根据我们之前的讨论，这条“172.20.5.0/24 NH=172.18.0.1”的路由，是管理员使用Web Client配置的，通过NSX Manager的Internal API转发给Controller，再由Controller转发给每一台ESXi的netcpad，最终写入到DLR-Instance

17.访问任意一台NSX Controller命令行，验证我们的结论，这里我们要用到另一个着重记录的字段，VDR ID

使用命令：show control-cluster logical-routers routes 0x00001771（VDRID）