IDC机房交换机选型、组网与运维实战

IDC机房交换机这玩意儿，说白了就是机房里所有服务器之间、服务器和外面世界之间的那个总开关。平时没人惦记它，一出事全机房的人都盯着它看。我干了这些年，见过太多项目在服务器上砸了大钱，结果在交换机上省了几千块，最后被一根劣质光模块、一个没配好的链路聚合折腾到凌晨三点。这篇东西不讲厂商宣传册上那些漂亮词，只讲一个真正要在机房里把IDC机房交换机装上去、配起来、跑稳、出问题能查出来的人需要知道的事：架构怎么选、指标怎么看、配置怎么写、坑在哪里。不管你是刚接手机房网络的新人，还是已经管着几十个机柜、想系统梳理一遍的老手，下面这些内容都能直接拿去对照。

1. 先搞清楚IDC机房交换机到底在机房扮演什么角色

1.1 三层分工：接入、汇聚、核心各自干什么活

机房里交换机的分层，本质上是按"谁连服务器、谁连交换机、谁连外面"来切的。最底下贴着服务器的那一层叫接入层，行业里习惯叫 ToR（Top of Rack），一个机柜顶上放一到两台，服务器用短跳线直接上去，这样走线最干净，也方便按机柜扩容。ToR 的典型规格是 48 个 25G 下行口加 4 到 8 个 100G 上行口，这个配比不是拍脑袋定的，而是根据机柜里常见的 20 到 40 台服务器、每台双上行来倒推的。

中间那一层叫汇聚层，或者在新架构里叫 Spine。它的活儿是把几十上百台 ToR 的上行口收拢起来，做高速转发。这一层几乎不接服务器，只接交换机和出口设备，端口速率通常是 100G 起步，新建的机房很多直接上 400G。再往上就是核心层或者出口层，负责南北向流量，跟防火墙、负载均衡、专线这些设备对接，同时承担跨机房互联。

除了这三层业务网络，实际机房里还有两张容易被新人忽略的网：一张是带外管理网，用独立的 1G 电口交换机把所有设备的管理口串起来，跟业务网物理隔离；另一张是存储网，跑分布式存储或者高性能计算的时候单独组一张，跟业务网分开。为什么一定要物理分开？因为管理网一旦跟业务网混在一起，某台服务器被打满带宽的时候，你连登录设备敲命令的机会都没有，那时候只能抱着键盘去机房按电源键，这个场面我见得太多了。

还有一个原则值得强调：层次越往上，设备越少、单台越贵、越不能出事。接入层一台挂了，影响一个机柜；汇聚层一台挂了，影响一片；核心层出问题，整个机房都受影响。所以钱要花在刀刃上，接入层可以选性价比高的盒式设备，汇聚和核心必须上双电源、双引擎、可插拔风扇这些冗余配置。这个思路决定了后面所有的选型和预算分配。

1.2 为什么IDC交换机不能拿办公网设备凑合

经常有人问：办公网那台交换机看着参数也不错啊，24 个千兆口，便宜一大截，为什么不能用在机房里？这个问题背后其实是对机房环境完全没概念。办公网的设备设计工况是 0 到 45 度、有人值守、每天关机也没关系；机房的工况是常年 18 到 27 度、7×24 不间断、粉尘浓度和气流速度都完全不一样。最直接的差别是风道：机房里机柜是前冷后热，交换机必须做成端口侧进风、电源侧出风（或者反过来），跟机柜气流方向对齐。办公网设备很多是侧进风或者自然散热，塞进机柜里直接就把热风循环起来了，夏天必挂。

再往深里说，三个硬指标差距是绕不开的。第一是表项规格。办公网一台接入交换机，MAC 表可能就 8K、ARP 表几 K，够用；IDC 的 ToR 下面挂几十台服务器，每台跑几十上百个虚拟机或者容器，MAC 和 ARP 表项需求轻松上到几万甚至十几万，小表项的设备一跑满就开泛洪，整个广播域全乱。第二是缓存。办公网流量是人的操作，突发性有限；机房里是备份、是镜像分发、是模型训练的数据加载，瞬间突发能打满端口好几毫秒，缓存小的设备直接就丢了，应用层表现为莫名其妙的超时重传。第三是可靠性设计，双电源、可热插拔风扇、支持在线升级不断业务，这些在办公设备上基本都是没有的。

所以结论很明确：IDC机房交换机的选型逻辑跟办公网完全是两套体系，别拿办公网的思路往机房套。我见过一个项目为了省钱把办公网堆叠交换机搬进机房当 ToR，结果第一周就因为风扇停转烧了一台，第二周因为 ARP 表打满导致整个网段瘫了半小时。这笔省下来的钱，后面用停机时间加倍还回去了。

1.3 一个机柜的网络到底怎么落地

把视角缩到一个机柜，你会更清楚交换机的角色。一个标准 42U 机柜，通常顶部 1U 或 2U 放两台 ToR 做冗余，中间放服务器，底部放 PDU。两台 ToR 之间用两条高速链路互联做跨设备聚合，每台服务器用双网卡分别上联到两台 ToR，这样任何一台 ToR 挂掉，服务器还有一条路活着。这就是机房里最基本的"双上联"原则，看起来简单，但真正做到位需要服务器侧的 bonding 配置、交换机侧的聚合组配置、以及两端哈希算法的一致性配合，任何一环没对上，都会退化成单链路。

机柜内的走线也有讲究。上联光纤走机柜侧面的理线槽，跟电源线严格分开走，避免电磁干扰；服务器到 ToR 的线缆长度尽量控制在 3 米以内，因为高速线缆越长信号衰减越大，25G 用 DAC 直连铜缆一般不超过 3 米，超过就得换光模块加光纤。这些细节在图纸上看不出来，但真到现场施工的时候，一根线长了两米，整个机柜的走线就得重来。

2. 硬件与关键指标拆解：选型时到底该盯哪几个数

2.1 交换容量和包转发率：先算清楚，别被标称值忽悠

厂商彩页上最显眼的两个数字是交换容量和包转发率，但这两个数字怎么来的、够不够用，很多人其实没算过。交换容量（也叫背板带宽）的计算方式是：所有端口速率之和乘以 2（全双工），单位是 Gbps 或 Tbps。一台 48 口 25G 加 8 口 100G 的 ToR，单向带宽是 48×25 + 8×100 = 2000G，双向就是 4000G，也就是标称 4T 交换容量。低于这个数的设备，说明内部架构存在收敛，高负载下会出现端口抢带宽。

包转发率（pps）更能反映真实转发能力，它的算法是按最小以太网帧来算的。一个 64 字节的最小帧，加上 8 字节前导码和 12 字节帧间隙，线路上实际传输 84 字节，也就是 672 bit。所以一个 25G 端口跑满小包时的转发率是 25×10⁹ ÷ 672 ≈ 37.2 Mpps，100G 端口是 148.8 Mpps。上面那台 ToR 的理论包转发率就是 48×37.2 + 8×148.8 ≈ 2976 Mpps。选型时拿这个数去对厂商标称值，如果标称明显偏低，说明设备在 64 字节小包场景下跑不满线速，做压测或者跑高频交易类业务时会露馅。

这里有个实操经验：真实业务里几乎不会全是 64 字节小包，但也不能只看大包性能。互联网业务的平均包长大概在 300 到 600 字节之间，视频类偏大，金融行情类偏小。如果你的业务里有大量小包（比如实时通信、行情推送），那 pps 指标就是硬门槛，必须按最小包去核对；如果是备份、存储、大文件传输为主，那带宽和缓存更重要。这个问题在选型会上一定要提前问清楚业务方，别自己拍脑袋。

2.2 缓存、表项、收敛比：三个最容易被忽略的隐形参数

缓存是决定"突发流量会不会丢包"的关键。交换机缓存分共享缓存和端口缓存两种架构，盒式设备常见的是 16MB 到 64MB 的共享缓存池。这个数字看着不大，但要看怎么用：假设 48 个 25G 端口同时有 1 毫秒的突发，需要的缓存量是 48×25G×1ms ÷ 8 ≈ 150MB，远超大部分盒式设备的能力。所以现实中的做法不是"靠缓存扛住所有突发"，而是靠上游限速、靠 ECN 拥塞标记、靠应用层的重传机制来兜底。缓存大的设备（行业里叫深缓存，几百 MB 到 GB 级）适合存储和 AI 训练这种长突发场景，普通业务没必要为深缓存多付钱。

表项规格要按业务实际规模去算，别只看设备标称。需要核对的至少有这几项：MAC 地址表、ARP 表（IPv4）和 NDP 表（IPv6）、IPv4/IPv6 单播路由表、ECMP 等价路径组数、ACL 条目数、VXLAN 隧道端点数。算法很直接：MAC 表 ≈ 服务器数量 × 每台虚拟机/容器数 × 网卡数，再留 50% 余量。VXLAN 场景下还要加上隧道封装带来的额外表项消耗，一台跑分布式网关的 Leaf 可能需要几万条 VXLAN 表项，入门级芯片根本撑不住。

收敛比是接入层到汇聚层的带宽比例。传统业务网常见的 3:1 到 4:1 都能接受，因为服务器网卡本身也不是时刻跑满。但超融合、分布式存储、AI 训练集群这些场景，要求 1:1 甚至超额订阅（下行总带宽小于上行），因为节点之间的数据同步是持续的大流量。算收敛比的时候要用"下行端口总带宽 ÷ 上行端口总带宽"，比如 48×25G 下行配 8×100G 上行，就是 1200:800 = 1.5:1，这个比例对一般业务够用，对存储集群就偏高了。

2.3 光模块和线缆： cheapest 的环节，最贵的故障源

机房里的链路故障，我统计下来超过一半出在光模块和线缆上，而不是交换机本身。这里面的门道不少。首先是光模块和交换机端口的兼容性，同一个端口可能支持多种封装（比如 QSFP28 转 4×SFP25 的 breakout 模式），但具体支持哪种、要不要配置拆分命令、编码方式对不对，必须查设备的兼容列表，不能想当然。其次是光纤类型匹配，多模光纤配多模模块，单模配单模，短距和长距模块的发光功率差很多，用错了要么不通，要么接收光功率过载把模块打坏。

接收光功率是个必须监控的指标。正常范围一般在 -1 到 -9 dBm 之间（具体看模块规格），低于灵敏度下限就开始出现误码，链路看起来是 up 的，但实际在丢包，这种问题最难查，因为 ping 小包可能通，大流量一压就崩。我习惯在新设备上线时把所有光口的收发功率记一遍基线，后面出问题一对比就知道是不是模块老化了。

DAC 直连铜缆便宜、省电、时延低，但距离限制严格，25G 一般不超过 3 米，100G 不超过 5 米，超过这个距离就只能用光模块。AOC 有源光缆介于两者之间，适合 5 到 20 米的机柜间连接。选线的时候还要注意线径和弯曲半径，机房理线槽里塞满线的时候，弯折过度会导致回波损耗增加，同样表现为误码。这些坑不踩过几次是记不住的。

提示：新采购的光模块不要一次性全部上机，先抽 5% 做插损测试和互通测试，确认批次质量再批量部署。不同批次混用是机房里的常见隐患。

3. 组网架构与核心技术落地

3.1 从生成树到跨设备聚合：二层环路怎么解

传统二层网络防环靠生成树协议，原理是逻辑上阻塞冗余链路，保证任何时刻只有一条路径。这个方案能用，但缺点在机房场景下非常致命：收敛慢（拓扑变化时秒级中断）、链路利用率低（一半链路常年闲置）、单播未知帧泛洪。机房里服务器数量多、东西向流量大，生成树那套逻辑基本就是浪费资源。

现在主流的替代方案有两个方向。第一个方向是设备堆叠/纵向虚拟化，把两台物理交换机逻辑上合成一台，管理简单，配置一份，链路聚合可以直接跨框做。但它的问题是控制面耦合，一台升级另一台也得跟着重启，而且堆叠线本身是单点，堆叠分裂的时候整个网络会出大问题。第二个方向是跨设备链路聚合（M-LAG 这一类技术），两台设备控制面独立、转发面双活，通过一条 peer-link 同步表项，再通过一条独立的 keepalive 链路检测对端存活。这个方案升级时可以逐台做，业务不中断，现在新建机房基本都是这个思路。

M-LAG 的配置里有几个关键点必须注意。peer-link 是一条高带宽链路，承载的是两台设备之间的表项同步和部分流量转发，它本身不能跑业务配置；keepalive 链路走管理网或者单独的直连链路，作用是防止脑裂——当 peer-link 断了但设备本身都活着的时候，keepalive 还在，两台设备都会主动降级，避免双主。这两条链路必须分开走物理路径，见过一个项目把 peer-link 和 keepalive 都配在同一个板卡上，板卡一坏直接脑裂，两台设备同时当主用，MAC 地址全乱，整个机柜瘫痪了两个小时。

3.2 Spine-Leaf 与 VXLAN：大机房的标准答案

机柜数量超过二三十个以后，传统三层架构的汇聚层就会成为瓶颈，这时候就该上 Spine-Leaf 了。这个架构很简单：所有 Leaf 连所有 Spine，Leaf 接服务器，Spine 只做转发不接服务器，Leaf 之间要通信就走"Leaf→Spine→Leaf"两跳。它的好处是任意两台服务器之间的跳数固定为两跳（同 Leaf 下是一跳），时延可预期；扩容的时候加 Spine 提带宽、加 Leaf 提端口数，水平扩展没有上限；配合 ECMP 可以做多路径负载均衡，所有链路都跑起来。

这个架构里路由协议一般用 eBGP，每台 Leaf 和 Spine 之间起一个 BGP 邻居，Leaf 把自己的服务器网段宣告出去。为什么用 BGP 而不是 OSPF？因为 BGP 的策略控制能力强、收敛行为可预测、跟 VXLAN EVPN 天然配套。OSPF 在大规模 ECMP 场景下的收敛时间和资源消耗都不太理想，而且没有 EVPN 那种基于 BGP 扩展团体的多租户能力。

VXLAN 加 EVPN 解决的是大二层和多租户的问题。VXLAN 把二层帧封装进 UDP 里，用 VNI 标识不同的虚拟网络，同一个 VNI 内的机器就像接在同一台交换机上，跨 VNI 完全隔离。EVPN 则用 BGP 来分发 MAC 和 IP 的可达性信息，替代了 VXLAN 早期那种靠泛洪学习的做法，控制面更干净、收敛更快。分布式网关是这套方案的关键设计：每台 Leaf 都做自己网段的网关，服务器跨网段通信时第一跳就在本地 Leaf 完成，不用回到集中的网关设备，东西向流量的路径最短。

VXLAN 有一个必须提前算清楚的参数：MTU。封装会在原始帧外面加 50 字节（IPv4 外层）或 70 字节（IPv6 外层）的开销，如果服务器侧 MTU 是 1500，那底层物理链路和隧道接口的 MTU 至少要设到 1550 以上，否则大包会被分片甚至被丢弃，表现为"能 ping 通但大文件传不动"。这个坑几乎每个上 VXLAN 的团队都会踩一次，配置的时候一定要把物理口、隧道口、服务器网卡三处的 MTU 对齐。

3.3 链路聚合实战：哈希算法决定你实际能用多少带宽

链路聚合（LACP）是机房里用得最多、也最容易出问题的技术。基本配置不难，难的是理解"聚合带宽不等于单流带宽"这件事。一条 4 成员的 25G 聚合链路，总带宽是 100G，但单条 TCP 连接的流量只会走其中一条成员链路，最多 25G。原因是负载均衡靠的是哈希算法，常见的是按源 IP、目的 IP、源端口、目的端口、协议号这几项的某种组合做哈希。同一条流的五元组不变，哈希结果就不变，永远走同一条物理链路。

所以如果业务方问"我配了 4 条聚合，为什么备份只有 25G"，答案就在这里。解决办法有两个：一是让应用层开多线程/多连接，让流量分散到不同的五元组；二是把哈希算法改成基于更多字段的组合，比如加上 MAC 地址或者 VLAN ID，这在不同厂商的设备上叫法不一样，配置时要查清楚支持哪几种模式。还有一个细节：聚合组两端的哈希算法必须一致，一端按三层哈希、另一端按四层哈希，会导致同一个流在两端的路径不一致，出现乱序，TCP 性能反而下降。

聚合组的成员端口配置也要严格一致：速率、双工、MTU、VLAN 配置、QoS 策略，任何一项不同都会导致成员端口无法加入聚合组，或者加进去了但流量只走一条。见过最隐蔽的一个问题是成员端口的光模块型号不同，一个是原厂的一个是第三方的，协商出来的参数有细微差异，聚合组看起来是 up 的，但其中一条成员链路常年零流量。这种情况必须靠监控每条成员链路的流量计数才能发现，光看聚合口的总流量是看不出来的。

# LACP 聚合配置示意（不同厂商语法有差异，仅示意结构） interface range 1/0/1-4 description To-Server-A-NIC1 mtu 9216 channel-group 10 mode active interface port-channel 10 description LACP-To-Server-A switchport mode trunk switchport trunk allowed vlan 100,200 lacp hash-mode src-dst-ip-l4port

3.4 QoS 与无损网络：存储流量跑得稳的关键

普通业务网的拥塞处理逻辑是"丢了再重传"，TCP 自己会退让，应用层感知不明显。但存储流量、尤其是走 RoCE 的分布式存储流量，要求网络尽量不丢包，因为一次丢包的重传代价远高于普通 TCP。这就需要在交换机上做无损网络的配置，核心是两个机制：PFC（优先级流控）和 ECN（显式拥塞通知）。

PFC 的作用是当某个优先级的接收队列快满时，向对端发暂停帧，让对端暂时别发。它把链路层做成了"不丢包"，但代价是可能引发连锁的暂停扩散，严重的时候整个网络出现死锁，行业内叫 PFC 风暴。所以 PFC 不能随便开，必须配合 ECN 一起用：ECN 是让交换机在队列水位超过阈值时，在报文头上打标记，接收端收到标记后主动降速，这是"提前预警"，比 PFC 的"急刹车"温和得多。

实操中的参数设置有个经验区间：ECN 的最小阈值设在队列缓存的 20% 到 30%，最大阈值设在 60% 到 70%，超过最大阈值还没降速的报文才丢。PFC 的触发水位要留在 ECN 之上，作为最后一道防线。另外 PFC 必须端到端配置，服务器网卡、接入交换机、上行链路全部启用同一个优先级（通常是优先级 3 给存储流量），中间任何一跳没配，整条链路就不是无损的。配置完一定要用打流工具验证，看暂停帧计数和 ECN 标记计数是不是在正常范围，不能只看配置回显。

4. 上线实操：从开箱到割接的完整流程

4.1 上线前的准备工作，比配置本身更重要

设备到货之后第一件事不是上电，是核对和登记。序列号、型号、板卡配置、电源数量、风扇数量逐项对清单，拍照存档。这一步看着繁琐，但后面报修、续保、资产盘点全靠它。同时要把固件版本统一，同一批次上线的设备必须刷成同一个版本，混版本是机房里最隐蔽的故障源之一，尤其是 VXLAN、M-LAG 这些特性，不同版本之间的行为差异可能导致互通问题。

上电之前要确认机柜的供电和散热条件：双路 PDU 是否分别接到不同的 UPS 回路，风道方向是否跟机柜气流一致，前后是否留足散热空间。这些是基础设施的事，但网络设备宕机的原因里，供电和散热占到相当比例。我习惯在设备上电后先空跑 24 小时，观察温度曲线和风扇转速，确认没有异常再开始配置。

配置之前先规划好三张表：IP 地址规划表（管理 IP、互联 IP、业务网段）、端口规划表（每个端口接什么设备、什么速率、什么 VLAN）、VLAN/VNI 规划表（业务隔离和映射关系）。这三张表是后面所有配置的依据，也是交接时的核心文档。见过太多项目配置是现敲的，没有规划表，半年后接手的人对着一堆 description 写着"temp""test"的端口完全不知道是干什么的。

4.2 基线配置：每台设备都必须有的一份底稿

基线配置的思路是"把该关的关掉、该开的开起来、该记的记下来"。要关掉的是未使用的端口（shutdown 掉，划到隔离 VLAN），要开起来的是 NTP 时间同步、syslog 日志外发、SNMP 或者 Telemetry 采集、AAA 认证。要记下来的是配置备份和版本信息。

时间同步这件事经常被忽略，但排查故障的时候极为关键。交换机、服务器、存储的日志时间不一致，你根本没法把同一时刻发生的事情串起来。NTP 服务器至少配两个，指向不同的源，避免单点失效。日志外发也要配，设备本地日志空间有限，重启就没了，必须实时送到日志服务器上。

# 基线配置示意 hostname LEAF-01 ntp server 10.0.0.10 priority ntp server 10.0.0.11 logging host 10.0.0.20 logging trap informational snmp-server host 10.0.0.30 version 2c snmp-server enable traps aaa authentication login default radius interface range 1/0/1-48 description UNUSED shutdown switchport mode access switchport access vlan 999

防环和边缘保护也是基线的一部分。接服务器的端口要配置边缘端口（收到 BPDU 直接 err-disable），防止服务器上的虚拟化软件或者误接的设备把生成树拓扑搅乱。同时要开广播风暴抑制和未知单播抑制，阈值按业务实际情况设，一般设在端口带宽的 5% 到 10%，既能挡住异常流量，又不会误伤正常业务。

4.3 割接执行：窗口、回滚、验证三件事

割接是整个上线流程里风险最高的环节。我的做法是把割接拆成"预演、灰度、全量"三步。预演是在测试环境或者非核心机柜上把完整流程走一遍，包括配置下发、链路切换、故障注入（拔线、断电），确认回滚脚本可用。灰度是先切一个机柜或者一组服务器，观察 30 分钟到 1 小时，确认业务指标正常再继续。全量才是真正的大规模切换。

回滚方案必须写成可执行的脚本或者步骤清单，不能只写"回滚到原配置"。因为割接过程中可能已经改了一部分配置，简单的配置回滚往往不彻底，涉及路由、VLAN、聚合的变更要逐项列出回退动作和验证方法。窗口时间要留足，一般来说实际耗时是预估的 1.5 到 2 倍，卡着窗口做是给自己找麻烦。

验证环节要看的不只是 ping 通不通。至少要包括：链路状态和聚合成员状态、光功率和误码计数、路由邻居状态、跨机柜的吞吐测试（用打流工具跑几分钟）、关键业务的事务成功率、以及日志里有没有新的告警。小包 ping 通但大包不通、单向通双向不通，这些情况在割接里都出现过，只靠 ping 是发现不了的。

注意：割接前一定要确认带外管理通道可用，并且不依赖正在割接的业务网络。业务网断了还能通过管理网登录设备，这是最后的救命通道。

5. 监控体系与日常运维

5.1 必须盯住的指标清单

监控不是把所有指标都采集一遍，而是盯住那些"出问题会直接影响业务"的项。端口层面最关键的是 up/down 状态变化、CRC 错误计数、丢弃计数、光收发功率。CRC 错误增长说明物理层有问题（模块、光纤、连接器），丢弃计数增长说明拥塞或者策略拦截。这两个指标分开看，能快速定位是物理问题还是逻辑问题。

设备层面要看 CPU 和内存利用率、温度、风扇转速、电源状态、表项使用率。CPU 长期高于 70% 就要警惕，可能是控制面协议震荡或者有异常流量在打设备。表项使用率超过 80% 就要准备扩容或者优化，ARP 表满了之后新上线的虚拟机就学不到地址，表现是"新机器上不了网，老机器正常"，这个现象很有辨识度。

协议层面要看 BGP 邻居状态和路由数量、LACP 成员状态、M-LAG 的 peer-link 和 keepalive 状态、VRRP/网关角色。这些状态的变化往往先于业务故障出现，是很好的预警信号。

5.2 巡检与变更管理

日常巡检不用每天都把上面所有项看一遍，但要有节奏。每天看告警和端口 flap 记录，每周看一次表项趋势和光功率变化，每月做一次配置备份比对和固件版本核查。配置备份比对这一步很有价值，能发现未经审批的变更，也能在出问题时快速定位"上次好好的，这次改了什么"。

变更管理是运维里最容易流于形式的环节。我的经验是把变更分成三类：一类是高风险的（涉及核心设备、涉及路由协议、涉及割接），必须走完整评审和窗口；二类是中风险的（接入层配置调整、VLAN 增删），需要双人复核；三类是低风险的（description 修改、端口开关），可以自助执行但要留记录。分类的意义在于把精力放在真正危险的操作上，而不是所有变更都走一遍冗长流程导致大家开始绕过流程。

还有一个实操习惯：所有变更前先抓一份"变更前状态快照"，包括关键命令的输出、端口计数、路由表条目数。变更后一对比，任何异常都能立刻发现。这个习惯帮我躲过好几次事故，比如某次升级后发现某条链路的误码计数从零开始增长，一查是新版本下光模块协商参数变了，及时换模块避免了后续的业务抖动。

6. 常见故障排查实录

6.1 一套可复用的排查顺序

网络故障排查最忌讳上来就改配置。我的顺序是：先确认影响范围（单机、单机柜、单网段、全网），再确认时间点（做了什么变更、有没有告警），然后从物理层往上逐层查（链路状态→光功率→误码→二层表项→三层路由→策略），最后才动配置。这个顺序的价值在于，大部分故障其实在物理层和二层就能定位，根本不用碰路由和策略。

影响范围的判断特别关键。一台服务器不通，先看它接的端口状态和光功率；一个机柜不通，看 ToR 的上行和聚合状态；一个网段不通，看网关和路由；全网异常，看核心和协议邻居。范围定下来，排查范围就缩小了 90%。

6.2 典型案例：五个踩过的坑

案例一：间歇性丢包，ping 通但大流量崩。某机柜的服务器反馈业务偶发超时，小包测试完全正常。查端口计数发现 CRC 错误在缓慢增长，查光功率发现接收功率在 -11 dBm 左右，接近模块灵敏度下限。换了一根光纤跳线后恢复正常。根因是跳线在理线槽里被压弯，弯曲半径过小导致损耗增加。这类问题的特征是"时好时坏"，因为温度和振动会让损耗轻微波动。

案例二：聚合链路带宽上不去。业务方配了 4 条 25G 聚合，实测只有 25G。查聚合组状态正常，四条成员都在。再看每条成员的流量计数，发现只有一条有流量。原因是哈希算法基于源目 IP，而业务是单连接的大文件传输，五元组固定。改成包含四层端口的哈希模式，并建议业务侧开多连接，问题解决。

案例三：新上线的虚拟机拿不到地址。老机器一切正常，新机器 DHCP 失败。查交换机的 ARP 表使用率已经到 95%，新表项学不进来。根因是这个二层域里挂了太多虚拟机，加上历史遗留的静态 ARP，把表撑满了。处置是清理无效表项、调整 ARP 老化时间，中长期方案是缩小二层域范围、把网关下沉到 Leaf。

案例四：跨设备聚合分裂后全网异常。两台做跨设备聚合的交换机同时认为自己是主用，MAC 表项冲突，流量在两个方向来回跳。查下来是 peer-link 和 keepalive 链路同时中断（都走在同一块板卡上），防脑裂机制失效。整改方案是把两条链路分到不同的板卡和不同的物理路径上，并在管理网侧增加独立的检测通道。

案例五：VXLAN 上线后大文件传不动。跨网段的小文件正常，大文件传输卡在几 MB 就断。抓包发现是 DF 位置位的大包被丢弃。根因是隧道封装增加了 50 字节开销，物理链路 MTU 仍然是 1500。把物理口和隧道口 MTU 调到 9216、服务器网卡 MTU 调到 1450 或 9000 后恢复正常。这个问题的排查关键是看丢包是不是集中在特定大小的包上。

6.3 几个不写在文档里的经验

第一，故障复现比故障修复更重要。很多间歇性问题一重启就"好了"，但根因没找到，过两周还会回来。宁可多花时间做压力测试和故障注入，把问题稳定复现出来，也不要满足于"暂时恢复了"。

第二，计数器的变化趋势比绝对值更有价值。CRC 错误有一两个可能是偶发，但持续增长一定是问题；丢弃计数在业务高峰期增长是正常的，但在低谷期增长就不正常。建立基线，看趋势，这是运维的核心能力。

第三，换件之前先记录。换光模块、换线缆、换板卡之前，把当前的所有计数和状态截图存档，换完之后对比。见过换完模块问题依旧、但原始状态没记录，导致无法判断是换错了还是另有原因，白折腾半天。

第四，别忽视物理环境。机房温度、湿度、积灰、理线，这些看似跟网络无关的因素，实际是很多"玄学故障"的根源。设备进风口积灰导致局部过热，风扇转速飙升但温度不降，最后触发保护降频，表现为转发性能下降。定期清灰这件事，比很多高级优化都管用。

第五，文档和配置要同步更新。端口规划表、IP 表、拓扑图，改一次配置就更新一次。这不是为了应付检查，是为了三个月后的自己。我在实际项目里见过最惨的一次故障，是接手的人对着过期的拓扑图排查，花了四个小时才发现在图上的那条链路早在半年前就被拆了。

最后分享一个我个人的习惯：每台新设备上线，我都会在本地存一份"出厂状态 + 基线配置 + 首次验证记录"的完整快照，命名带上日期和机柜号。这套东西在半年后设备出问题时，能把排查时间从几小时压缩到几分钟，因为你有一个确定的、已知正常的参照点。这件事没有任何技术含量，但它是我这些年做过的最有价值的运维动作。