在上一篇里，我们介绍了NSX控制平面的组件，包括NSX Controller集群、DLR-CVM控制虚拟机和很容易被忽略的netcpa。
通过一个简单的实验，我们一同验证了在没有DLR-CVM的前提下，管理员配置静态路由并更新的流程：
-
管理员通过vCenter Web Client配置静态路由，通过NSX Manager将静态路由配置推送给NSX控制器(Internal API)
-
NSX控制器将Routing Information Base (RIB)转发到集群每一台ESXi的netcpa
-
netcpa通过vmkIink，将更新的路由表FIB写入到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内核中
可以看到，在上述情况下，管理平面组件vsfwd也参与了静态路由配置并更新的流程。
我们通过第二个实验来验证我们的观点：
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部署的位置，一般建议部署在Edge Cluster边界集群
4.根据拓扑规划，配置DLR直连的网络
5.为了验证静态路由流程，不配置默认网关
6.确认各项参数设置无误后，开始部署DLR
7.在完成DLR-Instance部署后，相比无DLR-CVM的情况，可以看到2个明显的不同
-
多了一台DLR-CVM控制虚拟机
-
DLR-Instance的部署状态是Deployed已部署
8.SSH访问ESXi命令行，查看ESXi内核空间中，创建的逻辑路由器实例DLR-Instance
在ESXi主机使用命令：# net-vdr -l --instance
-
可以看到Edge Active状态已经是Active
-
新创建的DLR-Instance的VDR ID是0x00001771，VDR Name是default+edge-31
9.管理员通过Web Client添加一条静态路由
10.很快，我们就能看到JUMP虚拟机可以PING通172.20.5.180
11.访问NSX Controller，检查路由的更新源；可以看到路由的更新源从原来的API，变成了CONTROL_VM
12.查看DLR-Instance的路由表，可以看到多了一条静态路由条目
13.对比有无DLR-CVM的两种情况，不难发现：两种模式下，netcpad在路由更新的过程中，都扮演着无法替代的角色，现在我们通过命令行，停止在用户空间运行的netcpad服务
14.此时可以看到DLR-instance的路由条目没有发生改变，JUMP虚拟机也可以继续PING通172.20.5.180，说明NSX架构中，控制平面与转发平面完全隔离
注：这并不代表说，DLR-CVM控制虚拟机的故障不会影响DLR-Instance的无状态转发，相反，在配置动态路由的情况下，南北向流量可能会因为DLR-CVM的故障受到严重的影响。
15.管理员保持ESXi用户空间的netcpad停止服务状态的同时，通过Web Client删除静态路由
16.在保持netcapd停止的情况下，JUMP虚拟机可以继续PING通172.20.5.180
17.ESXi底层命令行查看DLR-Instance实例的信息，也可以看到路由条目没有发生变化
18.由于netcpad服务的停止，不会影响NSX Manager通过vsfwd，将路由配置下发到DLR-CVM，因此在DLR-CVM的底层，我们是可以看到“172.20.5.0/24 NH=172.18.0.1”这条静态路由已经不存在了
19.管理员通过命令行，重新启动netcpad服务
20.可以看到，在netcpad服务重新启动后，DLR-instance的路由条目发生了更新
21.相对应的，JUMP虚拟机也无法再PING通172.20.5.180地址
22.下面我们关闭DLR-CVM控制虚拟机电源
23.管理员重新添加一条静态路由
24.表面上看，似乎没有什么问题，但是在Publish Changes之后，再次刷新页面，这条静态路由会自动消失
25.很明显，这条静态路由并没有下发到DLR-CVM，当然也就不存在DLR-CVM报告给Controller，最终转发到DLR-Instance的后续步骤了，因此JUMP肯定无法PING通172.20.5.180
26.在ESXi底层，查看DLR-Instance信息，也可以证明这一点
27.访问Controller底层，也可以看到没有任何路由更新的信息
28.重新打开DLR-CVM控制虚拟机的电源，同时停止ESXi用户空间运行的vsfwd服务，验证vsfwd对于静态路由更新流程的影响
29.管理员添加一条静态路由
30.在这种情况下，管理员刷新Web Client，这条静态路由的配置是不会自动消失的
31.在Controller底层查看路由更新的信息，由于DLR-CVM没有收到vsfwd转发过来的路由配置，因此DLR-CVM也没有新的路由更新报告给Controller
32.在DLR-CVM命令行，确认没有收到静态路由配置的更新
33.我们在ESXi命令行，重新启动vsfwd服务
34.这时，DLR-CVM马上就收到了静态路由配置条目，这条路由更新是NSX Manager通过管理平面组件vsfwd下发给DLR-CVM的
35.在Controller底层，可以看到DLR-CVM通过netcpad报告的路由更新
36.集群每一台ESXi主机的netcpad在收到Controller的路由表更新后，转发给DLR-Instance
根据上文的描述，我们验证了在部署DLR-CVM的情况下，管理员配置静态路由后的更新流程：
vCenter------API------NSX Manager-----Internal API-----vsfwd-----VMCI-----DLR CVM-----VMCI-----netcpa-----TCP1234-----Controller-----TCP1234-----netcpa-----vmklink-----DLR Instance
通过前后两篇文字的讨论，相信各位对NSX控制平面组件及静态路由更新的流程，有了比较深入的了解，
