从一次诡异故障说起…
那天服务器重启后，集群里十几台机器同时失联。arp表项全空，vlan隔离正常，交换机日志毫无波澜。最后抓到罪魁祸首——某台老存储设备，在启动阶段疯狂发送RARP广播，直接把二层通路挤成了废铁。说实话，RARP这个老古董，几乎没人主动部署了，但它依然像幽灵一样藏在启动ROM、虚拟化网卡、甚至某些三层交换机的深度功能里。你碰不到它还好，一旦碰上，就是场考古噩梦。
为什么会有RARP这种反人类设计？
你得回到80年代，机器没有硬盘。无盘工作站通电后，它连自己IP都不知道，怎么去跟别人通信？它只有一个固化在网卡ROM里的MAC地址。于是就有了RARP——Reverse ARP。ARP是通过IP找MAC，RARP反过来，通过MAC找IP。过程粗暴：工作站发一个广播帧，写上“老子MAC是xx:xx:xx:xx:xx:xx，我IP是啥？”网络上必须有一台RARP服务器，维护着MAC到IP的映射表，听到广播后，就给那台机器单播一个应答，里面塞上IP。齐活。
但稍微琢磨一下，到处都是坑。第一个，广播。一个网段成千上万台主机，每次广播全得收，交换机端口瞬间被RARP淹没。第二个，服务器必须部署在每个广播域，还得事先配置静态表——这跟手动分配IP有啥区别？第三个，应答里只有IP，没有子网掩码、网关、DNS，这些还得靠别的方式去配。所以RARP很快就被扫进故纸堆，让位给BOOTP，进而DHCP。不过话说回来，RARP的精髓——基于MAC自举的思路，在PXE规范里还活着，因为启动阶段DHCP的offer也是基于客户端的MAC来分配IP的，对吧？
但RARP的局限逼出了BOOTP（RFC 951）。BOOTP依然用广播，但能带回子网掩码、网关、甚至引导文件名，响应用单播。而且服务器可以跨网段，通过BOOTP中继代理。又过了几年，DHCP（RFC 2131）出世，在BOOTP基础上加上动态IP池和租约概念，彻底消灭了静态MAC映射。不过，你注意到没？DHCP Discover消息依然包含客户端的MAC，服务器在分配IP时还是会查MAC绑定，这不就是RARP的内核么？RARP的基因其实偷偷活下来了。
拆包：钻进RARP帧内部
来看个具体帧。我抓过一个RARP请求，以太类型0x8035，和ARP的0x0806不同。帧结构跟ARP一模一样，只是操作码——请求是3，应答是4。硬件类型1（以太网），协议类型0x0800（IP），硬件地址长度6，协议地址长度4。发送者填自己MAC，目标MAC全0，发送者IP和目标IP都填0.0.0.0。服务器收到后，把目标MAC和IP填上，发送者填服务器自己的MAC和对应的IP，单播回去。整个过程极其简单，代码量不到50行C。
正因为简单，它没有任何状态机、重传机制。发一次请求没收到应答？再发。如果有多台服务器同时应答，客户端取第一个。这种无状态的粗暴，让它在嵌入式设备里顽强的活着——比如某些网络打印机、监控摄像头，还有我刚才碰到的老存储，它们的bootloader里就固化了RARP实现，因为代码小到可以忽略不计。当你插上网线，它们首先来一波RARP广播，不管网络上有没有服务器。这个“僵尸广播”就是定时炸弹。
压测数据：RARP广播风暴的破坏力
我搭了个环境，100台虚拟机同时启动，网卡BIOS开启PXE（会先发RARP）。实测结果，每秒广播包峰值达到3500个，25MB/s的纯广播流量。一台48口千兆交换机，其控制平面CPU一下子蹿到80%，导致STP、CDP等协议报文处理延迟，引起网络拓扑震荡。而用DHCP，同样的启动流程，广播包数量不到前者的1/10，因为DHCP有发现-提供-请求-确认的四步交互，且可以单播后续报文，极大减少了广播。更致命的是，RARP没有退避算法，冲突后只会固定间隔重试，加剧拥堵。用Wireshark抓包，你会看到每隔2秒一个请求，持续整整5分钟。如果在核心交换上做sFlow采样，那个时段流量会陡然增加一个数量级，就像心电图上的早搏。
别笑，很多数据中心在引入大量虚拟化后，常常被这类‘僵尸协议’搞崩。想想，几千个VM同时迁移启动…
三个致命坑，以及怎么填
坑一：无脑广播域泛滥。RARP请求能穿透所有交换机，除非你做VLAN隔离或者端口策略。解决方案：在交换机上配置广播抑制，比如Cisco的storm-control broadcast level 5.00，限制RARP帧速率；或者直接在接入端口过滤MAC帧类型0x8035。更优雅的是，如果你无法彻底禁止，就部署一个虚假RARP服务器，专门应答这些请求并给一个隔离IP，引导设备进入配置页面然后禁用RARP。这是应急野路子，但有效。
坑二：单点服务器故障。传统的RARP服务器必须独享映射表，多服务器极易造成IP冲突。解决方案：用anycast或VRRP部署多重服务器，但映射表必须保持一致，可以基于DHCP的静态绑定数据库动态生成。最佳实践是彻底迁移到DHCP，同时开启DHCP的静态MAC绑定，模拟RARP功能。比如在dhcpd.conf里加host legacy { hardware ethernet 00:1a:2b:3c:4d:5e; fixed-address 192.168.1.100; }，搞定。
坑三：安全裸奔。RARP没有任何认证，任何主机都能冒充服务器发送假应答。攻击者可以实施ARP毒化，导致流量劫持。对策：采用静态ARP绑定在核心交换机上，或者部署DAI（动态ARP检测），这能同时限制ARP和RARP。更根本的措施：禁用RARP，在BIOS/网卡ROM设置里关掉“Network Boot”或选择UEFI HTTP Boot等现代方式。相信我，你不会想在生产环境debug这玩意儿。
RARP的工程美学…及哀悼
尽管RARP早已被淘汰，但它的设计哲学——极简、直接、无状态——在资源受限的场景下仍有启示。它就像一段汇编写的启动扇区，短小却致命。而DHCP，则是一个完整的状态机，有租约、续期、中继、选项字段，复杂但健壮。技术演进大都如此：从简单粗暴，到工程优雅。
所以下次你的网络出现异常广播，别忘了检查是不是有RARP幽灵在作祟。别让它成为你架构中的“坑”。
