把万兆链路的物理层眼图调开、64b/66b 编码对齐稳定、MAC 收发通道跑通之后很多人的第一反应是立刻挂上 UDP 或者 TCP 的业务流结果遇到一个很别扭的局面链路指示灯是绿的收发统计计数器在涨可业务就是不通。这时候把抓包工具挂上去往往只能看到一个设备在反复广播谁是 192.168.1.10请告诉 192.168.1.20却始终等不到答复。原因很朴素——ARP 协议报文格式这一层没做或者做了但字段填错了。在万兆以太网MAC的设计里MAC 层只认 48 位物理地址它根本不知道什么叫 IP 地址把 IP 包封装成以太网帧这件事必须有人在中间完成地址翻译。这个中间人就是ARP层模块。这篇内容聚焦的就是这个中间人从 28 字节 ARP PDU 的每一个比特怎么摆到接收解析状态机怎么切拍、应答怎么组帧、表项怎么老化再到联调阶段抓包抓出来的几类典型异常。整套逻辑只涉及以太网和 IPv4 的最基础约定不依赖任何私有协议。适合已经能把万兆 MAC 收发跑通、正要往上接网络层的中级开发者也适合刚接触 FPGA 网络加速、想搞清楚为什么 ping 不通的初学者。下面按设计顺序一层层展开。1. 万兆MAC之上为什么还要单独做一层ARP1.1 链路通但业务不通的典型现象先描述一个几乎每个做网络加速的人都会遇到的场景。板子上电自协商完成光模块的 LOS 灯灭掉MAC 的 rx_valid 开始有翻转统计寄存器里收到的帧计数缓慢增长。心里一喜觉得大功告成。接着把 PC 的网线插到对端配置好同一网段的 IP敲一个 ping 命令返回的是目标主机不可达或者干脆超时。此时在 PC 上执行arp -a会发现目标 IP 对应的 MAC 地址一栏是空的说明 ARP 请求发出去之后没有收到应答。这个现象背后的机制非常直接ping 走的是 ICMPICMP 要装进 IP 包IP 包要装进以太网帧而以太网帧头部的目的 MAC 地址从哪来只能从 ARP 表里查。表里没有就要先发一个 ARP 请求去问问不到IP 包就压根发不出去。所以万兆以太网MAC设计得再漂亮只要 ARP 层缺位上层任何基于 IP 的业务都启动不了。这个因果关系不是可选项而是硬约束。更麻烦的是万兆场景下的一些特殊性。10Gbps 的线速意味着最小 64 字节的帧间隔只有 67.2 纳秒ARP 请求本身是广播帧很多为了省资源而裁剪过的接收通路只做了单播地址过滤广播帧直接被丢弃。所以第一件要检查的事往往不是状态机写没写对而是 MAC 的接收过滤配置里广播地址有没有被放行。这一点在后面第 6 章还会展开说。1.2 硬件自动应答与软件参与的边界划分确定要做 ARP 之后下一个问题是在哪儿做。常见的有三种思路各有适用面。第一种是纯软件方案MAC 收到 ARP 帧不做任何解析原样通过 DMA 送进主机内存由协议栈解析后生成应答再下发。这种方案实现门槛最低逻辑侧几乎不用改代价是延迟大、占用主机 CPU、而且必须有主机参与。对于纯逻辑的数据通路比如一个只有 FPGA 没有处理器的采集卡这条路直接堵死。第二种是硬件全自动方案ARP 层模块内部维护一张小表收到请求后自己判断目标 IP 是不是本机是就立刻组应答帧从发送通道打回去全程不惊动主机。这条路的延迟可以压到微秒级甚至更低资源开销也不大一张 32 项的表加上解析状态机在主流 FPGA 上占用的逻辑资源相当有限。第三种是混合方案常规请求由硬件自动应答同时把学习到的 IP-MAC 映射通过一个旁路通道上送软件软件可以下发静态表项、调整老化时间、或者做更复杂的策略。实际项目里用得最多的是这一种。我在一个纯逻辑的采集项目里选的是第二种理由是链路上只有一个固定的对端地址映射不超过四条硬件自动应答足够还省掉了软硬件交互的握手协议和随之而来的一堆时序问题。选型的判断标准其实就一条地址映射是否需要动态变化、是否需要策略控制。固定拓扑就硬件全自动动态拓扑就上混合方案不要为了通用在一开始就把复杂度拉满。2. 28字节ARP PDU的逐字段拆解2.1 以太网封装与长度账的完整算法先把帧结构摆清楚。ARP 报文并不是独立存在的它作为以太网帧的载荷出现前面套了一层 14 字节的以太网帧头。完整结构从线序来看是这样的层次字段长度字节说明以太网头目的 MAC6广播时为 FF:FF:FF:FF:FF:FF以太网头源 MAC6请求方的物理地址以太网头类型2固定 0x0806标识上层是 ARPARP PDU硬件类型2以太网填 0x0001ARP PDU协议类型2IPv4 填 0x0800ARP PDU硬件地址长度1填 6ARP PDU协议地址长度1填 4ARP PDU操作码21 为请求2 为应答ARP PDU发送方硬件地址6请求方的 MACARP PDU发送方协议地址4请求方的 IPARP PDU目标硬件地址6请求时全 0应答时填对端 MACARP PDU目标协议地址4被询问或被回复的 IP填充Padding18补齐到最小帧长尾部FCS4CRC32 校验长度账要算两遍。第一遍算有效载荷以太网头 14 字节加上 ARP PDU 28 字节合计 42 字节。第二遍对照最小帧长要求以太网规定从目的 MAC 到 FCS 之前的最小长度是 60 字节含 FCS 是 64 字节。42 字节明显不够需要补 18 字节的填充补完之后 42 加 18 正好 60再加上 4 字节 FCS 就是 64。这个 18 字节的填充量是固定的因为 ARP PDU 的长度是固定的 28 字节不像 IP 那样长度可变。很多实现里图省事直接不补短帧发出去之后对端的 MAC 可能因为长度不足直接丢帧或者在交换机侧被当成残帧处理。这个坑我踩过一次现象是抓包工具能看到请求但应答帧在交换机端口就被丢了因为交换机对 42 字节的帧判定为 runt。2.2 字段取值与字节序的双重陷阱字段本身的取值不难难的是字节序。ARP 协议规定所有多字节字段采用网络字节序也就是大端高字节在前。而我们在 FPGA 内部处理 IP 地址时习惯性地会把它当成一个 32 位无符号数存在寄存器里比如 192.168.1.10 存成32hC0A8010A。这个寄存器在线序上第一个字节应该发0xC0也就是取[31:24]。最容易出错的地方是 6 字节的 MAC 地址。在 Verilog 里通常写成48h02_00_00_00_00_01这个写法里[47:40]是0x02是线序上的第一个字节。但如果你在做比较的时候误用了[7:0]那一端比较逻辑写反了功能仿真可能因为两边的 MAC 正好对称而通过上板就完蛋。写代码时我养成一个习惯凡是 6 字节地址统一在命名上标注清楚比如local_mac_hi对应[47:40]避免后面接手的人误读。还有两个容易翻车的取值细节。一是硬件类型字段虽然以太网填 1但有些老实现会填 6对应 IEEE 802 网络接收侧如果判等只认 1遇到填 6 的请求就不应答。稳妥的做法是接收侧不强校验硬件类型和长度字段只校验协议类型和操作码发送侧老老实实填 1、0x0800、6、4。二是操作码值是 1 和 2占 2 字节但实际只有低字节有效高字节为 0。如果按字节流逐字节比较需要比较两个字节如果按 16 位字比较直接比16h0001和16h0002。2.3 请求与应答的字段镜像关系请求和应答的字段差异是设计应答组装逻辑的直接依据这张对照表建议直接对着写代码字段ARP 请求ARP 应答目的 MACFF:FF:FF:FF:FF:FF请求方的源 MAC源 MAC本机 MAC本机 MAC类型0x08060x0806硬件类型11协议类型0x08000x0800硬件地址长度66协议地址长度44操作码12发送方硬件地址本机 MAC本机 MAC发送方协议地址本机 IP本机 IP目标硬件地址全 0未知请求方的源 MAC目标协议地址被询问的 IP请求方的源 IP看出规律了吗应答帧就是把请求帧里的两对地址做了一次交换同时把操作码改成 2把目的 MAC 从广播改成请求方的单播地址。所以组帧逻辑可以写得非常简洁把接收到的 28 字节 PDU 缓存下来应答时按偏移取字段SHA 改成自己的SPA 改成自己的THA 取缓存里的 SHATPA 取缓存里的 SPA操作码覆写成 2。这里有个小细节值得注意请求帧里目标硬件地址是全 0如果直接原样交换应答帧的 THA 会变成 0那就错了。所以交换的对象不是目标硬件地址字段而是发送方硬件地址字段这两个不一样。写代码时如果图省事做了字段平移很容易把这个坑埋进去而且仿真用例如果只测字段全 0 的场景根本发现不了。3. ARP层模块的接口约定与状态机组织3.1 与MAC通道的握手约定与跨拍分割10G MAC 的数据通路典型配置是 64 位数据宽度配 156.25MHz 时钟一拍承载 8 个字节线速正好对得上。接口用标准的流式握手四个信号数据tdata、字节有效掩码tkeep、帧尾标志tlast、数据有效tvalid配一个反压tready。这套约定在业界是通用的不同 IP 的差异主要在字节序映射上。关键问题是 42 字节怎么落在 64 位总线上。42 除以 8 等于 5 余 2也就是需要 6 拍前 5 拍满第 6 拍只有 2 个字节有效。逐拍映射关系如下这张表是整个接收状态机的基础拍号字节范围承载内容tkeep00-7目的 MAC 源 MAC 前 2 字节0xFF18-15源 MAC 后 4 字节 类型 硬件类型0xFF216-23协议类型 两个长度 操作码 发送方 MAC 前 2 字节0xFF324-31发送方 MAC 后 4 字节 发送方 IP0xFF432-39目标 MAC 目标 IP 前 2 字节0xFF540-47目标 IP 后 2 字节 填充起始视情况第 5 拍比较特殊。如果对端发来的是标准 60 字节最小帧那么第 5 拍之后还有 2 拍填充数据如果对端直接发了 42 字节的短帧不规范但确实存在那么第 5 拍的tkeep就是0x03而且tlast会在这一拍拉高。这两种情况都要能处理不能假定填充一定存在。注意不要把以太网帧一定是 64 字节当成硬假设写进状态机。虽然标准要求如此但实际抓到过的短帧不少处理不了短帧的实现会在联调时莫名其妙地卡在某个状态出不来。3.2 接收解析状态机的状态划分状态机建议按帧头识别—载荷缓存—判定—触发四段来切不要试图一拍做完所有事。万兆下时序很紧组合逻辑链路一长时序收敛就是噩梦。先定义状态localparam S_IDLE 3d0; // 等待帧起始 localparam S_HEAD 3d1; // 收以太网头判地址与类型 localparam S_PAYLOAD 3d2; // 缓存 28 字节 ARP PDU localparam S_JUDGE 3d3; // 判操作码与目标 IP localparam S_HIT 3d4; // 命中置应答请求 localparam S_DROP 3d5; // 丢弃等帧尾S_IDLE里等tvalid tready同时有效进来之后进S_HEAD。S_HEAD处理前两拍第一拍一次性拿到目的 MAC 和源 MAC 的前两个字节此时就能完成地址过滤目的 MAC 是全 F 的广播地址或者是本机 MAC才继续往下走否则直接跳S_DROP。第二拍拿到类型字段判断是不是0x0806不是也跳S_DROP。S_PAYLOAD处理第 2 到第 5 拍把 28 字节 PDU 的字段按偏移拆出来存到寄存器里。这里不需要真的存 28 字节只存后面会用到的发送方 MAC 6 字节、发送方 IP 4 字节、目标 IP 4 字节、操作码 2 字节总共 16 字节省资源。拆分的时候按上表的偏移去截取对应的位段注意每一拍里字段是跨字节段的比如第 2 拍里操作码在[39:24]这个位置具体取决于你的字节序映射约定写之前一定要拿 MAC IP 的文档核对清楚第一拍里tdata[7:0]到底对应线序的哪个字节。S_JUDGE只做两件事操作码是不是 1目标 IP 是不是本机 IP。两个条件同时满足才进S_HIT否则跳S_DROP。这个状态独立出来是有讲究的如果把判断和缓存揉在一个状态里组合逻辑会拉得很长在 156.25MHz 下大概率时序不过。S_DROP的作用是一直等到tlast拉高把整个帧消化完再回S_IDLE。少了这个状态帧还没结束就回空闲态后面的填充数据会被误当成新帧的开头直接导致状态机错乱。3.3 应答组装流水线与发送仲裁应答帧的组帧相对简单因为所有字段都是已知的或者从缓存里取。但要注意组帧和发送之间需要一个 FIFO 或者至少一个深度可控的缓冲原因是发送通道可能正被业务数据占用ARP 应答不能等。组帧的顺序按线序走先填第 0 拍的目的 MAC来自缓存的发送方 MAC和源 MAC 前 2 字节第 1 拍填源 MAC 后 4 字节加类型和硬件类型第 2 拍填协议类型、两个长度、操作码 2、本机 MAC 前 2 字节第 3 拍填本机 MAC 后 4 字节和本机 IP第 4 拍填请求方 MAC 和目标 IP 的前 2 字节第 5 拍填目标 IP 后 2 字节和 6 个字节的零填充。第 6、7 拍补 12 个零字节凑满 60 字节tlast在第 7 拍拉高。发送仲裁的策略要提前想清楚。最简单的是 ARP 应答优先业务数据让路实现方式是给 ARP 应答一个高优先级请求业务侧看到这个请求就暂停一两个拍。这种策略的代价是业务流会有一个微小的抖动但 ARP 帧极其稀疏实际影响可以忽略。另一种是完全插空发送等业务帧之间的间隙实现复杂但业务无损。我在项目里用的是前一种因为在万兆下 ARP 帧的出现频率低到可以忽略不计为它设计复杂的调度器不划算。3.4 ARP缓存表的组织方式与查找时序表的核心是 IP 到 MAC 的映射外加有效位和老化信息。表项结构大概是这样字段位宽说明ip_addr32协议地址mac_addr48硬件地址valid1表项有效标志age_cnt16老化计数递减到 0 失效加起来 97 位一张 32 项的表大约 3104 位用一块小容量的块存储或者分布式存储都能装下资源压力很小。查找方式有两种选哪种取决于表的大小和查找频率。表项少于 16 条时直接用并行比较把所有表项的 IP 同时和待查 IP 比对一拍出结果逻辑资源大概几百个查找表完全可以接受。表项超过 32 条时并行比较的资源开销开始变得不划算改用哈希加链式查找或者干脆用内容寻址存储器的思路。有个时序上的坑需要提醒ARP 表的查找通常发生在发送 IP 包之前而万兆下帧与帧之间的间隔可能只有几个拍。如果查找需要多个周期就必须在帧开始发送之前预查到结果或者接受一个小的发送延迟。我的做法是在业务侧维护一个小的待发队列在出队之前就完成地址查找把查找延迟藏在排队时间里。这个设计变更看起来不起眼但它是把发送通路时序从查找拖慢发送变成查找与发送并行的关键。老化机制相对简单一个自由运行的定时器每秒钟产生一个脉冲所有表项的age_cnt递减减到 0 就把valid清零。老化时间一般设 60 到 300 秒具体看网络规模。太短会导致频繁重新请求太长会导致地址变更后长时间不通。4. 组帧、FCS与最小帧长的实操处理4.1 FCS由谁负责这一层责任划分FCS 是 4 字节的 CRC32 校验覆盖范围从目的 MAC 第一个字节到载荷最后一个字节不含前导码、帧起始定界符和 FCS 本身。这里有个责任划分问题FCS 到底由 ARP 层算还是由 MAC 层算绝大多数 10G MAC IP 都提供 FCS 自动插入功能配置寄存器里有一个使能位打开之后 MAC 自己算 CRC 并附加上层只需要把帧的载荷送到tlast拉高就行。这种情况下 ARP 层完全不用管 FCS省事很多。但也有一部分精简实现不提供这个功能或者提供了但需要软件在发送前写入一个长度字段那就得自己算。自己算 CRC32 的话多项式是0x04C11DB7反射形式是0xEDB88320初值全 1最后结果取反。硬件实现用 8 位并行的查表或者直接展开的异或树一个 64 位数据通路的 CRC 单元大概需要几十个异或门资源不大。关键的坑在于计算范围必须包含填充字节很多人算到 42 字节就截止了补的 18 个零没有参与计算结果对端校验失败帧被静默丢弃抓包工具上连个影子都看不到因为坏帧在物理层就被扔了。提示判断 FCS 该不该自己算最快的办法是看 MAC IP 的发送接口有没有tx_fcs_en之类的控制位有就交给 MAC没有就自己算。不要在文档不全的情况下猜。4.2 填充字节填什么与长度字段的关系填充的 18 个字节填什么值标准没有硬性规定填 0 是最常见的做法也有些实现对填充区填入随机数据目的是防止某些场景下的数据压缩侧信道问题那是安全领域的考量跟常规网络设备无关。做 FPGA 实现时一律填 0 就行。但有一个关联问题必须说清楚以太网帧头里的类型字段是0x0806这是一个大于0x0600的值按照标准大于这个值表示上层协议类型小于这个值才表示载荷长度。所以 ARP 帧走的是类型字段这条路接收方靠类型字段判断载荷是 ARP而不是靠长度字段推算载荷在哪结束。这意味着填充字节的内容不会被误解析因为解析器在读完 28 字节 PDU 之后就不再看了。如果哪天要做的是 802.3 长度字段格式的帧那填充字节的边界就必须精确计算因为接收方会用长度字段去界定载荷范围填充区一旦填了非零值又落在长度范围里就会被当成有效载荷的一部分。这两种封装格式的差别在实现时要区分清楚别混用。4.3 组帧时序与反压处理组帧的时序要跟发送通道的反压配合好。发送通道tready拉低时组帧状态机必须停住不动tdata、tkeep、tlast保持上一次的值不能因为内部计数器还在跑就把数据丢了。这一点在流式接口里是硬性要求违反了会导致对端收到的数据和tkeep不匹配。一个常见的写法错误是把组帧和数据发送写成一个状态机用计数器推进。计数器在反压期间如果没被冻结就会继续加等tready恢复时数据已经错位了。正确做法是让计数器只在tvalid tready同时为真的那一拍才递增或者把组帧和数据发送拆成两个阶段中间用一个小 FIFO 解耦。拆成两阶段的好处还有一个组帧阶段可以做得慢一点只要平均吞吐跟得上就行而发送阶段可以专门优化时序。ARP 应答的组帧频率极低完全没必要为了它把时序做到极限。5. 联调阶段的问题定位5.1 抓包工具能给出的有效信息联调时最有效的手段是抓包。主流协议分析软件对 ARP 的解码非常完善会直接把字段翻译成人话比如Who has 192.168.1.10? Tell 192.168.1.20。看到这一行至少说明三层信息请求发出去了、类型字段对、发送方 IP 填对了。抓包时要重点看几个地方。一是应答帧有没有出现。如果只有请求没有应答问题在接收侧或者判定条件。二是应答帧的字段。软件会把应答显示成192.168.1.10 is at xx:xx:xx:xx:xx:xx如果这个 MAC 显示出来跟你板子上的不一致说明组帧时字段取错了位置。三是帧长度。软件会标出帧的总长度如果显示 42 字节而不是 60 字节说明填充没做。还有一类问题抓包工具帮不上忙就是帧压根没发到线上。这时候要看 MAC 的发送统计寄存器有没有丢帧计数在涨有没有 undersize 错误。有些 MAC 会把小于最小帧长的帧直接丢弃并计数这个计数器是定位填充问题的最快入口。5.2 仿真环境里绕不过去的测试用例上板之前仿真里至少要把这几类用例跑一遍能省掉大量来回折腾的时间。第一类是标准请求应答对端发广播请求目标 IP 命中本机检查应答帧每个字段是否与第 2.3 节的对照表一致。这个用例要逐字节比对不能只看有应答输出。第二类是目标 IP 不命中发一个询问别人 IP 的请求检查模块没有产生应答。这个用例专门抓忘了判断目标 IP这个经典错误很多实现收到任何 ARP 请求都回看上去能用实际上会在网络上制造混乱。第三类是短帧强制发 42 字节不填充的请求检查模块能正常解析并产生应答状态机不卡死。第四类是背靠背请求连续发三个请求间隔很小检查应答是否全部正确产生缓冲有没有溢出。第五类是操作码异常发一个操作码为 3 的帧检查被正确忽略。第六类是类型字段异常发一个0x0800的 IP 帧检查不会被误判成 ARP。我在实际项目里发现最有价值的是第二类和第六类因为这两类错误在功能演示时完全看不出来只有多设备共存或者混合流量时才会暴露而那时候排查成本已经很高了。5.3 上板之后几类异常的分层排查思路上板之后如果还是不通按层次往下找别一上来就怀疑状态机。第一步看物理层和链路层MAC 的接收计数器有没有在涨。不涨问题在物理层或者 MAC 的接收使能配置。涨了但 ARP 没反应进第二步。第二步看接收过滤。很多 MAC IP 默认只接收目的地址等于本机 MAC 的帧广播帧需要单独使能。如果广播过滤没打开ARP 请求压根进不了 ARP 层这时候在 ARP 模块的输入端口上加一个计数器看有没有数据进来一目了然。第三步看判定条件。把目标 IP 比较的结果、操作码比较的结果各拉一个调试信号出来看看命中的时候这两个信号是不是同时为高。很多时候是 IP 地址的字节序搞反了明明是本机 IP比较却不等。第四步看发送通路。把应答帧的组帧完成信号和实际发送完成信号都拉出来看组帧完成了但发送没发出去还是压根没组帧。如果是前者去看发送仲裁和 FIFO 状态。这套分层排查的顺序不是拍脑袋定的它是按信号从远端到近端的顺序排的能保证每次只往下推一层不会在多处同时改东西导致问题定位失真。6. 容易被忽略的几个工程细节6.1 广播与组播过滤的配置差异前面提过广播帧被过滤的问题这里展开说清楚。MAC 层的地址过滤通常有几档单播命中本机地址、广播全 F、组播地址范围。ARP 请求走的是广播所以广播过滤必须打开。有些 IP 的过滤配置是分层的先过一遍哈希过滤再过精确匹配广播地址能不能通过哈希那一关取决于具体实现需要看手册确认。还有一个容易忽略的地方是混杂模式。调试阶段把 MAC 配成混杂模式能收到所有帧方便定位但正式运行时不能开否则所有经过交换机的帧都会被当成自己的ARP 层会被大量无关请求淹没应答风暴随之而来。6.2 复位后的初始状态与表项清空复位之后 ARP 表必须是全无效状态不能有残留。这在仿真里很少出问题因为仿真初始值通常是 X 或者 0但上板后如果用的是块存储上电初值是不确定的如果valid位恰好是 1就会拿着垃圾地址去应答或者去封装。稳妥的做法是在复位释放之后用一个短状态机把所有表项的valid位逐条清一遍几十个周期的事代价极小。这一步在项目里千万别省我见过因为省这一步导致上电后前几百毫秒网络行为诡异的案例排查了大半天才发现是存储初值问题。6.3 应答风暴与请求限速最后说一个理论上不常见但实际会遇到的场景如果网络上有个设备在疯狂发 ARP 请求或者有人用工具做地址扫描ARP 层的应答频率会突然升高。如果应答通路没有限速大量应答帧会挤占业务带宽严重的会导致发送 FIFO 溢出、业务帧丢失。处理办法很简单在应答触发路径上加一个简单的漏桶每 N 个微秒最多产生一次应答超出的请求直接丢弃。ARP 协议本身有重传机制丢一两个请求不会导致通信失败对端会重发。这个限速阈值设多少合适按经验正常网络里 ARP 请求的频率极低每秒几十个已经算多了把限速设成每毫秒一次就足够覆盖正常场景同时把异常流量压制住。再补充一个跟表项有关的经验如果项目里对端地址是固定的与其让模块动态学习不如在复位之后直接把固定映射写进表里并把这些表项的valid位锁死不参与老化。这样一来即使链路上出现过短暂的 ARP 风暴或者异常帧固定映射也不会被冲掉通信的确定性会好很多。我在一个需要长时间无人值守运行的项目里就是这么做的运行几个月没有出现过地址失效导致的通信中断。
