小型以太网组网实操指南：从设备选型到抓包排障

简介：一份针对计算机网络基础课程的实验指导文档，面向高校学生及自学者，目标是通过亲手组建小型以太网，掌握以太网基本搭建方法并理解局域网中软硬件协同工作的原理。内容以完整实验报告为主线：先规划网络框架，给出使用交换机连接终端、千兆端口互连两组局域网等拓扑参考；再配置主机软硬件环境，包括网卡安装、驱动程序部署、TCP/IP协议添加及IP地址分配；最后详述双绞线制作全流程，区分普通网线与交叉网线的EIA/TIA 568A/568B标准，并讲解压接RJ45接头的关键步骤与排错要点。整体设计贴近教学需求，能帮助读者规避常见的线序错误和配置遗漏。资源为单个PDF文件，大小约241KB，结构清晰、步骤齐全，便于在实验过程中随时对照操作。已有147人学习下载，适合计算机网络实验备查、作业参考或实训技能巩固，能显著提升组网动手能力。

1. 组建小型以太网：这个实验为什么值得认真做一遍

把两台电脑用一根网线连起来、配上 IP 就能互相 ping 通，看起来是计算机网络课里最不起眼的第一个实验。但恰恰是这个“简单”的实验，能把链路层、IP 层、ARP 解析、帧格式这些后面所有章节的地基一次性铺实。很多人在这个实验里翻车，不是不会敲命令，而是不知道集线器和交换机转发逻辑的差别、不知道交叉线和直通线在千兆网卡下为什么“都能用”、更不知道抓包看到的帧里藏着什么信息。

本文按“硬件选型 → IP 规划 → 连通性验证 → 抓包看帧”这条线，把组建小型以太网从零到一讲透。适合正在做课程实验的学生，也适合想补网络基本功的从业者——实验本身不复杂，但里面的参数细节和排错思路，能直接迁移到真实办公网和车载以太网的调试场景。

2. 先搞清楚拓扑和设备选型：交换机组网与共享式以太网的区别

2.1 集线器 vs 交换机：同样的接线，完全不同的转发逻辑

组建小型以太网，核心设备无非两个选择：集线器（Hub）或交换机（Switch）。课程实验里经常要求“先用集线器组网，再换成交换机对比”，这个对比本身就是实验的考点。

集线器工作在物理层，它收到任何端口上的电信号，会向所有其他端口原样广播出去，所有主机共享同一根总线，任意时刻只允许一对主机通信。两台主机同时发数据就会产生冲突，冲突域是全体端口。共享式以太网的组网就是这个原理，标准是 10BASE-T，半双工模式，用 CSMA/CD 机制协调发送。不要小看这套老机制，后面学交换机的 MAC 地址学习、VLAN 划分时，很多概念的出发点是“我要解决共享式以太网的那些痛点”。

交换机工作在数据链路层，它内部维护一张 MAC 地址表，收到帧后查表，知道目标 MAC 在哪个端口就直接点对点转发，不知道才广播。这样每个端口独立冲突域，全双工模式下根本不存在冲突问题。实验里如果只是两台电脑互联，交换机和集线器表现一样；但接三台以上设备时，交换机明显“聪明”得多。

2.2 直通线与交叉线：千兆网卡让老规矩失效了

设备选型确定之后，网线是下一个坑。传统的规则是：同种设备（电脑连电脑、交换机连交换机）用交叉线，异种设备（电脑连交换机）用直通线。交叉线把 1/2 和 3/6 两组线对调，因为早期网卡发送和接收各用固定线对，必须交叉对接。

但 1000BASE-T 千兆以太网标准里，四对线全部用于双向收发，网卡自己会做自动协商，所以现在千兆网卡用直通线也能电脑直连。这导致很多学生在实验里“随便拿一根线就通了”，反而忽略了线序的知识点。考试和实验报告里，建议把两种线序都写清楚：T568A 和 T568B 的线序排列，以及交叉线在 10/100M 时代为什么必要。实验台上如果用的还是百兆老设备，线序错了真的会不通。

2.3 最小组网拓扑：从两台到多台

建议实验按三步走，而不是一步到位接五台机器：

1. 两台电脑网线直连，不做任何交换机介入。这是最干净的调试环境，能排除设备故障变量。
2. 加一台交换机，三台或四台电脑接进来。验证交换机 MAC 地址表的自学习过程。
3. 有条件的话，把交换机换成集线器，对比同拓扑下抓包行为的变化。

这个递进顺序的价值在于：第一步排查物理层，第二步排查链路层，第三步对比设备原理。每步之间单独验证，不要一次接完再排错。

3. 配置 IP 与验证连通性：从 ping 通到抓帧看细节

3.1 规划 IP 地址：子网掩码和网段是第一个必坑点

组网完成后，最直接影响“能不能通”的是 IP 规划。小型实验网最常见的配置是 C 类私有地址段：192.168.1.0/24。子网掩码 255.255.255.0，网关可以不配，因为实验网不跨网段。

IP 规划表至少包含下面几项，写实验报告前先把这个表做出来

注意几个细节：网段必须一致，A 和 B 都在 192.168.1.x，掩码一致才能互相识别；IP 不能冲突，实验中最常见的故障就是两台机器被 DHCP 自动分配了同一个地址；如果实验网里还有一台机器开了 DHCP 服务，静态 IP 要和 DHCP 地址池错开，避免冲突。有一类实验讲义会把网关设为 192.168.1.1，但如果没接路由器，这个网关地址是空转的，不配也没问题——很多学生在配置界面看到“默认网关”就慌了，认为必须填。

3.2 Windows 静态 IP 配置与常用命令

Windows 上用图形界面配置最快，但命令行也必须会，因为实验考试经常只给命令行环境。配置静态 IP 的命令行写法，注意版本差异：

# 查看当前网卡的接口名称和索引号 ipconfig /all # 以管理员身份运行 PowerShell，给以太网接口配静态 IP New-NetIPAddress -InterfaceAlias "以太网" -IPAddress 192.168.1.10 -PrefixLength 24 -DefaultGateway 192.168.1.1 # PrefixLength 24 等价于子网掩码 255.255.255.0 # 如果实验网没有出口网关，DefaultGateway 可以不写 # 配置完成后立刻验证 ipconfig /all ping 192.168.1.20 -t

逻辑说明：New-NetIPAddress是在网卡上添加一个 IP 地址，不是修改。同一个网卡可以绑定多个 IP，实验里如果你的网卡已经有 DHCP 自动获取的地址，再绑静态 IP 是允许的。但要注意，绑定后路由表会多一条直连路由，如果原有 DHCP 地址和静态地址在不同网段，ping时可能走错接口。-PrefixLength 24是 CIDR 写法，24 就是 255.255.255.0，两者等价，配错一个数字就前功尽弃。

ping -t参数让 ping 持续运行，方便观察网络抖动，实验报告里截图的存活时间（TTL）也有讲究：Windows 默认 TTL 是 128，Linux 默认 64，如果 ping Windows 主机看到 TTL=128、ping Linux 主机看到 TTL=64，说明 IP 层转发正常。如果看到 TTL 莫名其妙变小，说明经过了多层路由转发。陈旧的 TTL 参数在混合操作系统实验环境里，可以帮你快速判断两台机器的系统类型。

3.3 Linux 侧配置：netplan 与 ip 命令

实验里如果有一台 Linux 主机，配置方式完全不同。Ubuntu 18.04 之后的版本用 netplan，配置文件是 YAML 格式。配置前先看清楚网卡名，别再默认 eth0 了，现在常见的是 ens33、ens5 这类由固件命名的接口。

# /etc/netplan/01-netcfg.yaml network: version: 2 renderer: networkd ethernets: ens33: dhcp4: false addresses: - 192.168.1.20/24 # 不加网关，实验网内部转发不需要网关 # nameservers: # addresses: []

# 应用配置 sudo netplan apply # 验证地址是否生效 ip addr show ens33 # 检查路由表，确认直连路由存在 ip route # 连通性测试 ping 192.168.1.10 -c 4

逻辑说明：dhcp4: false关闭自动获取，否则你配的静态 IP 会被 DHCP 覆盖。addresses列表里的192.168.1.20/24是 CIDR 格式，和 Windows 里的-PrefixLength 24对应。renderer: networkd是 Ubuntu 默认的网络管理后端，桌面版也可能是 NetworkManager，如果 apply 后 ip 命令没看到新地址，检查 renderer 是否匹配。

Linux 下最容易踩的坑是防火墙。Ubuntu 默认开启 ufw 时，ping 请求可能被拦。排错时先临时关掉它再定位问题：

# 临时关闭防火墙，实验结束记得恢复 sudo ufw disable ping 192.168.1.10 -c 4

另外，如果两台机器都是 Linux，直接用ip addr add 192.168.1.10/24 dev ens33临时加地址也可以，但重启失效。实验报告里建议写 netplan 方案，因为这代表你理解了持久化配置和临时配置的区别。

3.4 验证连通性的完整命令链路

从 ping 到确认数据真正通了，标准验证顺序如下：

# 第 1 步：验证本机 IP 配置正确 ip addr show | grep 192.168.1.10 # 第 2 步：验证到对端物理链路是否 up ethtool ens33 | grep "Link detected" # 输出应为 Link detected: yes，如果为 no，说明网线没插好或对端没开机 # 第 3 步：ping 对端 IP，验证 IP 连通性 ping 192.168.1.20 -c 4 # 第 4 步：查看 ARP 表，确认 MAC 解析成功 arp -a

这段命令链的每一步都是独立的验证点：第 1 步排除本机配置错误，第 2 步排除物理层问题，第 3 步验证 IP 层转发，第 4 步验证链路层地址解析。很多学生 ping 不通就干瞪眼，其实arp -a能告诉你答案——如果 ARP 表里对端 IP 的状态是 incomplete，说明对端根本没回应 ARP 请求，问题大概率在物理层或对端网卡；如果 ARP 解析成功但 ping 丢包，那才需要看防火墙和路由。

4. 抓包看帧格式与交换机行为：实验的核心环节

4.1 抓包前的三个准备动作

实验做到这里，网络已经通了，但课程设计里通常还要求“观察以太网帧格式”，这就是抓包的用途。Wireshark 是首选，免费且跨平台。抓包前有件事必须先做：把无关流量滤掉。Windows 主机后台可能有大量广播包、LLMNR 查询、mDNS 请求，这些会淹没实验产生的 ICMP 流量。

抓包前的三个准备动作，按顺序执行

# 1. 确认抓包网卡是实验网卡，别抓错接口 # Windows: Wireshark 选择"以太网"接口；Linux: 先 ip addr 看接口名，Wireshark 选择 ens33 # 2. ping 之前先清 ARP 缓存，保证能看到完整的 ARP 请求/应答过程 # Windows: arp -d # Linux: sudo ip neigh flush all # 3. 设置抓包显示过滤器，只看实验流量 # 显示过滤器：icmp || arp

这些准备动作不是可选项。不清 ARP 缓存的话，第一次 ping 之前系统已经做过地址解析，抓到的包就只有 ICMP echo request/reply，ARP 过程被错过。只过滤 ICMP 的话，交换机 MAC 地址表的学习过程也看不到。

4.2 看懂一个标准的以太网帧

抓包后双击任意一个 ICMP 包，看 Ethernet II 层的字段，这是实验报告里必须截图的内容。一个标准以太网帧包含以下字段，要能对着帧格式图说出来：

这里有个细节值得单独讲：以太网最小帧长是 64 字节，从目的 MAC 到 FCS 结尾。ARP 请求包因为载荷太短，必须填充到 46 字节才能凑满最小帧长。抓包能看到 ARP 包数据区尾部一串 0x00，这就是填充。理解这个填充机制，后面学 VLAN 标签（4 字节插入后会改变最小帧长计算）、学车载以太网的时候，就不会被“为什么帧长和 MTU 对不上”困扰。

4.3 交换机 MAC 地址表养成观察

现在把抓包点放在交换机连接的其中一台主机上，另一台主机持续 ping 第三台，观察 ARP 和 ICMP 的配合。交换机内部地址表学习过程在 Wireshark 里看不到，但可以通过一个技巧间接验证：把网线从交换机端口 1 换到端口 2，如果交换机有 CLI 管理界面，用show mac address-table查看地址表老化前后的状态变化；如果用的是傻瓜交换机，就改用 arping 测试。

课程实验做到这步就够了：明确交换机是“学习源 MAC、转发按目标 MAC”，而不是像集线器那样对所有端口复制。实验报告里建议画一张图，标注三台主机的 MAC 地址和交换机端口的对应关系，这个图比任何文字都值钱。实际工作中排查网络环路和 MAC 漂移问题，看的也是这张表。

4.4 集线器环境下的抓包对比

把交换机换成集线器，同样拓扑再抓一次包，你会看到完全不一样的画面：主机 A 发给主机 B 的单播帧，主机 C 的网卡也会收到。因为集线器广播所有帧，主机 C 的网卡收到后检查目标 MAC 不是自己，正常应丢弃；但在 Wireshark 里，只要网卡没开过滤，混杂模式下这些帧照样显示出来。这个实验直观展示冲突域的概念：集线器下所有端口在同一冲突域，交换机下每个端口独立冲突域。

对比实验不用做太久，抓几十个包足够说明问题。注意观察 Wireshark 右下角的统计信息：集线器环境下帧数量明显更多，而且可能看到 CRC 错误或短帧——这通常是多主机同时发送导致冲突后的残帧，411 错误在共享式以太网里并不稀奇。

5. 组建小型以太网的典型坑与排查路径：现象、原因、解决

5.1 “网线插了但网络适配器显示电缆被拔出”

现象：Windows 右下角网络图标显示红色叉号，ipconfig里以太网适配器状态为“网络电缆被拔出”，Linux 下ethtool ens33显示 Link detected: no。

原因分析：首先排查物理层。网线没插到位、水晶头松动、线序错误、网口指示灯不亮都属于这一类。另一个常见原因是网线质量太差，特别是实验室里那种反复插拔的水晶头，金属簧片弹力下降导致接触不良。还有一种容易忽略的情况：对端设备没开机或网卡被禁用，链路协商无法完成。

解决办法：重新压线或换一根已知完好的网线；确认对端设备已开启且网卡启用；检查链路协商状态，用ethtool ens33查看 Speed 和 Duplex，如果显示 Speed: Unknown!，说明物理链路没起来。不要一上来就查 IP 配置，物理层不通一切免谈。

5.2 IP 配置正确但 ping 不通，ARP 表显示 incomplete

现象：ip addr看到的 IP 和掩码都没问题，但 ping 对端超时，arp -a里对端条目状态是 incomplete。

原因分析：ARP 请求发出去了，但没收到应答。可能是对端防火墙拦截了 ARP（少见但存在），更常见的是对端 IP 配置根本没生效——比如 Linux 下改了/etc/network/interfaces但忘了重启网络服务，或者 Windows 上静态 IP 和 DHCP 冲突导致网卡显示“未识别的网络”。还有一类情况：两台机器 IP 在不同网段，但没人配置网关，ARP 请求被本机路由表直接丢弃。

解决办法：先在对端机器上ip addr show确认地址确实生效；再在两端分别arp -d清缓存重试；Linux 下检查ufw status和iptables -L；最后确认掩码一致。如果对端是多网卡机器，还要检查路由表，确保回包走的接口和 ARP 请求进来的接口一致，否则就是异步路由问题。

5.3 能 ping 通但 Wireshark 抓不到包

现象：ping 持续正常返回，但 Wireshark 里什么流量都看不到，或者只看到其他主机的广播包。

原因分析：抓包接口选错是最常见原因。笔记本往往同时有有线以太网口和无线网卡，Wireshark 默认选中的可能是无线网卡。另外 Windows 上如果没有安装 Npcap 驱动，Wireshark 根本抓不了包。还有一种情况是抓包过滤器写错，比如把icmp || arp写成了icmp && arp，导致所有包都被过滤掉。

解决办法：查看抓包窗口状态栏显示的接口名，确认是“以太网”而不是“WLAN”；重装 Npcap 驱动并以管理员身份运行 Wireshark；检查显示过滤器和抓包过滤器两处设置。注意显示过滤器不影响抓包，抓包过滤器在 Wireshark 主界面顶部的绿色条里，两者的语法和时机完全不同。

5.4 集线器组网时 ping 通但传输极慢

现象：多台主机通过集线器组网，能 ping 通，但拷贝文件速度只有几十 KB/s，CPU 占用率还特别高。

原因分析：集线器是半双工共享信道，主机越多冲突概率越高。CSMA/CD 机制下，冲突后要随机退避重发，负载一高就陷入“冲突-退避-重发”的恶性循环。抓包会看到大量 CRC 错误帧和短帧，这都是冲突留下的残骸。

解决办法：实验目的是观察现象，保留这个状态抓包截图写进报告即可。实际组网直接把集线器换成交换机，问题立刻消失。需要注意的是，有些交换机支持强制 10M 半双工模式，如果网卡协商成了半双工，同样会有类似症状。检查ethtool ens33里的 Speed 和 Duplex 字段，确认是 1000Mb/s 全双工再继续排查。

5.5 明明接了交换机，但抓包里仍有广播风暴迹象

现象：三台主机的抓包里，有大量重复的 ARP 请求和 NetBIOS 广播，即使没有主动通信，每秒都有几个包。

原因分析：这是正常现象，不是故障。Windows 主机默认开启了网络发现、LLMNR 等协议，会周期性发广播包，和交换机无关。交换机只是把广播包转发到所有端口，并不产生广播包。这和“以太网下面怎么会有无线网的名称”是同一个原理——网络发现机制会主动探测周围设备，和实际物理拓扑无关。

解决办法：实验抓包时用显示过滤器把广播帧滤掉，只看目标 MAC 是自己网卡的帧，即eth.dst == 你的MAC。不要在实验里纠结清理广播流量，那是真实网络运维的工作，课程实验只需要理解广播域的边界在路由器。

6. 进阶技巧：用帧间隔和 CRC 统计给实验网做体检

实验做到 ping 通、抓包到帧，只算及格线。建议再花半小时做一个帧级体检，这套方法在真实网络排障里同样管用。

第一个技巧是检查帧间隔。以太网标准规定两个帧之间至少要有 96 bit 的空闲时间，百兆以太网下约等于 9.6 微秒，千兆下约等于 0.96 微秒。Wireshark 在 “Statistics → TCP Stream Graph” 里看不出这个，但可以通过 “Statistics → Capture File Properties → Capture File Details” 看平均数据速率和包速率，如果包速率超过理论上限，说明帧间隔时间太长或碎片包太多。更直接的办法是设置显示过滤器frame.time_delta < 0.000096，找出间隔小于标准的帧，这些帧往往对应网卡驱动的发送队列问题。我在排查车载以太网某个节点丢包问题时，就是靠这条过滤器锁定了一个驱动层缓存配置错误。

第二个技巧是统计 CRC 坏帧。在 Linux 下用 tcpdump 直接统计：

# 在实验网主机上统计坏帧数量 sudo tcpdump -i ens33 -e -nn 'ether[20:2] != 0' -c 100 # 解释：-e 显示以太网层头部，ether[20:2] 指向 FCS 校验位置 # 正常情况下没有输出，如果有输出说明链路存在比特错误 # 更简单的方式：用 Wireshark 的 IO 图表，显示过滤器设为 eth.fcs.bad # eth.fcs.bad == 1 代表 FCS 校验失败的帧

逻辑说明：ether[20:2] != 0这个过滤条件不是标准用法，它依赖帧结构偏移，但教育实验里不建议深究，直接用 Wireshark 的frame.check字段更清晰：frame.check && frame.check.status == "Bad"。CRC 坏帧出现的原因通常不是线缆，而是网卡和交换机端口之间的电平匹配问题。以太网电平标准里，发送端用差分信号驱动，如果网线过长、水晶头氧化、或者用了质量差的线缆导致衰减，误码率就会上升。

第三个技巧是用 Python 构造一个自定义以太网帧，验证你对帧格式的理解，而不是只用 ping 产生现成的流量。用 scapy 发一个最小帧看真实抓包：

from scapy.all import Ether, IP, ICMP, sendp # 构造以太网帧：目标 MAC、源 MAC 填本机实网卡 MAC，Type 自动识别 frame = Ether(dst="ff:ff:ff:ff:ff:ff", src="aa:bb:cc:dd:ee:ff") / IP(dst="192.168.1.20") / ICMP() # 直接在第 2 层发送，不经过系统路由表 sendp(frame, iface="ens33", verbose=True) # 参数说明：iface 指定物理网卡，默认走 eth0，名字不对会报错

这个脚本的坑在于：scapy 默认发的帧可能比最小帧长还短，如果不用默认值而手工删掉填充，实际发出去的会是 runt 帧，交换机会直接丢掉。我一般会在构造完帧后加一句frame = frame / b"\x00" * 46把载荷补足，这个细节也是当年踩出来的——曾经用 scapy 发了一个 24 字节的帧，抓包软件能看到，但交换机端口统计里计数为“丢弃帧数量 +1”。所以发帧之前先想清楚以太网最小帧长 64 字节这个约束，载荷不足 46 字节时必须补零。

做完这三项体检，一份小型以太网实验报告拿到手就不再只是“ping 通了”四个字。你手里有了物理层状态、链路层坏帧率、帧间隔分布这组指标，任何时候再遇到网络诡异问题，都知道先看物理层再查链路层，而不是一上来就重装驱动。这算是我做网络调试这些年最值回票价的一个习惯，希望帮到你。

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