简介北航研究生计算机网络实验三报告是一份聚焦地址解析协议与网络层工作原理的实验资料面向计算机网络课程学生、考研复试者及需要借助网络封包分析工具进行抓包学习的初学者。报告以实际操作为主线完整记录了地址解析请求与应答报文的字段解析、同网段与跨网段通信时地址解析交互的差异、地址解析缓存对通信效率的影响以及默认网关在跨路由转发中的关键作用。同时内容还涵盖网际控制消息协议的回送请求与应答、地址掩码请求、时间戳请求等常见类型能够帮助读者系统掌握网络层地址映射机制并提升网络排错能力。压缩包仅含一个 PDF 文件体积 40KB轻便易阅适合按步骤对照学习。目前已有 111 人学习下载是一份针对性强、适合实践教学的北航实验参考资料。1. 这份北航研究生计算机网络实验把 ARP 和 ICMP 报文从黑匣子变成可复现的抓包步骤拿到这份北航研究生计算机网络实验报告的时候我原本以为又是一份填表交差的课程存档。翻到实验 3 的网络层部分才发现整篇都在做同一件事把 ARP 缓存解析、默认网关选路、ICMP 各种 Type/Code 报文全部拿 Wireshark 实测数据做了一道对照。从 192.168.1.22 这台 VMware 虚拟机出发实验依次覆盖了空缓存状态、同网段 ARP、跨网段 ARP 和 tracert 路径探测每一张表都能落回报文里的真实字段值。这份资源适合所有想把计算机网络自顶向下那套理论落实为抓包实操的人研一新生能照着 arp -d、ping、arp -a 三步复现整个流程有基础的读者可以直接把报告里的 Type/Code 字段表当作排错速查来用。它最大的价值不是结论本身而是每一条结论背后都有真实抓包数据在支撑读一遍比自己对着教材猜协议流程要稳得多。2. ARP 请求与应答用 Opcode 和六个地址字段还原解析全过程2.1 ARP 缓存是理解一切的起点从空缓存到 dynamic 条目报告的第一个实验动作很讲究在 2.6.1 步骤 2 里先执行了一次 ARP 查询命令结果只有一行 “No ARP Entries Found”随后在步骤 4 再查缓存里就有了新条目。这两个状态一对比其实就是 ARP 机制最小闭环的演示。步骤 2 对应刚开机、还没有和对端通信过的状态缓存自然为空步骤 4 对应 ping 过一次之后的状态对端 MAC 已经被写入缓存。Interface: 192.168.1.22 --- 0x2 Internet Address Physical Address Type 192.168.1.21 00-0c-29-99-cb-04 dynamicType 列里的 dynamic 是判断映射来源的关键字段。它表示这条条目是主机通过网络中的 ARP 应答动态学到的和人为指定的 static 条目在刷新策略上完全不同。常见做法是在需要固定映射的场景用 arp -s 手工添加但实验环境里最好保持 dynamic否则改完 IP 后缓存不会自动跟随反而容易被旧映射误导。在我反复做这类实验的经验里很多人第一步就会在这里翻车ping 通了但 arp -a 看不到目标条目就以为网络配置有问题。实际上 Windows 主机的 ARP 缓存有自己的老化机制常用条目如果没有持续流量刷新过几分钟就会过期消失。命令行里执行 arp -d 能把全部 dynamic 缓存清空让主机回到实验要求的空缓存初始状态——这是整份报告里最实用的一条命令后面所有复现都建立在这一步上。2.2 请求与应答的六元组对比广播与单播的字段差异实验报告第 3 题把 ARP 请求报文和应答报文的字段逐项填了一张表这六项就是 ARP 报文的核心载荷。我看着这份对比最直观的感受是请求报文有两个识别特征应答报文也恰好有两个对应特征四个特征一抓一个准。字段项ARP 请求数据报文ARP 应答数据报文链路层 DestinationBroadcast (ff:ff:ff:ff:ff:ff)Vmware_2f:e3:85 (00:0c:29:2f:e3:85)链路层 SourceVmware_2f:e3:85 (00:0c:29:2f:e3:85)Vmware_99:cb:04 (00:0c:29:99:cb:04)网络层 Sender MAC AddressVmware_2f:e3:85 (00:0c:29:2f:e3:85)Vmware_99:cb:04 (00:0c:29:99:cb:04)网络层 Sender IP Address192.168.1.22192.168.1.21网络层 Target MAC Address00:00:00:00:00:00Vmware_2f:e3:85 (00:0c:29:2f:e3:85)网络层 Target IP Address192.168.1.21192.168.1.22请求报文的链路层 Destination 是广播地址Target MAC 全零意思是“我不知道谁是 192.168.1.21你们谁是这个 IP 就把 MAC 报上来”应答报文则完全反过来Destination 换成请求者的单播 MACTarget MAC 填上自己的真实值完成一对一回复。判断请求还是应答除了看 Opcode 之外最快的办法就是看链路层目标是不是 ff:ff:ff:ff:ff:ff广播目标只出现在请求里。报告 2.6.1 步骤 6 的统计也很直接截获的报文里只有 2 个 ARP 报文其余 8 个是 ICMP。这个比例说明 ARP 只负责“问一次”拿到映射后后续报文全部直接走单播不会再重复广播。Opcode 字段两个取值分别表达 request1和 reply2Wireshark 里过滤时应写成 arp.opcode 1 或 arp.opcode 2比全量 arp 过滤更能定位问题。2.3 三步命令复现 ARP 填充流程要复现报告里的完整流程命令顺序必须固定先清缓存、再开抓包、最后发流量。顺序反了就会什么都抓不到这是我在多个环境里反复验证过的血泪经验。:: 在 Windows 虚拟机 A 上以管理员身份执行 arp -d ping 192.168.1.21 -n 4 arp -a第一句 arp -d 清空缓存让主机回到空缓存状态第二句 ping 触发一次完整的 ARP 解析和四次 Echo 交互第三句 arp -a 查看缓存是否被写入。如果抓包工具开着会在报文列表里依次看到一条 ARP 广播请求、一条 ARP 单播应答、四个 ICMP Echo 请求、四个 ICMP Echo 应答。这里有两个参数细节值得注意。ping 的 -n 4 指定发送 4 个 Echo 请求和报告里统计到的 8 个 ICMP 报文4 请求 4 应答正好对上如果默认只发 4 个Wireshark 里看到的就是 2 个 ARP 加 8 个 ICMP这和实验记录完全一致。arp -d 不带参数清全部缓存带具体 IP 可以只清某一条。另外在地址栏输入 cmd 时务必用管理员身份运行否则 arp -d 会提示“请求的操作需要提升”白执行一次。3. 跨网段 ARP 与默认网关解析目标从对端主机变成网关 IP3.1 同网段和跨网段的三处决定性字段差异实验 2.6.2 把场景改成了跨网段PC A 的默认网关换成 192.168.1.10PC B 的默认网关换成 192.168.2.10。第二次抓包的结果拿出来和第一次对比ARP 报文的结构出现了三个关键差异报告第 5 题问的就是这个请求报文的目标 IP 是谁、应答报文的源 MAC 是谁、应答报文的源 IP 是谁。对比项同网段2.6.1跨网段2.6.2ARP 请求的 Target IP192.168.1.21对端主机192.168.1.10PC A 默认网关ARP 应答的链路层 Source00:0c:29:99:cb:04对端主机3c:e5:a6:45:6b:bc网关 E0/1ARP 应答的 Sender IP192.168.1.21192.168.1.10ARP 应答的 Sender MAC00:0c:29:99:cb:043c:e5:a6:45:6b:bcICMP 报文的目标 MAC00:0c:29:99:cb:043c:e5:a6:45:6b:bc这三处差异背后的逻辑只有一句话主机只对自己二层可达的设备发 ARP。跨网段的对端不在自己的局域网广播域里数据帧必须先交给网关由网关在三层转发。所以 ARP 请求落在谁头上谁就是二层下一跳。跨网段 ping 时请求的目标 IP 是网关地址应答的源 MAC 是网关接口的 MAC后续 ICMP 报文的目标 MAC 也一律是网关——三层目标是对端主机 IP二层目标却是网关 MAC这两层目标不一致正是网络层和链路层各自职责的体现。报告里还有一个容易被忽略的细节跨网段应答报文里的 Sender IP 是 192.168.1.10不是对端主机。这进一步说明网关在代答 ARP它用自己的 MAC 和 IP 去回应请求者而不是把对端主机的信息转发回去。整个过程中 PC A 根本不知道 PC B 的 MAC 地址也永远不需要知道。3.2 不设默认网关的后果二层广播域外的数据帧直接丢报告第 4 题问了一个反向问题如果不设置默认网关会有什么后果答案写在实验记录里无法访问不同网段的主机。这个结论听起来像废话但实际报文层面发生的事情值得展开。PC A 要向 192.168.2.10 发包首先查自己的路由表发现目标不在直连网段也没有默认路由于是返回“无路由”错误。此时根本不会发 ARP因为系统在 IP 层就判定目标不可达。这与设置了网关但网关没回来的情况是两回事后者会发出 ARP 请求但无人应答表现在现象上是 ping 超时前者则是 ping 直接报 “Destination host unreachable”而且 Wireshark 里一个报文都抓不到。我在自建环境排障时判断这两种现象差别是快速定位问题的关键。如果抓包全是零流量先怀疑主机路由配置如果能抓到 ARP 请求但没人应答再怀疑链路和网关状态。报告里“如果不设置默认网关则无法访问不同网段主机”这个答案落到排查动作上就应该先看 route print 输出里有没有默认路由 0.0.0.0/0。3.3 在模拟器上复现跨网段场景的配置要点实验环境里的 S1 是一台三层交换机E0/1 端口接 PC A 所在网段。要在自己的环境复现同样效果GNS3 或 eNSP 里至少需要一台三层设备充当网关配置逻辑如下# S1 上配置两个网关接口以 Cisco IOS 为例 interface GigabitEthernet0/1 no switchport ip address 192.168.1.10 255.255.255.0 no shutdown interface GigabitEthernet0/2 no switchport ip address 192.168.2.10 255.255.255.0 no shutdown ip routingPC A 和 PC B 分别配置 IP 地址默认网关指向 S1 的对应接口。这里最容易错的一个点是如果 S1 运行在二层交换模式ip routing 没开两个网段之间永远不通即使所有 IP 都配对了。另一个常见做法是直接用路由器串接两个网段但实验报告的报文结构里明确写了“S1 E0/1”三层交换机的端口形态更能还原这份数据的产出场景。配置完成后从 PC A ping PC B再到 PC A 上抓包应该能看到和报告 2.6.2 一模一样的现象ARP 请求的目标 IP 是 192.168.1.10应答的源 MAC 是 3c:e5 开头的网关 MAC。如果在模拟器里抓到的是对端主机的 MAC说明 PC A 的默认网关没生效数据帧走了直连路径。4. ICMP 报文全家桶Type 与 Code 字段的实测对照4.1 Echo 请求与应答Type 8 和 Type 0 的一一对应报告 3.6.1 步骤 2 截获了 8 个 ICMP 报文第 1、3、5、7 个是 Echo requestType 字段值为 8第 2、4、6、8 个是 Echo replyType 字段值为 0。这 8 个报文的 Code 字段全部是 0。对应关系由网络层的 Source 和 Destination 字段保证——这是报告给出的答案也是最容易在 Wireshark 里验证的一点。# Wireshark 显示过滤器 icmp.type 8 # 只看 Echo request icmp.type 0 # 只看 Echo reply ip.addr 192.168.1.21 # 锁定目标主机相关报文从报文数量可以倒推 ping 的默认行为4 个请求对应 4 个应答。每一个 Echo request 里的 Identifier 和 Sequence Number 与对应的 Echo reply 完全一致这是应用层匹配请求和应答的另一重保障。报告中特意强调网络层的 Source 和 Destination 保证一一对应实际理解时把 IP 层和 ICMP 层两层都对照一遍更稳妥IP 层告诉你报文从哪来、到哪去ICMP 层的 Identifier 和 Sequence 告诉你它是第几个请求、属于哪个会话。4.2 地址掩码与时间戳两个低频但必考的查询报文字段报告第 7、8 题分别记录了地址掩码请求/应答和时间戳请求/应答的完整字段。这两类报文在实际业务流量里非常少见Windows 自带的 ping 命令也不支持发送它们实验里是借助 pingtest 程序构造的。地址掩码报文用于主机向网关询问子网掩码时间戳报文则用于测量往返延迟。ICMP 字段名地址掩码请求报文字段值地址掩码应答报文字段值Type17 (Address mask request)18 (Address mask reply)Code00Checksum0xe3ff [correct]0xe3fe [correct]Identifier (BE/LE)2560 (0x0a00) / 10 (0x000a)2560 (0x0a00) / 10 (0x000a)Sequence number (BE/LE)256 (0x0100) / 1 (0x0001)256 (0x0100) / 1 (0x0001)Address mask0.0.0.0255.255.255.0图中出现了一个很关键的现象同样的 Identifier 字段Wireshark 同时用 BE大端和 LE小端两种方式解析BE 显示 25600x0a00LE 显示 100x000a。这说明发送端按大端字节序填充接收端解析时按小端读则得到 10。报告里没有展开讲字节序但排查真实网络问题时遇到过不少报文解析不一致的案例都是发送端和接收端的字节序假设不一致导致的。看到 BE 和 LE 两个值同时显示时以 BE 为准是 Wireshark 的默认逻辑。时间戳报文的 Type 13/14Originate timestamp 在请求和应答里都是 0Receive timestamp 和 Transmit timestamp 在应答里是 14 小时 23 分 57.871 秒。这三个字段分别表示发送方发出报文的时间、接收方收到报文的时间、接收方回复报文的时间。应答报文里 Originate 保持 0 说明中间这台主机没有实现完整的时间戳回显这在虚拟化环境里很常见因为虚拟机时钟同步策略会干扰子秒级时间字段。4.3 差错报文Destination Unreachable 和 TTL 超时的封装结构实验 3.6.2 用 10.1.2.10 到 10.1.4.10 的 ping 构造了终点不可达场景截获的 ICMP 报文 Type 为 3Destination unreachableCode 为 0网络不可达。报告指出一个关键机制这个差错报文的 ICMP 部分至少分两层外层是差错报文自身内层封装了触发差错的原始 Echo 请求的 IP 头和 ICMP 头。ICMP 差错报文类型 / Code含义网络不可达Type 3Code 0无路由到达目标网络主机不可达Type 3Code 1目标主机不可达TTL 超时Type 11Code 0传输过程中 TTL 减为 0内层封装的作用是让源主机知道“哪个请求出了问题”。因为 ICMP 差错报文不会单独携带完整的原始数据只在载荷里回带原始报文的 IP 头和前 8 字节负载源主机据此匹配到具体是哪个 Echo 请求触发的差错。这解释了为什么报告里专门强调“封装的源 Echo 请求报文的 IP 层和 ICMP 层”——没有内层封装源主机只能看到差错不知道差错对应哪个会话。同一次实验还对比了两种不同的目标10.1.3.20 在 S1 一个端口子网内路由器能转发出报文10.1.4.10 不在路由表内路由器直接回 Destination unreachable。这个对比说明差错报文是路由器在丢弃报文时向源端反馈的机制而“能转发”不等于“能到达”路由器只对自己的路由表负责。5. 实验踩坑自查ARP 缓存抓包漏报的五个真实原因5.1 抓不到 ARP 报文因为缓存里残留了 dynamic 条目现象Wireshark 开着ping 也通了但过滤器里一个 ARP 报文都没有只有成对的 Echo 请求和应答。原因目标主机的 MAC 地址已经在 ARP 缓存里主机发 ping 前直接查缓存拿到映射不再发广播请求。Windows 的 dynamic 条目通常保留几分钟只要在这段时间内再次访问同一目标缓存就不会被清除。解决抓包前先执行 arp -d 清空全部缓存确认 arp -a 输出是 “No ARP Entries Found” 或空表再启动抓包工具。要注意 arp -d 需要管理员权限普通终端会执行失败但不报错检查方法就是清完后再执行一次 arp -a 看是否为空。5.2 跨网段抓包看不到对端 MAC看到的是网关 MAC现象按 2.6.2 组网后抓包ARP 应答报文的 Sender MAC 不是对端主机地址而是网关接口地址初看以为抓错包了。原因跨网段通信时PC A 根本不需要知道 PC B 的 MAC。数据帧的二层目标是网关网关在三层把 IP 报文解包后再重新封装转发。ARP 只解决二层目标所以解析对象是网关而不是对端主机。解决接受这个事实。判断标准是 ARP 请求的 Target IP 字段同网段填对端主机 IP跨网段填默认网关 IP。如果跨网段场景里看到 Target IP 是对端主机反而是配置出了问题多半是默认网关没生效。5.3 过滤条件写错报文在混合流量里被淹没现象Wireshark 里全是 TCP 重传、DNS 查询之类的噪声找不到 ICMP 报文以为实验失败。原因虚拟机的网卡上跑着大量管理流量而实验只关心 ARP 和 ICMP。直接翻全量报文就像在流水账里找一页尤其当 Wireshark 的默认排序不是按时间顺序时。解决抓包期间先只过滤需要的内容用显示过滤器把噪声压到最低。备用过滤器写法是 arp || icmp只看两类协议如果还在跑 tracert加上 icmp.type 11 只关注超时报文。过滤条件写好后再回到 ping 命令重新触发一次流量比在历史报文里翻找靠谱得多。5.4 tracert 中途断跳中间路由器不回应 TTL 超时现象tracert 只显示第一跳或第二跳就停住后面的路径全变成星号以为网络链路真的断了。原因部分路由器的安全策略会禁用 ICMP 回显或 TTL 超时响应报文到达该设备后被静默丢弃源端收不到任何反馈。这不等于链路不可达目标可能依然能收到后续 TTL 更大的探测报文。解决先把 tracert 的等待时间参数加大然后用 ping 直接测试目标可达性作为对照。如果 ping 目标能通而 tracert 中间有星号基本可以判断是中间设备策略导致的。抓包验证时注意只要源端还在继续发送 TTL 递增的 Echo 请求就说明 tracert 进程没有放弃星号只是收不到回执。5.5 地址掩码请求发出去没有应答协议被系统安全策略拦掉了现象pingtest 程序发出 Type 17 地址掩码请求后Wireshark 里只有请求没有应答等半天也没有 Type 18 报文。原因Windows、Linux 的新版本内核默认不响应地址掩码请求这类协议被认为具有信息泄露风险大部分主机和路由器固件默认关闭。实验报告里能抓到应答是因为实验环境使用了较老的操作系统镜像或模拟器版本。解决不要在现代操作系统上纠结这类报文直接换用 GNS3 里的旧镜像或 eNSP 模拟环境复现。抓包验证的重点放在报文格式的解析上请求和应答的 Type/Code/Identifier/Sequence 字段完全对称理解这个对称关系比跑通一次更重要。6. 把实验报告当排错手册BE 字节序与 Type 速查的两种用法这份报告读到最后最有复用价值的其实是两张表一张是地址掩码和时间戳报文里的 BE/LE 字段对照一张是 ICMP 各类报文的 Type/Code 速查。我在实际跟踪网络问题时通常会把这两个维度组合成一套快速验证的方法。先说 BE/LE 字段。Wireshark 对同一个 Identifier 同时显示 BE 和 LE 两个值这在报告的时间戳和地址掩码表格里都出现过。例如 BE 25600x0a00和 LE 100x000a对应关系就是 0x0a00 按小端读出来等于 0x000a 即十进制 10。遇到可疑报文时我一般会先对比 BE 显示的值和发送端日志里的十六进制原始内容确认发送端按什么字节序填充的再决定以哪个视图为准。排查两边系统字节序不一是很常见的问题例如嵌入式设备和 x86 主机互发报文就经常在这里错位。第二张表是 ICMP Type 速查。实验覆盖了两类询问报文和两类差错报文测试和排障光靠这四组还不够但可以用同样的方法扩展遇到陌生报文先记 Type再查 Code最后看内层封装。例如 Type 3 的 Code 从 0 到 15 分别表示网络不可达、主机不可达、协议不可达、端口不可达等报告只覆盖了 Code 0 这个场景但排查思路完全一样外层 Type 说明报文类别内层原始负载说明是哪个请求触发的。把这份实验报告作为自检清单来用时我建议每个人照着 2.3 小节的命令序列完整跑三遍第一遍只看 ARP 请求和应答第二遍加看 Echo 请求的 Type 字段第三遍用 tracert 构造 TTL 超时。每一遍都在 Wireshark 里用固定的显示过滤器例如 arp.opcode、icmp.type而不是凭肉眼在报文列表里找。三遍跑完网络层这组协议的字段对应关系基本就刻在脑子里了。从那以后我每次抓网络层实验前都强制走一遍清缓存、过滤、逐层展开的流程再也没被空报文列表坑过。希望这份实验数据也能帮你把 ARP 和 ICMP 的细节彻底理顺。本文还有配套的精品资源点击获取
 函数)
