NSX干货分享·Edge传输节点和路由

简介: 笔者最近持续跟进了一个客户的NSX-T数据中心实施项目。对于用户来说,这个项目最难的地方就是实现业务网络从传统拓扑“渐进式”过渡到NSX逻辑网络。我们知道,VMware NSX-T是一款纯软件方式实现SDN架构的产品,其带给用户网络的灵活性体现在能够满足在网络拓扑中同时存在SDN拓扑和传统拓扑的需求。

     笔者最近持续跟进了一个客户的NSX-T数据中心实施项目。对于用户来说,这个项目最难的地方就是实现业务网络从传统拓扑“渐进式”过渡到NSX逻辑网络。我们知道,VMware NSX-T是一款纯软件方式实现SDN架构的产品,其带给用户网络的灵活性体现在能够满足在网络拓扑中同时存在SDN拓扑和传统拓扑的需求。

     对于新建数据中心这类项目来说,是否采用SDN架构是一个“TO BE or NOT TO BE”的简单问题。但对于一些对现网进行改造的项目来说,尽最大可能地减少对生产系统的影响,进而实现业务网络的“平滑迁移”就显得弥足珍贵了

     如上图所示,目前用户的虚拟机流量完全由分布式虚拟机端口组或者NSX-T VLAN传输区域的分段来承载。管理员创建一个Overlay传输区域,以“传输节点配置文件”的方式关联vCenter上的某一个群集应用生效。在完成了包括Tier0网关、Tier1网关、Overlay分段、南北向路由等一系列配置后,就为业务从传统网络平滑过渡到NSX-T的逻辑网络创造了全部的先决条件。注意:上述所有组件的创建和生效并不会对现网产生任何的影响,自然也不会造成虚拟机的任何网络中断或者影响生产。这之后的工作,就和我之前公众号的一篇分享所描述的那样(NSX逻辑桥接不仅仅是一个L2组件),按部就班循序渐进即可。

     不过,今天的主题并不是想要“炒冷饭”。而是在这个项目中,一线工程师因为【采用虚拟机版本的Edge传输节点和启用了HSRP的上游设备】遇到了一些“小小的阻力”。所以想利用公众号这个平台,和各位关注VMware NSX的朋友一同分享经验和教训。


✨0x01.Edge虚拟机的上联网络(端口组)配置

     对于Edge传输节点(后文简称Edge)来说,至少存在三种不同的网络流量:
➀ Edge与NSX Manager之间的管理流量;

➁ Edge与其他传输节点之间的Underlay流量,该流量通过GENEVE协议封装,属于Overlay传输区域的流量;

➂ Edge与物理网络设备之间的南北向流量,属于VLAN传输区域的流量。如果Edge采用裸金属方式部署,一般情况下它的连接方式如下图所示:

     由于是物理设备之间的跳线,管理员可以非常“直观”地连接Edge与ToR交换机或者核心设备。对于虚拟机Edge来说,Edge与物理设备之间,还夹着一层ESXi上的虚拟交换机,情况就有点复杂了。对于Edge中运行的Tier0网关来说,业务虚拟机的北向流量最终会通过Tier0网关的上联接口传输到物理网络。从路径上看,这个流量至少经过了Underlay网络-Edge实例中的Tier0上联-虚拟交换机的端口组-ESXi的VMNIC适配器-物理设备这些节点。中间任何一个环节配置出现了纰漏,必然会造成南北向通信的不可达。那么,面对由ESXi承载的虚拟机Edge,管理员应该如何来进行基本的上联网络配置呢?

     首先各位要清楚一点:Edge虚拟机默认情况下一共有4块vNIC虚拟网络适配器用于承载管理、Overlay传输区域和VLAN传输区域的流量。

     ➀ 管理流量:管理员在虚拟交换机上配置一个虚拟机端口组vPG-VLAN1001,将Edge虚拟机的第一块vNIC连接到这个端口组,就可以实现通信。(毫无难度,基本操作)

     ➁ Overlay流量:管理员同样可以在虚拟交换机上配置一个虚拟机端口组vPG-VLAN100,然后将Edge虚拟机的第二块vNIC连接到这个端口组。(毫无难度,基本操作)

可对于VLAN流量而言,那就有点复杂了!

很多人会说,这有什么复杂的!每一台Edge虚拟机不是2块vNIC么?每一块vNIC连接到对应的一个端口组不就好了,就像下图所示的这样。

表面上看,这种设计没有任何的漏洞。但对于Edge01这台Edge的VLAN102的流量,真的会经过vNIC3转发么?同理,对于Edge02而言,VLAN104的流量,真的会经过它的vNIC3转发么?

答案是否定的!因为在NSX-T的体系中,有一个概念叫做“传输区域(后文称TZ)”。管理员在置备或者交付Edge传输节点的时候,其实都会配置“传输区域”和“主机交换机”。

如上图所示,以Edge01举例来说,VLAN TZ的主机交换机在关联Edge虚拟机vNIC的时候,其实只关联了vNIC2。vNIC3处于“未被使用”的状态。因此,无论是VLAN101还是VLAN102的流量,都只会经过vNIC2的虚拟网卡转发到ESXi的虚拟交换机。此时,虚拟交换机的端口组就要满足同时放行VLAN101和VLAN102的流量。所以管理员应该配置一个Trunk类型的虚拟机端口组提供给Edge虚拟机的vNIC2上联。

就这个情况来说,也会有朋友提出疑问:能不能创建两个VLAN TZ,这样不就可以用上vNIC3了么?的确如此。在许多采用裸金属Edge的项目中,为了实现多上行链路冗余,的确可以采用配置两个VLAN TZ,关联Edge的两块物理网络适配器来提高利用率、提高带宽(A-A模式,开启ECMP)、实现冗余。但是在虚拟机Edge的场景下,本身的多链路冗余是通过ESXi的多上行链路实现的,因此不太需要考虑这个问题。当然,虚拟机Edge可能存在一些别的问题,这点我们后面再谈。


✨0x02.一种可借鉴的路由配置参考

“世上没有两片完全相同的树叶”,莱布尼茨的话放到NSX-T的项目中同样适用。不同的用户、不同的环境、不同的架构自然会有不同的配置。区别于传统网络设备的“刷配置”,包括路由在内的NSX-T的配置只是简单地点击鼠标、输入文字而已。但反过来说,很多项目的经验又是值得归纳、总结和分享的,所以晓冬想借这个机会,结合之前亲身经历的几个项目,给出一个典型的路由配置示例,为工程师提供一些建议和参考。

路由拓扑:一个典型的NSX南北向互联拓扑通常包括Tier0网关、物理设备和路由协议。

     通常情况下,出于高可用性、高利用率、高吞吐性能等考量,项目中都会采用Active-Active方式部署Tier0网关。Edge群集中的多台Edge内核中都会创建并运行Tier0网关的服务路由器(后问称SR)角色。如上图所示,两台Tier0SR将通过BGP协议与上游物理设备建立邻居关系,实现路由互通。每一台Tier0SR都会有两根上行链路,分别与上游物理设备互联。所有有状态的服务,都将由Tier1SR承载。

     传输区域设计:

     基于Tier0有多条上行链路,对应“Edge的不同接口与物理设备接口”的互联线路。因此至少应该配置两个VLAN传输区域,才能满足同一个Tier0SR的每一根上行链路的流量分别由两块物理网络适配器承载的要求。

image.png

每一台Edge实例,都需要配置两个主机交换机,分别关联不同的VLAN传输区域,并且使用不同的物理网络适配器来承载流量。

image.png

VLAN分段与接口配置:

因为Tier0网关合计有四根不同的网络上联,所以管理员需要配置四个分段,并且两两关联到对应的VLAN传输区域。

在完成VLAN分段的配置后,紧接着完成Tier0网关的配置。建议配置环回口用于标识RouterID和为路由故障排查提供方便。

当然,四根不同的上行链路会由两台Edge承载。换句话说,每台Edge中运行的Tier0SR实例都会有两根上行链路到不同的两台上游物理设备。

image.png

在Edge实例的命令行,管理员可以通过命令验证配置是否生效。比如下图所示的Edge01中运行的Tier0SR实例的概况:

image.png

路由协议配置:

NSX的路由配置是相当直观与便捷的。BGP的声明一般分为几个步骤:邻居关系的声明、本地源接口的声明、需要重分发的分段声明。

image.png

通常情况下,包括Tier1直连分段、负载均衡器的VIP地址、NAT的转换IP都会重分发到BGP。

而且,为了实现链路的快速收敛,需要在Tier0网关和上游物理设备配置BFD协议。

通过命令行进入到Tier0SR实例之后,可以直观地了解到每一台Tier0SR通过eBGP学习到的路由条目以及BFD会话的状态。

image.png

但是这样真的够了么?

在某一个项目中,晓冬遇到了一个紧急故障:因为用户的不规范操作触发了BUG,导致Edge群集中正常运行的所有Tier0SR全部移除了BGP邻居。这无疑会造成所有南北向流量的中断,影响到所有业务的正常运行。因此为了避免出现BUG或者人为因素造成的上述情况,管理员可以酌情增加若干静态路由。

比如Tier0SR可以增加一条默认静态路由,将去往非直连或者服务网段的流量转发到上游物理设备。同时,为了避免对通过eBGP学习到的“全零”路由产生影响,需要将管理距离调高一点,比如180(高于eBGP,低于Inter-SR iBGP)

     这样,在正常情况下,Tier0SR会根据eBGP学习到的路由条目执行转发。当所有的eBGP邻居全部中断的情况下,默认静态路由就会出现在路由表中,确保南北向业务的正常互访。当然,对于上游物理设备来说,同样需要有南向的汇总静态路由。其实,在许多项目中,由于网络规模不是很大,用户会直接选择静态路由的方式来实现NSX网络与外部网络的互通。

     说到这里,各位看官认为我们的路由协议的配置“完满”了么?

     答案依旧是否定的。静态路由虽然简单,但是它无法像动态路由一样侦测链路状态。如果简单地使用静态路由而不考虑故障的情况,可能会造成路由黑洞。因此,对于静态路由而言,同样需要配置BFD。

image.png

     比如现在Tier0SR的其中一条上行链路因为Edge的物理网络适配器出现故障而造成了中断。在配置了静态路由,但未配置BFD的情况下,上游物理设备依旧会转发到这条互联链路上,进而触发路由黑洞,造成部分南北向流量的中断。因此,动态路由/静态路由+BFD在NSX的路由协议配置中是绝对要遵循的原则之一。

     最后,大家不要忘记一点。就是在同一个Tier0SR实例有多条上联的时候,一定要开启Inter-SR iBGP功能,这同样也是避免出现路由黑洞情况而做的配置。详细的说明,可以参考晓冬之前的一篇分享-NSX干货分享·一些有趣且实用的Tips。


✨0x03.虚拟机Edge环境下Tier0网关路由配置Tips

上文的路由设计与配置示例是针对裸金属Edge的,那么在面对Edge是虚拟机的场景下,是否依然适用呢?首先可以确定的是,路由设计与配置的整体思路肯定是相同的。实际上,VMware有专门的VVD文档来指导管理员进行设计与配置。比如:VLAN传输区域的流量不要配置HSRP了吧(此处应该有一张滑稽脸)                                     image.png


但并不是所有用户都有客观条件去按照VVD的描述落地NSX的。实际上,晓冬参与的这个项目正式因为Edge虚拟机+上游网络设备配置了HSRP才遇到了一些问题。

image.png

我们知道,通常情况下,虚拟交换机至少会使用两块网络适配器作为上联,连接到VLAN或者Underlay网络。虚拟机Edge用于VLAN传输区域的vNIC2和vNIC3连接到虚拟交换机上的端口组。如上图所示,红色的链路表示Tier0SR的某一个实例用于和某一台上游网络设备互联的线路。当Edge是裸金属的情况下,其实Tier0SR的上行链路与裸金属Edge的物理网络适配器是可以通过主机交换机实现Mapping的。但对于虚拟机Edge来说,红色的流量到达虚拟交换机之后,由于Edge和ESXi的物理网络适配器没有任何的对应关系,可能会有50%的流量到达另一台物理网络设备。这是裸金属Edge场景下不会遇到的问题。

当然,解决问题的办法还是多种多样的。比如手动指定特定的端口组,只使用固定的某一块网络适配器。

image.png

如此,流量就只会转发到与对应物理设备互联的网络适配器上。同时单个特殊端口组的配置并不会影响虚拟交换机和其他端口组。但这种方式仅适用于物理服务器(ESXi)直连网络核心的情况,如果中间有服务器区域的接入交换机或者服务器是刀片式服务器(真正连接网络设备的是刀箱,刀片和刀箱上联中间存在“看不见的”背板交换机),那就无能为力了。

在这个项目中,用户就遇到了这样的情况。无论是ESXi还是NSX,都无法控制虚拟机Edge的VLAN TZ上行流量走向。好在办法总比困难多!基于用户的上游网络设备配置了HSRP,因此Tier0网关可以相对应地做出一些改变来实现南北向流量的互通。

对于Tier0网关来说,其实只需要配置两根上行链路。由于该用户采用静态路由的方式来实现南北向互通。那么对于10.0.0.4/29这个接口而言,路由条目的下一跳地址设置为10.0.0.1;同样地,对于10.0.0.12/29这个接口而言,路由条目的下一跳地址设置为10.0.0.9。这样,无论红色的流量究竟被转发到哪一台上游物理设备,都可以“找到”10.0.0.1这个地址;反之无论去往NSX的流量被转发到哪一台上游物理设备,都可以找到10.0.0.4这个地址。只是这种做法可能不太符合最佳实践罢了。

在说明Tier0网关路由配置的0x02章节,晓冬提到无论是动态路由还是静态路由,为了实现链路的快速故障切换,都应该配置BFD。但对于上述这个用户而言,虽然静态路由的下一跳地址写成了HSRP的VIP地址,解决了VLAN TZ流量的转发问题。但VIP地址如果作为BFD的对端地址,BFD会话是无法建立的,最终会导致包括全零路由在内的静态路由条目的丢失,同样会造成南北向业务的中断。在查阅了文档之后,通过在NSX的Tier0网关配置静态路由+BFD,同时在上游思科的网络设配配置IP SLA之后完美解决了这个问题。


✨0x04.说点什么

在经历了多个NSX的项目之后,越来越觉得NSX数据中心是一款既需要了解原理更需要实践和积累的产品。比如在涉及分段和虚拟交换机的时候,需要熟悉MAC表、ARP表和VTEP表的更新和工作流程,才能在项目中遇到问题情况下,运用原理知识去针对现象提供思路帮助排障。相比之vSphere的“下里巴人”或者vRealize Suite的“阳春白雪”,NSX更像是一曲永不休止的乐章,充满着吸引人不断深入评鉴的魅力。

相关文章
|
SDN 网络虚拟化 数据中心
联盟时代III.Edge传输节点就绪
相比较Single-Site以及典型的Multi-Site场景,NSX Federation架构下就绪Edge传输节点会有一些额外的步骤。就单从网络层面来说,Underlay的规划会有一些额外的设置。今天的分享想和大家说说Federation架构下,Edge传输节点的就绪步骤。
联盟时代III.Edge传输节点就绪
|
安全 SDN 网络虚拟化
变形金刚外传0x05:虚拟机版本Edge传输节点部署
这几日与同事聊起NSX,谈起如何用最简单的语言来描述它,无非就是软件定义网络SDN+网络功能虚拟化NFV+安全微分段DFW。NSX DC产品的软件定义网络是借助在Hypervisor内核中的vdl2和vdrb模块实现,vsip模块则用于实现安全微分段功能。那么问题来了,包括网络地址转换NAT、负载均衡器Load Balancer等在内的NFV是由谁在承载的呢?
变形金刚外传0x05:虚拟机版本Edge传输节点部署
|
网络安全 虚拟化 数据中心
一步步实现SDDC-Edge与动态路由实现
实验摘要: 1>Windows Server软路由器静态路由设置 [难度★复杂度★] 2>Edge Services Gateway边界服务网关部署 [难度★复杂度★] 3>动态路由实现 [难度★★复杂度★★★]
一步步实现SDDC-Edge与动态路由实现
|
Kubernetes 测试技术 应用服务中间件
Kubernetes的service mesh – 第五部分:DogFood环境,Ingress和Edge路由
概述 在这篇文章中,我们将向您展示如何使用Linkerd实现的Service Mesh来处理Kubernetes上的入口流量,在Service Mesh中的每个实例上分发流量。我们还将通过一个完整的例子来介绍Linkerd的高级路由功能:如何将特定的请求路由到较新版本的应用实例上,比如用于内部测试的、预发布的应用版本。
1357 0
|
2月前
|
Web App开发 安全 中间件
谷歌、火狐、Edge等浏览器如何使用ActiveX控件
allWebPlugin 是一款为用户提供安全、可靠且便捷的浏览器插件服务的中间件产品,支持 Chrome、Firefox、Edge 和 360 等浏览器。其 V2.0.0.20 版本支持一个页面加载多个插件,并解决了插件与浏览器之间的焦点问题。用户可通过“信息化系统 + allWebPlugin + 插件 + 浏览器”的解决方案实现 ActiveX 插件的无缝集成。下载地址见文末,安装包含详细说明。
|
2月前
|
安全 搜索推荐 数据安全/隐私保护
定制你的清爽Mac版Edge浏览器
【10月更文挑战第5天】本文介绍了如何定制Mac版Edge浏览器以实现清爽高效的操作体验。内容包括:选择主题以适应不同环境,自定义工具栏以保持界面简洁;启用隐私浏览模式及调整隐私设置来保护个人信息;通过更新浏览器和开启安全筛选器来加强安全性;安装扩展程序以增强功能,并设置启动选项和快捷方式以便于操作。通过这些方法,你可以根据个人需求打造个性化的浏览器环境。
|
3月前
|
安全 Oracle Java
edge浏览器加载java插件
edge浏览器加载java插件
|
3月前
|
安全
微软网站上关于在Edge浏览器中打开或关闭smartScreen的说明有误
微软网站上关于在Edge浏览器中打开或关闭smartScreen的说明有误
微软网站上关于在Edge浏览器中打开或关闭smartScreen的说明有误
|
3月前
|
Web App开发 缓存 安全
解决Edge浏览器提示“此网站已被人举报不安全”
【9月更文挑战第1天】当 Edge 浏览器提示“此网站被举报为不安全”时,可尝试:关闭 Microsoft Defender SmartScreen;检查网站安全性;清除缓存和 Cookie;更新 Edge 至最新版;或使用其他浏览器。若问题依旧,联系网站管理员和技术支持。同时,避免在不可信网站输入敏感信息,保护网络安全与隐私。
494 7
|
4月前
|
数据采集 Web App开发 测试技术
使用Selenium调试Edge浏览器的常见问题与解决方案
在互联网数据采集领域,Selenium常用于自动化网页爬取。针对使用Edge浏览器时遇到的启动远程调试失败、访问受限及代理IP设置等问题,本文提供了解决方案。通过特定命令启动Edge的远程调试模式,并利用Python脚本配合Selenium库,可实现代理IP、User-Agent的设定及Cookie管理等高级功能,有效提升爬虫稳定性和隐蔽性。遵循步骤配置后,即可顺畅执行自动化测试任务。
858 1
使用Selenium调试Edge浏览器的常见问题与解决方案