NSX static routing and control plane update process 1

In the last years, through the discussion of the NSX distributed firewall implementation principle, we are familiar with a component -vsfwd NSX management plane can easily be overlooked.

Today, we discuss NSX control plane components and processes to verify static routing updates through a simple experiment.

NSX control plane comprises three important components, respectively NSX Controller Cluster controller cluster , NSX the Logical Control Router router control logic the VM virtual machine and can easily be overlooked netcpa .

NSX best practice, the recommendation to deploy a data center cluster 3, namely bearer vCenter, NSX Manager, NSX Controllers components such management cluster the Cluster Management , carrying Edge, DLR-CVM the boundary cluster Edge Cluster and bearer traffic calculated cluster cluster Compute .

NSX Controllers management plane is generally installed and running on the management ESXi cluster, the cluster management virtual machine does not need to carry the logic switching or logical routing functions, it is not necessary for the host is ready to operate, no need for installing esx-nsxv vib. But for border and cluster computing clusters, you must host the preparatory stage , installing esx-nsxv vib, in order to implement the logic switching and routing.

Access the ESXi command line, use the command: # esxcli software vib list | grep nsx, you can see the installation of 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。

 

 

发布了3 篇原创文章 · 获赞 20 · 访问量 4万+

Guess you like

Origin blog.csdn.net/z136370204/article/details/104107375