北航计算机网络实验三：ARP与ICMP抓包分析实战报告

简介：这份PDF是北航研究生计算机网络课程的实验三报告，面向正在学习网络层协议、需要完成ARP与ICMP相关实验的高校学生及自学者。报告围绕ARP地址解析、ARP缓存、默认网关与跨网段通信等核心机制展开，结合Wireshark抓包结果逐项记录并分析报文结构。资源包共1个PDF文件，约40KB，内容为实验报告正文，包含ARP请求与应答字段对照表、ICMP回送请求与应答、地址掩码及时间戳请求等报文的填写与分析。读者可借此对照实验步骤，理解同网段与跨网段ARP解析的差异，掌握默认网关在多网络环境中的作用，并学习如何从抓包数据中提取协议字段、排查通信问题。目前已有111人学习下载，适合作为网络层实验的参考范例与复习材料。

1. 北航研究生计算机网络实验三：一份能直接复现 ARP 与 ICMP 抓包分析的实战报告

如果你正在做北航研究生计算机网络实验三，或者任何一门要求用 Wireshark 抓 ARP、ICMP 报文并逐字段填表的网络层实验，这份 PDF 报告的价值不在于“答案”，而在于它把整个实验的操作路径、字段对照和现象解释都留了下来。实验三的核心是网络层：ARP 请求与应答的报文结构、ARP Cache 的命中逻辑、默认网关在跨网段通信中的角色，以及 ICMP 询问报文和差错报文的类型/代码字段。适合正在跟实验指导书一步步做、但抓完包不知道怎么看、填表时对不上字段的人。我拆完这份报告后最大的感受是：它把“抓包—筛协议—对字段—解释现象”这条链路走通了，你照着复现，能省掉大量在 Wireshark 里瞎点的时间。

2. ARP 报文结构与同网段解析：从 Opcode 到四个地址字段

2.1 先搞清楚 ARP 请求和应答到底差在哪

实验报告里反复出现的一张表，是 ARP 请求报文和 ARP 应答报文的字段对照。很多人第一次抓 ARP 包，看到 Opcode 有 1 和 2 两个值就懵了，其实这两个值就是 ARP 的全部“动作类型”：1 表示 request，2 表示 reply。请求是广播出去的，所以链路层 Destination 是ff:ff:ff:ff:ff:ff；应答是单播回来的，链路层 Destination 就是请求方的 MAC。

真正容易填错的是网络层的四个字段：Sender MAC Address、Sender IP Address、Target MAC Address、Target IP Address。在 ARP 请求里，Target MAC Address 是全零00:00:00:00:00:00，因为请求方还不知道目标 MAC；在 ARP 应答里，Target MAC Address 才被填成请求方的 MAC。这个“请求时目标 MAC 为空、应答时目标 MAC 被填上”的对称关系，是判断你抓到的包对不对的第一直觉。

报告里给出的实测数据很典型：同网段下，PC A（192.168.1.22）ping PC B（192.168.1.21），ARP 请求的 Sender IP 是 192.168.1.22，Target IP 是 192.168.1.21；ARP 应答的 Sender IP 变成 192.168.1.21，Target IP 变成 192.168.1.22。Sender 和 Target 在请求/应答之间正好互换，这是 ARP 协议设计上最干净的一点。

2.2 用 Wireshark 过滤并定位 ARP 报文

实验指导书里让你在 2.6.1 步骤 6 截获报文，统计 Protocol 字段。报告里填的是“有 2 个 ARP 报文，有 8 个 ICMP 报文”。这个数字不是拍脑袋来的，是 ping 一次产生 4 个 Echo request + 4 个 Echo reply，加上 ARP 请求和应答各 1 个。下面是我一般会用的过滤和统计方式：

# 在 Wireshark 显示过滤器里输入，只看 ARP arp # 只看 ICMP icmp # 同时看 ARP 和 ICMP，用于统计总数 arp || icmp # 只看 ARP 请求（Opcode=1） arp.opcode == 1 # 只看 ARP 应答（Opcode=2） arp.opcode == 2

逻辑说明：arp.opcode是 Wireshark 对 ARP 协议树里 Opcode 字段的过滤语法，值 1 对应 request，值 2 对应 reply。参数上，如果你只想看某个 IP 相关的 ARP，可以叠加arp.src.proto_ipv4 == 192.168.1.22这类条件。统计报文数量时，不要用“包列表里肉眼数”，直接看 Wireshark 底部状态栏的 Displayed 计数，或者用Statistics > Protocol Hierarchy看协议占比，这样填“几个 ARP、几个 ICMP”不会出错。

提示：抓包前先清空 ARP Cache，否则你可能抓不到 ARP 请求。Windows 下用arp -d *，Linux 下用ip neigh flush all，这样 ping 的时候才会强制走一次 ARP 解析。

2.3 ARP Cache 的作用与“少了 ARP 报文”现象

报告里有一个很关键的对比：第一次 ping 和第二次 ping 抓到的报文不一样，第二次“少了 ARP 报文”。原因就是 ARP Cache。主机收到 ARP 应答后，会把 IP 和 MAC 的对应关系写进缓存，默认存活时间通常几分钟。第二次 ping 同一个目标时，主机先查 ARP Cache，命中就直接发 ICMP，不再发 ARP 请求。

你可以用下面的命令验证缓存的存在和老化：

# Windows 查看 ARP 缓存 arp -a # Linux 查看邻居表 ip neigh show # Windows 删除所有 ARP 缓存条目，强制重新解析 arp -d * # Linux 删除指定条目 ip neigh del 192.168.1.21 dev eth0

逻辑说明：arp -a输出里的 Type 字段如果是 dynamic，说明是动态学习到的；如果是 static，说明是手工绑定的。参数上，arp -d *在 Windows 下需要管理员权限，删完之后再 ping，你就能重新抓到 ARP 请求。这一步是实验里“比较两次 ping 报文差异”的操作基础，不做清缓存，你永远只能看到 ICMP，看不到 ARP。

3. 跨网段 ARP 与默认网关：Target IP 为什么变成了网关地址

3.1 同网段和跨网段 ARP 的核心差异

实验报告里第二个重点，是重新组网后 PC A 和 PC B 在不同网段，PC A 的默认网关改成 192.168.1.10，PC B 的默认网关改成 192.168.2.10。这时候再抓 ARP，你会发现一个反直觉的现象：PC A 发出的 ARP 请求，Target IP Address 不是 PC B 的 IP，而是 PC A 自己的默认网关 IP 192.168.1.10。

原因很简单：PC A 发现目标 IP 和自己不在同一网段，它不会直接 ARP 询问 PC B，而是把数据包交给默认网关。所以 ARP 请求问的是“网关的 MAC 是多少”，网关回复自己的 MAC 后，PC A 把整个 IP 包发给网关，由网关继续转发。报告里写得很清楚：跨网段时，ARP 应答的链路层 Source 和网络层 Sender MAC Address 都是网关 S1 e0/1 的 MAC 地址3c:e5:a6:45:6b:bc，而不是 PC B 的 MAC。

这个差异是实验填表时最容易翻车的地方。很多人以为 ARP 请求的 Target IP 永远是目标主机 IP，结果跨网段一抓，发现对不上。记住一句话：ARP 只在同一广播域内解析，跨网段时解析的是网关地址。

3.2 默认网关不设置的后果与验证方法

报告里有一个直接的问题：“如果不设置默认网关会有什么后果？”答案是：无法访问不同网段的主机。这个结论需要你亲手验证一次，否则记不住。操作上，把 PC A 的默认网关清空，再 ping 另一个网段的地址，你会看到 ICMP 差错报文里的 Destination unreachable。

# Windows 查看当前路由表，确认默认网关 route print # Linux 查看默认网关 ip route show # 临时删除默认网关（Linux，需要 root） ip route del default # 重新添加默认网关 ip route add default via 192.168.1.10

逻辑说明：route print里0.0.0.0那一行就是默认路由，Gateway 列就是默认网关。删掉默认路由后，主机不知道把跨网段包发给谁，内核直接返回“网络不可达”。参数上，ip route del default只删默认路由，不影响同网段直连；验证完记得加回去，否则后续实验全断。这一步做完，你就能理解为什么实验报告里强调“默认网关是跨网段通信的出口”。

3.3 用 ping 和 tracert 观察跨网段路径

报告里还涉及 tracert 的工作过程：PC A 向 PC B 发送 TTL 从 1 开始递增的 ICMP Echo 请求，路径上每个路由器把 TTL 减 1，减到 0 就回一个 ICMP 超时报文（Type 11，Code 0）。PC A 通过收集这些超时报文，就能画出路径。

# Windows 跟踪路由，-d 表示不解析域名 tracert -d 192.168.2.21 # Linux 跟踪路由 traceroute -n 192.168.2.21 # 指定最大跳数 tracert -h 5 192.168.2.21

逻辑说明：tracert默认最多 30 跳，-h可以改小，方便在实验环境里快速看到前几跳。-d不反查 DNS，速度更快。抓包时配合icmp过滤器，你能同时看到 Echo request、Time-to-live exceeded 和 Echo reply 三类报文。参数上，TTL 的初始值在 Windows 下通常是 128，Linux 下是 64，但 tracert 会自己控制发送的 TTL，不需要你手动改。

4. ICMP 询问报文与差错报文：Type/Code 字段对照与抓包排查

4.1 四类 ICMP 询问报文的字段速查

实验报告里填了三张 ICMP 询问报文的表：回送请求/应答、地址掩码请求/应答、时间戳请求/应答。这些表的字段值很容易混，我整理成下面这张对照表，方便你抓包时直接对：

逻辑说明：Identifier 和 Sequence number 是保证请求和应答一一对应的关键字段。报告里特别问了“哪些字段保证回送请求和回送应答一一对应”，答案是网络层的 Source/Destination 加上 ICMP 的 Identifier/Sequence。抓包时，你在 Wireshark 里展开 ICMP 协议树，看到Identifier (BE)和Identifier (LE)两个表示，这是字节序的不同展示，值本身是一样的。

4.2 差错报文：Destination unreachable 与 Time-to-live exceeded

报告里第二个实验场景抓到了两类 ICMP 差错报文。第一类是 Destination unreachable，Type 3，Code 0 表示网络不可达。它的 ICMP 协议部分除了 Type/Code/Checksum，还封装了原始 Echo 请求的 IP 层和 ICMP 层，这样源主机才知道是哪个包出了问题。第二类是 Time-to-live exceeded，Type 11，Code 0，这是 tracert 依赖的报文。

# Wireshark 过滤终点不可达 icmp.type == 3 # 过滤超时报文 icmp.type == 11 # 过滤所有 ICMP 差错报文（Type 3、4、5、11、12） icmp.type == 3 || icmp.type == 4 || icmp.type == 5 || icmp.type == 11 || icmp.type == 12

逻辑说明：icmp.type是显示过滤器里最直接的字段。参数上，Type 3 下面还有 Code 0 到 Code 15，分别表示网络不可达、主机不可达、协议不可达、端口不可达等。实验里常见的是 Code 0 和 Code 1。抓包时如果只看到 Echo request 没有 reply，先看有没有 Type 3 回来，这比盲目重 ping 有效得多。

4.3 用 pingtest 程序构造非标准 ICMP 询问

报告里用了一个 pingtest 程序来发地址掩码请求和时间戳请求，这两种报文普通 ping 命令发不出来。如果你手头没有这个程序，常见做法是用 Scapy 自己构造：

from scapy.all import * # 构造地址掩码请求 pkt = IP(dst="192.168.1.21")/ICMP(type=17, code=0)/ICMPAddrMask(address="0.0.0.0") send(pkt) # 构造时间戳请求 pkt = IP(dst="192.168.1.21")/ICMP(type=13, code=0)/ICMPTimestamp(orig=0, recv=0, trans=0) send(pkt)

逻辑说明：Scapy 的ICMPAddrMask和ICMPTimestamp是专门为这两类报文准备的层。参数上，address="0.0.0.0"是请求报文的固定填法，应答里会被填成实际掩码。orig、recv、trans三个时间戳在请求里通常填 0，应答里由目标主机填写。发完之后在 Wireshark 里用icmp.type == 17 || icmp.type == 18过滤，就能看到请求和应答成对出现。

注意：Scapy 发原始 ICMP 需要管理员/root 权限，Windows 下还要装 Npcap。如果发不出去，先检查权限和网卡选择，不要一上来就怀疑代码。

5. 实验避坑与排查：填表对不上、抓不到包、网关配错怎么办

5.1 抓不到 ARP 请求，只看到 ICMP

现象：ping 的时候 Wireshark 里只有 ICMP，没有 ARP。原因：ARP Cache 里已经有目标 IP 的 MAC 映射，主机不需要再发 ARP 请求。解决：先执行arp -d *（Windows）或ip neigh flush all（Linux）清空缓存，再 ping。如果还是抓不到，检查 Wireshark 抓的是不是正确的网卡，虚拟机组网时经常抓错虚拟网卡。

5.2 ARP 请求的 Target IP 填成了目标主机 IP

现象：跨网段实验里，填表时 Target IP Address 写成了 PC B 的 IP，和报告里的网关 IP 对不上。原因：没有理解 ARP 只在同一广播域内解析，跨网段时解析的是默认网关。解决：先确认 PC A 的默认网关配置，再抓包看 Target IP 是不是网关地址。如果是同网段实验，Target IP 才是目标主机 IP。

5.3 ICMP 差错报文里看不到原始请求的 IP 层

现象：抓到 Type 3 或 Type 11 报文，但展开后只有 ICMP 头，没有封装的原始 IP 包。原因：Wireshark 默认可能只解析到 ICMP 层，需要手动展开“Internet Protocol”和“Internet Control Message Protocol”两层。解决：在报文详情面板里逐层展开，差错报文的 ICMP 数据部分会完整封装原始请求的 IP 头和 ICMP 头。如果确实没有，可能是抓包长度不够，检查 Wireshark 的 snaplen 设置。

5.4 默认网关配错导致 ping 不通

现象：跨网段 ping 直接返回 Destination unreachable，或者完全没有回应。原因：默认网关 IP 写错，或者网关接口没配好。解决：用route print或ip route show确认默认路由指向正确的网关 IP；在网关设备上确认接口地址和路由表。实验报告里 PC A 的网关是 192.168.1.10，PC B 的网关是 192.168.2.10，配错一个就全断。

5.5 时间戳报文的三个时间戳字段分不清

现象：填表时 Originate、Receive、Transmit 三个字段不知道哪个对应哪个。原因：没有理解时间戳请求/应答的语义。解决：Originate 是发送方发出请求的时间，Receive 是接收方收到请求的时间，Transmit 是接收方发出应答的时间。请求报文里 Receive 和 Transmit 通常为 0，应答报文里三个都有值。报告里的实测数据是 Receive 和 Transmit 都是 14 小时 23 分 57.871 秒，说明处理延迟极小。

6. 把实验报告变成可复用的抓包分析模板

这份报告最大的价值，不是让你抄答案，而是它留下了一套可复用的分析路径。我后来把实验三的流程固化成了一个检查清单：先清 ARP Cache，再启动 Wireshark 抓包，然后用arp || icmp过滤，统计协议数量，接着按“请求/应答”成对展开字段，最后对照 Type/Code 表解释现象。这套流程不只适用于北航这个实验，任何涉及 ARP 和 ICMP 的网络层排查都能套。

如果你想把实验做得更扎实，可以在报告基础上加一步：用 Scapy 构造异常 ICMP 报文，比如错误的 Code 值，观察目标主机怎么回应。这一步能帮你理解 ICMP 差错报文的触发条件，而不是只停留在填表。参数上，Scapy 的ICMP(type=3, code=1)可以模拟主机不可达，配合 Wireshark 抓包，你能看到完整的差错报文结构。

还有一个我踩过的坑：虚拟机组网时，网卡模式选错会导致 ARP 广播收不到。VMware 下用 NAT 模式，宿主机和虚拟机之间的 ARP 行为跟桥接模式不一样。实验报告里用的是 192.168.1.x 网段，如果你复现时发现 ARP 请求发出去没有应答，先检查虚拟机网络模式，再检查防火墙。Windows 防火墙有时候会拦 ICMP，导致 ping 不通但 ARP 正常。

从那以后我每次做网络层实验，都强制自己先跑一遍arp -a和route print，确认缓存和路由表的状态，再开始抓包。这个习惯帮我省掉了大量“为什么抓不到”的无效时间。希望这份拆解能帮到你，实验报告里的字段和现象，照着复现一遍，比看十遍理论都管用。

本文还有配套的精品资源，点击获取