某次智算集群的性能复盘会上监控大屏上的一组数据让我印象极深训练节点之间的东西向流量占到了全网92%而支撑业务对外服务的南北向流量只占8%。当时所有人都在盯GPU利用率、盯集合通信时延结果最先把业务卡住的恰恰是那个被大家忽视的“8%”出口——几十台GPU节点同时回传Checkpoint和样本数据直接把边界链路打满了。也是在那个节点上我才真正认真审视了Border Leaf这个角色它站在Spine-Leaf架构的边界既要在内部织起东西向的高速通路又要替整个智算中心扛住南北向的进和出。这篇就以我实际参与的项目为主线聊聊Border Leaf到底在智算中心网络里做了什么东西向流量和南北向流量如何在它身上汇合以及我从部署到踩坑、再到优化走完的完整链路。需要说明的是本文面向的是正在做数据中心网络、智算网络建设或运维的朋友也适合准备从传统园区网转向数据中心网络的工程师。我会尽量把原理讲明白也会把我在现网里踩过的问题一一摊开倘若你刚好在规划或调整自己的Spine-Leaf出口应该能省下不少试错时间。1. 智算中心流量模型剧变东西向为主南北向为何重新成为焦点1.1 教科书上的定义在智算场景下已经变了味“东西向流量”是数据中心内部服务器与服务器之间的流量“南北向流量”是数据中心与外部之间的流量这两个概念在几乎所有网络教材里都能找到。传统IT数据中心的经验是东西向流量占大头大概70%到80%南北向只占20%到30%所以设计时大家会把大量精力放在Spine-Leaf的横向带宽上出口链路给个万兆、几万兆也就够了。但智算中心不一样。先说东西向一个千卡集群做大模型训练每轮迭代都要做梯度同步AllReduce、AllGather这些集合通信会把GPU节点之间的流量推得极高。我见过最夸张的情况训练任务跑起来时全网东西向占比能到95%左右而且流量特征非常“刚”——每个GPU都要和同组内的其他GPU交换数据短报文密集周期性强对时延极度敏感。这种情况下东西向的设计目标是“快”路径要短带宽要足抖动要小。再说南北向。很多人以为智算中心既然以东西向为主南北向就可以随便弄弄这个认知在训练阶段也许能糊弄过去但放到整条业务链上看就完全站不住脚。模型训练之前要把海量样本数据从存储集群灌进训练节点的缓存盘训练过程中要周期性地把Checkpoint回传到远端存储训练结束要导出模型文件、推到推理平台推理服务上线之后外部的API请求要进来结果要出去。这些全是南北向流量它们不像东西向那样汹涌澎湃却在“关键时刻”绝不能掉链子——卡一次Checkpoint可能意味着整个训练任务白跑几小时。1.2 改变流量占比的三个智算典型场景我在项目里总结出三个会显著放大南北向压力的场景这也是当初我们决定把Border Leaf单独拎出来设计的关键原因。第一个是样本数据入场。智算训练启动前的数据集加载阶段存储节点和计算节点之间要建立海量数据拷贝任务。如果存储依然挂在内部网络里流量或许还在东西向范围内但更多实际部署中数据湖、样本库、备份灾备存储往往放在独立存储网络甚至另一个园区这时候从训练集群到存储系统的流量本质上就是南北向流量。第二个是Checkpoint回写。大规模训练任务为了防止节点故障导致断点会每隔固定步长保存一次模型状态。一个千亿参数模型的Checkpoint可能几十GB到上百GB多个训练任务同时回写对出口带宽的冲击非常直接。我记得有一次现场刚好赶上两个任务同时保存Checkpoint南北向出口瞬间跑满其他业务丢包率直接飙升。第三个是推理和在线服务接入。训练完成后的模型要挂到推理平台上对外提供能力比如内部系统调用、边缘站点请求集中汇聚。这种流量虽然单个请求不大但连接数极多而且要求稳定低时延对Border Leaf上会话表项和NAT策略的压力很大。1.3 流量模型变化倒逼网络架构调整传统数据中心里南北向流量通常通过防火墙、负载均衡器一层层送出去出口设备负责做NAT、做安全策略内部互访靠VLAN或VXLAN的二三层转发就够了。但智算中心如果沿用这套思路会撞上两个现实问题一是链路收敛比严重失调。假如内部Spine-Leaf已经做到128×400G结果出口只有2×100G那么一旦有大量南北向流量突发边界就是整个网络最窄的瓶颈。更麻烦的是很多智算业务对时延的容忍度极低出口拥塞引发的TCP重传会一路传导到GPU训练任务影响整个集群效率。二是路径语义混乱。南北向流量出去时通常希望走安全设备、做地址转换、匹配业务策略东西向流量内部流动时则希望尽量短路径直达千万别绕到出口去溜一圈。如果Border Leaf没有一个清晰的“边界”角色很容易出现内部流量和外部流量混在一起策略没法分、故障不好查。所以智算中心的网络设计必须把Border Leaf当作一个明确的功能层来规划而不是顺带加两台Leaf了事。后面几节我会按我实际操作的顺序把这个角色从选型、部署到问题排查整条链路讲清楚。2. Border Leaf是谁连接内外与横纵的关键节点2.1 物理位置与角色定位Spine-Leaf架构里的“边关”先给不太熟悉这个术语的朋友补个基础。Spine-Leaf架构是数据中心网络的主流结构下层是大量Leaf交换机直接连接服务器或GPU节点上层是Spine交换机把各Leaf全互联起来。每个Leaf和每个Spine之间都有链路形成无阻塞的Clos拓扑。Border Leaf并不是一种新硬件它更像是一个“角色”。在经典Clos架构中Leaf通常只连接服务器Spine负责转发Leaf之间的流量。但如果某些Leaf除了连接服务器之外还要负责和网络边界上的防火墙、出口路由器、其他园区网络对接这类Leaf就承担了边界职责行业内习惯叫它Border Leaf也有叫边界Leaf或出口Leaf的。在智算中心的部署里Border Leaf的物理位置一般在Spine层旁边下行接入内部Leaf上行接入外部网络设备或者安全设备。有人会问为什么不直接用Spine对外出口理论上可以但实际没人这么干。Spine的核心职责是提供高速无阻塞转发它的路由表、策略表、ACL资源都得优先为内部东西向服务。一旦让Spine承担外部出口安全策略、NAT、多租户隔离这些逻辑就会侵入Spine的转发表项轻则影响转发性能重则造成内部流量和外部流量互相干扰。Border Leaf存在的意义就是把“内部高速交换”和“外部策略接入”在功能上剥离开。2.2 Border Leaf与普通Leaf的核心区别同一个型号的设备做成普通Leaf和做成Border Leaf其实是两种完全不同的设计思路。我把它们的差异列成了一张对比表现在看仍然很直观对比维度普通Leaf接入LeafBorder Leaf边界Leaf主要连接对象服务器/GPU节点、存储节点防火墙、出口路由器、外部网络核心转发使命快速转发东西向流量本地终结VXLAN内部VXLAN与外部三层网络的桥接与策略执行点路由表需求以Overlay内部路由为主路由数量可控需要同时维护内部Overlay路由和外部路由表项压力大策略能力较弱主要用于QoS、ACL基础保护较强需要做安全策略联动、NAT、重定向甚至VXLAN封装转换部署可靠性要求通常按机柜或POD冗余部署必须双机或多机集群避免单点导致全域出口故障常见故障风险局部接入链路问题、端口协商问题路由震荡、会话表满、外部策略冲突、Uplink带宽瓶颈在实际部署中Border Leaf的可靠性要求比普通Leaf高得多。普通Leaf坏了影响的只是它下连的几十台服务器Border Leaf一旦出问题整个智算中心的南北向通道全部断掉。所以我们通常会部署两台Border Leaf形成集群对外通过BGP ECMP或VRRP做网关冗余对内通过EVPN多活机制保证任意一台故障不掉线。2.3 硬件选型表项、带宽与转发能力怎么平衡Border Leaf的选型我吃过一次亏后面单独展开。这里先给结论不要简单按照“Leaf同型号”或者“Spine降一档”来选而要按它的三个核心压力来定。第一是隧道封装能力。Border Leaf作为VXLAN的L3网关需要把VXLAN报文解封装后再以普通IP报文发出去这个过程涉及VXLAN报文的封装和解封装对芯片的隧道处理能力要求很高。如果选的设备隧道表项很小可能在部署了多个租户或业务VNI之后直接表项耗尽表现形式是部分VNI的网关路由消失业务随机丢包。第二是路由表容量。Border Leaf既要在Overlay里跑EVPN通过BGP学习大量内部主机路由或前缀路由又要维护外部网络路由。很多情况下还要做路由汇总和发布所以路由表容量要留足。我的建议是至少按当前峰值路由数的两倍来选型别卡着上限买设备。第三是灵活性与带宽的平衡。Border Leaf的端口配置通常是两部分面向内部的下行口与Spine互联和面向外部的上行口接防火墙或出口路由器。如果上下行带宽比例差距太大比如下行128×400G、上行只有4×400G那即便设备选得再好出口收敛比也会在业务突发时卡死一切。我一般的经验是把Border Leaf的上行带宽做到下行带宽的1/4以上并且在出口侧配有独立的QoS调度能力。3. 全向通达的实现机制南北向打通与东西向加速3.1 南北向打通VXLAN L3 VNI与分布式网关的接入设计Border Leaf要打通南北向本质上是解决“内部VXLAN网络里的业务流量如何安全、可控地走到外部网络”的问题。在VXLAN EVPN架构里关键设计是这样几个环节。首先每个业务域或者租户在VXLAN Fabric内部会有自己的L3 VNI它承载三层网关能力。普通Leaf上通常也会配置对应的IRB接口作为分布式网关让本地的服务器可以直接通过本地Leaf完成三层转发。但当这份流量需要离开Fabric去外部网络时就必须经过Border Leaf内部Leaf和Border Leaf之间通过Spine建立VXLAN隧道流量封装到对应的L3 VNI里送到Border Leaf。Border Leaf收到这个VXLAN报文后先解封装再按普通IP路由表查找出接口把报文送到和它直连的防火墙或出口路由器。在这个过程里Border Leaf实际上担任了“VXLAN Fabric的默认网关出口”角色所有出Fabric的流量都要在它这里完成“由Overlay到Underlay”的转换然后交给外部设备。外部流量进到内部时则是相反的过程。外部路由从出口路由器或防火墙进到Border Leaf后Border Leaf会通过EVPN把这些外部前缀路由以合适的方式注入内部Overlay让内部Leaf知道去往外部目的地的下一跳指向Border Leaf。注入时通常要控制路由范围避免大量外部明细路由冲垮Leaf设备一般的做法是做成默认路由或汇总路由注入。在接入设计上还有几个值得注意的细节。如果外部网络是VLAN环境Border Leaf和防火墙之间直接做成三层子接口每个业务域一个VLAN如果外部网络是BGP环境Border Leaf和出口路由器之间建立eBGP邻居同时把内部VNI网段通过network方式或redistribute方式发布出去。两种方式我都用过eBGP方式的扩展性明显更好路由状态可控故障收敛也快建议有条件直接上BGP。3.2 东西向加速本地转发与对称模式的原理Border Leaf虽然主要负责南北向但在“全向通达”这个目标里它不能拖东西向的后腿。智算环境中东西向流量的核心设计原则是“能在本地解决的不要绕路”——两个GPU节点如果连在同一台Leaf下流量应该直接在该Leaf内部完成转发如果分属不同Leaf则通过Spine最短路径完成转发只有需要出Fabric的流量才上送Border Leaf。这套逻辑的关键机制是VXLAN EVPN的分布式网关能力。每台Leaf都配置了相同VNI的IRB接口和相同的MAC地址当服务器发送ARP请求时由本地Leaf直接响应从而让每个节点都把本地Leaf当作网关。这样同一Leaf下的互访流量直接在接入层完成完全不需要经过Spine更不需要经过Border Leaf。这对训练集群的意义很大同一机柜内的多个GPU节点做集合通信时如果每一条流量都绕到Spine再回来延迟会显著增加而本地转发可以把这部分时延降到最低。跨Leaf的东西向流量则靠Spine转发路径上完全不碰Border Leaf除非业务本身需要出外网。这就避免了“东西向流量被绑架到出口设备”的尴尬——很多传统三层架构里服务器之间的跨VLAN互访必须绕到核心交换机核心一忙全网都卡。智算网络用Border Leaf把内外职责分开之后东西向流量和南北向流量就像两条专用车道各走各的。还有一个不能忽略的技术点是对称模式也就是对称IRB。在VXLAN EVPN里流量从Leaf A进入、从Leaf B离开双向都必须选择相同的VNI处理路径否则会出现去程走L3 VNI、回程走L2 VNI这种不对称情况。不对称在传统网络里可能只是多绕一段但在有状态安全设备介入的场景下会导致会话被丢弃。Border Leaf与内部Leaf之间的路径设计一定要保持双向对称这也是我在部署阶段反复检查的要点之一。3.3 将东西向与南北向融合在Border Leaf上的三种方案实际落地的智算网络不会只有单纯的“内部互通”和“边界出口”更多时候要求Border Leaf同时处理多种流量我梳理了三种主流方案分别适用不同规模的场景。方案一是集中式出口。整个Fabric只有一个Border Leaf集群所有需要出Fabric的东西向流量和南北向流量都在这里汇合。优点是架构清晰、安全策略集中适合规模不大、业务域少的园区。缺点是Border Leaf本身容易成为瓶颈设备规格要求高。方案二是分布式出口加集中安全。每个POD区域部署自己的Border Leaf独立对接外部网络但安全设备仍然集中在核心出口处。这种方案适合多POD的大型智算中心流量可以在POD本地完成南北向进出不需要跨整个园区绕行但安全策略的管控成本会上升。方案三是多Border集群互联。多个Border Leaf集群之间通过VXLAN或专线打通外部网络也按业务域就近接入实质上形成了一个“多出口、多路径”的边界网络。这种方案扩展性最强适合跨园区、多数据中心的场景。代价是路由规划和故障定位的复杂度明显上升对运维团队要求很高。我在实际项目中主导过从方案一到方案二的演进。刚开始整个园区只有一个出口后来训练任务变多、外部存储对接变频繁集中式出口很快出现带宽瓶颈和路由表压力。把Border Leaf拆成按POD部署之后每个POD都可以就近完成数据加载和Checkpoint回传核心出口的压力立刻降了下来。4. 部署Border Leaf的实测链路问题定位与避坑记录4.1 MTU不一致引发的丢包从“通而不畅”到定位下线第一次在智算网络里上线Border Leaf就遇到了一个非常典型的MTU问题。现象是业务反馈小包一切正常大包出现间歇性丢包TCP传输速度上不去但ping小包完全看不出来。我第一反应是查链路光模块和误码率结果全部正常。后来用增大ping包的方式逐段测试从Leaf到Spine都通了一到Border Leaf的上行口就开始丢包最大传输单元的限制一下子浮出水面。原因其实很常见VXLAN封装会在原始报文之外增加50字节左右的额外开销其中VXLAN头8字节、UDP头8字节、IP头20字节、外层MAC头14字节。如果Underlay网络的三层链路MTU设置成1500而服务器发出的报文是标准的1500字节经过VXLAN封装之后总长度就超过1500字节交换机只能丢包或者分片。处理办法听着简单做起来要全线核对所有Underlay链路Leaf到Spine、Spine到Border Leaf、Border Leaf到外部网络必须统一把IP MTU调整到9000字节以上Overlay业务接口的MTU则要留出隧道开销余量。我当时的做法是在全网配置9000字节MTU业务VXLAN接口调整到8950确保封装后不超限。验证命令是使用扩展ping指定数据包大小且不分片从服务器一路测到外部网关逐步放开载荷值找出真正的最大可用值。这个坑希望每一个部署VXLAN Fabric的朋友都重视别等业务上线了才去排查莫名其妙的“偶发丢包”。4.2 ECMP哈希不均业务全部挤上一条物理链路Border Leaf上联出口路由器时我用了两条400G链路做ECMP理论上流量应该大致均分。结果监控一看一条链路利用率85%另一条只有15%。这种严重不均的哈希结果在训练集群的数据加载阶段尤其致命因为大流量都走了一条链路链路拥塞后TCP整体降速数据灌入速度被拖慢了一个多小时。排查思路先查ECMP成员是否都正常参与转发。确认没有问题后问题出在哈希因子上智算业务流量多为大流量TCP流每条流的五元组可能都相同——同一个存储节点向多个训练节点传输数据时源IP、源端口、目的端口很多场景下都一样只有目的IP变化。如果设备默认按五元组做哈希当源端口和目的端口都被固定时哈希结果的离散度就会很差。解决的方向有二一是调整交换机的ECMP哈希算法加入自定义的多字段组合把更多可变字段纳入计算。二是如果设备支持开启增强型负载均衡例如基于数据包长度分布的自动感知哈希或者随机化哈希算法。我在这个案例里通过修改哈希字段并重新验证把链路利用率拉回到45%和55%左右整体改善明显。同时提醒一点不要为了追求“绝对均分”就开启逐包负载均衡它会导致TCP乱序训练场景里乱序比拥塞还可怕。4.3 南北向回流不对称路由绕远走引发的会话异常Border Leaf接入防火墙之后又冒出一个经典问题部分业务建立连接时会话直接失败尤其是访问外部存储和推理服务的连接时好时坏。抓包看到的现象是去程报文经过了防火墙A回程报文却从防火墙B回来防火墙A上维护的连接表找不到对应会话就直接丢弃了回程流量。这个问题的根因在于路由不对称。Border Leaf集群内有主备或者负载分担逻辑去程路由指向防火墙A但回程路由因为内部协议选路逻辑的原因走了防火墙B。很多有状态防火墙要求双向流量经过同一台设备否则会话失效尤其是开启严格模式的防火墙更是如此。解决思路一是调整Border Leaf和防火墙之间的路由发布策略通过AS Path、Local Preference等手段让去回程流量的路由偏好一致二是开启uRPFUnicast Reverse Path Forwarding严格模式让路由器主动丢弃源地址与路由不一致的报文起到快速发现问题的效果三是干脆把防火墙也做成集群让防火墙之间同步会话状态。最终我用了组合拳防火墙做集群同步会话同时在Border Leaf上统一回程路由的下一跳指向并把uRPF从strict改成feasible模式既兜底又不误伤合法流量。4.4 BGP收敛太慢维护操作引爆全网抖动的一次教训有一次计划内维护我准备把Border Leaf的其中一个上联接口shutdown做更换想着双上联、BGP双邻居最多几秒切换一次。结果业务侧的反馈是“网络卡了将近一分钟”运维群直接炸锅。定位后发现两个问题叠加在一起。第一BGP邻居没有启用BFD检测默认的Hold Time配置又比较长链路down掉之后BGP要经过一段时间才能感知邻居失效这个期间流量还在继续往这条链路里塞。第二Border Leaf上的BGP路由策略里没有提前做prepend或as-path控制导致Down掉的邻居在收敛过程中短暂参与了选路流量走了不该走的路径又快速撤回造成反复震荡。这个教训之后我给自己定了一条硬规矩任何Border Leaf的BGP邻居都必须启用BFDHold Time按需调短凡是涉及出口链路的维护操作必须提前在路由策略里做好预告比如在planned down之前先降低该链路的选路优先级再执行物理操作避免流量在新旧路径之间来回抖动。这个习惯后来救了我很多次尤其在大规模集群里一次无预告维护引发的全网震荡损失可能是几十个小时的GPU算力。5. 从“全向通达”到“全向优达”进阶优化思路5.1 控制面优化路由聚合与定时器调优Border Leaf跑稳定之后我开始琢磨怎么从“能通”优化到“通得好”。控制面首当其冲。EVPN模式下Border Leaf如果用纯明细路由注入外部网络每一台服务器的路由都会变成一条BGP路由广而告之路由表膨胀速度非常可怕。我的做法是做三层收敛内部Leaf上通过aggregate命令或路由策略将同一网段内的主机路由汇总为一条或少数几条前缀路由上层网络只看到收敛后的路由减少全网设备的路由表负担。尤其智算网络动辄几千台GPU节点如果每台节点都带着一个64位MAC和IP作为EVPN路由广而告之Border Leaf和Spine都要被路由条目淹没。BGP定时器优化同样重要。Border Leaf对外连接的稳定性和收敛速度直接影响智算业务的连续性。我习惯把外部BGP邻居的Keepalive间隔设为10秒Hold Time设为30秒同时开启BFD检测把失效检测时间压缩到毫秒级。对内部IBGP或EVPN会话可以稍微宽松一点但也要配合BFD防止控制面故障长时间无感知。5.2 数据面优化硬件表项与转发路径的专项检查数据面的优化方向主要是让流量始终走最短且最不拥塞的路径我分为三步执行。第一步是检查硬件表项余量。Border Leaf上最容易被忽略的资源是L3 VNI转发表和主机路由表。如果表项余量不足设备可能采取软件转发或直接丢弃部分新学习路由表现为部分业务突然无法访问新网段。我通常是部署完成后立即用命令查看各表项的占用百分比低于60%才算安全低于80%就要赶紧做扩容规划。第二步是优化转发路径。对经常互访的Leaf对通过配置等价链路组确保东西向流量选择最短Spine路径对外部高频访问的目的网段在Border Leaf上设置直连或静态路由减少递归查询和下一跳依赖。还有一个小技巧如果设备支持把东西向流量的QoS队列和南北向流量的QoS队列分开调度系统保障南北向关键连接避免训练洪峰把出口完全挤死。第三步是开启硬件级采样或流统计为后续的可观测性打底。Border Leaf上的流量是全网最混杂的内外交织、协议众多如果不提前把采样的基础打好后面做排障会非常被动。5.3 可观测性建设从流统数据到路径可视化以前做网络运维主要靠ping和traceroute在智算中心这个量级下完全不够用。Border Leaf汇聚了大量东西向和南北向流量这个点是天然的可观测性富矿。我落地了一套组合监控方案。第一步在Border Leaf上开启sFlow或NetStream采样按目的网段、协议、应用端口做分桶统计把南北向流量的总体趋势和突发特征可视化出来第二步对关键业务下发Telemetry订阅实时上报CPU、内存、表项使用率、接口利用率这些指标第三步做路径可视化的基础数据采集记录每条业务流经过的Leaf、Spine和Border节点。这套监控建好之后的直接收益是几个月后有一次外部链路抖动监控大屏上直接看出流量在Border Leaf上出现短暂的接口utilization尖峰同时Telemetry上报了对应接口的错包计数器上升十分钟内就定位到了物理链路的光模块问题而不是像以前一样全网抓包猜来猜去。从东西向到南北向的“全向通达”归根结底不只是带宽指标的事。它更像是一套秩序让该短的路径短下来让该守的边界守得住让每一条流量都知道自己该走哪条路。Border Leaf就是这条秩序里最关键的枢纽它会一直站在内部高速交换与外部策略接入的交汇点上。
