干网络排障这行总有新手拿着抓包软件问我这显示的到底是“包”还是“帧”还有人会把“链路层”和“网络层”混在一起分析结果过滤条件写错、判断方向跑偏查了半天才发现看的是不同层面的东西。这个困惑太常见了所以我想围绕“从帧到包”这条主线把链路层与局域网通信的核心机制掰开揉碎讲一遍讲清楚帧是什么、包是什么、MAC怎么寻址、交换机怎么转发、ARP怎么工作以及真正动手排查二层问题时应该从哪里下手。这篇文章适合刚接触网络基础、正在学抓包排障或者对局域网通信机制一知半解想系统梳理一遍的人。1. 帧与包先把这个概念理清楚后面才不白忙活1.1 帧和包到底差在哪——从一次抓包说起很多人第一次用抓包工具看到一行一行的记录习惯性地说“抓到一个包”。其实严格来讲抓包软件在网卡上收到的每一个条目是一个“帧”。帧是链路层的协议数据单元而“包”或者说“数据报”严格对应的是网络层IP层的协议数据单元。关键区别在于IP包是“内容”帧是“包装”。当你的电脑要发送一个IP数据报时这个数据报会往下传给链路层链路层在它前面加上目的MAC地址、源MAC地址、类型字段在它后面加上帧校验序列然后才交给物理层变成比特流发出去。接收端收到后先把帧头帧尾剥离把中间的IP数据报提取出来再往上交给网络层处理。我用快递来打个比方IP包是你要寄的那本书帧是快递公司给它套上的纸箱、填的快递单、贴的封条。书的内容是网络层关心的纸箱和快递单是链路层关心的。寄件人和收件人看的是书快递员只看纸箱上的地址。这个理解直接影响实际排障。比如在抓包工具里你想过滤某个设备的流量如果知道的是IP地址就用ip.addr如果你知道的是MAC地址就得用eth.addr。很多人搞错过滤条件其实根子就在于没分清自己要看的是“包”还是“帧”。有一次排查一个二层环路问题对方一直用ip.addr过滤找源IP结果看到大量来源相同、目的不同的广播帧实际上问题出在链路层该用eth.addr或直接看二层头部才对。1.2 分层的本质每一层只干自己该干的事为什么非要区分得这么细因为网络通信本身就是分层的。OSI七层模型也好TCP/IP四层模型也好核心思想都是“每一层只解决自己那一层的难题把其他问题交给上下层”。链路层解决的是“相邻节点之间怎么把比特流安全可靠地送到对端”。这里的“相邻节点”指的是物理上直连或者在同一个二层广播域内的设备。链路层根本不关心数据要去哪个城市、走哪条路它只负责把这一“车货”交到下一站。而网络层解决的是“数据怎么在多个网络之间找到路径”它需要全局的拓扑信息通过IP地址来寻址。理解这一点很多现象就说得通了。比如两个不同网段的设备即使连着同一台交换机也不能直接用MAC地址通信因为交换机只知道“网线插在哪个口”不知道“IP地址对应的路径”。跨网段通信必须经过网关也就是路由器由网络层做路由决策再把包交给下一个链路的链路层重新封装成新的帧。有个典型的认知误区是认为交换机是“智能转发设备”所以它能理解IP。实际上交换机主要工作在链路层它看的是MAC地址对IP地址最多做一点“顺带看一眼”的工作比如某些三层交换机的某些功能。真正理解IP、做路由决策的是路由器或三层设备。明白这个分工排障时就不会拿着一台交换机非要查IP路由表了。2. 链路层核心机制拆解MAC、FCS与封装2.1 以太网帧格式从比特流到帧结构以太网是链路层最常见的实现方式它的帧结构很值得逐字段拆一遍。一个标准的以太网II帧物理层会先发出7字节的前导码全10101010的交替序列和1字节的帧起始定界符用来让接收方同步时钟、确认帧的开始。然后才是真正的帧本体字段长度说明目的MAC地址6字节接收方的物理地址源MAC地址6字节发送方的物理地址EtherType2字节表示上层协议如0x0800是IPv4、0x86DD是IPv6、0x0806是ARP数据46-1500字节网络层下发的数据报帧校验序列FCS4字节CRC-32校验值用于检测传输错误这里面有几个数字值得记住。数据段最小是46字节最大是1500字节这1500就是常说MTU。如果IP包太小链路层会补零到46字节如果IP包太大超过1500就需要分片。整个帧加上14字节的头部和4字节的尾部最小是64字节最大是1518字节。如果交换机端口开启了VLAN功能会在源MAC和EtherType之间插入4字节的802.1Q标签最大帧就变成1522字节。为什么数据段非得有最小46字节这是从历史沿袭下来的老规矩。早期以太网是共享介质、半双工工作用CSMA/CD协议来避免冲突。一个站点发送数据后如果发生冲突必须在这个帧的传输过程中就能检测到否则这个帧就被确认“成功发送”了。为了保证在最远的网络距离上也能检测到冲突规定帧长不能小于64字节。所以即使上层数据很少也要填充到46字节。今天全双工交换网络已经不存在冲突域了但这个最小帧长约束仍然保留。2.2 MAC地址寻址局域网内的“门牌号”规则MAC地址是链路层寻址的基础一共48位写作12个十六进制字符比如00:1A:2B:3C:4D:5E。它分成两部分前24位是厂商代码OUI由IEEE分配给网卡制造商后24位是厂商自己分配的序列号理论上全球唯一。实际操作中虚拟机和部分网卡支持修改MAC但同一局域网内MAC冲突还是会真实影响通信。MAC地址的第一个字节里最低位第8位表示单播/多播0是单播1是多播。全1的48位FF:FF:FF:FF:FF:FF是广播地址表示发给同一广播域内的所有设备。还有一个很容易忽略的字段是“本地管理位”也就是第一个字节的倒数第二位0表示全球唯一由厂商分配1表示本地自行管理。Windows下手动修改网卡MAC后常会看到第二位变成1。交换机转发数据靠的就是一张MAC地址表。这张表的核心内容是“MAC地址”和“端口”的对应关系。那MAC表是怎么建起来的不是配置出来的是交换机自己学习的。后面我会细说它的工作过程。2.3 FCS与CRC怎么知道一帧数据有没有坏帧尾巴上的4字节FCS用的是CRC-32算法。这个算法把整个帧不含前导码和FCS本身看作一个巨大的二进制数除以一个固定的生成多项式0x04C11DB7反射形式是0xEDB88320余数作为校验值附在帧尾。接收方收到帧后用同样的方式重新计算如果计算出的余数是0说明数据在传输中没有被篡改如果不是0说明这一帧坏了直接丢弃由上层协议比如TCP的重传机制负责补救。CRC-32的检错能力非常强它能检测出所有奇数个比特错误、所有长度不超过32比特的突发错误以及绝大多数更长的突发错误。但要注意它并不能纠正错误检测出错误后只能丢弃。这也是链路层“尽力而为”的表现——它保证的是“收到的帧大概率是完整的”但不保证“一定能送达”。如果抓包时看到大量“bad FCS”或者“frame check sequence”错误基本可以断定物理链路有问题可能是网线老化、水晶头接触不良、光模块信号衰减或者两端双工模式不匹配。这种问题在网络层是看不出来的因为IP层根本看不到FCS只有在链路层抓原始帧才能发现。3. 局域网通信是怎么“找到对方”的——ARP与交换机工作机制3.1 ARP的完整工作链路局域网里两台主机通信网络层用的是IP地址可链路层转发帧只认MAC地址。那怎么把IP地址翻译成MAC地址这个翻译工作就是ARP协议干的。我拿一个最经典的场景走一遍主机AIP为192.168.1.10第一次要ping主机BIP为192.168.1.20。A知道B的IP但不知道B的MAC于是A先查自己的ARP缓存表发现没有B的映射。A在网络层构造好ICMP请求包之后要先解决“把包封装进什么MAC帧里”。它不知道B的MAC于是发一个ARP请求源MAC是A自己的目的MAC是FF:FF:FF:FF:FF:FF内容大致是“谁的IP是192.168.1.20请把你的MAC地址告诉192.168.1.10”。这个广播请求进入交换机交换机发现目的MAC是广播地址就把这个帧从除接收端口以外的所有端口转发出去。所以同一广播域内的所有设备都会受到这个请求。主机B收到后发现问的是自己就回应一个ARP应答这是单播帧目的MAC是A的MAC内容就是“192.168.1.20的MAC是XX:XX:XX:XX:XX:XX”。A收到应答把IP和MAC的映射写入ARP缓存然后才真正发出那个ICMP echo请求。这个过程中容易忽略一个细节B在收到A的ARP请求时会把“192.168.1.10对应A的MAC”也写进自己的ARP缓存。为什么因为B马上要回ARP应答回完以后大概率还要跟A通信提前学一步能省一次广播请求。这里还有几个ARP相关的知识点值得讲。第一ARP缓存是有老化时间的Windows系统一般是2到10分钟Linux系统常见是30秒左右不同系统差异很大这会导致首次通信偶尔延迟或抓包时看到定期的ARP请求再刷新。第二免费ARPGratuitous ARP指主机启动或者IP地址变更后主动广播一个ARP请求来询问自己的IP目的不是让别人回答而是告诉整个广播域“这个IP现在归我用了”同时用于检测IP地址冲突。如果你抓包看到某台主机反复发免费ARP那很可能是在抢IP或者在宣告主备切换。还有一种情况很常见主机A要访问另一个子网的主机C它发现C不在自己的网段内于是不直接请求C的MAC而是把包交给默认网关。这时A发出的ARP请求问的是网关的MAC地址而不是C的MAC。很多人一抓包发现目标全在问网关还以为有问题其实这是完全正常的行为。3.2 交换机是如何学习和转发帧的交换机是局域网通信的核心设备我来还原一台交换机从零开始学习的过程。假设一台交换机刚上电MAC地址表是空的。某天主机A从端口1发来一个帧目的MAC是主机B。交换机会做三件事学习把“源MAC A的MAC”记录到表中并绑定端口1。这样以后任何发往A的帧交换机都知道该从端口1出去。查表交换机查找目的MAC在不在自己的MAC地址表里。转发决策如果表里有目的MAC的记录交换机就把帧从对应的端口转发出去这叫“精确转发”。如果表里没有说明交换机还不知道目的设备在哪它就把帧从除了接收端口以外的所有端口复制一份发出去这叫“泛洪”。接下来主机B收到帧回复给主机A。交换机从端口2收到B的回包又学到“B的MAC对应端口2”。等下一轮A发给B时交换机查表发现B已经在端口2了就只往端口2发不再泛洪。这里有几个细节容易踩坑。一是MAC地址表的条目不永久有效通常老化时间是300秒约5分钟如果这期间设备不再发帧交换机就删掉这个条目下次通信又要重新泛洪。这是正常的不是故障。二是有一种情况要特别警惕如果交换机从端口1收到一个源MAC的帧而MAC表里这个源MAC恰好已经对应端口1那就刷新一下老化时间但要是表里记录这个MAC对应端口2端口1却又收到了同样源MAC的帧这就是“MAC地址漂移”说明网络里可能存在环路或者有人插了不该插的线。三是交换机对广播帧、组播帧的处理只要目的MAC是多播或广播地址交换机一律泛洪。所以在抓包时看到大量广播帧并不稀奇但如果广播流量异常高、甚至占到总流量的百分之三四十就要怀疑是不是有二层环路、ARP攻击或者某些设备在疯狂重传。四是交换机MAC表容量有限如果表被恶意MAC泛洪攻击塞满交换机会进入“故障保护”模式对所有未知单播帧都泛洪整个局域网效率直线下降严重时跟用集线器没区别。这也是二层安全里必须做端口MAC限制port-security的原因。4. 实战排查链路层问题怎么定位4.1 抓包如何区分帧与包聊天讨论了不少理论现在上点实操。真正到了抓包排障的时候第一个要明确的还是“我到底该看帧还是看包”。在抓包软件里默认每一行记录本质上是一个帧。这行的“Length”字段指的是整个以太网帧的长度包含14字节的链路层头部和末尾的4字节FCS。所以你看到的IP包大小和帧大小之间总是差着18字节。如果你看到帧大小是1518说明IP包几乎塞满了1500字节的MTU如果你看到帧大小是64字节那是一个最小的以太网帧里面往往只装了极少量数据比如TCP ACK再加上各种可选头部就刚好凑到64字节。排查链路层问题时我习惯这样操作先用eth.addr 某个MAC过滤只观察这台设备的二层流量。如果怀疑ARP异常直接加过滤条件arp一眼就能看出谁在发大量ARP请求。检查是否有“Duplicate IP address detected”之类的提示这种报文通常是免费ARP冲突检测发出来的。再看是否有Bad checksum或FCS错误提示如果频繁出现基本锁定物理层问题。结合帧长度做统计大量长度64字节的小帧往往是控制报文ARP、TCP ACK或者协议探测大量1518字节的大帧说明在跑大流量传输。有一个真实案例某单位网络隔一阵就卡顿几分钟抓包一看交换机上有一台设备在不断向一个已经不存在的单播MAC地址发送大量帧目的MAC在MAC表里查不到交换机只能不停泛洪占满了下行带宽。从网络层看这些帧没有对应任何正常的IP会话纯属底层异常从链路层看帧长度、格式也没问题就是目的MAC地址“没人要”。最后找到那台设备发现是一个业务系统的后台服务在向旧网关地址发心跳配置更新后问题消失。这个排查的关键点在于不要一上来就看IP先把目的MAC放进MAC表里查一查。4.2 MAC地址表与环路问题二层环路是局域网里非常经典的故障。环路产生的原因通常是把交换机的两根线做了冗余连接却没启用生成树协议STP/RSTP或者生成树被误关闭。环路一旦出现广播帧会在环路里无限循环转发形成“广播风暴”整个局域网几乎瘫痪。排查二层环路的思路我按优先级整理如下看交换机CPU负载如果CPU利用率飙升先怀疑环路或攻击。看MAC地址表是否出现漂移连续多次执行查看MAC表的命令如果发现同一个MAC不断在不同端口之间跳动基本可以肯定是环路。抓包统计广播帧和未知单播帧数量如果数量异常大说明有帧在循环。检查生成树状态确认端口是否处于转发或阻塞状态看看有没有端口一直不停切换状态。用物理手段二分定位拔掉可疑链路观察广播流量是否下降。这个方法粗暴但有效排查环路时往往比理论分析更快。说一个我踩过的坑实验室里为了冗余用两根网线把两台交换机连起来忘了开STP结果整个实验网广播帧爆炸远程设备全部失联。到现场一看交换机端口指示灯疯狂闪烁用命令看MAC表出现大量漂移记录。最后拔掉一根线网络瞬间恢复。这个案例说明STP不是可选项是必须项。现在新交换机默认可能开启RSTP但很多改过配置的设备会把生成树关掉所以确认环境时需要自己检查一下。4.3 常见问题速查表现象可能原因优先排查手段同网段主机ping不通ARP解析失败、IP冲突先看arp -a有无对端条目再抓包看有无ARP应答全网广播流量异常高二层环路、MAC泛洪攻击查交换机MAC表漂移、检查STP状态、拔线二分大流量传输频繁中断FCS错误增多、双工模式不匹配抓包看bad FCS、检查两端协商速率帧长度超过1518字节MTU设置不一致、巨型帧检查两端MTU、关闭巨型帧或统一配置交换机频繁泛洪MAC表被塞满、老化过快查端口MAC数量、启port-security能上网但内网互相不通VLAN配置错误、端口类型不对检查access/trunk端口与VLAN划分还有一个排查小技巧想分享当你觉得问题可能出在二层时先不要急着分析IP层。拿一台电脑接在交换机上用arp -a看网关、看目标机的MAC解析情况。如果ARP表里根本没有对方条目就说明二层解析阶段已经失败了再往上分析IP层纯属浪费时间。如果ARP有条目但依然不通那再看看是不是端口安全、VLAN隔离等策略拦住了。这个顺序能帮你省掉很多无效排查。我个人做实验的时候还有个习惯每次搭完二层环境第一件事就是清空所有设备的ARP缓存和交换机的动态MAC表让整个网络“从零开始”学习一遍。这样做的好处是能观察到最完整的学习过程排查问题时也能排除旧缓存带来的干扰。尤其在模拟器和实验平台里这个操作只要几条命令就能完成但对理解“从帧到包”的整个过程帮助特别大。最后再聊一点实际感触。链路层的坑往往不像应用层那么直观它藏得深一出问题影响面却极大。但只要你盯着“帧”不放——看目的MAC、看FCS、看交换机的MAC表——大部分问题都能找到源头。网络这东西分层理解得越透排障越有底气。 
长河君 · 2026/10/19 15:13:47 · 阅读 1.2k 从帧到包：链路层与局域网通信排查实战指南
干网络排障这行总有新手拿着抓包软件问我这显示的到底是“包”还是“帧”还有人会把“链路层”和“网络层”混在一起分析结果过滤条件写错、判断方向跑偏查了半天才发现看的是不同层面的东西。这个困惑太常见了所以我想围绕“从帧到包”这条主线把链路层与局域网通信的核心机制掰开揉碎讲一遍讲清楚帧是什么、包是什么、MAC怎么寻址、交换机怎么转发、ARP怎么工作以及真正动手排查二层问题时应该从哪里下手。这篇文章适合刚接触网络基础、正在学抓包排障或者对局域网通信机制一知半解想系统梳理一遍的人。1. 帧与包先把这个概念理清楚后面才不白忙活1.1 帧和包到底差在哪——从一次抓包说起很多人第一次用抓包工具看到一行一行的记录习惯性地说“抓到一个包”。其实严格来讲抓包软件在网卡上收到的每一个条目是一个“帧”。帧是链路层的协议数据单元而“包”或者说“数据报”严格对应的是网络层IP层的协议数据单元。关键区别在于IP包是“内容”帧是“包装”。当你的电脑要发送一个IP数据报时这个数据报会往下传给链路层链路层在它前面加上目的MAC地址、源MAC地址、类型字段在它后面加上帧校验序列然后才交给物理层变成比特流发出去。接收端收到后先把帧头帧尾剥离把中间的IP数据报提取出来再往上交给网络层处理。我用快递来打个比方IP包是你要寄的那本书帧是快递公司给它套上的纸箱、填的快递单、贴的封条。书的内容是网络层关心的纸箱和快递单是链路层关心的。寄件人和收件人看的是书快递员只看纸箱上的地址。这个理解直接影响实际排障。比如在抓包工具里你想过滤某个设备的流量如果知道的是IP地址就用ip.addr如果你知道的是MAC地址就得用eth.addr。很多人搞错过滤条件其实根子就在于没分清自己要看的是“包”还是“帧”。有一次排查一个二层环路问题对方一直用ip.addr过滤找源IP结果看到大量来源相同、目的不同的广播帧实际上问题出在链路层该用eth.addr或直接看二层头部才对。1.2 分层的本质每一层只干自己该干的事为什么非要区分得这么细因为网络通信本身就是分层的。OSI七层模型也好TCP/IP四层模型也好核心思想都是“每一层只解决自己那一层的难题把其他问题交给上下层”。链路层解决的是“相邻节点之间怎么把比特流安全可靠地送到对端”。这里的“相邻节点”指的是物理上直连或者在同一个二层广播域内的设备。链路层根本不关心数据要去哪个城市、走哪条路它只负责把这一“车货”交到下一站。而网络层解决的是“数据怎么在多个网络之间找到路径”它需要全局的拓扑信息通过IP地址来寻址。理解这一点很多现象就说得通了。比如两个不同网段的设备即使连着同一台交换机也不能直接用MAC地址通信因为交换机只知道“网线插在哪个口”不知道“IP地址对应的路径”。跨网段通信必须经过网关也就是路由器由网络层做路由决策再把包交给下一个链路的链路层重新封装成新的帧。有个典型的认知误区是认为交换机是“智能转发设备”所以它能理解IP。实际上交换机主要工作在链路层它看的是MAC地址对IP地址最多做一点“顺带看一眼”的工作比如某些三层交换机的某些功能。真正理解IP、做路由决策的是路由器或三层设备。明白这个分工排障时就不会拿着一台交换机非要查IP路由表了。2. 链路层核心机制拆解MAC、FCS与封装2.1 以太网帧格式从比特流到帧结构以太网是链路层最常见的实现方式它的帧结构很值得逐字段拆一遍。一个标准的以太网II帧物理层会先发出7字节的前导码全10101010的交替序列和1字节的帧起始定界符用来让接收方同步时钟、确认帧的开始。然后才是真正的帧本体字段长度说明目的MAC地址6字节接收方的物理地址源MAC地址6字节发送方的物理地址EtherType2字节表示上层协议如0x0800是IPv4、0x86DD是IPv6、0x0806是ARP数据46-1500字节网络层下发的数据报帧校验序列FCS4字节CRC-32校验值用于检测传输错误这里面有几个数字值得记住。数据段最小是46字节最大是1500字节这1500就是常说MTU。如果IP包太小链路层会补零到46字节如果IP包太大超过1500就需要分片。整个帧加上14字节的头部和4字节的尾部最小是64字节最大是1518字节。如果交换机端口开启了VLAN功能会在源MAC和EtherType之间插入4字节的802.1Q标签最大帧就变成1522字节。为什么数据段非得有最小46字节这是从历史沿袭下来的老规矩。早期以太网是共享介质、半双工工作用CSMA/CD协议来避免冲突。一个站点发送数据后如果发生冲突必须在这个帧的传输过程中就能检测到否则这个帧就被确认“成功发送”了。为了保证在最远的网络距离上也能检测到冲突规定帧长不能小于64字节。所以即使上层数据很少也要填充到46字节。今天全双工交换网络已经不存在冲突域了但这个最小帧长约束仍然保留。2.2 MAC地址寻址局域网内的“门牌号”规则MAC地址是链路层寻址的基础一共48位写作12个十六进制字符比如00:1A:2B:3C:4D:5E。它分成两部分前24位是厂商代码OUI由IEEE分配给网卡制造商后24位是厂商自己分配的序列号理论上全球唯一。实际操作中虚拟机和部分网卡支持修改MAC但同一局域网内MAC冲突还是会真实影响通信。MAC地址的第一个字节里最低位第8位表示单播/多播0是单播1是多播。全1的48位FF:FF:FF:FF:FF:FF是广播地址表示发给同一广播域内的所有设备。还有一个很容易忽略的字段是“本地管理位”也就是第一个字节的倒数第二位0表示全球唯一由厂商分配1表示本地自行管理。Windows下手动修改网卡MAC后常会看到第二位变成1。交换机转发数据靠的就是一张MAC地址表。这张表的核心内容是“MAC地址”和“端口”的对应关系。那MAC表是怎么建起来的不是配置出来的是交换机自己学习的。后面我会细说它的工作过程。2.3 FCS与CRC怎么知道一帧数据有没有坏帧尾巴上的4字节FCS用的是CRC-32算法。这个算法把整个帧不含前导码和FCS本身看作一个巨大的二进制数除以一个固定的生成多项式0x04C11DB7反射形式是0xEDB88320余数作为校验值附在帧尾。接收方收到帧后用同样的方式重新计算如果计算出的余数是0说明数据在传输中没有被篡改如果不是0说明这一帧坏了直接丢弃由上层协议比如TCP的重传机制负责补救。CRC-32的检错能力非常强它能检测出所有奇数个比特错误、所有长度不超过32比特的突发错误以及绝大多数更长的突发错误。但要注意它并不能纠正错误检测出错误后只能丢弃。这也是链路层“尽力而为”的表现——它保证的是“收到的帧大概率是完整的”但不保证“一定能送达”。如果抓包时看到大量“bad FCS”或者“frame check sequence”错误基本可以断定物理链路有问题可能是网线老化、水晶头接触不良、光模块信号衰减或者两端双工模式不匹配。这种问题在网络层是看不出来的因为IP层根本看不到FCS只有在链路层抓原始帧才能发现。3. 局域网通信是怎么“找到对方”的——ARP与交换机工作机制3.1 ARP的完整工作链路局域网里两台主机通信网络层用的是IP地址可链路层转发帧只认MAC地址。那怎么把IP地址翻译成MAC地址这个翻译工作就是ARP协议干的。我拿一个最经典的场景走一遍主机AIP为192.168.1.10第一次要ping主机BIP为192.168.1.20。A知道B的IP但不知道B的MAC于是A先查自己的ARP缓存表发现没有B的映射。A在网络层构造好ICMP请求包之后要先解决“把包封装进什么MAC帧里”。它不知道B的MAC于是发一个ARP请求源MAC是A自己的目的MAC是FF:FF:FF:FF:FF:FF内容大致是“谁的IP是192.168.1.20请把你的MAC地址告诉192.168.1.10”。这个广播请求进入交换机交换机发现目的MAC是广播地址就把这个帧从除接收端口以外的所有端口转发出去。所以同一广播域内的所有设备都会受到这个请求。主机B收到后发现问的是自己就回应一个ARP应答这是单播帧目的MAC是A的MAC内容就是“192.168.1.20的MAC是XX:XX:XX:XX:XX:XX”。A收到应答把IP和MAC的映射写入ARP缓存然后才真正发出那个ICMP echo请求。这个过程中容易忽略一个细节B在收到A的ARP请求时会把“192.168.1.10对应A的MAC”也写进自己的ARP缓存。为什么因为B马上要回ARP应答回完以后大概率还要跟A通信提前学一步能省一次广播请求。这里还有几个ARP相关的知识点值得讲。第一ARP缓存是有老化时间的Windows系统一般是2到10分钟Linux系统常见是30秒左右不同系统差异很大这会导致首次通信偶尔延迟或抓包时看到定期的ARP请求再刷新。第二免费ARPGratuitous ARP指主机启动或者IP地址变更后主动广播一个ARP请求来询问自己的IP目的不是让别人回答而是告诉整个广播域“这个IP现在归我用了”同时用于检测IP地址冲突。如果你抓包看到某台主机反复发免费ARP那很可能是在抢IP或者在宣告主备切换。还有一种情况很常见主机A要访问另一个子网的主机C它发现C不在自己的网段内于是不直接请求C的MAC而是把包交给默认网关。这时A发出的ARP请求问的是网关的MAC地址而不是C的MAC。很多人一抓包发现目标全在问网关还以为有问题其实这是完全正常的行为。3.2 交换机是如何学习和转发帧的交换机是局域网通信的核心设备我来还原一台交换机从零开始学习的过程。假设一台交换机刚上电MAC地址表是空的。某天主机A从端口1发来一个帧目的MAC是主机B。交换机会做三件事学习把“源MAC A的MAC”记录到表中并绑定端口1。这样以后任何发往A的帧交换机都知道该从端口1出去。查表交换机查找目的MAC在不在自己的MAC地址表里。转发决策如果表里有目的MAC的记录交换机就把帧从对应的端口转发出去这叫“精确转发”。如果表里没有说明交换机还不知道目的设备在哪它就把帧从除了接收端口以外的所有端口复制一份发出去这叫“泛洪”。接下来主机B收到帧回复给主机A。交换机从端口2收到B的回包又学到“B的MAC对应端口2”。等下一轮A发给B时交换机查表发现B已经在端口2了就只往端口2发不再泛洪。这里有几个细节容易踩坑。一是MAC地址表的条目不永久有效通常老化时间是300秒约5分钟如果这期间设备不再发帧交换机就删掉这个条目下次通信又要重新泛洪。这是正常的不是故障。二是有一种情况要特别警惕如果交换机从端口1收到一个源MAC的帧而MAC表里这个源MAC恰好已经对应端口1那就刷新一下老化时间但要是表里记录这个MAC对应端口2端口1却又收到了同样源MAC的帧这就是“MAC地址漂移”说明网络里可能存在环路或者有人插了不该插的线。三是交换机对广播帧、组播帧的处理只要目的MAC是多播或广播地址交换机一律泛洪。所以在抓包时看到大量广播帧并不稀奇但如果广播流量异常高、甚至占到总流量的百分之三四十就要怀疑是不是有二层环路、ARP攻击或者某些设备在疯狂重传。四是交换机MAC表容量有限如果表被恶意MAC泛洪攻击塞满交换机会进入“故障保护”模式对所有未知单播帧都泛洪整个局域网效率直线下降严重时跟用集线器没区别。这也是二层安全里必须做端口MAC限制port-security的原因。4. 实战排查链路层问题怎么定位4.1 抓包如何区分帧与包聊天讨论了不少理论现在上点实操。真正到了抓包排障的时候第一个要明确的还是“我到底该看帧还是看包”。在抓包软件里默认每一行记录本质上是一个帧。这行的“Length”字段指的是整个以太网帧的长度包含14字节的链路层头部和末尾的4字节FCS。所以你看到的IP包大小和帧大小之间总是差着18字节。如果你看到帧大小是1518说明IP包几乎塞满了1500字节的MTU如果你看到帧大小是64字节那是一个最小的以太网帧里面往往只装了极少量数据比如TCP ACK再加上各种可选头部就刚好凑到64字节。排查链路层问题时我习惯这样操作先用eth.addr 某个MAC过滤只观察这台设备的二层流量。如果怀疑ARP异常直接加过滤条件arp一眼就能看出谁在发大量ARP请求。检查是否有“Duplicate IP address detected”之类的提示这种报文通常是免费ARP冲突检测发出来的。再看是否有Bad checksum或FCS错误提示如果频繁出现基本锁定物理层问题。结合帧长度做统计大量长度64字节的小帧往往是控制报文ARP、TCP ACK或者协议探测大量1518字节的大帧说明在跑大流量传输。有一个真实案例某单位网络隔一阵就卡顿几分钟抓包一看交换机上有一台设备在不断向一个已经不存在的单播MAC地址发送大量帧目的MAC在MAC表里查不到交换机只能不停泛洪占满了下行带宽。从网络层看这些帧没有对应任何正常的IP会话纯属底层异常从链路层看帧长度、格式也没问题就是目的MAC地址“没人要”。最后找到那台设备发现是一个业务系统的后台服务在向旧网关地址发心跳配置更新后问题消失。这个排查的关键点在于不要一上来就看IP先把目的MAC放进MAC表里查一查。4.2 MAC地址表与环路问题二层环路是局域网里非常经典的故障。环路产生的原因通常是把交换机的两根线做了冗余连接却没启用生成树协议STP/RSTP或者生成树被误关闭。环路一旦出现广播帧会在环路里无限循环转发形成“广播风暴”整个局域网几乎瘫痪。排查二层环路的思路我按优先级整理如下看交换机CPU负载如果CPU利用率飙升先怀疑环路或攻击。看MAC地址表是否出现漂移连续多次执行查看MAC表的命令如果发现同一个MAC不断在不同端口之间跳动基本可以肯定是环路。抓包统计广播帧和未知单播帧数量如果数量异常大说明有帧在循环。检查生成树状态确认端口是否处于转发或阻塞状态看看有没有端口一直不停切换状态。用物理手段二分定位拔掉可疑链路观察广播流量是否下降。这个方法粗暴但有效排查环路时往往比理论分析更快。说一个我踩过的坑实验室里为了冗余用两根网线把两台交换机连起来忘了开STP结果整个实验网广播帧爆炸远程设备全部失联。到现场一看交换机端口指示灯疯狂闪烁用命令看MAC表出现大量漂移记录。最后拔掉一根线网络瞬间恢复。这个案例说明STP不是可选项是必须项。现在新交换机默认可能开启RSTP但很多改过配置的设备会把生成树关掉所以确认环境时需要自己检查一下。4.3 常见问题速查表现象可能原因优先排查手段同网段主机ping不通ARP解析失败、IP冲突先看arp -a有无对端条目再抓包看有无ARP应答全网广播流量异常高二层环路、MAC泛洪攻击查交换机MAC表漂移、检查STP状态、拔线二分大流量传输频繁中断FCS错误增多、双工模式不匹配抓包看bad FCS、检查两端协商速率帧长度超过1518字节MTU设置不一致、巨型帧检查两端MTU、关闭巨型帧或统一配置交换机频繁泛洪MAC表被塞满、老化过快查端口MAC数量、启port-security能上网但内网互相不通VLAN配置错误、端口类型不对检查access/trunk端口与VLAN划分还有一个排查小技巧想分享当你觉得问题可能出在二层时先不要急着分析IP层。拿一台电脑接在交换机上用arp -a看网关、看目标机的MAC解析情况。如果ARP表里根本没有对方条目就说明二层解析阶段已经失败了再往上分析IP层纯属浪费时间。如果ARP有条目但依然不通那再看看是不是端口安全、VLAN隔离等策略拦住了。这个顺序能帮你省掉很多无效排查。我个人做实验的时候还有个习惯每次搭完二层环境第一件事就是清空所有设备的ARP缓存和交换机的动态MAC表让整个网络“从零开始”学习一遍。这样做的好处是能观察到最完整的学习过程排查问题时也能排除旧缓存带来的干扰。尤其在模拟器和实验平台里这个操作只要几条命令就能完成但对理解“从帧到包”的整个过程帮助特别大。最后再聊一点实际感触。链路层的坑往往不像应用层那么直观它藏得深一出问题影响面却极大。但只要你盯着“帧”不放——看目的MAC、看FCS、看交换机的MAC表——大部分问题都能找到源头。网络这东西分层理解得越透排障越有底气。