万兆以太网MAC设计：ARP报文格式与RTL模块实现

1. 先把位置摆正：ARP层在万兆MAC旁边到底管什么

做万兆以太网MAC这件事，做到第七篇才回头补ARP，其实是很典型的工程节奏。前面几篇大概率已经把PHY接口、XGMII收发、CRC校验、帧过滤这些啃完了，链路能起来，包能收发，用回环测试也能跑通，但只要你想让这个MAC真正接到协议栈上、能回应一个ping，ARP这块就必须补上——因为没有ARP，IPv4报文根本发不出去。我这次要聊的就是万兆以太网MAC设计里的ARP层：ARP协议报文格式详解，以及ARP层模块设计在RTL层面怎么落地。这两件事看起来一个是协议、一个是代码，实际上是绑在一起的，报文格式里每一个字节的位置，最终都会变成代码里某个信号的第几位，错一位就抓不到包。

先把适用人群说清楚。这篇内容适合已经能跑通基本以太网帧收发、手上有能工作的MAC核、准备往上叠IPv4协议栈的开发者；也适合做网络测试设备、做自研网卡、做工业实时以太网终端的同学。如果你还没做过MAC，看这篇会有点吃力，但报文格式那部分依然能看懂，因为ARP是少数几个用肉眼看十六进制就能完全读明白的协议，非常适合拿来建立“协议到硬件”的映射直觉。

我个人的判断是：ARP是整个以太网协议族里性价比最高的练手对象。它足够简单——固定28字节、没有选项字段、没有分片、没有校验和；又足够完整——涉及广播、单播、缓存、超时重传、请求应答配对，一个小协议把网络层设计的核心套路全占了。你在ARP上把状态机和缓存表写顺了，后面做ICMP、UDP、甚至TCP握手，架构是同一套。

1.1 从一次“ping不通”说起

绝大多数人第一次把MAC跑通之后，做的第一件事就是发一个ARP请求出去，然后等回应。我见过太多卡在这一步的案例：发送侧波形上明明有帧出去，抓包工具也能看到请求帧，但就是没有应答回来。往下查，八成是三个原因之一——报文里某个字段填错了、帧长没填充到最小值被对端悄悄丢掉、或者接收侧根本没把目的MAC是广播的帧放进来。这三个问题，本质上都对应ARP层设计里的一个具体决策点，而不是MAC的锅。

所以我把ARP层的职责划得很清楚：它不碰PHY，不碰XGMII时序，也不管CRC怎么算，那些是MAC的事。ARP层只做四件事——识别进来的帧是不是ARP、解析28字节载荷、查表决定要不要回应、组帧把请求或应答交给MAC发出去。这四个动作对应四个模块，边界清晰，出了问题一眼就能定位到是哪一段。

这里有个容易被忽略的点：ARP层的位置在MAC之上，意味着它拿到的应该是已经剥掉前导码、SFD、FCS的净载荷加以太网头。如果你的MAC核把FCS也算进了用户数据长度里，ARP层解析时长度判断就会多出4字节，表现出来就是“帧长校验永远失败”。这个问题我在两个不同项目里都遇到过，原因都是MAC和上层对“帧长”的定义没对齐。

1.2 职责边界：ARP层该做什么、不该做什么

我习惯在动手写代码之前，先把“不做什么”列出来，这比列“做什么”更能防止后期返工。ARP层不该做的事包括：不做IP路由决策、不做ARP代理（除非明确需要）、不做安全过滤。特别是最后一条，有些设计会让ARP层去判断“这个IP是不是本网段”，这属于网络层的活，放在这里会让模块变成一坨浆糊。

该做的部分，我整理成一张表，方便直接对照着拆分模块：

按这张表切分，模块数量控制在五六个，每个模块的接口信号不超过二十根，后期改需求也只改其中一块。这是我做过的几个网络IP里最舒服的一种切法，比把所有逻辑塞进一个always块强太多，特别是当你要加ARP缓存老化、要加免费ARP宣告、要加多IP别名的时候，模块边界清晰能省下大量调试时间。

1.3 万兆链路给ARP带来的三个新约束

千兆时代的ARP层可以写得很随意，一个8位数据通路，慢慢吞吞解析几十个时钟周期也没人管。到了万兆，情况变了，主要是三个约束。

第一是数据位宽。万兆MAC的用户侧接口常见是64位数据配156.25MHz时钟，正好10Gbps；也有用32位配312.5MHz的。64位意味着一个时钟周期吞8个字节，28字节的ARP载荷只需要4个周期就流完了。这就逼着你必须在4个周期内完成所有字段的提取和判决，没法像8位通路那样一个字节一个字节慢慢挪。

第二是帧起始位置不固定。以太网帧在64位通路上不一定从第0字节开始对齐，前导码和SFD占掉的位置会导致有效载荷起始于任意字节lane。ARP解析必须做字节对齐移位，否则字段提取全乱。这是万兆设计里最典型的坑，我在下面第2.3节会专门展开。

第三是响应延迟的可见性。万兆链路上一个最小帧的传输时间只有五十多纳秒，如果你的ARP层用软件轮询的方式处理，延迟会大到对端直接判定超时。硬件实现天然有优势，但前提是你的状态机不能有“等CPU”这种环节，所有判决必须在流水线里完成。

提示：万兆下不要试图用“先存整帧再解析”的笨办法。最小帧加FCS才64字节，缓冲区开销不大，但整帧存储会引入至少8个时钟的额外延迟，而且让组帧和解析的逻辑耦合在一起，后期加VLAN标签就得重写。边收边解析、只缓存需要回应的字段，是更干净的做法。

2. ARP报文格式逐字段拆解与字节序陷阱

报文格式这块，很多资料只给你一张字段表，看完还是不知道怎么往寄存器里填。我的做法是把它拆成“线上长什么样”和“寄存器里怎么摆”两个视角，中间用字节序规则连起来。这一节就把这条链路走通。

2.1 28字节固定头的字段清单与取值

ARP载荷是固定28字节，没有可选字段，这个“固定”对硬件极其友好——长度校验只需要判断等于28，不需要解析TLV。字段依次是：

这张表里有三个细节值得单独说。操作码只认1和2，遇到其他值（比如RARP的3、4）直接丢弃，不要试图“兼容处理”，那会引入意外行为。硬件地址长度和协议地址长度这两个字节看着像废话，但它们是很好的自检点——收到一个HLEN不等于6的包，说明对端不是以太网，直接扔，比后面按6字节解析出一堆垃圾要安全得多。请求帧里的目标MAC字段，标准里没强制要求填什么，实践中填全0最常见，也有填全F的，所以应答逻辑绝对不能拿这个字段做判断依据，必须用发送方字段来组帧，这一点我在早期版本里就写错过。

关于发送方MAC与以太网头源MAC是否必须一致，标准是这么要求的，但现实里确实有不一致的情况（比如某些代理实现）。我的处理策略是：解析时把两者都取出来，以ARP载荷里的发送方MAC为准组应答帧，同时把不一致这个事件挂一个统计计数器，方便排查问题。这样既不影响互通，又能留下诊断线索。

2.2 以太网封装：14字节头、18字节填充与FCS的位置关系

ARP帧的完整结构是：前导码7字节 + SFD 1字节 + 以太网头14字节 + ARP载荷28字节 + 填充18字节 + FCS 4字节。注意这里的顺序，填充在载荷之后、FCS之前。

为什么是18字节填充？因为以太网最小帧长规定是64字节（不含前导码和SFD），而14 + 28 = 42字节，42 + 4(FCS) = 46，距离64还差18字节。所以ARP帧必须补18个0字节，才能凑够最小帧。这个规则在千兆时代就存在，很多人没在意是因为大多数交换机和网卡都能容忍短帧；但在万兆设备上，尤其是某些严格实现的交换芯片，短帧会被直接计入错误统计并丢弃。我吃过这个亏——一对设备互通正常，换到另一台设备上就是不通，最后抓包发现就是帧长差了18字节。

以太网头的14字节是：目的MAC 6字节 + 源MAC 6字节 + EtherType 2字节。ARP的EtherType是0x0806，这个值必须写对，写成0x0800就成了IP包，对端会按IP解析，直接丢弃。请求帧的目的MAC是全F广播地址，应答帧的目的MAC是请求方的MAC，这是单播和广播的分界线，也是接收侧过滤逻辑的关键依据。

FCS的位置很明确，在最后4字节，由MAC层计算并附加。ARP层交付给MAC的应该是“以太网头 + 载荷 + 填充”这三部分，长度是60字节，MAC再加上FCS变成64字节。如果你的架构里MAC层要求上层交完整帧含FCS，那ARP层就要自己算CRC32，这会多消耗资源。我的建议是让MAC统一管FCS，ARP层只管内容，职责更清楚。

注意：填充的18个字节内容必须是0，不要填随机值。虽然大多数接收端不看填充内容，但某些做严格校验的实现会把非零填充当作异常。填0是最省事也是最安全的做法。

2.3 64位数据通路上的字节摆放与对齐移位

这一段是整篇里最“硬件”的部分，也是最容易出问题的地方。假设你的通路是64位数据加8位控制（每比特对应一个字节是否有效，类似XGMII的形态），那么一个字节流在总线上是这样摆的：字节0放在data[7:0]，字节1放在data[15:8]，依此类推，字节7放在data[63:56]。这是最常见的排列，但不同IP核的排列可能相反，动手前必须先确认。

问题在于，以太网帧不一定从字节0那个lane开始。由于前导码和SFD的存在，加上MAC内部可能有的流水线延迟，一帧的第一个字节可能出现在data[15:8]或者data[39:32]。这就需要一个对齐移位逻辑：先找到帧起始标志（SOP）所在的lane索引，然后把后续数据整体左移相应字节数，让字节0落到lane0。

硬件实现上，我一般用两级处理：第一级根据SOP的lane索引打拍记录偏移量，第二级用8选1的字节选择器做移位。因为64位通路一次8字节，而偏移量只有0到7共8种可能，用一个8路×8字节的交叉开关就够了。这个逻辑综合出来大概是几十个LUT，不心疼，但能省掉后面所有字段提取时的偏移计算。

对齐之后的字段提取就简单了。ARP载荷从对齐后的第14字节开始，也就是第三个8字节周期的第6个字节。为了不搞错，我在代码里不用绝对偏移，而是用“周期计数 + 周期内字节索引”的组合，写成参数，改位宽的时候只改参数不动逻辑。

还有一个坑：帧长不足一个完整周期的尾部处理。ARP载荷28字节，从第14字节开始到第41字节结束，跨了第1、2、3、4个周期的部分字节。第4个周期（字节32到39）只用到前10个字节，后面的字节属于填充。如果直接用整周期数据参与校验，会把填充字节也算进载荷长度里。所以长度校验必须基于总长度信号，而不是基于周期数推算。

2.4 字节序：网络大端与寄存器小端的对撞

ARP所有多字节字段都是网络字节序，也就是大端。硬件里最常见的错误是：把发送方IP取出来后，直接存成一个32位寄存器，然后拿去和目标IP比较，结果发现永远不相等，因为比较时一个是字节反序的。

我的处理原则是：在解析模块的出口统一转换成主机字节序，之后的模块一律用主机序处理，不再关心线上怎么排。具体做法是按字节重组——线上偏移14到17依次是IP的最高字节到最低字节，那么寄存器值就是{byte14, byte15, byte16, byte17}，用拼接运算符一行搞定。组帧的时候反过来，把主机序拆成四个字节依次输出。

MAC地址的处理稍有不同，因为它不是数值，而是标识符，理论上不需要转序。但为了后续做缓存表比较方便，我还是会统一成一种表示，比如{b0,b1,b2,b3,b4,b5}按线上顺序拼接，比较时两边都用同样的规则，就不会出错。真正要小心的是别混用——同一个MAC地址，在解析路径和组帧路径里用了不同的拼接顺序，这种bug极难查，因为单看每一段逻辑都是对的。

操作码和硬件类型这类16位字段，同理。我见过有人把操作码写成16'h0100想表示“请求”，结果线上发出去的是0x0001的字节反序，对端看到的是0x0100，直接当成未知操作码丢弃。这种问题抓一次包就能看出来，但前提是你知道要去抓包。

3. ARP层模块的架构设计与状态机划分

模块切分这件事，我越来越倾向于“按数据流方向切”，而不是按功能名称切。ARP层天然是两条流：接收流和发送流，中间用一个缓存表和一个判决逻辑连起来。这一节讲具体怎么分、状态机怎么画、缓存表怎么选。

3.1 顶层接口定义与模块切分

顶层的端口我一般这么定义，尽量窄，够用就行：

module arp_layer #( parameter DATA_W = 64, parameter LOCAL_MAC = 48'h00_11_22_33_44_55, parameter LOCAL_IP = 32'hC0_A8_01_0A, // 192.168.1.10 parameter CACHE_DEPTH = 16, parameter RETRY_MAX = 3, parameter TIMEOUT_MS = 1000 )( input wire clk, input wire rst_n, // 接收侧：来自MAC的净载荷 input wire [DATA_W-1:0] rx_data, input wire [DATA_W/8-1:0] rx_ctrl, input wire rx_sop, input wire rx_eop, input wire [15:0] rx_len, input wire rx_valid, // 发送侧：交付给MAC output reg [DATA_W-1:0] tx_data, output reg [DATA_W/8-1:0] tx_ctrl, output reg tx_sop, output reg tx_eop, output reg [15:0] tx_len, output reg tx_valid, output reg tx_ready_in, // 请求接口：上层要查某个IP的MAC input wire lookup_req, input wire [31:0] lookup_ip, output reg [47:0] lookup_mac, output reg lookup_hit, // 状态与统计 output reg [7:0] stat_req_sent, output reg [7:0] stat_rpl_recv, output reg [7:0] stat_drop );

切分上，我分成四个子模块：arp_rx_parse（接收解析）、arp_cache（缓存表）、arp_tx_build（组帧）、arp_ctrl（判决与调度）。arp_ctrl是大脑，它接收解析结果、查表、决定发应答还是发起请求、管重传计数。这么切的好处是：缓存表可以单独换实现（寄存器堆换成双口RAM），组帧模块可以单独加VLAN支持，互不影响。

tx_ready_in这个信号值得说一下。它其实是MAC给的背压信号，表示发送通路现在能不能收数据。ARP层不能假设MAC永远空闲，必须处理背压——如果MAC正在发一个大包，ARP应答就得等着。等待期间状态机要保持，不能丢帧。这是很多人第一次做时忽略的点，表现是“有时候能ping通有时候不能”，因为刚好撞上MAC忙。

3.2 接收通路状态机：从帧到字段

接收状态机我设计成六态，跑在64位通路上，每个状态对应一个时钟周期左右的处理阶段：

localparam RX_IDLE = 3'd0; // 等SOP localparam RX_HDR = 3'd1; // 取以太网头14字节，判EtherType localparam RX_PAY0 = 3'd2; // 载荷字节0-7：硬件类型/协议类型/长度/操作码 localparam RX_PAY1 = 3'd3; // 载荷字节8-15：发送方MAC前6 + 发送方IP前2 localparam RX_PAY2 = 3'd4; // 载荷字节16-23：发送方IP后2 + 目标MAC前4 localparam RX_PAY3 = 3'd5; // 载荷字节24-27：目标IP + 判决

关键设计点是边收边解析，不缓存整帧。收到EOP的时候，所有字段已经在寄存器里躺好了，判决逻辑可以直接用，输出一个时钟的脉冲决定要不要回应。这样从帧结束到发出应答，延迟可以压到十几个时钟，万兆下完全够用。

有几个细节必须处理。第一，rx_ctrl要逐字节检查，只有有效字节才参与拼接，否则填充字节会污染字段。第二，SOP到EOP之间如果长度不足28+14，直接标记为短帧丢弃，不要进入解析状态。第三，EOP如果和SOP是同一个周期（超短帧），要单独处理，否则状态机会卡死。

我在第一版里犯过一个错：状态机在RX_PAY3里直接做判决并跳转到发送，结果发送模块还没准备好，字段就被下一帧覆盖了。后来改成判决结果先锁存到一个独立的寄存器组，发送模块异步取用，才彻底解决。这个教训是：跨模块传递的数据必须锁存，不能指望对方在你持有数据的时候及时消费。

3.3 发送通路与请求调度：谁先发、发几次、什么时候放弃

发送侧有两类帧要发：应答帧（被动，收到请求就发）和请求帧（主动，上层要查MAC时发）。两类帧格式不同但结构相似，我复用一个组帧状态机，用参数区分。

请求调度是这块的核心。上层调lookup_req要查一个IP，如果缓存命中，直接返回；没命中，就得发ARP请求并等回应。这里有个经典的时序问题：请求发出后，回应可能在几十微秒后到，也可能永远不到。所以需要重传机制。我的做法是：请求发出后启动一个毫秒级计数器，到TIMEOUT_MS没收到应答就重发，重发次数到RETRY_MAX就放弃，返回失败。

计数器位宽要算一下。假设时钟156.25MHz，要计1ms，需要156.25e6 × 1e-3 = 156250个时钟，也就是18位计数器。如果要做1000ms超时，就是156.25e6 × 1 = 1.5625e8，需要28位。位宽不够会导致超时时间严重缩水，表现出来就是“重传太频繁”。我见过有人用16位计数器做秒级超时，溢出后变成几十微秒就重传一次，把对端打懵了。

同一时刻只允许一个未完成的请求，这是简化设计的常见做法。如果上层要查多个IP，用队列排队，一次处理一个。这样做的好处是请求状态机只需要一套超时和重传逻辑，不用管并发。缺点是查表延迟变大，但对ARP这种低频操作完全可接受。

3.4 缓存表：寄存器堆还是双口RAM

缓存表存的是 IP到MAC 的映射，每条记录包含：IP（32位）、MAC（48位）、有效位（1位）、老化计数（若干位）。深度一般16到64条够用，家用设备可能就几条。

深度在16以内，我用寄存器堆加并行比较，一个时钟就能出结果，逻辑资源大概几百个LUT，很划算。深度到64，并行比较的扇入就太大了，这时候换成双口RAM加哈希索引，或者干脆用CAM（如果器件支持）。我实际项目里16条够用，就没上复杂结构。

老化机制有两个思路：定时扫描和懒删除。定时扫描是每隔一段时间遍历所有条目，把超时的清掉，逻辑简单但占一个扫描状态机。懒删除是查表时顺便检查时间戳，超时就当未命中，需要新条目时再覆盖最老的。我更倾向懒删除，因为ARP表大部分时间没人查，定时扫描纯属浪费。

有个细节要注意：覆盖策略。表满的时候来了新IP怎么办？替换最久未使用的，还是直接丢弃？我选的是替换最久未使用的，用一个访问计数器实现，代价很小。如果不替换，表会被早期条目占满，后面新地址永远学不到，表现出来就是“用一阵子之后新设备就连不上了”。

4. 关键实现细节与参数计算

前面讲的是架构，这一节下沉到具体实现。包括解析流水线的写法、组帧时字段怎么填、FCS和填充交给谁做、时间参数怎么算。

4.1 解析流水线的三段式写法

我习惯把解析写成三段流水：字节重组 → 字段提取 → 判决输出。每段一个时钟，中间用寄存器隔开，这样时序好收敛，改起来也好定位。

第一段负责把64位宽的数据按字节拆开，根据SOP的lane索引做对齐移位，输出一个干净的8字节对齐流。这一段是组合逻辑最重的地方，8路选择器加上有效性判断，综合后大概两三级LUT，问题不大。

第二段按周期计数提取字段。用计数器byte_cnt记录当前是帧内第几个字节，用case语句按周期分段处理。比如第2个周期（字节14到21）对应载荷的0到7，包含硬件类型、协议类型、两个长度字节和操作码；第3个周期（字节22到29）对应载荷8到15，包含发送方MAC全部6字节和发送方IP的高2字节。这种按周期切分的方式比逐字节更省资源，因为一个周期处理8个字节，四个周期就完了。

第三段做判决：检查硬件类型是不是1、协议类型是不是0x0800、两个长度字段是不是6和4、操作码是不是1或2、目标IP是不是本机IP。全部通过且是请求，就触发应答；是应答，就更新缓存表。这一段全是组合判断，输出一个脉冲给控制模块。

写的时候有个小技巧：把“是否本机IP”的判断做成参数化，支持多个IP别名。比如设备有两个IP，用一个小的匹配表，比写死一个比较器灵活得多，代价只是一点点资源。

4.2 应答帧组装的字段填充规则

应答帧的组装规则，我总结成一张对照表，写代码时直接照着填：

这张表里最容易错的是“发送方IP”。如果设备有多个IP，你必须回填“被查询的那个IP”，而不是默认IP。比如请求方查的是192.168.1.11，你回192.168.1.10，虽然MAC对，但请求方会因为IP不匹配而丢弃应答，表现出来就是“查A地址却学到B地址的MAC”，非常隐蔽。

组帧的顺序要严格按字节流来：先14字节以太网头，再28字节ARP载荷，再18字节填充。用64位通路的话，60字节需要7.5个周期，最后半个周期只有4个字节有效，tx_ctrl要相应置位，不能全置1。这个细节错了，MAC会把填充垃圾也当成有效数据发出去，帧长变成64字节（不含FCS），对端可能报长度错误。

4.3 超时重传与老化计数的参数计算

参数这事，拍脑袋定数值是最容易出问题的。我把几个关键参数的计算过程写出来，你可以直接套。

超时时间：ARP请求的重传间隔，实践中1秒是常见值，太短会对网络造成不必要的广播，太长会让上层业务等待过久。1秒对应的时钟数，按156.25MHz算：156250000 × 1 = 156250000，需要28位计数器（2^28 = 268435456）。如果你用32位计数器当然更保险，但综合时会多几个触发器，无所谓。

重传次数：3次是常见配置，加上首次发送共4次尝试，总耗时约3秒。超过这个时间基本可以判定对端不存在。4次广播ARP请求在局域网里完全可接受，不用担心。

缓存老化时间：这个值和网络规模有关。小局域网里设备不常变动，老化时间可以设长，比如300秒；设备频繁上下线的场景，60秒更合适。我一般设120秒，兼顾两边。老化计数器的位宽按clk_freq × age_sec算，120秒在156.25MHz下是1.875e10，需要35位。这个位宽有点吓人，实际实现时我用的是分频后的慢时钟计数，比如1kHz的tick，这样120秒只需要17位，省很多资源。

提示：老化计数不要每个条目一个计数器，用一个全局tick加每条记录的时间戳，查表时做减法判断是否超时。这样N条记录只多N个时间戳寄存器，而不是N个计数器，资源省一个数量级。

4.4 FCS与填充的归属：一次架构决策

FCS到底在ARP层算还是在MAC层算，这是个架构决策，两种做法我都见过。

放在MAC层的理由是：FCS是所有以太网帧共有的，不只ARP用，MAC统一处理避免重复逻辑；而且CRC32的计算需要遍历整个帧，放在MAC里可以和发送流水线自然结合，不额外增加延迟。缺点是MAC需要知道帧的有效长度，这要求上层把长度信号传准。

放在ARP层的理由是：ARP层自己知道哪些字节是有效载荷、哪些是填充，算CRC时不会搞错边界。缺点是要多写一份CRC逻辑，如果上层还有ICMP、UDP，就得复制好几份。

我选的是放在MAC层，因为MAC本来就要做接收侧的CRC校验，发送侧顺手做掉很自然。ARP层只需要把tx_len设成60（不含FCS），MAC根据这个长度算CRC并附加4字节。这里要注意tx_len的定义必须和MAC的约定一致——是含FCS还是不含，是含前导码还是不含。这个约定写在接口文档第一行，能省掉后面无数次对不上。

填充的处理位置也类似。我让ARP层负责填好18个0字节，因为只有它知道载荷是28字节、需要补到最小帧长。MAC层不该关心上层载荷多长，它只管把上层给的数据加上FCS发出去。如果让MAC来填充，MAC就得知道“ARP帧最小46字节载荷”这种上层知识，职责就混了。

5. 上板联调与常见问题排查

写完代码只是开始，真正花时间的是联调。这一节我把实际踩过的坑整理出来，按现象、原因、排查方法组织，方便你直接对照。

5.1 抓包与逻辑分析仪的分工

排查网络问题，我一般两条腿走路：外部抓包看线上真实发生了什么，内部逻辑分析仪看FPGA里信号是什么状态。两者对照，问题基本藏不住。

外部抓包的要点是：抓包点要尽量靠近被测设备，中间不要过交换机，否则你看到的是交换机转发后的帧，可能已经被修改（比如VLAN标签被剥掉）。抓的时候把过滤器设成arp，只看ARP帧，避免被其他流量淹没。如果抓不到任何ARP帧，先确认物理链路和MAC的发送使能，别急着怀疑ARP层。

内部信号的观察点，我一般布这几个：接收状态机的当前状态、byte_cnt计数、解析出的操作码和目标IP、缓存表的命中信号、发送状态机的状态和tx_len。这几个信号加起来不超过十个，用片上逻辑分析仪抓一次就能看清整个流程。触发条件设成“收到EOP且操作码为1”，这样每次收到请求都会触发，方便复现。

有个实用技巧：把解析出的字段直接引到LED或者寄存器上，通过读写寄存器的方式观察，比逻辑分析仪更省资源，适合长时间监控。比如把最近一次收到的请求的操作码和目标IP存起来，隔一会儿读一次，就能知道有没有收到、解析对不对。

5.2 典型故障速查表

下面这张表是我这几年积累的，覆盖了八成以上的ARP联调问题：

这张表里我特别想强调“以太网源MAC与载荷发送方MAC不一致”这一条。它的隐蔽性在于：很多对端实现只用其中一个做缓存，另一个不检查，所以在你自己的测试环境里可能完全正常，换一台设备就出问题。我现在的做法是在组帧时用同一个参数同时驱动两处，从根本上杜绝不一致。

5.3 几条踩过的坑和经验

第一条：不要相信“标准就是这么写的”这句话能解决问题。标准写的是必须，现实里全是兼容。比如请求帧的目标MAC字段，标准没说必须填什么，有的实现填全0，有的填全F，有的甚至填自己的MAC。你的解析逻辑如果依赖这个字段做任何判断，一定会挂。正确做法是只用发送方字段，目标字段一律忽略。

第二条：广播帧的接收过滤要单独确认。ARP请求是广播，如果你的MAC接收过滤只放行目的MAC等于本机的帧，广播帧就被挡在门外了。这个问题的表现很有迷惑性——你能发请求，对端也能收到并回应，但你就是收不到回应，因为回应是单播，单播能收到，所以你会以为是应答帧格式错了。实际上如果是别人向你发请求，你根本收不到。检查方法很简单：让对端主动ping你，看你有没有反应。

第三条：时序收敛别等到最后。64位通路的组合逻辑很容易堆出长路径，尤其是“对齐移位 + 字段提取 + 判决”串在一起。我一般在字段提取和判决之间强制打一拍，哪怕功能上不需要，也要为时序留余量。这一拍带来的延迟在万兆下可以忽略，但省下的时序违例排查时间是以天计的。

第四条：统计计数器比你想的重要。我在每个模块出口都挂了几个计数器：收到多少ARP帧、丢弃多少、发出多少请求、收到多少应答、重传多少次。联调时这些计数器是第一手信息，能快速判断问题出在收、发还是判决环节。资源代价极小，收益极大，强烈建议一开始就加上。

第五条：测试要用两个方向。只测“我发请求、对端应答”是不够的，还要测“对端发请求、我应答”。这两条路径的代码是不同的，前者走请求调度，后者走应答组帧，任何一条有问题都表现为“不通”，但原因完全不同。我习惯用两台设备互查，或者用一台设备的两个网口对接，双向都跑通才算完。

第六条：免费ARP值得单独测一次。免费ARP是发送方IP等于目标IP的请求帧，用来宣告自己的地址变更。很多实现不处理它，收到就当普通请求回应，也能工作；但如果你的判决逻辑里有“目标IP不能等于发送方IP”这种想当然的检查，就会把它丢掉，导致对端学不到你的新MAC。这个场景在设备热插拔、IP切换时很常见，提前测一下能避免上线后才发现。

第七条：注意缓存表的更新时机。收到应答时更新缓存，这是常规做法；但收到请求时也应该更新——因为请求里带了发送方的IP和MAC，这是一次免费的地址学习机会。很多实现只在应答时更新，导致双向通信时一边要查表一边不用查，行为不对称。我现在的做法是：任何ARP帧，只要解析成功且字段合法，就更新发送方条目，这样缓存收敛更快。

最后说一个我认为最值得分享的体会。ARP这个协议，代码量不大，但它是整个网络栈里第一个需要“记住状态”的模块——缓存表要记、重传要记、超时要记。状态一多，边界条件就多，测试用例就得设计得细。我现在的习惯是先把状态转移图画在纸上，把所有可能的分支都标出来，包括异常分支，然后再写代码。图画完了，代码基本就是照着抄，反而快。跳过这一步直接写，后期debug的时间会翻好几倍，这个账怎么算都不划算。