我刚工作那几年，最怕的就是半夜手机响。群里来一句“核心又不行了”，整个人瞬间清醒。这种故障的特点很统一：影响面大、时间紧迫、领导盯得紧，而且越是紧张越容易乱。如果你也是网络工程师，核心交换机、核心路由器、出口防火墙这类设备肯定不陌生。它们承担着全网流量的汇聚与转发，一台设备出问题，可能整张网都要跟着遭殃。
做了这么多年排障，我最大的感受是：核心节点“总崩”这件事，表面上看是突发事故，其实大部分都有前兆，只是平时没留意。这篇文章我不打算讲那些课本上的泛泛理论，而是把核心节点为什么容易崩、通常崩在哪几类原因上，以及我自己常用的排查神技和一套能直接套用的实战流程，一步步拆给你看。不管你是刚入门的新人，还是已经扛过不少故障的老手，这篇文章都值得收藏下来当参考。
1. 核心节点为啥总崩：先给故障分分类
1.1 先搞清楚核心节点到底扛了多少东西
很多人一听到“核心节点”，第一反应就是“核心交换机”。但实际在现网中，核心节点是一个更广义的概念。它可能是核心交换机，也可能是核心路由器、出口防火墙、负载均衡设备、认证网关、DNS服务器等等。这些设备有一个共同特点：所有流量都要经过它，它是一个天然的汇聚点。
拿一张局域网来举例，终端接入交换机，接入交换机汇聚到分布层，分布层再上联到核心，核心再连出口防火墙、路由器去外网。在这张拓扑里，核心交换机就是最关键的“十字路口”。一旦它出了问题，所有接入层设备都会失联，业务系统全挂。你可以把它理解成一个城市的中心交通枢纽，一条小路堵了只影响一小片区域，但中心枢纽瘫痪了整个城市都动不了。
所以排查核心节点故障之前，你得先清楚这台设备在整张网络中的角色和位置。它管着哪些网段、跑了哪些路由协议、下面挂了多少台接入设备、有哪些关键业务依赖它。这些信息平时就要整理好，否则出故障的时候临时翻文档，时间根本来不及。
1.2 硬件层面：最常见的“死法”之一
硬件问题是导致核心设备崩溃的一大类原因，而且这类问题往往没有太多前兆，一发生就是大事。
先说电源。很多机房的核心设备虽然是双电源，但有的人图省事只接了一路电，或者两路电其实来自同一个配电柜。一旦那个回路跳闸，设备直接掉电。我见过最离谱的案例是，某项目核心交换机双电源都插着，结果发现两根线绑在一块儿走同一个PDU，现场人员拔线维护的时候顺手就把核心的电源给断了。所以检查核心设备，第一步永远是看冗余是否真的冗余，而不是仅仅看指示灯。
再说光模块和光衰。核心设备上跑的都是主干链路，光模块长期满负荷工作，再加上机房温度偏高或者模块本身质量一般，时间一长就会出现光衰变大、误码率升高，最后链路闪断甚至完全中断。这种故障表现很奇怪，CPU不高、日志里可能也只有简单的“link down”，但业务就是频繁抖动。所以排查链路类问题时，一定要查光模块的光功率、温度，看看收发光是否在阈值范围内。
还有风扇和温度。核心设备一般都有温度告警机制，但很多机房的空调系统并非双备份。某次高温天气，机房精密空调故障，温度升到40度以上，核心交换机直接因温度过高自动关机，因为它的设计逻辑是宁可停机保护硬件，也不能把设备烧了。这种问题靠监控就能提前发现，但前提是你的监控里确实包含了温度这个指标。
1.3 软件与协议层面：隐蔽性最强的“定时炸弹”
如果说硬件问题还有迹可循，那软件层面的问题就隐蔽得多了。这一类我见过的故障占了六成以上。
第一类是路由协议震荡。核心设备通常跑着动态路由协议，比如OSPF、BGP，用来维护全网或跨区域的路由可达性。一旦某个邻居接口频繁up/down，协议就会反复重新计算，CPU直接飙升。更可怕的是，路由震荡会引起全网的路由重算，导致其他设备的CPU也跟着遭殃。
第二类是二层环路和广播风暴。很多人觉得现在的网络都做了STP，不会再有环路，但实际工作中环路仍然很常见。比如某些傻瓜交换机不支持STP，或者某根线被误插形成了物理环路。一旦环路出现，广播帧会在环路里无限循环，瞬间把链路打满，核心交换机的CPU因为要处理海量广播包而直接过载，导致整个网络“假死”，表现得像完全瘫痪一样。
第三类是表项问题。ARP表、MAC地址表、FDB表、路由表，这些表项都有容量上限。正常情况下没事，但如果网络里出现异常扫描、某个终端的网卡故障疯狂发包，或者有人把后门设备直接接入了办公网，核心设备可能短时间内收到海量ARP请求，ARP表被打满，新的ARP学习不了，老的表项不停老化重新学习，CPU一路狂飙。还有的人会因为思科设备默认的ARP表老化时间设置不当，导致频繁刷新。
第四类是配置问题。这块就比较“人祸”了。比如有人在核心设备上刷ACL的时候把顺序弄反了，该放行的流量被误拦；比如做虚拟化（VRRP/堆叠）的时候，优先级配置不对，两个节点来回抢占，导致业务间歇性中断；又比如QoS队列配置失误，把某类重要流量限速限没了。这类问题最坑的地方在于，设备本身没坏，协议也正常，但网络就是不通或者很卡。
1.4 外部流量与“脏流量”攻击：核心也是受害者
核心节点还经常成为攻击或异常流量的受害者。
一种是突发的流量冲击。比如公司某个业务系统做活动，瞬时流量暴涨，虽然核心设备的设计容量一般远高于正常业务量，但如果流量来得太猛，或者存在明显的PPS（每秒数据包数）过高的情况，转发面可能还撑得住，控制面CPU就顶不住了。现在的核心交换机普遍采用了分布式转发架构，数据面由硬件芯片转发，但控制面的CPU还是需要处理一些特定的报文，比如目标为设备自身IP的报文、ARP请求、BGP/OSPF心跳包等。
另一种是网络扫描。内网如果有主机中了某个脚本，或者有人用扫描工具做测试，每秒发出大量探测包。这些包很多是无效的，不会占用多少转发带宽，但会消耗设备控制面的CPU资源。很多设备都有“控制面保护”功能，英文缩写CoPP或者CPP，但默认往往没有启用或配置不全，结果就是一台小小的扫描设备，就能把核心设备的CPU打满。
还有一种隐蔽的“单播洪泛”。假如某台服务器网卡故障或驱动异常，向一个本不该存在的MAC地址发送大量单播帧，交换机学不到对应表项，默认行为是向所有同VLAN端口广播转发。这种流量在核心上汇聚后，会造成全网广播数量激增，看起来像广播风暴，但源头其实是单播洪泛。
这些原因归纳下来，其实核心节点崩溃主要就五大类：硬件故障、协议异常、配置错误、表项过载、外部流量冲击。排查的思路，就是先判断当前到底属于哪一类，再针对性下探。这也引出了下面要讲的排查神技。
2. 排查神技：先把工具包和思维方法练熟
2.1 命令行三板斧：状态、日志、计数器
核心设备出问题时，你最直接的武器就是命令行。不管是什么厂商的设备，思路都一样，先看三样东西：状态、日志、计数器。
第一，先看CPU和内存。这块有个经典命令，在思科设备上是show processes cpu history，它能显示CPU使用率的历史曲线，非常有用。通过历史曲线你可以快速判断故障是持续性的还是突发性的：如果曲线像锯齿一样，说明是周期性的负载波动；如果突然垂直上升，那大概率是某时间点发生了异常。华为设备上类似的是display cpu-usage，还有display cpu history。内存也一样，show memory或display memory，重点关注是否有持续增长趋势。一个健康的核心设备，CPU长期保持在50%以上都很可疑，更不要说90%了。
第二，看日志。核心设备上show log或者display logbuffer，重点找三个关键词：down、err、reset。链路抖动一定会留下日志，协议邻居断开也会留日志，设备重启更会留日志。日志信息非常关键，它能帮你精准锁定故障事件的时间点。但你得注意，日志缓冲区的默认大小可能只够存几千条，故障发生后如果流量异常，大量日志瞬间就把缓冲区刷满了，早先的日志反而被挤掉了。所以对核心设备，建议提前调大日志缓冲大小。
第三，看接口计数。show interface命令里最重要的不是那个带宽和双工状态，而是里面的错误计数器：CRC错误、input errors、output errors、runts、giants、FCS错误。正常情况下这些都应该是0或者长期不变。如果发现某个接口CRC错误在快速增长，基本可以断定物理层有问题，光模块或线缆劣化跑不掉。如果错误包大量存在但CRC正常，则可能是缓冲区溢出，比如突发的流量超过了接口处理能力。
这三板斧是最基础但最实用的起点。每一次排障，我都是先看完这三项，心里基本就有个大概方向了。
2.2 抓包与流量分析：让数据开口说话
命令行的三板斧能告诉你设备自己看到了什么，但有时候设备自己也是“受害者”，它的判断并不准确。这时候就需要抓包了。
最常用的方式是在核心设备上做端口镜像，也就是SPAN。你可以把接出故障的那个接口的流量，或者上联口方向的流量，复制一份送到一个专门抓包的接口上，再用笔记本或者服务器抓包分析。华为的叫镜像端口（observe-port），思科的叫monitor session。如果核心设备支持远程镜像（RSPAN/ERSPAN），还可以把镜像流量送到远端分析设备，方便得很。
抓包工具方面，命令行下用tcpdump就够了，比如抓ARP风暴：sudo tcpdump -i eth0 -nn arp，如果几秒钟之内有成千上万个ARP请求，那基本就是风暴了。图形化界面上推荐Wireshark，它的统计—协议分级功能非常好用，能直观告诉你流量里哪种协议占了大头。还经常用“分析—流量的时间序列”来做IO图，看那个时间节点流量是否有尖峰。
我个人最深的体会是：抓包不是拿来即兴发挥的，而是要有目的性地抓。问题出现前，你就得想清楚：我要抓什么协议？在哪个接口抓？抓多久？比如怀疑ARP问题，就只抓ARP；怀疑TCP重传导致卡顿，就只抓TCP并打开Wireshark的TCP分析功能，看重传率、乱序情况；怀疑BGP路由震荡，就只抓端口179上的报文，看是不是频繁up/down。
2.3 监控与告警：别等崩了才上手
没有事后的神技能够替代事前的监控。核心设备的排障离不开监控数据，因为故障发生后的现场往往没法复制，而你当时需要的是故障发生前后的数据对比。
监控这块，最常见的方案是用SNMP协议轮询设备，采集CPU、内存、温度、端口流量、光功率等指标，再配合图形化展示。新一代设备还支持Telemetry，也就是推模式，性能和实时性都比SNMP轮询好很多，但部署成本也高一些。不管用哪种，关键是要把核心设备的重点指标都纳入监控范围。
哪些指标最值得监控？我个人觉得是这几项：CPU使用率、内存使用率、设备温度、端口流量（入向和出向）、端口错误计数、光模块光功率、电源和风扇状态、关键协议邻居状态（比如BGP peer、OSPF neighbor）、软件版本及变更记录。光功率很多团队都不监控，这是个盲区。其实光模块是最脆弱的物理部件，光功率缓慢变差的过程，往往能提前数周看出趋势来。
监控告警的阈值设置也有讲究。别照搬厂商默认值，也别拍脑袋。我习惯按历史基线来定：先让设备跑一段时间正常流量，记录CPU波动范围，然后把告警阈值设为正常值的1.5倍左右。例如平时CPU在10%到20%波动，可以设置在60%预警，80%紧急告警。这样能减少误报，也能确保真出问题的时候及时通知到人。
另外，加一些主动探测也很有必要。在监控服务器上定期ping核心设备的管理地址，或探测关键业务端口，一旦连续失败多少次就触发告警。这样即便设备自身告警没发出来（比如自身都卡死了，SNMP响应不了），外部探测也会先发现异常。
2.4 排障方法论：分层、二分、对比
工具是术，方法论才是道。任何一次核心设备排障，都离不开三套思维：分层、二分、对比。
分层法就是按OSI模型逐层排查。先从物理层看起，链路状态、光衰、误码；再到链路层，看ARP、MAC、STP；再到网络层，看路由、ICMP；再到传输层和应用层。不要跳层，不要上来就怀疑应用重启。很多新手排障容易直接跳到应用层，盯着一台服务器来回查，查了半天没问题，回头一看是底层光模块挂了。
二分法就是不断把故障范围一分为二。核心设备下面挂了多台接入交换机，现在所有区域都出问题，就先确认是整个核心崩了，还是只有某个区域受影响。如果只有某区块出问题，就往该区块往下追；如果是全网的，就要聚焦在核心自身或上行链路上。一层层缩小包围圈，很快就能锁定故障域。
对比法就是拿异常和正常做对照。哪台接口回显异常？另一台正常的接口回显什么样？某个指标现在异常，那半小时前监控图长什么样？拿故障时间节点前后的数据进行对比，往往一眼就能看出谁在“作案”。
这些方法单独看都很简单，但真正出故障的时候，大家最容易因为着急而跳着排查。所以我的习惯是：接到故障先深呼吸，按流程走。流程化才能控制节奏，节奏稳了，排障效率才高。
3. 实战套路：从“核心崩了”到“定位根因”的完整剧本
3.1 故障现场：现象与第一反应
理论聊了这么多，我来讲一个比较典型的实战场景。某公司和我在合作的一个项目中，核心机房有一台核心交换机，某天上午10点左右，业务群有人反馈：办公网大面积卡顿，OA系统登录不上，部分数据库连接超时。紧接着监控告警弹出：核心交换机CPU使用率95%，持续超过5分钟。
第一反应不是马上把设备重启了，也不是立刻拔线。而是先看了一眼时间，记下故障开始时间，同时瞄了一眼当前告警面板。然后远程登录核心设备，准备做现场信息收集。这一步很关键：故障发生时的运行状态，是排障最珍贵的资料。你一旦手动重启设备，很多线索就跟着一起“重启”了。
登录后，我先快速敲了几个命令：show processes cpu sorted看哪些进程在吃CPU，show log看有什么异常日志，show interface counters errors看所有接口的错误计数，show arp看ARP表项数是否异常暴涨。
3.2 信息收集与快速止血
命令很快回显了。CPU核心占用高的进程是“IP Input”，这个进程主要负责处理到达设备自身CPU的报文，比如ARP、ICMP，以及一些需要CPU协助的转发报文。IP Input高，说明有大量流量在打控制面。再看ARP表，平时局域网内也就一两千条，现在ARP表项有5000多，还在涨。
日志里发现大量如下内容：
%ARP-3-INPUT_ERR: Invalid ARP request received from 00:1a:2b:3c:4d:5e on Vlan 10这说明有设备在向VLAN 10内发送异常格式的ARP请求。此时网络已经不是单纯的卡顿，而是有演变成全网瘫痪的趋势。需要快速止血。
我的处理思路是：既然异常源指向VLAN 10，那就先在核心设备上临时配置风暴控制或对VLAN 10做流量隔离，把广播和未知单播限制在可控范围，保住其他VLAN的业务。同时把疑似VLAN 10下的接入层交换机上联口暂时shutdown，先让整体网络恢复稳定。做完这两步，CPU慢慢回落到20%左右，业务逐渐恢复。这时才进入真正的定位阶段。
3.3 抽丝剥茧：定位根因
网络恢复后，开始精确锁定“作案者”。核心设备上可以按源MAC统计ARP报文数量。我用了一个比较直接的办法：在接入交换机上，用抓包工具镜像VLAN 10的上联口，开了tcpdump，命令很简单，就抓ARP包：
sudo tcpdump -i eth0 -nn arp结果停不下来，屏幕上每秒都在刷同一条信息：一个固定的源MAC地址，向全VLAN广播ARP请求，请求的目标IP是它自己。这是什么情况？正常情况下，设备只会请求别人的IP地址来解析MAC，你怎么会一直请求自己的IP？
结合这个现象，我判断大概率是某个终端网卡驱动异常。后来查到该MAC对应的端口，发现接的是一台文件服务器。登上去看，网卡驱动的TCP/IP协议栈出了异常，导致它不断向网络中发送ARP请求解析自己的地址。服务器本身看着“没死”，但它的网卡实际上已经不正常工作了。
到这里，根因就算闭环了。不是核心设备坏了，也不是路由协议有问题，而是一台服务器的网卡驱动Bug引发了一场ARP风暴，打爆了核心的CPU。处理办法很简单：把文件服务器的网卡驱动更新，并更换新的物理网卡（因为旧网卡已经不稳定），同时在该接入端口上做了Mac地址飘移防护和风暴控制，防止同类事件再发生。
这个案例很典型，它印证了一个我经常跟别人讲的观点：很多核心崩溃，源头根本不在核心本身。最核心的那台设备，经常只是整个故障链上最倒霉的一环。
3.4 加固与复盘：别让同类事故再发生
故障解决之后，真正的工作才刚开始。我在处理完这类故障后，一般会做三件事。
第一件事是设备加固。在核心设备上配置控制面保护（CoPP/CPP），专门限制ARP、ICMP、BGP等关键报文对CPU的冲击速率。合理配置CoPP之后，即使再有ARP风暴，CPU也只会承受每秒几百个包的转发量，核心设备不会因此瘫痪。很多设备默认不启用CoPP，或者启用了但策略太宽松，形同虚设。这块值得专门研究一下。
第二件事是配置优化。在接入层交换机上，统一开启广播风暴抑制、未知单播抑制，并配置端口安全或MAC地址限制。这样一来，异常流量在接入层就被控制住了，不会涌到核心。也要检查所有VLAN的ARP表项老化时间，避免短周期内大量表项同时刷新，给CPU制造瞬时压力。
第三件事是复盘。复盘会议不要开成追责会，而要聚焦在“流程有没有漏洞、监控有没有盲区、预案有没有缺失”上。比如这次事件，监控虽然报了CPU高，但没有监控ARP表项数量，否则可以提前一天就发现异常苗头。另外应急手册没写清楚“核心CPU高时先隔离再定位”的操作步骤，导致现场人员一开始有点犹豫。这些都在复盘后补充到了文档里。
4. 常见问题与排查技巧实录
4.1 核心设备故障速查表
在实际工作中，我积累了不少针对特定故障症状的排查套路。下面这个表格是我自己整理的，碰到类似问题可以照着用。
| 典型症状 | 可能原因 | 快速验证命令 | 处理方向 |
|---|---|---|---|
| CPU持续90%以上 | ARP风暴/协议震荡/网络扫描 | show processes cpu history、show log、抓包 | 先隔离异常源，配置CoPP，查找根因 |
| 某区域频繁卡顿、丢包 | 光模块劣化、链路误码、级联带宽不足 | show interface counters errors、检查光功率 | 更换光模块，扩容链路或做链路聚合 |
| 业务偶发中断，但链路显示正常 | VRRP/堆叠主备频繁切换、生成树收敛 | show log、show vrrp、show spanning-tree | 检查冗余协议配置是否合理 |
| 核心内存持续增长，缓慢上涨 | 软件内存泄漏、路由表膨胀、FIB超规格 | show memory statistics、show ip route summary | 收集内存趋势，联系厂商或升级版本 |
| 设备自动重启 | 电源故障/高温/看门狗/内核异常 | show version（查看重启原因）、show environment | 检查硬件状态，分析故障时的环境数据 |
| 整网瘫痪，业务全断 | 二层环路广播风暴、核心板卡故障 | show interfaces counters、看MAC漂移日志 | 找环路、隔离端口，检查硬件 |
用户在用这张表的时候有个容易忽略的点：不要只验证一列，直接把表中“可能原因”里的两三种都快速验证一遍，因为故障往往不是单一原因，也可能先是链路劣化，再继发协议震荡，最后把CPU打满。
4.2 排障中容易翻车的5个细节
第一，不要在没保存现场信息的情况下重启设备。除非网络全瘫、业务彻底不可用，否则一定要先收集信息再动手。我有次在故障现场，同事上来就重启核心，重启完网络确实恢复了，但故障日志无从查起，最后只能判定“未发现异常”，等于什么都没搞清楚，两周后同类故障又来了。
第二，不要忽略时间同步。排障时经常要对比设备日志和监控系统记录，如果你的设备NTP没配好，日志时间和监控时间差了几个小时，定位线索就全乱了。所以核心设备必须配置NTP同步，这属于基本功。
第三，抓包抓“方向”。在核心设备上抓包，你要清楚抓的是哪个方向的流量：入方向、出方向还是双向。镜像一个上联口时，如果只镜像了RX方向，而异常流量正好在TX方向，那抓半天也是白抓。
第四，CPU高不一定等于流量大。有的设备CPU高是因为路由协议的hello超时不断触发重算，实际流量本身并不大。所以看到CPU高，不要条件反射去加带宽，先查进程，看看到底是IP Input高，还是某个路由进程高，两者处理思路完全不同。
第五，注意“备用”设备也可能是故障源。主备架构里，备用设备看似没接业务，但它的状态同步、健康检查一样会消耗资源。如果备用设备故障，导致频繁的主备切换，照样会把业务打断。所以在排查时，主设备和备用设备的状态都要看。
4.3 几个我认为最值得养成的好习惯
每次处理完核心故障后，我都会花点时间把这次故障的完整经过写下来，包括故障时间、现象、排查步骤、根因、处置动作、遗留风险。别嫌麻烦，这不仅是给他人的参考，更是给自己建立“故障直觉”的素材库。很多有经验的工程师一看现象就能猜个八九不离十，不是因为天赋，而是因为他们见过足够多的案例。
另一个习惯是定期做“带外巡检”。不要等到监控告警了才登录设备。我习惯每季度对核心设备做一次全量checklist检查，内容包括：配置文件备份是否最新、固件版本是否有已知Bug、风扇状态、光模块光衰趋势、日志缓冲区占用、表项利用率等。这些事情要花时间，但比起故障后熬夜排障的成本，这点时间几乎可以忽略。
5. 长期主线的思考：让核心节点学会“自证清白”
回到标题那个问题：核心节点为啥总崩？说到底，是因为它的定位决定了它必须承受所有流量和风险。我们改变不了它的角色，但可以改变它暴露在风险下的方式。我越来越觉得，排障的真正分水岭不是“出了问题能不能快速恢复”，而是“能不能在出问题之前就提前感知，并在问题发生后快速找到证据链”。这就是监控、巡检、配置基线这些东西的真正价值。
针对核心节点的长期运维，有几条主线值得提前铺好。一是监控体系的完善，把光功率、表项数、日志关键字这些容易被忽略的指标纳入监控范围。二是冗余设计的彻底化，链路要冗余、设备要冗余、电源要冗余，连光模块的型号都要尽量统一，备件库要清晰。三是自动化能力的逐步引入，比如把常规巡检做成脚本，定期比对配置差异，甚至做配置回滚。很多事故其实是配置变更引起的，而不是设备本身坏了。
再往深一步说，核心节点故障的定位还有一个很实用的思路，就是“让设备自证清白”。什么意思？比如有人报障说核心设备有问题，你先用show clock和show version确认时间对不对、设备已经运行多久了，如果运行时间长达几个月、且重启记录显示没有异常重启，那么起码能排除设备重启和系统崩溃的可能。再比如，有人说网络慢，你把核心上的丢包率数据拉出来，如果接口无错误、无丢包、CPU正常，那问题大概率不在核心而在链路或应用侧。用数据说话，而不是用感觉打架，是高级工程师和普通运维最大的区别。
这篇文章的很多案例和经验，都是我一步步踩坑踩出来的。现在每次群里再发“核心崩了”，我不像以前那么慌了，因为我知道任何故障都是有迹可循的。按着硬件、协议、配置、流量这四类方向走，配合命令、抓包、监控三种手段，再套用分层、二分、对比的思路，大概率能在半小时内把范围缩小到“某个接口”甚至“某台设备”。核心排障没有银弹，有的只是一遍遍的练习和复盘。希望这篇文章能给你一些参考，让你在下一次“核心崩了”的时候，多一分从容，少一分手忙脚乱。
