在上一篇里，借着对NSX分布式防火墙实现原理的讨论，我们熟悉了NSX管理平面中很容易被忽略的一个组件-vsfwd。
今天，我们一起讨论NSX控制平面的组件，并通过一个简单的实验来验证静态路由更新的流程。
NSX控制平面包含三个重要的组件，分别是NSX Controller Cluster控制器集群，NSX Logical Router Control VM逻辑路由器控制虚拟机和很容易被忽略的netcpa。
根据NSX的最佳实践，一个数据中心建议部署3个集群，分别是承载vCenter、NSX Manager、NSX Controllers等组件的管理集群Management Cluster，承载Edge、DLR-CVM的边界集群Edge Cluster和承载业务的计算集群Compute Cluster。
管理平面中的NSX Controllers一般安装并运行在管理集群的ESXi，管理集群承载的虚拟机不需要逻辑交换或者逻辑路由等功能，因此不需要进行主机准备操作，没必要安装esx-nsxv vib。但是对于边界集群和计算集群而言，必须经过主机准备阶段，即安装esx-nsxv vib，才能实现逻辑交换与路由。
访问ESXi的命令行，使用命令：# esxcli software vib list | 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）
可以看到这条路由的来源是API，指的就是NSX Manager通过Internal API下发给NSX Controller，与我们的结论相一致
18.此时我们通过命令行，停止在用户空间运行的netcpad服务
使用命令：# /etc/init.d/netcpad stop
19.管理员通过Web Client删除静态路由
20.在发布更改操作后，路由更新已经通过Internal API，由NSX Manager转发给了Controller
21.但是由于netcpad服务一直没有启动，路由更新不会写入到DLR Instance，因此无论过了多久，JUMP虚拟机都可以继续访问172.20.5.180
22.通过ESXi命令行查看DLR-Instance的路由条目，也可以确认这一点
23.此时管理员再通过命令行，重启启动netcpad服务
24.ESXi命令行查看DLR-Instance的路由条目，我们会发现之前的静态路由依旧存在，但是在等待一段时间后，这条静态路由就会从DLR-Instance路由表中消失
注：这个时间我还没有想到比较好的办法去验证，不知道各位读者是否有比较好的建议
通过上文的描述，相信各位对NSX的控制平面及没有DLR-CVM参与的静态路由更新有了比较深入的了解。
当然，在没有DLR-CVM的情况下，管理员是没有办法配置动态路由的，因为动态路由的邻居关系需要DLR-CVM的参与。那么如果管理员要为现有Active部署状态的DLR-Instance添加DLR-CVM，是否可行呢？
我们可以验证一下，可以看到，即使管理员在DLR Appliance页面，重新添加DLR-CVM，它的部署状态依旧是Undeployed，因此必须删除该DLR-Instance，重新部署一台DLR，才能满足我们的要求
下一篇，我们将介绍在DLR-CVM参与的情况下，静态路由如何下发到DLR-Instance。
