1.4 搭建报文解剖台：Mininet 与抓包环境

1.4 搭建报文解剖台：Mininet 与抓包环境

本节摘要：解剖报文需要一个能随时复现协议交互的环境。本节用 Mininet（轻量网络仿真器）加 Open vSwitch 加 Wireshark 搭一套最小实验台，跑通"启动拓扑 → 连接控制器 → 抓到 OpenFlow 报文"全流程。后续章节的所有字节级分析都可以在这套环境里对照验证。

学习目标

阅读完本节，你应当能够：

1. 搭建 Mininet + 控制器 + Wireshark 实验环境
2. 抓到并识别一次 OpenFlow 握手（Hello 交换）
3. 用命令查看交换机上的流表条目

为什么是这套组合

真实 OpenFlow 交换机贵且难折腾，而 Mininet 在一台 Linux 机器（或虚拟机）上用进程模拟主机、Open vSwitch 实例模拟交换机，控制通道是真协议栈——抓到的报文与生产环境别无二致。对解剖来说，"报文是真的"就够了。

组件分工：

五步搭台

以下命令在 Ubuntu 上执行（虚拟机亦可）：

# 1 安装基础件
sudo apt install mininet openvswitch-switch wireshark
sudo pip install ryu

# 2 启动控制器（另一个终端）
ryu-manager ryu.app.simple_switch_13

# 3 启动两主机一交换机拓扑
sudo mn --controller=remote,ip=127.0.0.1 --switch ovsk,protocols=OpenFlow13

# 4 在 Mininet 内触发流量
mininet> h1 ping h2

# 5 抓包（第三终端），过滤 OpenFlow
sudo tcpdump -i lo -w of.cap tcp port 6653
​

抓到的 of.cap 用 Wireshark 打开，过滤器输入 openflow，你会看到会话开头的三次握手之后紧跟两帧 Hello——这就是解剖的第一份标本。

实验台数据面与控制面视图

验证解剖台工作正常

两个必做的验证动作：

验证一：看流表。 在 Mininet 里让 h1 ping h2 之后退出到宿主 shell：

sudo ovs-ofctl -O OpenFlow13 dump-flows s1
​

输出里应能看到两条匹配 h1、h2 MAC 的条目，idle_timeout 默认由控制器应用决定（simple_switch_13 不设超时，条目常驻）。这就是 1.3 节说的"Flow-Mod 落地后的样子"。

验证二：看握手。 Wireshark 里按时间序应看到：TCP 三次握手 → 双方各发一条 Hello（版本位 0x04 即 1.3）→ Features-Request / Features-Reply → 一串 Echo。2.6 节会把这条时间线逐帧拆开。

⚠️ 常见坑：Mininet 退出后残留的 OVS 实例会让下次实验端口对不上。用 sudo mn -c 清理后再起拓扑。
⚠️ 常见坑：tcpdump 抓不到不代表没有流量——控制通道默认走回环口，抓 eth0 是白忙一场。

排错手册：搭台失败的四种典型现场

环境搭建的失败模式高度收敛，基本逃不出下面四种。第一种，启动拓扑时报 "Cannot find required executable controller"。这是上次实验的残留进程占着 6653 端口，先 sudo mn -c 清场再重来；这个命令会杀掉残留的 OVS 实例、清理 /tmp 下的网络文件，养成每次实验前先跑一遍的习惯。

第二种，Ryu 明明启动了，拓扑也起了，但 Wireshark 里一条 OpenFlow 都没有：

# 诊断三连：
ss -tlnp | grep 6653        # 控制器真的在监听吗？没有则回查 Ryu 启动报错
sudo ovs-vsctl get-controller s1   # 交换机记录的目标地址对吗
# 输出应为 "tcp:127.0.0.1:6653"；若为空说明拓扑用了默认控制器参数
sudo ovs-vsctl show | grep -A2 is_connected
#       is_connected: true       <- 必须是 true
​

第三种，报文抓到了但 Wireshark 显示成一堆 TCP 裸数据。原因是老版本 Wireshark 的 OpenFlow 解析器只认 6633，或没有跟随版本。两个解法：升级到 2.x 以上；或手动 Decode As 指定 OFP 端口。判断解析器是否工作，看 Hello 帧能不能展开出 "OpenFlow Protocol" 层。

第四种，h1 ping h2 第一次通、后面也通，但 dump-flows 永远是空的。这多半是拓扑起在了 legacy 模式，OVS 以 NORMAL 动作自转，根本没接控制器。验证办法是看交换机的控制器表项（如上 is_connected），以及抓包里有没有 Features-Request——没有控制报文的"能通"，对解剖台来说等于白搭。

提高复现质量的两个习惯

第一，把每次实验的拓扑参数固化成命令行注释或小脚本，尤其记录 --topo 与 --mac 参数。--mac 让主机 MAC 变成 00:00:00:00:00:0N，抓包时字段一眼可认，代价是失去了真实随机 MAC 的混乱感——学习协议时前者价值大得多。第二，给每次抓包立即改一个有语义的文件名（如 01-hello-only.pcap、02-first-ping.pcap），并随手记一行"触发条件"。第 2 章的逐帧解剖会反复回放这些文件，命名混乱的 pcap 目录是未来自己的敌人。

本节要点回顾

• 组合拳：Mininet 出拓扑，OVS 出交换机，Ryu 出控制器，Wireshark 出解剖镜
• 控制通道：本机实验走回环口，端口 6653，过滤词 openflow
• 两个验证：dump-flows 看规则落地，Hello 序列看握手成功
• 清理习惯：mn -c 是下次实验不出妖的前置条件

环境就绪，下一章正式把报文放上解剖台。