1. 从二层到三层当VM想和“隔壁小区”的邻居聊天大家好我是老张在云网络这块儿摸爬滚打十来年了。今天咱们来聊聊华为云Stack 8.X里一个非常核心但也让不少刚入行的兄弟有点迷糊的话题VPC内部的三层流量模型。说白了就是同一个VPC虚拟私有云里两个不在同一个子网网段的虚拟机它们之间是怎么“打电话”的。你可能会想这不就是路由嘛有啥复杂的哎在传统的物理网络里确实就是路由器一转的事。但在云里特别是在华为云Stack这种分布式架构下事情就变得非常有意思了。这里没有一台实体的、集中式的路由器杵在那儿所有的“路由”功能都被打散到了每一台计算节点宿主机上。这就是所谓的“分布式网关”。想象一下你们小区的每个门卫宿主机不仅知道自己楼里本子网的住户VM还都有一份整个小区VPC的住户名册和路线图路由表能直接帮你把快递送到隔壁楼而不用先跑到小区中央的物业办公室去绕一圈。这种设计带来的直接好处就是流量路径最优、延迟低而且没有单点瓶颈性能可以随着节点数量线性增长。那么二层和三层流量模型最本质的区别是啥我打个比方。二层通信就像你和你的对门邻居聊天都在同一层楼同一个子网你喊一嗓子他就能听见靠的是MAC地址广播和“吼”ARP协议。而三层通信呢就像你要去隔壁那栋楼找朋友虽然还在同一个小区VPC里但已经不在同一栋楼子网了。这时候你就不能直接喊了你得先走到你这栋楼的单元门口网关把话数据包交给门卫分布式网关告诉他你要找隔壁楼几零几的朋友门卫根据他手里的地图路由表帮你把话传过去。在华为云Stack 8.X里这个“单元门口的门卫”角色在8.0.3版本之前主要是由br-int网桥来扮演的它上面挂着各个子网的网关接口。但从8.0.3版本开始这个重要的职责移交给了专门的br-router网桥。这个变化很关键相当于把“居民楼门卫”br-int负责楼内交换和“跨楼快递员”br-router负责跨子网路由的职责分得更清楚了架构更清晰也更容易管理和排错。咱们后面会详细看到br-router是怎么干活的。2. 一次跨子网访问的完整旅程拆解数据包“闯关”流程光说概念可能还是有点抽象咱们直接跟一个数据包走一遍它的冒险旅程。假设现在VM1IP: 192.168.1.10想ping一下VM2IP: 192.168.2.20它们属于同一个VPC下的不同子网。第一步出发前的准备——ARP请求网关MACVM1很聪明它一看目的IP192.168.2.20发现跟自己不在一个网段192.168.1.0/24vs192.168.2.0/24。它立刻明白这事儿得找“领导”网关帮忙转发。于是VM1会发起一个ARP请求大声问“我的网关192.168.1.1你的MAC地址是啥啊”这个ARP广播报文会被它所在的宿主机Host1上的虚拟交换机OVS捕获。关键点来了这个ARP请求并不会离开Host1在华为云Stack的分布式网关模型下每个宿主机上的br-tun网桥就“知道”本机所承载的所有子网网关的MAC地址。所以br-tun会直接代网关回复一个ARP应答告诉VM1“我就是网关192.168.1.1我的MAC是GW1_MAC。”这个过程极其快速完全在Host1内部完成避免了跨主机的广播泛洪。第二步首次封装——穿上“小区内部通行马甲”拿到网关MAC后VM1开始封装要发送的原始ICMP请求数据包我们称之为“原始载荷”。二层封装源MAC填自己的VM1_MAC目的MAC填刚刚问到的网关MACGW1_MAC。三层封装源IP是192.168.1.10目的IP是192.168.2.20。这个数据包现在看起来就是一个最普通的、目标是本地网关的IP包。VM1将它从虚拟网卡发出进入Host1的虚拟网络世界。第三步br-tun的魔法——换上“跨楼快递服”数据包首先到达br-int网桥但它的目的MAC是网关所以会根据流表被转发到负责隧道和外部通信的br-tun网桥。这里是第一个魔法发生地。br-tun一看这个包是要跨子网的它需要为这个包穿上一件“快递服”以便它在宿主机之间的物理网络上传输。这件“快递服”就是VXLAN封装。br-tun会做以下几件事识别目标子网根据目的IP192.168.2.20查询本地控制信息知道它属于VNI-2VXLAN Network Identifier可以理解为隔壁楼的编号。更换外层源MAC它不会用VM1的MAC作为快递单的发件人。而是用本宿主机Host1上针对目标子网网关192.168.2.1所对应的那个分布式虚拟路由器端口的MAC地址我们称之为DVR1_MAC。记住同一个逻辑网关在不同宿主机上的这个DVR MAC是不同的这是分布式网关的一个关键特征。封装VXLAN头加上VXLAN头部其中关键的VNI字段设置为VNI-2。确定外层目的IP和MACbr-tun需要知道这个包该从哪个物理网卡发出去、发给谁即VM2所在的宿主机Host2的隧道端点IP。它通过查询隧道映射表获得Host2的IP。接着它需要知道到达Host2的下一跳MAC在物理Underlay网络里这通常是通过标准的ARP/路由过程获得我们这里简化为Host2_Phy_MAC。于是数据包被套上了一个新信封外层二层源MACDVR1_MAC 目的MACHost2_Phy_MAC外层三层源IPHost1_IP 目的IPHost2_IPVXLAN头VNIVNI-2内层原始载荷就是VM1最初发出的那个源MACVM1_MAC 目的MACGW1_MAC 源IP192.168.1.10 目的IP192.168.2.20。第四步物理网络之旅——贴上“派送标签”封装好的VXLAN报文被送到br-physnet网桥负责连接物理网络的网桥。在发送到物理网卡之前根据网络配置可能会被打上一个特定的VLAN标签比如tunnel_bearingVLAN。这个标签就像快递袋上的“航空件”“陆运件”标签告诉物理交换机这个包属于哪个承载网络该走哪条链路。然后报文就从物理网卡eth0发送出去进入数据中心底层的物理网络Underlay。物理网络设备只关心外层IP和MAC会顺利地将这个包路由或交换到Host2。第五步抵达目的地——拆包与派送Host2的物理网卡收到这个带VLAN标签的报文。br-physnet网桥先识别并剥离tunnel_bearingVLAN标签然后将“脱了快递袋”的VXLAN报文送给br-tun网桥。br-tun进行解封装剥掉外层IP/UDP/VXLAN头露出了里面的原始载荷。此时它看到内层目的MAC是GW1_MAC。注意在Host2上VM2的网关是GW2_MAC对应于192.168.2.1。这里又是一个关键处理br-tun或br-router在8.0.3版本会执行一次MAC地址替换将内层源MAC从GW1_MAC替换为GW2_MAC。为什么因为对于VM2来说它认为回包应该发给自己的网关GW2。这个替换确保了VM2看到的通信对方是符合预期的网关地址保持了网络逻辑的一致性。接着这个目的MAC已被替换为GW2_MAC的报文被送到br-int网桥。br-int通过MAC地址学习表知道GW2_MAC对应的是VM2的虚拟网卡于是将报文最终转发给VM2。VM2成功收到了来自192.168.1.10的ICMP请求整个跨子网访问的“去程”就完成了。回程的流程与之对称由Host2上的分布式网关处理封装后发送回Host1再解封装送达VM1。3. 核心组件深度剖析br-tun、br-router与流表流水线走完了流程咱们得回头仔细瞧瞧这几个幕后英雄br-tun、br-router还有指挥它们行动的“大脑”——流表下发体系。理解了它们你才算真正摸到了华为云Stack三层流量模型的筋骨。br-tun隧道的守卫与搬运工br-tunBridge - Tunnel是OVS中专门处理隧道流量的网桥。在三层流量模型里它的核心职责有两个封装与解封装就像我们上面看到的为跨主机的流量穿上或脱下VXLAN“外套”。它维护着VNI与目标宿主机隧道端点VTEP的映射关系。分布式网关功能执行在封装时它将内层网关MAC替换为本地DVR MAC在解封装时执行反向的MAC替换。它是分布式网关理念在数据平面的直接体现。你可以把它想象成一个国际邮件处理中心。本地邮件同子网流量它不处理但凡是要寄往国外跨子网且跨主机的邮件它负责给邮件贴上国际标签VXLAN封装换上国际格式的寄件人地址DVR MAC然后扔进国际邮路物理网络。收到国际来信时它负责撕掉标签换回本地格式的寄件人地址再交给本地邮递员。br-router8.0.3版本的路由核心在8.0.3版本之前路由查询和网关接口都挂在br-int上。从8.0.3开始华为云Stack引入了独立的br-router网桥来专门承担路由功能。这是一个非常重要的架构优化。职责分离br-int更专注于同一租户、同一网络内的二层交换。br-router则专注于跨子网的三层路由。分工明确提升了性能和可管理性。路由查询当br-tun解封装后发现是一个需要路由的包比如目的MAC是网关MAC它会将包送到br-router。br-router内部有路由表通过查询决定这个包该从哪个端口出去可能是另一个子网的网关端口也可能是通往外部网络的端口。与br-tun的协作在跨子网跨主机的场景中br-router处理的是解封装后的“内层报文”的路由决策。而实际的跨主机封装动作仍然由br-tun基于br-router的决策结果来执行。它们俩一个定策略往哪走一个干粗活怎么打包送出去。流表下发体系云网络的“中央神经系统”流量怎么转全靠流表指挥。华为云Stack的流表下发是一条精密的流水线我把它称为“中央神经系统”。它的顺序是Pecado-Kafka-Local Controller-Agent-OVS-vSwitchD咱们拆开看Pecado这是顶层网络控制器掌握全局网络拓扑和策略。它决定了“应该”有什么流表。Kafka消息队列。Pecado把流表生成指令发到Kafka实现异步、解耦、可靠的消息传递。即使某个组件暂时挂掉指令也不会丢失。Local Controller每个计算节点或网络节点上的本地控制器。它订阅Kafka的消息接收属于本节点的流表指令并进行预处理和优化。Agent运行在每个节点上的代理程序如neutron-openvswitch-agent。它从Local Controller获取最终的流表项并翻译成OVS能理解的命令。OVS/vSwitchD开源的Open vSwitch守护进程。它接收Agent下发的命令最终将流表配置到内核或DPDK数据路径中真正指挥报文转发。这个过程确保了网络策略能够从全局控制器快速、可靠、一致地下发到成千上万台宿主机上的每一个虚拟交换机。当你创建一个新的子网、配置一条安全组规则或者建立一条VPC对等连接时背后都是这套系统在默默地更新所有相关节点上的流表。4. 实战排错指南当三层流量不通时你该看哪里理论懂了流程也清楚了但真正考验人的是出了问题怎么排查。三层流量不通可能的原因比二层更多、更复杂。下面我结合自己的踩坑经验给你梳理一个排查思路。第一步确认基础连通性从VM内部开始别一上来就扎进宿主机看流表。先在最源头确认问题。登录VM1检查IP地址、子网掩码、网关配置是否正确。ip addr show或ifconfig看一下。从VM1ping自己的网关例如ping 192.168.1.1。这步至关重要如果连自己的网关都不通问题大概率出在本地子网内可能是安全组、虚拟机内部防火墙、或者Host1上该子网的二层流表有问题。如果网关能通再尝试ping目标VM2的IP。此时应该触发我们上面说的三层流程。第二步在源宿主机Host1上抓包如果VM1能通网关但不通VM2就需要登上Host1抓包了。抓包点是黄金诊断工具。找到VM1的虚拟网卡对应在OVS上的端口。可以用ovs-vsctl show命令找到连接VM1tap设备或qbr网桥的端口号比如qvoXXXXX。在br-int网桥上对该端口进行抓包ovs-ofctl snoop br-int --timestamp 21 | grep -E (in_portVM1_PORT|dl_dstGW1_MAC) | head -50或者用更直接的tcpdump -i br-int的端口设备名 -nev。这里你要看VM1是否发出了目的MAC为GW1_MAC的ARP请求br-int是否收到了这个ARP请求是否有ARP回复回复应该来自br-tunVM1发出的ICMP请求报文是否以GW1_MAC为目的MAC进入了br-int在br-tun网桥上抓包ovs-ofctl snoop br-tun --timestamp 21 | grep -E vxlan | head -30或者tcpdump -i br-tun -nev。这是关键你要看从br-int送来的、目的MAC是GW1_MAC的报文是否到达了br-tunbr-tun是否对其进行了VXLAN封装外层源IP是不是Host1的IP外层目的IP是不是Host2的IPVNI是否正确封装后的报文是否从正确的物理网口比如phy-br-eth0发送出去了可以用tcpdump -i eth0 -nev在物理网卡上确认。第三步检查流表关键中的关键抓包能告诉你报文走到哪一步消失了流表则告诉你为什么它没往下走。查看br-int上的流表特别是针对目的MAC是网关MAC的流表项ovs-ofctl dump-flows br-int | grep -i GW1_MAC看这条流表的动作actions是不是将报文送到了br-tun的某个端口比如patch-tun。查看br-tun上的流表。这是最复杂也最容易出问题的地方。重点关注隧道映射流表如何根据内层目的IP或VNI决定外层目的IPVTEP。命令类似ovs-ofctl dump-flows br-tun table20具体表号因版本和设计可能不同。封装动作流表决定如何打上VXLAN头、设置VNI、替换外层MAC。命令类似ovs-ofctl dump-flows br-tun table30。 如果这些流表缺失或动作错误封装就会失败。第四步在目标宿主机Host2上反向排查如果Host1的抓包显示VXLAN报文已经发出那么问题可能出在路径上或Host2。在Host2的物理网卡eth0上抓包确认是否收到了来自Host1的VXLAN报文。tcpdump -i eth0 -nev udp port 4789(VXLAN默认端口)。如果收到了在br-tun上抓包看是否成功解封装解封装后的内层报文目的是否是GW1_MAC。检查Host2上br-tun或br-router的流表看是否有流表负责将目的MAC为GW1_MAC的报文替换为目的MAC为GW2_MAC并送入br-int。最后在br-int上抓包看替换后的报文是否被正确转发到了VM2的虚拟网卡端口。常见坑点总结安全组规则这是最常被忽略的确保VM1和VM2的安全组入方向规则允许ICMP或你使用的协议从对方子网的CIDR访问。安全组是在虚拟网卡级别生效的流表再正确安全组拦了也白搭。流表未下发或过期可能是Pecado、Kafka、Local Controller、Agent这个流水线中某个环节出了问题。检查相关服务的日志。VNI映射错误Host1封装时用了错误的VNI导致Host2无法识别或将其转发到错误的逻辑网络。物理网络问题Underlay网络的VLAN配置、MTU设置VXLAN封装需要额外头部MTU通常要调大、或路由问题导致VXLAN报文在物理网络中被丢弃。分布式网关MAC不一致或混乱不同宿主机上对同一逻辑网关的DVR MAC学习或维护出现异常导致MAC替换逻辑出错。5. 性能调优与设计思考让三层流量飞起来理解了原理排除了故障咱们还可以更进一步想想怎么让它跑得更快、更稳。分布式网关的三层模型虽然避免了集中式网关的瓶颈但依然有可以优化的点。1. 流表优化与快速路径OVS的流表匹配是软件行为虽然快但在超高流量压力下也可能成为瓶颈。华为云Stack结合智能网卡如SDI卡或硬件交换机如CE系列可以将一些固定的、高频的流表项例如特定子网间的路由和封装规则卸载到硬件。这就是“快速路径”或“硬件卸载”。数据包进来后直接在硬件芯片上完成查表、封装、转发完全绕过宿主机的CPU和OVS软件栈性能可以得到数量级的提升。在规划和选型时如果业务对网络延迟和吞吐要求极高可以关注是否支持以及如何配置这种硬件卸载功能。2. 避免“次优路径”与东西向流量规划在分布式网关下跨子网通信默认是直接点对点Host1-Host2。但有一种特殊情况如果两个VM所在的宿主机在物理Underlay网络上距离很远比如跨了多个机架甚至跨了机房核心而网络节点如果有的位置更中心那么Host1- 网络节点 -Host2的路径可能比Host1直连Host2更优。这就需要通过Underlay网络的路由策略或SDN控制器进行智能调优避免流量走“弓背”路径。在设计VPC和子网时也要有意识地将通信频繁的VM尽量部署在同一个可用区或物理距离较近的宿主机集群上减少东西向流量的延迟。3. MTU与巨帧设置VXLAN封装会增加50字节的头部外层Ethernet IP UDP VXLAN。如果底层物理网络的MTU是标准的1500字节那么封装后的报文就会超过1500导致分片严重影响性能。务必确保物理网络包括所有物理交换机和宿主机网卡的MTU至少设置为1600或更大常见的是9000即支持巨帧。同时虚拟机内部操作系统的MTU通常需要设置为14501500-50或者通过路径MTU发现PMTUD自动适配。MTU设置不当是导致网络性能低下和某些连接莫名奇妙的深层原因。4. 控制平面的规模与稳定性分布式网关的优势也带来了挑战每个宿主机都需要维护全量的或相关的路由信息。在超大规模部署中比如上万台VM成千上万个子网控制平面Pecado、Local Controller需要下发的流表规模会非常庞大对消息总线Kafka和各个Agent的稳定性和性能都是考验。在设计网络时虽然VPC提供了隔离但也要避免在一个VPC内创建过多、过细的子网除非业务确实需要。合理的子网规划例如按业务模块、按安全等级划分既能满足需求也能减轻控制平面的压力。5. 监控与可视化这么复杂的流量路径没有好的监控工具就是睁眼瞎。除了利用华为云Stack自身的监控组件建议重点关注流表数量与下发延迟监控每个OVS上的流表项数量以及从策略变更到流表生效的延迟。隧道端点状态监控所有VTEP宿主机的可达性与健康状态。东西向流量带宽与包速率区分不同VPC、不同子网间的流量及时发现热点和异常。丢包与错包统计在br-tun、物理网卡等关键接口上监控丢包计数。把这些点都考虑到你不仅能搞定华为云Stack三层流量的基础运维更能参与到高可用、高性能的云网络设计中去真正从“会用”变成“精通”。网络这东西细节多坑也多但每踩过一个坑你对它的理解就深一层。希望我分享的这些经验和拆解能帮你少走点弯路。