VMware SD-WAN by VeloCloud(后文称VeloCloud)的基本拓扑和组网模型。与VMware NSX数据中心产品相类似，VeloCloud也分可大体分为管理平面、控制平面和数据平面。在之前的分享中，晓冬和大家已经完成了Gateway和Edge的注册，组建了Hub-Spoke的双站点基本框架。如下图示，管理员可以在Orchestrator界面可以查看所有组件的状态。
今天，我们将继续共同完成VeloCloud的网络(数据平面)配置，实现HQ站点业务与BO站点业务的SD-WAN连接。
我们可以将Edge视为一台普通的三层交换机设备，用来作为站点内部所有分段的网关使用。管理员通过几次简单的鼠标点击和配置，就可以声明该站点内使用到的VLAN。
点击进入“Configure-Edge”界面，对Edge设备进行配置工作。
在Device页面下，找到“Configure VLAN”栏，根据需要添加VLAN信息。
如下图所示，管理员可以定义VLAN ID、网络信息、DHCP等配置。
LS-VLAN4000-HQ-Web-Tier-10.1.10.0；用于HQ站点的Web前端应用使用；
LS-VLAN4009-HQ-ALBEND-Tier-10.1.2.0；用于AVI后端地址池网段使用。
0x02.简单的三层配置
当然，在完成VLAN的划分后，需要定义一个TRUNK接口，作为这些VLAN的三层网关接口使用，如下图GE1所示。
（内心活动：对于分支站点来说，Edge同时一台AP设备，多个VLAN的互通就是这么简单，实在没有什么太多的配置操作，便捷性毋庸置疑。）
现在，晓冬将Web01虚拟机连接到VLAN4000进行网络连通性测试：
VLAN4000已经与VLAN4009实现了L3互通：
同时，Edge也实现了内部网络与Internet互联网络的互通：
在BO站点LAN网络尚未配置完善的情况下，HQ站点的Web前端应用尚无法访问BO站点的App中间件应用：
不难发现，在上面的用例中，Edge并没有配置任何静态路由或者动态路由。这是因为所有的业务网络(比如4000和4009)都属于Edge设备直连网络，默认L3互通；Edge设备用于上联的接口(10.1.0.17/29)因为配置了默认网关，路由表中默认就会存在0.0.0.0/0的默认路由，这样就实现了下游网络与上游网络的互通。在没有其他站点与HQ组网WAN的情况下，不会有其他的WAN相关路由。
注意：因为BO站点的Spoke已经与HQ站点的Hub建立了Cloud VPN，因此在VLAN4000和VLAN4009上线后，BO站点实际已经可以学习到了这两个地址段的路由。
那Edge能不能通过定义动态或者静态路由实现更为复杂的网络拓扑呢？
在BO站点，晓冬将演示Edge设备是如何作为NSX DC Tier0网关的上游设备，通过BGP协议动态更新路由信息的。
细心的朋友不难发现：启用路由协议的Edge设备接口都分配了唯一可用的IP地址，接口类型也区别于HQ站点的【Switched】，而是【Routed】。
Edge支持BGP和OSPF两种不同的动态路由协议，由于是和NSX DC集成，晓冬将演示如何使用BGP实现动态路由和互联。
首先，管理员同样是要在Edge设备的“Device”页面，激活BGP功能；
定义本地自治域AS，如65001；邻居的IP地址和AS，如采用eBGP方式与下游的NSX Tier0网关建立BGP邻居；
另一方面，在NSX DC的Tier0网关，也需要对应地进行BGP设置：
BO站点的这台Tier0网关下联2个Tier1网关，分别承载了BO站点的App中间件业务与DB后端数据库业务，我们需要将这些网络重分发到BGP。
在完成BGP配置后，我们不妨来看看Tier0网关和BO站点Edge之间的BGP邻居是否已经建立了连接、学习到了路由。
如下图，可以看到，在Tier0网关侧看到邻居已经建立【BGP state – Established】
进一步查看路由表，可以看到Tier0网关通过BGP学习到了三条路由条目：
10.0.100.11/32，这是上联Edge设备的管理地址；
10.1.2.0/24，这是HQ站点的ALB后端地址池网络，也就是之前我们定义的HQ站点的VLAN4009；
10.1.10.0/24，这是HQ站点的Web前端应用网络，也就是之前我们定义的HQ站点的VLAN4000。
这说明上游Edge设备已经通过SD-WAN的VeloCloud Gateway组件接收到了路由更新，学习到了HQ站点的网络信息，并且通过BGP协议，传递给了下游的Tier0网关设备。
而查看BO站点Edge的路由表，可以相互印证这一点。
如下图所示，Edge设备通过BGP路由协议学习到了10.2.11.0/24和10.2.12.0/24两个NSX DC网络的路由。
现在，通过简单的网络配置，我们已经将HQ站点和BO站点利用Internet链路构建了SD-WAN网络。接下来各位跟随我一同来验证一下虚拟云网络的连通性：
源10.1.10.11，位于HQ站点的一台Web前端虚拟机；目的是BO站点的App中间件虚拟机；
第一跳是10.1.10.254，即自己所在的网关地址，换言之到达了HQ站点的Edge设备；
第二跳是1.0.0.102，这是BO站点Edge的公网IP地址，换言之数据包已经通过HQ站点与BO站点的SD-WAN链路(Overlay)到达了BO站点；这其实包含了Overlay的封装，通过1.0.0.0/24公网的传输，以及到达BO Edge之后的解封装等一系列复杂的网络交互；
第三跳是10.2.10.1，这是BO站点Edge下联的Tier0网关的上行链路地址；
第四跳是100.64.144.1，这是BO站点Tier0网关的下联Tier1网关的内联地址，我们在NSX DC的连载中介绍过，Tier0与Tier1之间的级联将会由NSX-T Manager自动分配一个100.64.0.0/16的地址用于互联。
最终在Tier1网关的路由下，到达了目标的App中间件网络10.2.11.0/24。
现在右侧HQ站点的NSX DC网络与左侧BO站点的NSX DC网络，已经通过SD-WAN链路实现了三层互通。Web服务器通过SD-WAN与中间件App服务器进行通信，而中间件App服务器通过NSX DC的软件定义网络与后端DB数据库服务器进行通信，形成了一个覆盖虚拟云网络的典型3-Tier应用模型。
我们知道，NSX DC除了提供软件定义网络、分布式防火墙以外，也可以提供软件负载均衡器的功能。如下图所示，晓冬利用该特性，实现了App01和App02两台中间件的负载均衡。
现在，用户已经可以正常地访问业务了。如下图所示，软件负载均衡器会“轮询”，将Web服务器发来的请求，负载均衡到App01和App02两台中间件进行处理。
客观地说，NSX DC的负载均衡能扩大SDN加速业务敏捷上线的优势。在一些实际的项目中，通过vRealize Automation这样的云管理平台，我们的客户能自动化地交付SDN网络，并提供负载均衡功能，在短短数十分钟内上线大量业务，为企业发展助力。但不可否认的一点，是NSX DC的负载均衡有自己的不足之处，比如需要借助CMP才能实现Auto-Scaling功能、缺少WAF功能等。为了解决这个问题，用户也可以选择使用NSX Advanced Load Balancer(旧称AVI)组件来提供更为强大的负载均衡功能，完善整个基于VMware NSX家族的虚拟云网络拓扑。
