1. 为什么要在单机上折腾虚拟网络实验刚入行那会儿我最头疼的就是网络实验环境。想验证一个路由策略、抓一次TCP握手、复现一个ARP异常要么去借几台物理机要么在虚拟机里套娃装完系统配完网卡半天就过去了。后来接触到Linux网络命名空间network namespace和Mininet这套组合才发现原来一台普通笔记本就能跑出几十个节点的拓扑而且启动只要几秒。这套方案的核心价值就三个字轻、快、真。轻是指资源占用小一个命名空间本质上就是内核里的一组网络栈配置没有额外的虚拟化开销快是指拓扑搭建和销毁都是秒级改完脚本立刻能验证真是指它用的是Linux内核真实的协议栈抓包、调参数、看路由表和真机行为一致。这篇文章适合谁看如果你是网络方向的学生、刚转行做云网络或容器网络的工程师、或者单纯想搞明白“一个网卡怎么同时属于多个网络”的运维那这套东西值得花一个下午搭起来。我会从命名空间的底层逻辑讲起把Mininet的封装机制拆开然后给出一套可以直接抄的实操流程最后把我踩过的坑和排查套路整理成速查表。全程不需要额外硬件一台装了主流Linux发行版的机器就够。需要提前说明的是网络命名空间和Mininet都不是新东西网上零散资料很多但大多要么只讲命令不讲原理要么直接甩一个复杂脚本让人看不懂。我写这篇的目的是把“为什么这么设计”和“具体怎么敲”串起来让你看完能自己改拓扑、自己加链路参数而不是只会跑别人的demo。2. 核心机制拆解命名空间与Mininet到底做了什么2.1 网络命名空间内核里的独立网络栈理解网络命名空间最直观的类比是“把一台机器的网络部分切成了好几个平行世界”。每个命名空间里有自己独立的网卡列表、路由表、ARP缓存、iptables规则、socket端口空间。默认情况下进程活在初始命名空间里你ip netns add ns1之后内核就为ns1创建了一套全新的网络栈此时它里面只有一个down掉的loopback其他什么都没有。关键点在于命名空间之间的隔离是内核级别的不是模拟出来的。你在ns1里ping 127.0.0.1能通在ns2里也ping 127.0.0.1能通两者互不干扰因为loopback是各自独立的。这就解决了“同一台机器上多个网络环境共存”的根本矛盾。以前要做这种事得开虚拟机现在一个命令搞定。那命名空间之间怎么通信靠veth pair虚拟以太网对。你可以把veth pair想象成一根网线的两端一端插在ns1里另一端插在ns2里数据从一端进去从另一端出来。创建方式是ip link add veth0 type veth peer name veth1然后把veth0塞进ns1veth1塞进ns2各自配上同网段IP就能通了。这个过程中内核只做了数据包的转发没有经过任何物理网卡所以延迟极低。还有一个容易忽略的点命名空间里的进程怎么和外部世界交互答案是靠NAT或者路由转发。比如你在ns1里想访问公网需要把ns1的默认路由指向宿主的一个veth地址然后在宿主上开IP转发并配MASQUERADE规则。这套逻辑和容器网络是一模一样的Docker的bridge模式底层就是命名空间加veth加iptables。2.2 Mininet把手工命令封装成可编程拓扑如果只有命名空间搭一个五节点拓扑你得敲几十条命令改一次拓扑重来一遍效率太低。Mininet的价值就在于它把这套手工操作抽象成了Python API和一套CLI。你用几行代码描述“我要两个交换机、四个主机、链路带宽10Mbps、延迟5ms”Mininet就自动帮你创建命名空间、插veth、配IP、设tc规则、启动OpenFlow交换机默认是Open vSwitch。Mininet的架构分三层。最底层是Linux的网络原语就是命名空间和veth。中间层是Open vSwitch负责交换逻辑支持OpenFlow协议这意味着你可以接外部控制器做SDN实验。最上层是Python库提供Topo类让你自定义拓扑还有mn命令行工具做交互。它默认给每个主机分配一个命名空间主机名就是命名空间名你mininet h1 ping h2的时候实际上是在h1的命名空间里执行ping。这里有个设计取舍值得说Mininet默认用Open vSwitch而不是Linux bridge。原因是OVS支持OpenFlow能做流表编程适合SDN教学和研究。但OVS本身有一定资源开销如果你只是想做纯路由实验用Linux bridge或者直接手动配命名空间会更轻。我个人的选择是做SDN相关实验用Mininet加OVS做纯协议栈验证或者容器网络原理验证直接手写命名空间脚本更可控。另一个关键参数是--switch可以指定ovs、ovsbr、lxbr等。lxbr就是Linux bridge资源占用小但不支持OpenFlow。还有--controller参数默认Mininet会启动一个内置的控制器如果你要接外部控制器比如Ryu或者ONOS就把它设成remote并指定IP端口。2.3 两者结合后的能力边界这套组合能做什么我列几个实际跑过的场景验证OSPF或者BGP的收敛行为在Mininet里跑Quagga或FRR、测试TCP拥塞控制算法在不同延迟带宽下的表现、复现ARP欺骗和防御、模拟多租户网络隔离、做OpenFlow流表下发实验。基本上只要不涉及物理层特性比如无线信号衰减、光模块兼容性逻辑层的网络行为都能模拟。不能做什么第一它不模拟物理链路误码和信号干扰链路质量靠tc的延迟、丢包、抖动参数来近似。第二它的吞吐量受限于单机CPU和内存跑大带宽测试比如10Gbps以上不现实一般用来验证功能而非性能。第三它不涉及真实硬件卸载比如SR-IOV、DPDK这些所以高性能数据面实验得换方案。理解这些边界很重要否则你可能会在Mininet里花大量时间调一个根本不该用它测的性能指标。我的经验是功能验证用Mininet性能基线用物理机或专业测试仪两者分工明确。3. 环境搭建与基础实操从零到第一个拓扑3.1 系统准备与依赖安装我用的环境是Ubuntu 22.04内核5.15这是比较稳的组合。其他主流发行版也可以但包名和默认配置有差异下面以Debian系为例。首先确认内核支持命名空间uname -r看版本2.6.24以后都支持现在基本不用担心。然后装Mininet官方推荐用源码安装因为apt源里的版本可能偏旧。源码安装的步骤是git clone官方仓库进入目录执行sudo util/install.sh -a。这个脚本会自动装Open vSwitch、OpenFlow参考实现、wireshark的OpenFlow解析插件等。整个过程大概五到十分钟取决于网络。装完后sudo mn --test pingall验证如果看到所有主机两两ping通说明基础环境OK。这里有个坑如果你机器上已经有Open vSwitch在跑比如装了Docker或者KVMinstall.sh可能会和现有OVS冲突。我的做法是先systemctl stop openvswitch并禁用开机启动等Mininet装完再决定要不要恢复。另外install.sh会修改一些系统配置建议在干净的虚拟机或者容器里做别在生产机上直接跑。还有一个依赖是iproute2ip netns命令就来自它。大部分发行版默认都有如果没有就apt install iproute2。抓包工具tcpdump和wireshark也建议装上后面排查问题全靠它们。3.2 手工创建命名空间先搞懂底层再上封装在碰Mininet之前我强烈建议先手工做一遍命名空间互联这样后面Mininet出问题你能定位到底层。流程如下# 创建两个命名空间 sudo ip netns add ns1 sudo ip netns add ns2 # 创建veth pair sudo ip link add veth1 type veth peer name veth2 # 把两端分别塞进两个命名空间 sudo ip link set veth1 netns ns1 sudo ip link set veth2 netns ns2 # 在ns1里配IP并启用 sudo ip netns exec ns1 ip addr add 10.0.0.1/24 dev veth1 sudo ip netns exec ns1 ip link set veth1 up sudo ip netns exec ns1 ip link set lo up # 在ns2里配IP并启用 sudo ip netns exec ns2 ip addr add 10.0.0.2/24 dev veth2 sudo ip netns exec ns2 ip link set veth2 up sudo ip netns exec ns2 ip link set lo up # 测试连通性 sudo ip netns exec ns1 ping -c 3 10.0.0.2如果ping通了恭喜你你已经理解了Mininet最核心的那层。注意ip netns exec这个前缀它的作用是在指定命名空间里执行命令。Mininet的CLI本质上就是帮你自动加了这个前缀。清理的时候用ip netns del ns1和ip netns del ns2veth pair会随之消失。这里有个细节删除命名空间时里面的veth会自动被内核回收但如果你先把veth删了再删命名空间也没问题。我习惯先删命名空间省事。3.3 Mininet快速上手第一个自定义拓扑手工验证完上Mininet。先用内置的mn命令跑一个最简单的树形拓扑sudo mn --topo tree,depth2,fanout2 --controllerdefault这条命令会创建一个深度2、扇出2的树也就是1个根交换机、2个叶子交换机、4个主机。进入CLI后pingall测试全连通dump看节点信息h1 ping h2测单对连通。exit退出后Mininet会自动清理所有命名空间和OVS网桥这点比手工脚本省心。但真正有用的是自定义拓扑。下面是一个我常用的Python脚本定义了两个交换机、四个主机、链路参数各不相同的拓扑from mininet.topo import Topo from mininet.net import Mininet from mininet.node import OVSController from mininet.link import TCLink from mininet.cli import CLI class MyTopo(Topo): def build(self): # 添加两台交换机 s1 self.addSwitch(s1) s2 self.addSwitch(s2) # 添加四台主机 h1 self.addHost(h1, ip10.0.1.1/24) h2 self.addHost(h2, ip10.0.1.2/24) h3 self.addHost(h3, ip10.0.2.1/24) h4 self.addHost(h4, ip10.0.2.2/24) # 主机到交换机的链路带带宽和延迟参数 self.addLink(h1, s1, bw10, delay5ms) self.addLink(h2, s1, bw10, delay5ms) self.addLink(h3, s2, bw5, delay20ms) self.addLink(h4, s2, bw5, delay20ms) # 交换机之间的链路 self.addLink(s1, s2, bw20, delay10ms) if __name__ __main__: topo MyTopo() net Mininet(topotopo, controllerOVSController, linkTCLink) net.start() CLI(net) net.stop()保存成mytopo.py用sudo python3 mytopo.py运行。注意linkTCLink这个参数没有它的话bw和delay不会生效。TCLink底层用的是Linux的tc命令给veth接口加qdisc规则所以延迟和带宽是真实生效的不是模拟值。跑起来后你可以h1 ping h3会看到延迟明显比h1 ping h2大因为跨交换机链路有10ms延迟h3到s2还有20ms。这就是TCLink的价值能构造出异构网络环境。4. 进阶实操抓包、调参、接控制器4.1 在命名空间里抓包的正确姿势Mininet环境里抓包有两种方式。第一种是在CLI里用h1 tcpdump -i h1-eth0 -w /tmp/h1.pcap注意主机名后面的接口名格式是主机名-ethX。第二种是在宿主机上直接对veth接口抓包先用ip link找到对应的veth然后tcpdump -i vethXXX。两种方式各有用途前者抓的是主机视角的包后者抓的是链路视角的包排查链路层问题时后者更直接。我踩过的一个坑是在Mininet CLI里执行tcpdump后如果直接exit退出tcpdump进程可能没被清理干净导致下次启动时端口或文件被占用。正确做法是在CLI里先CtrlC停掉tcpdump再退出。或者用h1 kill %tcpdump这种job control的方式。另外抓包文件默认存在命名空间的挂载点里但命名空间共享宿主文件系统所以/tmp/h1.pcap在宿主上也能直接看到。还有一个技巧如果你想抓交换机之间的流量可以在OVS网桥上抓。ovs-vsctl list-ports看端口名然后tcpdump -i s1-eth3。这个接口是OVS的内部端口能看到经过交换机的所有包包括广播和未知单播泛洪。4.2 链路参数调优带宽、延迟、丢包、抖动TCLink支持的参数不止bw和delay还有loss丢包率、jitter抖动、max_queue_size队列长度。这些参数底层都是通过tc qdisc实现的。比如loss5表示5%丢包jitter2ms表示延迟在基准值上下浮动2ms。这里要理解一个原理tc的netem模块对延迟的实现是“排队等待”包进入qdisc后按设定时间延迟发出。如果队列满了后续包会被丢弃。所以当你设了很小的max_queue_size和较大的延迟时可能会观察到意外丢包这不是bug是队列溢出。我一般会把max_queue_size设成100以上除非专门测拥塞。带宽限制用的是tbftoken bucket filterbw10表示10Mbps。注意这个值是单向的如果你要双向限制得在链路两端都设。Mininet的addLink默认在两端都加规则所以实际是双向各10Mbps。但如果你手工用tc配容易只配一边导致单向限速测出来的吞吐量会翻倍。实测数据在i7-1165G7的机器上两个命名空间之间用veth直连不设任何tc规则iperf3能跑到20Gbps以上。加了bw100之后稳定在95Mbps左右加了delay10ms之后RTT稳定在20ms出头往返各10ms。这些数字可以作为你判断环境是否正常的基线。4.3 接入外部控制器做SDN实验Mininet默认启动一个内置控制器功能很简单就是学习交换机行为。要做真正的SDN实验得接外部控制器。以Ryu为例先在宿主机上pip install ryu然后写一个简单的app或者直接用Ryu自带的simple_switch_13.py。启动命令是ryu-manager simple_switch_13.py默认监听6633端口。然后Mininet启动时指定--controllerremote,ip127.0.0.1,port6633。这样OVS就会把流表下发请求发给RyuRyu按自己的逻辑决定转发行为。你可以改Ryu的代码实现自定义转发比如根据源IP做策略路由或者实现一个简单的防火墙。这里有个常见问题控制器和Mininet不在同一台机器时要确保防火墙放行6633端口并且Mininet的--controller参数里IP要写控制器的实际可达地址。另外OVS和控制器之间的连接是TCP如果控制器挂了OVS会进入“fail secure”模式默认行为是丢弃所有包。调试时如果发现网络突然不通先检查控制器进程还在不在。5. 常见问题与排查速查表5.1 启动失败与资源冲突现象可能原因排查命令解决方法mn启动报错“Cannot find required executable”依赖没装全which ovs-vsctl重跑util/install.sh -a启动后ping不通OVS服务没起来systemctl status openvswitch启动OVS并检查日志命名空间创建失败残留命名空间占名ip netns listip netns del清理残留端口被占用上次Mininet没清理干净ps aux | grep mnkill残留进程mn -c清理mn -c是我用得最多的命令它会清理所有Mininet创建的命名空间、OVS网桥、veth接口和tc规则。有时候Mininet异常退出残留一堆东西直接mn -c比手工清理快得多。但注意它会删掉所有以mn开头的命名空间如果你有自己手工建的命名空间叫mnXXX也会被误删所以命名时避开这个前缀。5.2 连通性问题的分层排查法网络不通时我按从下到上的顺序查第一层看接口状态ip netns exec h1 ip link确认接口是UP第二层看IP配置ip netns exec h1 ip addr确认地址和掩码正确第三层看ARPip netns exec h1 ip neigh看有没有解析到对端MAC第四层看路由ip netns exec h1 ip route确认路由表有对应条目第五层抓包在两端同时tcpdump看包有没有发出去、有没有收到。大部分问题出在第二层和第三层。比如掩码配错导致同网段判断失误或者ARP没解析成功导致包发不出去。Mininet默认会给主机配好IP和路由但如果你自定义拓扑时手写了IP容易漏掉网关或者掩码写错。我的习惯是自定义拓扑里IP一律用/24网关用网段第一个地址减少出错概率。还有一个隐蔽问题OVS网桥的STP生成树协议默认是关闭的。如果你搭了环形拓扑又没开STP广播风暴会瞬间打满CPU。Mininet的--switch ovs默认不开STP需要手动ovs-vsctl set bridge s1 stp_enabletrue。做环形实验时务必记得这一步。5.3 性能异常的定位思路如果iperf3测出来的吞吐量远低于预期先确认三件事一是tc规则有没有生效tc qdisc show dev h1-eth0看有没有netem或tbf二是CPU是不是瓶颈top看ksoftirqd和ovs-vswitchd的占用三是veth的MTU默认1500如果设小了会分片影响性能。我遇到过一次诡异情况两个主机之间ping延迟正常但iperf3吞吐只有几百Kbps。查了半天发现是max_queue_size设成了10而延迟设了50ms导致队列频繁溢出TCP疯狂重传。把队列调到1000后恢复正常。这个教训是延迟和队列长度要匹配高延迟链路需要更大的队列来吸收在途数据。另一个常见误区是拿Mininet测绝对性能。前面说过它受限于单机资源而且OVS是用户态转发除非用DPDK加速所以吞吐量天花板不高。正确的用法是测相对性能比如对比两种拥塞控制算法在同一拓扑下的表现或者验证某个参数调整带来的趋势变化。6. 我个人的实操心得与扩展方向这套东西我用了大概三年最大的体会是不要一上来就追求复杂拓扑。我见过不少人直接抄一个几十节点的脚本跑起来一堆问题最后连哪个环节出错都不知道。正确的路径是先手工敲命名空间命令理解底层再用Mininet跑两节点然后逐步加交换机、加链路参数、加控制器。每一步都验证通过再往下走这样出问题能快速定位。另一个心得是关于脚本管理。我习惯把拓扑定义、启动逻辑、测试用例分成三个文件。拓扑文件只描述节点和链路启动文件负责实例化和CLI测试文件用Mininet的Python API做自动化验证比如net.pingAll()返回丢包率。这样改拓扑不影响测试逻辑复用性高。测试文件可以集成到CI里每次改完拓扑自动跑一遍连通性和性能基线。扩展方向有几个我觉得值得深入一是结合FRRFree Range Routing做动态路由实验在Mininet主机里跑OSPF或BGP观察收敛过程二是结合P4和BMv2做可编程数据面实验这个比OpenFlow更底层三是把Mininet拓扑导出成容器网络配置验证Kubernetes的CNI插件行为。这几个方向我都试过一部分后面有机会再单独写。最后分享一个小技巧Mininet的CLI支持py命令执行Python代码比如py net.get(h1).cmd(ip addr)这比在CLI里敲shell命令灵活得多。你可以用这个特性在CLI里动态改配置、读状态、做断言。我经常用它来快速验证某个想法不用退出重写脚本。 
长河君 · 2026/10/19 12:48:24 · 阅读 1.2k Linux网络命名空间与Mininet：单机虚拟网络实验入门
1. 为什么要在单机上折腾虚拟网络实验刚入行那会儿我最头疼的就是网络实验环境。想验证一个路由策略、抓一次TCP握手、复现一个ARP异常要么去借几台物理机要么在虚拟机里套娃装完系统配完网卡半天就过去了。后来接触到Linux网络命名空间network namespace和Mininet这套组合才发现原来一台普通笔记本就能跑出几十个节点的拓扑而且启动只要几秒。这套方案的核心价值就三个字轻、快、真。轻是指资源占用小一个命名空间本质上就是内核里的一组网络栈配置没有额外的虚拟化开销快是指拓扑搭建和销毁都是秒级改完脚本立刻能验证真是指它用的是Linux内核真实的协议栈抓包、调参数、看路由表和真机行为一致。这篇文章适合谁看如果你是网络方向的学生、刚转行做云网络或容器网络的工程师、或者单纯想搞明白“一个网卡怎么同时属于多个网络”的运维那这套东西值得花一个下午搭起来。我会从命名空间的底层逻辑讲起把Mininet的封装机制拆开然后给出一套可以直接抄的实操流程最后把我踩过的坑和排查套路整理成速查表。全程不需要额外硬件一台装了主流Linux发行版的机器就够。需要提前说明的是网络命名空间和Mininet都不是新东西网上零散资料很多但大多要么只讲命令不讲原理要么直接甩一个复杂脚本让人看不懂。我写这篇的目的是把“为什么这么设计”和“具体怎么敲”串起来让你看完能自己改拓扑、自己加链路参数而不是只会跑别人的demo。2. 核心机制拆解命名空间与Mininet到底做了什么2.1 网络命名空间内核里的独立网络栈理解网络命名空间最直观的类比是“把一台机器的网络部分切成了好几个平行世界”。每个命名空间里有自己独立的网卡列表、路由表、ARP缓存、iptables规则、socket端口空间。默认情况下进程活在初始命名空间里你ip netns add ns1之后内核就为ns1创建了一套全新的网络栈此时它里面只有一个down掉的loopback其他什么都没有。关键点在于命名空间之间的隔离是内核级别的不是模拟出来的。你在ns1里ping 127.0.0.1能通在ns2里也ping 127.0.0.1能通两者互不干扰因为loopback是各自独立的。这就解决了“同一台机器上多个网络环境共存”的根本矛盾。以前要做这种事得开虚拟机现在一个命令搞定。那命名空间之间怎么通信靠veth pair虚拟以太网对。你可以把veth pair想象成一根网线的两端一端插在ns1里另一端插在ns2里数据从一端进去从另一端出来。创建方式是ip link add veth0 type veth peer name veth1然后把veth0塞进ns1veth1塞进ns2各自配上同网段IP就能通了。这个过程中内核只做了数据包的转发没有经过任何物理网卡所以延迟极低。还有一个容易忽略的点命名空间里的进程怎么和外部世界交互答案是靠NAT或者路由转发。比如你在ns1里想访问公网需要把ns1的默认路由指向宿主的一个veth地址然后在宿主上开IP转发并配MASQUERADE规则。这套逻辑和容器网络是一模一样的Docker的bridge模式底层就是命名空间加veth加iptables。2.2 Mininet把手工命令封装成可编程拓扑如果只有命名空间搭一个五节点拓扑你得敲几十条命令改一次拓扑重来一遍效率太低。Mininet的价值就在于它把这套手工操作抽象成了Python API和一套CLI。你用几行代码描述“我要两个交换机、四个主机、链路带宽10Mbps、延迟5ms”Mininet就自动帮你创建命名空间、插veth、配IP、设tc规则、启动OpenFlow交换机默认是Open vSwitch。Mininet的架构分三层。最底层是Linux的网络原语就是命名空间和veth。中间层是Open vSwitch负责交换逻辑支持OpenFlow协议这意味着你可以接外部控制器做SDN实验。最上层是Python库提供Topo类让你自定义拓扑还有mn命令行工具做交互。它默认给每个主机分配一个命名空间主机名就是命名空间名你mininet h1 ping h2的时候实际上是在h1的命名空间里执行ping。这里有个设计取舍值得说Mininet默认用Open vSwitch而不是Linux bridge。原因是OVS支持OpenFlow能做流表编程适合SDN教学和研究。但OVS本身有一定资源开销如果你只是想做纯路由实验用Linux bridge或者直接手动配命名空间会更轻。我个人的选择是做SDN相关实验用Mininet加OVS做纯协议栈验证或者容器网络原理验证直接手写命名空间脚本更可控。另一个关键参数是--switch可以指定ovs、ovsbr、lxbr等。lxbr就是Linux bridge资源占用小但不支持OpenFlow。还有--controller参数默认Mininet会启动一个内置的控制器如果你要接外部控制器比如Ryu或者ONOS就把它设成remote并指定IP端口。2.3 两者结合后的能力边界这套组合能做什么我列几个实际跑过的场景验证OSPF或者BGP的收敛行为在Mininet里跑Quagga或FRR、测试TCP拥塞控制算法在不同延迟带宽下的表现、复现ARP欺骗和防御、模拟多租户网络隔离、做OpenFlow流表下发实验。基本上只要不涉及物理层特性比如无线信号衰减、光模块兼容性逻辑层的网络行为都能模拟。不能做什么第一它不模拟物理链路误码和信号干扰链路质量靠tc的延迟、丢包、抖动参数来近似。第二它的吞吐量受限于单机CPU和内存跑大带宽测试比如10Gbps以上不现实一般用来验证功能而非性能。第三它不涉及真实硬件卸载比如SR-IOV、DPDK这些所以高性能数据面实验得换方案。理解这些边界很重要否则你可能会在Mininet里花大量时间调一个根本不该用它测的性能指标。我的经验是功能验证用Mininet性能基线用物理机或专业测试仪两者分工明确。3. 环境搭建与基础实操从零到第一个拓扑3.1 系统准备与依赖安装我用的环境是Ubuntu 22.04内核5.15这是比较稳的组合。其他主流发行版也可以但包名和默认配置有差异下面以Debian系为例。首先确认内核支持命名空间uname -r看版本2.6.24以后都支持现在基本不用担心。然后装Mininet官方推荐用源码安装因为apt源里的版本可能偏旧。源码安装的步骤是git clone官方仓库进入目录执行sudo util/install.sh -a。这个脚本会自动装Open vSwitch、OpenFlow参考实现、wireshark的OpenFlow解析插件等。整个过程大概五到十分钟取决于网络。装完后sudo mn --test pingall验证如果看到所有主机两两ping通说明基础环境OK。这里有个坑如果你机器上已经有Open vSwitch在跑比如装了Docker或者KVMinstall.sh可能会和现有OVS冲突。我的做法是先systemctl stop openvswitch并禁用开机启动等Mininet装完再决定要不要恢复。另外install.sh会修改一些系统配置建议在干净的虚拟机或者容器里做别在生产机上直接跑。还有一个依赖是iproute2ip netns命令就来自它。大部分发行版默认都有如果没有就apt install iproute2。抓包工具tcpdump和wireshark也建议装上后面排查问题全靠它们。3.2 手工创建命名空间先搞懂底层再上封装在碰Mininet之前我强烈建议先手工做一遍命名空间互联这样后面Mininet出问题你能定位到底层。流程如下# 创建两个命名空间 sudo ip netns add ns1 sudo ip netns add ns2 # 创建veth pair sudo ip link add veth1 type veth peer name veth2 # 把两端分别塞进两个命名空间 sudo ip link set veth1 netns ns1 sudo ip link set veth2 netns ns2 # 在ns1里配IP并启用 sudo ip netns exec ns1 ip addr add 10.0.0.1/24 dev veth1 sudo ip netns exec ns1 ip link set veth1 up sudo ip netns exec ns1 ip link set lo up # 在ns2里配IP并启用 sudo ip netns exec ns2 ip addr add 10.0.0.2/24 dev veth2 sudo ip netns exec ns2 ip link set veth2 up sudo ip netns exec ns2 ip link set lo up # 测试连通性 sudo ip netns exec ns1 ping -c 3 10.0.0.2如果ping通了恭喜你你已经理解了Mininet最核心的那层。注意ip netns exec这个前缀它的作用是在指定命名空间里执行命令。Mininet的CLI本质上就是帮你自动加了这个前缀。清理的时候用ip netns del ns1和ip netns del ns2veth pair会随之消失。这里有个细节删除命名空间时里面的veth会自动被内核回收但如果你先把veth删了再删命名空间也没问题。我习惯先删命名空间省事。3.3 Mininet快速上手第一个自定义拓扑手工验证完上Mininet。先用内置的mn命令跑一个最简单的树形拓扑sudo mn --topo tree,depth2,fanout2 --controllerdefault这条命令会创建一个深度2、扇出2的树也就是1个根交换机、2个叶子交换机、4个主机。进入CLI后pingall测试全连通dump看节点信息h1 ping h2测单对连通。exit退出后Mininet会自动清理所有命名空间和OVS网桥这点比手工脚本省心。但真正有用的是自定义拓扑。下面是一个我常用的Python脚本定义了两个交换机、四个主机、链路参数各不相同的拓扑from mininet.topo import Topo from mininet.net import Mininet from mininet.node import OVSController from mininet.link import TCLink from mininet.cli import CLI class MyTopo(Topo): def build(self): # 添加两台交换机 s1 self.addSwitch(s1) s2 self.addSwitch(s2) # 添加四台主机 h1 self.addHost(h1, ip10.0.1.1/24) h2 self.addHost(h2, ip10.0.1.2/24) h3 self.addHost(h3, ip10.0.2.1/24) h4 self.addHost(h4, ip10.0.2.2/24) # 主机到交换机的链路带带宽和延迟参数 self.addLink(h1, s1, bw10, delay5ms) self.addLink(h2, s1, bw10, delay5ms) self.addLink(h3, s2, bw5, delay20ms) self.addLink(h4, s2, bw5, delay20ms) # 交换机之间的链路 self.addLink(s1, s2, bw20, delay10ms) if __name__ __main__: topo MyTopo() net Mininet(topotopo, controllerOVSController, linkTCLink) net.start() CLI(net) net.stop()保存成mytopo.py用sudo python3 mytopo.py运行。注意linkTCLink这个参数没有它的话bw和delay不会生效。TCLink底层用的是Linux的tc命令给veth接口加qdisc规则所以延迟和带宽是真实生效的不是模拟值。跑起来后你可以h1 ping h3会看到延迟明显比h1 ping h2大因为跨交换机链路有10ms延迟h3到s2还有20ms。这就是TCLink的价值能构造出异构网络环境。4. 进阶实操抓包、调参、接控制器4.1 在命名空间里抓包的正确姿势Mininet环境里抓包有两种方式。第一种是在CLI里用h1 tcpdump -i h1-eth0 -w /tmp/h1.pcap注意主机名后面的接口名格式是主机名-ethX。第二种是在宿主机上直接对veth接口抓包先用ip link找到对应的veth然后tcpdump -i vethXXX。两种方式各有用途前者抓的是主机视角的包后者抓的是链路视角的包排查链路层问题时后者更直接。我踩过的一个坑是在Mininet CLI里执行tcpdump后如果直接exit退出tcpdump进程可能没被清理干净导致下次启动时端口或文件被占用。正确做法是在CLI里先CtrlC停掉tcpdump再退出。或者用h1 kill %tcpdump这种job control的方式。另外抓包文件默认存在命名空间的挂载点里但命名空间共享宿主文件系统所以/tmp/h1.pcap在宿主上也能直接看到。还有一个技巧如果你想抓交换机之间的流量可以在OVS网桥上抓。ovs-vsctl list-ports看端口名然后tcpdump -i s1-eth3。这个接口是OVS的内部端口能看到经过交换机的所有包包括广播和未知单播泛洪。4.2 链路参数调优带宽、延迟、丢包、抖动TCLink支持的参数不止bw和delay还有loss丢包率、jitter抖动、max_queue_size队列长度。这些参数底层都是通过tc qdisc实现的。比如loss5表示5%丢包jitter2ms表示延迟在基准值上下浮动2ms。这里要理解一个原理tc的netem模块对延迟的实现是“排队等待”包进入qdisc后按设定时间延迟发出。如果队列满了后续包会被丢弃。所以当你设了很小的max_queue_size和较大的延迟时可能会观察到意外丢包这不是bug是队列溢出。我一般会把max_queue_size设成100以上除非专门测拥塞。带宽限制用的是tbftoken bucket filterbw10表示10Mbps。注意这个值是单向的如果你要双向限制得在链路两端都设。Mininet的addLink默认在两端都加规则所以实际是双向各10Mbps。但如果你手工用tc配容易只配一边导致单向限速测出来的吞吐量会翻倍。实测数据在i7-1165G7的机器上两个命名空间之间用veth直连不设任何tc规则iperf3能跑到20Gbps以上。加了bw100之后稳定在95Mbps左右加了delay10ms之后RTT稳定在20ms出头往返各10ms。这些数字可以作为你判断环境是否正常的基线。4.3 接入外部控制器做SDN实验Mininet默认启动一个内置控制器功能很简单就是学习交换机行为。要做真正的SDN实验得接外部控制器。以Ryu为例先在宿主机上pip install ryu然后写一个简单的app或者直接用Ryu自带的simple_switch_13.py。启动命令是ryu-manager simple_switch_13.py默认监听6633端口。然后Mininet启动时指定--controllerremote,ip127.0.0.1,port6633。这样OVS就会把流表下发请求发给RyuRyu按自己的逻辑决定转发行为。你可以改Ryu的代码实现自定义转发比如根据源IP做策略路由或者实现一个简单的防火墙。这里有个常见问题控制器和Mininet不在同一台机器时要确保防火墙放行6633端口并且Mininet的--controller参数里IP要写控制器的实际可达地址。另外OVS和控制器之间的连接是TCP如果控制器挂了OVS会进入“fail secure”模式默认行为是丢弃所有包。调试时如果发现网络突然不通先检查控制器进程还在不在。5. 常见问题与排查速查表5.1 启动失败与资源冲突现象可能原因排查命令解决方法mn启动报错“Cannot find required executable”依赖没装全which ovs-vsctl重跑util/install.sh -a启动后ping不通OVS服务没起来systemctl status openvswitch启动OVS并检查日志命名空间创建失败残留命名空间占名ip netns listip netns del清理残留端口被占用上次Mininet没清理干净ps aux | grep mnkill残留进程mn -c清理mn -c是我用得最多的命令它会清理所有Mininet创建的命名空间、OVS网桥、veth接口和tc规则。有时候Mininet异常退出残留一堆东西直接mn -c比手工清理快得多。但注意它会删掉所有以mn开头的命名空间如果你有自己手工建的命名空间叫mnXXX也会被误删所以命名时避开这个前缀。5.2 连通性问题的分层排查法网络不通时我按从下到上的顺序查第一层看接口状态ip netns exec h1 ip link确认接口是UP第二层看IP配置ip netns exec h1 ip addr确认地址和掩码正确第三层看ARPip netns exec h1 ip neigh看有没有解析到对端MAC第四层看路由ip netns exec h1 ip route确认路由表有对应条目第五层抓包在两端同时tcpdump看包有没有发出去、有没有收到。大部分问题出在第二层和第三层。比如掩码配错导致同网段判断失误或者ARP没解析成功导致包发不出去。Mininet默认会给主机配好IP和路由但如果你自定义拓扑时手写了IP容易漏掉网关或者掩码写错。我的习惯是自定义拓扑里IP一律用/24网关用网段第一个地址减少出错概率。还有一个隐蔽问题OVS网桥的STP生成树协议默认是关闭的。如果你搭了环形拓扑又没开STP广播风暴会瞬间打满CPU。Mininet的--switch ovs默认不开STP需要手动ovs-vsctl set bridge s1 stp_enabletrue。做环形实验时务必记得这一步。5.3 性能异常的定位思路如果iperf3测出来的吞吐量远低于预期先确认三件事一是tc规则有没有生效tc qdisc show dev h1-eth0看有没有netem或tbf二是CPU是不是瓶颈top看ksoftirqd和ovs-vswitchd的占用三是veth的MTU默认1500如果设小了会分片影响性能。我遇到过一次诡异情况两个主机之间ping延迟正常但iperf3吞吐只有几百Kbps。查了半天发现是max_queue_size设成了10而延迟设了50ms导致队列频繁溢出TCP疯狂重传。把队列调到1000后恢复正常。这个教训是延迟和队列长度要匹配高延迟链路需要更大的队列来吸收在途数据。另一个常见误区是拿Mininet测绝对性能。前面说过它受限于单机资源而且OVS是用户态转发除非用DPDK加速所以吞吐量天花板不高。正确的用法是测相对性能比如对比两种拥塞控制算法在同一拓扑下的表现或者验证某个参数调整带来的趋势变化。6. 我个人的实操心得与扩展方向这套东西我用了大概三年最大的体会是不要一上来就追求复杂拓扑。我见过不少人直接抄一个几十节点的脚本跑起来一堆问题最后连哪个环节出错都不知道。正确的路径是先手工敲命名空间命令理解底层再用Mininet跑两节点然后逐步加交换机、加链路参数、加控制器。每一步都验证通过再往下走这样出问题能快速定位。另一个心得是关于脚本管理。我习惯把拓扑定义、启动逻辑、测试用例分成三个文件。拓扑文件只描述节点和链路启动文件负责实例化和CLI测试文件用Mininet的Python API做自动化验证比如net.pingAll()返回丢包率。这样改拓扑不影响测试逻辑复用性高。测试文件可以集成到CI里每次改完拓扑自动跑一遍连通性和性能基线。扩展方向有几个我觉得值得深入一是结合FRRFree Range Routing做动态路由实验在Mininet主机里跑OSPF或BGP观察收敛过程二是结合P4和BMv2做可编程数据面实验这个比OpenFlow更底层三是把Mininet拓扑导出成容器网络配置验证Kubernetes的CNI插件行为。这几个方向我都试过一部分后面有机会再单独写。最后分享一个小技巧Mininet的CLI支持py命令执行Python代码比如py net.get(h1).cmd(ip addr)这比在CLI里敲shell命令灵活得多。你可以用这个特性在CLI里动态改配置、读状态、做断言。我经常用它来快速验证某个想法不用退出重写脚本。