简介这是一份面向企业网络架构师、云数据中心运维与软件定义网络规划人员的解决方案设计指南聚焦多云多数据中心互联场景下的整体架构与落地路径。资源为单个docx文档压缩包大小约2.28MB内容以图文形式系统梳理多数据中心发展趋势、业务场景分类、互联需求与SDN网络要求并重点展开华为Multi-DC Fabric方案整体架构、场景分类以及Multi-Site方案的完整设计过程涵盖大VPC、VPC互通、VMM对接、转发面设计、外部网络多活等关键内容也给出按安全等级划分VPC等多活部署推荐。读者可据此理解从业务需求分析到网络方案设计的完整方法论直接参考其中的架构思路、设计原则与部署建议对规划跨数据中心网络或选型落地大有帮助。目前已有226人学习。1. CloudFabric 云数据中心网络的 Multi-Site 设计它到底在解什么题手上有两个机房业务要跨机房做高可用这是很多云数据中心团队都绕不过去的坎。单机房网络方案成熟得很可一旦把业务搬到第二个站点问题就一串接一串ARP 广播跨机房乱窜、站点间路由来回路径不一致、一边的网关断了整条业务跟着断。CloudFabric 云数据中心网络解决方案里的 Multi-Site 设计指南正是用来回答这些问题的。它不把单机房方案平移过去而是围绕 DCI 链路、VXLAN EVPN 控制面、分布式网关和故障域切分给出一整套跨站点设计方法论。这篇笔记按这份设计指南的方向把架构怎么立、配置骨架怎么搭、坑在哪、怎么验证讲清楚。适合正在规划双机房或两地三中心的网络工程师和运维也适合还没接触 CloudFabric 但想评估这套方案值不值得投入的人。2. Multi-Site 三层架构模型为什么 VXLAN EVPN 是跨站点的唯一靠谱底座2.1 单机房方案复制到双机房第一个翻车点就是广播域最常见的起步姿势是机房 A 的 VLAN 划分、网关规划都是现成的直接把同样的 VLAN 透传到机房 B让两边的服务器地址互通。很多人第一反应是让 DCI 设备把 VLAN 透传过去就像在同一台交换机上多拉了一根线。小规模时确实能通但隐患从上线第一天就埋下了。第一广播域跟着 VLAN 走ARP 广播、DHCP 请求、未知单播全会顺着 DCI 灌到对端。机房 B 一台上线、批量装机广播风暴就能打满机房 A 的核心链路两个机房一起抖。第二STP 在跨机房场景下收敛极慢DCI 链路一抖动触发拓扑重算两个机房的交换机全部参与故障域直接从单机房扩大成跨机房。这就是为什么 CloudFabric 的 Multi-Site 设计不把 VLAN 透传当推荐项VLAN 的广播域和物理拓扑强绑定跨机房后这些绑定关系全部变成风险敞口。2.2 VXLAN EVPN 解决的三件事也是 CloudFabric 选它的三条理由VXLAN 把二层报文封装进 UDP 里Underlay 网络只关心 IP 可达广播域被约束在逻辑层面。EVPN 则用 BGP 把 MAC、IP 前缀、VRF 路由当作路由对象来发布替代传统 ARP 泛洪和远程 MAC 学习。这两件事组合起来正好解决跨站点的三个核心痛点。第一控制面收敛速度。MAC/IP 路由通过 BGP 通告站点间不再依赖广播去学习收敛从秒级降到毫秒级。第二BUM 流量可控。ARP 抑制、BUM 复制剪枝是 EVPN 的标配跨站点广播不再是盲目的洪泛而是按需复制。第三分布式网关。每个 Leaf 都能做 VXLAN 三层网关网关 IP 和 MAC 全站点一致双活能力是天然的。CloudFabric 把 VXLAN EVPN 定为 Multi-Site 的底座核心就是看中这三点。设计指南里凡是绕开这三点的方案要么收敛慢要么广播不可控要么网关单点基本都不值得投入。可以说在跨站点这个场景下VXLAN EVPN 不是可选项而是唯一靠谱的地基。2.3 二层延伸还是三层互联用一张表定边界再算 DCI 参数Multi-Site 设计最先要回答的问题站点间网络到底是二层延伸还是三层互联。答案取决于业务数据流形态不是拍脑袋定的。判断维度二层延伸大二层三层互联路由互通业务要求同 VLAN 跨站点主机迁移 IP 不变站点内闭环站点间只通服务接口故障域广播/组播跨站传播故障半径大广播隔离在本站故障半径小网关位置分布式网关两站同 IP 同 MAC各站独立网关路由互通典型场景双活数据库、存储复制、虚机迁移应用多活、前端负载、数据异步复制DCI 时延建议单程 ≤10ms20~30ms 可接受二层延伸不是不行而是它把 DCI 链路变成了广播域的组成部分。设计指南的常规做法是能三层就三层必须二层时给小 VNI。举个例子数据库的存储同步网段必须跨站点那就单独划一个 VNI打开 ARP 抑制把广播半径压到最小应用层业务走三层互联站点内各自有网关互不拖累。DCI 链路参数也得在方案阶段定清楚。带宽按业务峰值的两倍预留站点间至少两条物理路径避免单链路成为必然单点。时延按业务类型区分存储同步最敏感单程 1ms 和 10ms 直接决定数据库能不能开同步复制模式。丢包率要达到电信级否则 TCP 拥塞窗口会被频繁打回慢启动业务体感像丢了带宽一样。故障域半径是这章的落点。你要在图纸上明确标出哪条链路断了、会影响哪些网段、拖累哪些业务。设计的终极目标是压缩故障域半径——一个 VNI 的故障不能拖垮整条 DCI一个站点的故障不能拖垮另一个站点。这决定了 VNI 的划分粒度也决定了后面逃生链路必须独立于主 DCI 物理路径。3. 落地配置骨架控制器编排顺序与跨站点 EVPN 邻居怎么搭3.1 控制器编排顺序站点、Fabric、VXLAN 一步都不能跳CloudFabric 的控制器采用意图驱动的方式把网络配置从手工 CLI 搬到编排流程里。我一般会在两个站点设备上架前先按这个顺序在控制器上操作创建站点Site→ 纳管交换机 → 创建 Fabric → 创建 VXLAN 网络 → 绑定接入端口。为什么必须是这个顺序因为控制器把网络意图转成设备配置时得先知道每台设备的角色Spine 还是 Leaf和 Underlay 编址信息VXLAN 才能被正确编排。先建 Fabric 后加设备控制器会对未纳管的设备报错下发任务直接卡住。这一步的常见翻车是把两个站点建成两个 Fabric结果跨站点 EVPN 邻居关系完全出不来。在设计指南里多站点共享一套 Fabric 逻辑站点只是 Fabric 里的物理分组这点一定要在控制器里选对。配置下发完成后登录交换机核对控制器有没有真正把配置推下去。我会先跑三条命令确认骨架在不在# 确认 VXLAN 相关配置是否已下发 display current-configuration | include vxlan # 确认 VNI 有没有被创建出来 display vxlan vni # 确认 BGP EVPN 地址族已启用 display bgp evpn peer此时看到 VNI 列表和 EVPN 邻居为空别慌大概率是控制器编排顺序没走完或设备未保存配置触发回滚。先回控制器界面看站点和设备状态再回交换机上查配置不要一上来就手工改否则控制器下次编排又会把你手改的部分顶掉。3.2 Underlay 配置Loopback 地址与跨站点 BGP EVPN 邻居跨站点 EVPN 邻居的建立是所有业务的前提。常见做法是站点内 Spine-Leaf 用 OSPF 打通 Underlay站点间用 Spine-Spine 直连建 BGP EVPN 会话。隧道源地址必须是 Loopback而不是物理口否则 DCI 链路一抖动BGP 会话跟着闪断隧道重建的代价远高于业务能承受的窗口。以站点 A 的 Spine-1 为例最小可用的配置骨架是这样的# 站点 A 的 Spine-1Loopback 作为 VTEP 源地址身份固定 interface LoopBack1 ip address 10.0.0.1 255.255.255.255 # 站点内用 OSPF 打通 Underlay并宣告 Loopback ospf 1 router-id 10.0.0.1 area 0.0.0.0 network 10.0.0.0 0.0.0.255 network 10.1.0.0 0.0.0.255 # 与站点 B 的 Spine 建立跨站点 BGP EVPN 会话 bgp 65501 router-id 10.0.0.1 peer 10.0.0.2 as-number 65501 peer 10.0.0.2 connect-interface LoopBack1 l2vpn-family evpn peer 10.0.0.2 enable逻辑说明OSPF 让对端的 Loopback 可达BGP 会话建在 Loopback 之上物理链路抖动不会立刻导致 BGP 断连。peer 命令里 connect-interface 必须指到 Loopback1如果不指BGP 会用物理口地址去建邻居VXLAN 隧道封装出来的源地址就会飘跨站点隧道直接起不来。参数说明AS 号两端建议统一同一自治域内做 iBGP如果你的 DCI 是经过运营商或独立 AS 的那就要按 EBGP 写并且在对端方向打开 allow-as-loop 避免环路误判。站点内 Leaf 到 Spine 同样走 iBGP EVPN 时注意 next-hop 属性EVPN 场景下隧道下一跳是发布路由的 Leaf LoopbackUnderlay 必须能解析到它否则路由学到但隧道建不了。3.3 桥域与 VXLAN 配置BD、VNI 与 RD/RT 的规划规则数据面配置的核心是桥域Bridge Domain和 VNI 的映射。一个 BD 对应一个业务二层网段BD 绑定 VNIVNI 是跨站点唯一的标识。站点 A 的 Leaf-1 上最小配置如下# 站点 A 的 Leaf-1一个桥域对应一个业务二层网段 bridge-domain 500 vxlan vni 5000 evpn route-distinguisher 65501:5000 # RT 导入导出值两端站点必须完全一致EVPN 路由才能互相广播 # 手动配置时务必核对控制器编排时会按 VNI 自动生成 # 接入侧带 VLAN tag 500 的流量进入桥域 500 interface 100GE1/0/1.500 encapsulation dot1q vid 500 bridge-domain 500RDRoute Distinguisher和 RTRoute Target的规划是这里最容易埋雷的地方。RD 负责让同一 VNI 在不同站点产生独立路由RT 负责决定路由能不能被对端站点接收。我的习惯如下表配置项站点 A站点 B说明VNI50005000跨站点必须一致RD65501:500065502:5000按站点维度区分避免路由混淆RT 导入/导出65501:500065501:5000两端一致路由才能互通RD 两端不同、RT 两端相同这是跨站点 VXLAN 的标准做法。如果 RT 配反了现象很典型站点 A 学到对端 MAC 路由但 ping 不通因为数据面隧道没建起来或者路由被 RT 过滤了。我踩过的教训是别在控制器界面上只抄 VNI 号把 RD/RT 的规划表格先在文档里列好再往控制器里填。控制器虽然能自动算 RT但跨站点场景下手动核对一遍能少走两小时弯路。4. 业务跨站点怎么走分布式网关、逃生链路与回程路由4.1 分布式网关的生效条件anycast IP 与 ARP 收集Multi-Site 里网关放在哪是设计中分歧最大的问题。我推荐的常规做法是每个站点每个 Leaf 都做 VXLAN 三层网关网关 IP 和 MAC 在所有 Leaf 上完全相同anycast 网关。这样主机无论从哪个 Leaf 接入ARP 解析出来的网关都是一样的跨站点访问不需要依赖任何一台专用网关设备。Leaf 上的网关配置骨架# Leaf 上的 VXLAN 三层网关IP 和 MAC 在站点内所有 Leaf 保持一致 interface Vbdif500 ip address 10.10.100.254 255.255.255.0 mac-address 00e0-fc00-0001 arp collect host这里 arp collect host 是最关键的一行。它的作用是让 Leaf 收集主机 ARP 表并通过 EVPN 的 RT-2 路由发布到对端站点。不开这条命令主机的 MAC 和主机路由就不会跨站点广播对端站点访问本端主机时只能依赖广播那等于又回到大二层泛洪的坑里。参数说明mac-address 必须所有 Leaf 一致否则主机在站点间切换后 ARP 缓存里的网关 MAC 失效直接造成断流。ip address 用 24 位网关地址即可网关 IP 不要和任何主机 IP 冲突这是基本功但多站点场景下检查的次数要翻倍因为两个站点各自规划地址段时很容易撞上。4.2 逃生链路设计断纤与控制器失联时的兜底路径DCI 断纤后跨站点 VXLAN 隧道会整体撕裂此时业务不能死等隧道恢复必须有一条本地逃生路径顶上。常见设计是每个站点配独立的上联出口链路逃生链路上只跑三层路由不进 VXLAN 封装。这条链路要和主 DCI 完全隔离物理路径否则光缆同沟一次施工挖断两条逃生就变成口号了。逃生路由的配置要巧妙利用路由优先级# 逃生链路站点 A 的出口网关方向 interface 10GE1/0/1 ip address 10.254.1.2 255.255.255.252 # preference 80 高于华为静态路由默认值 60主链路正常时不参与选路 ip route-static 10.10.200.0 255.255.255.0 10.254.1.1 preference 80逻辑说明preference 数值越大优先级越低逃生路由平时不占优主链路一断它自动顶上。配置里特别要注意逃生链路的静态路由必须覆盖关键业务网段并且要和主链路的路由在同一个 VRF 路由表里否则逃生时流量进了错误的路由视图直接黑洞。逃生链路的另一个用途是控制器失联时的管理兜底。CloudFabric 的控制面故障不影响数据面转发但如果你需要登录交换机改配置而此时控制器和带内管理都依赖 DCI那就真失联了。建议把管理网段也加进逃生链路的静态路由里同时交换机留一个带外管理口接独立的运维网络双保险别把逃生链路做成黑匣子。4.3 回程路由别把去程配通了就以为业务通了跨站点最容易出现的认知误区站点 A 到站点 B 通了就认为业务通了。实际上A 访问 B 的服务器B 服务器回包时回程路由表里如果没有去 A 的路由要么丢包要么绕到出口 NAT 再回来。设计指南里反复强调一个原则双向路由必须同时成立去程回程对称。具体的坑有两个方向。第一Vbdif 所在的 VRF 里只写了去程路由回程方向没有对应的明细路由或默认路由数据包到了对端网关后找不到出口。第二去程走 VXLAN 隧道回程被策略路由扔到本地出口来回路径不一致中间只要有状态化防火墙就会丢包。常规排查做法是分别在两个站点查看 VRF 路由表把去程和回程的下一跳对比着看# 站点 A 查看业务 VRF 里的路由明细 display ip routing-table vrf tenant-a # 站点 B 同样查看对比两边是否有对称的路由条目 display ip routing-table vrf tenant-a只要发现一边有、另一边没有就说明回程路由漏配了。解决办法很简单把对端站点的业务网段路由加进本端 VRF或者通过 BGP 从逃生链路学到默认路由并确保 DCI 断开时逃生路由优先级最高。回程路由这种问题光靠 ping 大包测不出来必须两边同时抓包才能定位属于上线前就要排查干净的血泪经验。5. Multi-Site 避坑指南五个高频翻车点与排查思路5.1 EVPN 邻居反复重置先查 Underlay MTU再看 BGP 报文现象display bgp evpn peer 看到邻居状态一直在 Established 和 Connect 之间来回跳日志里全是 BGP 连接重置。原因最常见是 Underlay 的 MTU 不够。EVPN 的 BGP Update 报文带扩展团体属性和大量 MAC 路由报文体积轻松超过 1500 字节互联口 MTU 不达标就直接被丢弃。其次是 OSPF 邻居没起来Loopback 互不可达BGP 会话根本没有承载通道。解决先在两个 Spine 之间用大包 ping 验证 Underlay我一般用 9000 字节的包打 100 次然后把互联口 MTU 统一调到 9216包括 DCI 链路两端的对接设备最后 display bgp evpn peer 看 Last-error 字段判断是报文被丢还是认证失败。MTU 问题十次有八次优先查它。5.2 DCI 链路被广播打满二层延伸没做抑制的后果现象业务量不大但 DCI 链路带宽告警端口流量曲线是平的一看全是广播帧。原因二层延伸后广播域跨站ARP 请求、组播、未知单播全量从 DCI 复制。站点内一旦有主机批量上线或扫描行为BUM 流量直接灌满波分通道。解决在 VXLAN 网络里打开 ARP 抑制等价于 EVPN 的 ARP 代答让 Leaf 能应答的就地应答不把请求转发到对端。同时把 VNI 划小广播域收窄到业务必须的范围存储同步用一个 VNI办公网段绝不放进来。最后确认 BUM 复制方式用的是 EVPN 单副本复制而不是入口泛洪这能省掉 DCI 上大部分的重复流量。5.3 小包秒回、大包超时VXLAN 封装后的 MTU 欠账现象ping 小包全通ping 大包丢包率极高数据库日志同步任务频繁超时重传。原因VXLAN 封装会增加大约 50 字节的外层开销Underlay MTU 还是默认 1500 时应用负载超过 1450 字节的报文就被静默丢弃。DCI 链路上如果还有波分设备它们自身的帧长限制可能更小问题会被放大。解决全网 Underlay 设备接口 MTU 统一调到 9216DCI 设备开启 jumbo frame 透传。如果某段链路设备不支持大帧唯一的下策是让 VXLAN 隧道允许分片但分片后重组开销极大数据库这类低时延业务会很难受不建议长期这么干。上线前把 MTU 检查写进验收清单这是最便宜的后悔药。5.4 逃生路由生效了业务还断十几秒ARP 表没跟着切现象手动拔掉主 DCI 光纤后路由切换是秒级的但业务中断窗口长达十几秒甚至有站点完全不通。原因路由层面的收敛很快但主机的 ARP/邻居表还在老化周期里数据帧仍然发往已经不可达的对端网关。或者网关切换到逃生路径后主机没有收到网关的免费 ARP旧 MAC 条目一直占着。解决逃生链路上配置策略路由让本地优先成为默认行为而不是等路由协议慢慢收敛关键网段开启 ARP 快速老化把老化时间从默认的几分钟压到几十秒。切换发生时让逃生网关主动发送免费 ARP强制刷新主机的邻居表。这个坑在虚拟化环境里尤为明显虚拟机内置的网卡状态检测往往比网络收敛还慢。5.5 去程通回程不通跨站点最容易忽略的对称性检查现象站点 A 能 ping 通站点 B 的服务器但业务连接建立失败抓包一看B 的回包根本没回到 A。原因典型的单向路由配置。去程路由写了回程方向的明细路由或默认路由没写或者去程走 VXLAN 隧道回程被出口策略扔到 NAT来回路径不一致状态化设备把连接判定为非法直接丢弃。解决在两端分别查看业务 VRF 的路由表逐条核对站点间网段的去程回程条目抓包确认回包的源 IP 和目标 IP看它实际走了哪个接口把回程 VRF 的导入路由补全。这个问题的隐蔽之处在于ping 用的是 ICMP 有时能绕过去但 TCP 的握手包只要有一个方向不通连接就建不起来属于上线前必查项。6. 上线前必做的三层验证连通性、路由与切换演练6.1 先证明 Underlay 能扛大包在任何业务流量接入前先证明站点间 Underlay 是健康的。我用 Loopback 对 Loopback 打大包这是最直接的体检# 从本机 Loopback 用 9000 字节大包打对端 Spine Loopback ping 10.0.0.2 -a 10.0.0.1 -s 9000 -c 100大包能通说明 MTU 链条是完整的大包不通业务上线后一定会在某一刻暴露问题早发现早处理。6.2 再确认 EVPN 路由收齐并核对 RTUnderlay 健康后查 EVPN 路由是否收齐。跨站点场景下重点看对端站点的 MAC 路由和主机路由数量是否符合预期# 检查 EVPN 邻居状态是否为 Established display bgp evpn peer # 查看跨站点学到的 MAC 路由明细 display l2vpn evpn mac-routes # 核对 VNI 状态是否正常 display vxlan vni如果 MAC 路由只有本端没有对端先查 RT 是否一致再查 arp collect host 有没有开这两个都是高频问题点。6.3 最后做拔线演练记录真实中断窗口验证的最高级形式是演练。我会在业务低峰期做一次拔线断开主 DCI 的一个方向计时观察逃生路由生效时间和业务中断窗口恢复主链路后再观察回切是否引发路由振荡。演练要有明确的判定标准比如逃生切换必须在 10 秒内完成回切不能造成超过 3 秒的丢包。我自己的习惯是把这三层验证写成固定 checklist每次上新的站点或新业务网段都从头过一遍。尤其是 MTU 和回程对称性这两项十次里有八次能提前抓到设计遗漏。跨站点的网络细节全在验证环节里别指望上线后靠监控救场。希望帮到你。本文还有配套的精品资源点击获取