简介这份网络切片仿真资源面向5G通信网络方向的研究人员、高校学生与工程技术人员聚焦在共享物理基础设施上构建多个独立逻辑网络这一核心命题帮助读者在真实部署前完成切片建模、资源分配与性能评估。压缩包共67个文件约280KB以m脚本、ot仿真输出、c源码、obj目标文件为主辅以exp、lib、dll、seq、prj等工程配置与库文件构成一套可运行的仿真工程结构。内容围绕网络切片概念、NFV与SDN虚拟化技术、SLA服务等级协议、资源分配、安全隔离、动态调整与自愈能力等知识点展开并涉及Omnet、ns-3、MATLAB等仿真工具的使用思路。目前已有1031人学习下载适合希望理解切片建模流程、借鉴仿真工程组织方式、验证资源调度与隔离机制的读者参考也可作为5G应用场景性能预测与优化研究的入门素材。1. 网络切片仿真到底在仿什么从一个资源争抢的翻车现场说起把「网络切片仿真」当成一个压缩包名来看它背后其实是一整套方法论在单台机器或一个小集群上用软件把一张物理网络切成若干条逻辑隔离的通道每条通道有独立的带宽、时延、丢包和计算资源配额然后观察业务跑在这些通道上到底会不会互相踩脚。我第一次做这类仿真时踩的坑很典型三条切片共享同一段链路视频切片一压满另外两条做工业控制的切片时延直接从 8ms 抖到 90ms业务侧报警刷屏而我在仿真日志里翻了半天才定位到是队列调度没配权重。这件事说明网络切片仿真真正要回答的不是「切片能不能建起来」而是「资源被抢的时候隔离还成不成立」。它适合三类人做 5G/专网方向、需要验证端到端 SLA 的工程师做云网融合、想把 Kubernetes 网络策略和底层链路配额对齐的人以及做教学或方案预研、需要一个可复现实验环境的学生和研究者。你不需要真实基站和核心网一台 16GB 内存的机器就能跑通最小闭环。下面按「概念立住 → 环境搭起来 → 切片建起来 → 业务压上去 → 坑填掉」的顺序讲每一步都给可抄的命令和参数。2. 仿真环境选型与最小拓扑搭建为什么我最终选了容器加流量控制2.1 三种常见路线的取舍做网络切片仿真常见做法有三条路线。第一条是纯离散事件仿真比如用通用网络仿真器建模优点是快、可重复缺点是和真实协议栈差距大你验证不了 Linux 内核里的排队规则。第二条是虚拟机加 OpenFlow 软交换机隔离性好但每台虚机吃 1GB 起步跑五六条切片就顶到内存天花板。第三条是容器加 Linux 流量控制也就是我一般会推荐的路线用 network namespace 模拟独立网元用 veth pair 连线用 tc 做带宽和时延整形用 cgroup 限制 CPU。它的好处是全部走真实内核协议栈你测出来的时延抖动是有参考价值的而且资源开销小。选型时盯三个指标单节点能承载的切片数、时延整形的最小粒度、以及能否复现。容器路线在 16GB 内存机器上跑 6 到 8 条切片没问题tc 的 tbf 和 netem 组合能做到 1ms 级别的时延注入脚本化之后完全可复现。虚拟机路线适合需要强隔离的合规验证场景但迭代慢。仿真器路线适合大规模拓扑的算法研究不适合验证具体业务。2.2 用脚本搭出三切片最小拓扑下面这段脚本创建三个 network namespace分别代表三条切片通过一个中心 bridge 互联并给每条切片打上不同的带宽和时延。这是整个仿真环境的地基。#!/bin/bash # 创建三条切片的最小拓扑ns_video / ns_control / ns_iot set -e # 1. 建中心网桥模拟共享的承载网 ip link add br-slice type bridge ip addr add 10.0.0.1/24 dev br-slice ip link set br-slice up # 2. 循环创建三个 namespace 并连线 for i in 1 2 3; do nsns_slice$i ip netns add $ns # 建一对 veth一头在 namespace 内一头挂到网桥 ip link add veth$i type veth peer name veth${i}-br ip link set veth$i netns $ns ip link set veth${i}-br master br-slice ip link set veth${i}-br up # namespace 内配地址并启用 ip netns exec $ns ip addr add 10.0.0.1$i/24 dev veth$i ip netns exec $ns ip link set veth$i up ip netns exec $ns ip link set lo up done # 3. 给每条切片注入基础时延模拟不同接入方式 # 切片1视频时延 20ms ip netns exec ns_slice1 tc qdisc add dev veth1 root netem delay 20ms # 切片2工业控制时延 5ms ip netns exec ns_slice2 tc qdisc add dev veth2 root netem delay 5ms # 切片3物联网时延 50ms ip netns exec ns_slice3 tc qdisc add dev veth3 root netem delay 50ms echo 拓扑就绪验证 ip netns exec ns_slice1 ping -c 2 10.0.0.12逻辑说明先建网桥作为共享承载再用 veth pair 把 namespace 接入这一步决定了切片之间是否真的共享链路。参数上10.0.0.1/24是承载网段10.0.0.1$i给每条切片分配独立地址避免地址冲突。netem delay是基础时延注入数值按你的目标场景改工业控制类通常设 1 到 10ms视频类 20 到 50ms。注意set -e让脚本遇错即停避免半成品拓扑污染后续实验。2.3 验证拓扑是否真的隔离搭完别急着压业务先验证隔离性。用ip netns exec ns_slice1 ping 10.0.0.12能通说明二层转发正常再在切片1里跑ping -f打满同时看切片2的时延是否稳定。如果切片2时延跟着涨说明你的隔离只做到了地址隔离没做到资源隔离后面必须补 tc 的队列规则和 cgroup 限制。这一步是很多人跳过的也是后面业务翻车的根因。3. 切片资源配额与隔离配置把带宽、时延、CPU 三样都锁住3.1 带宽整形tbf 和 htb 怎么选带宽隔离是切片仿真的核心。常见做法有两种tbf 做单条切片的令牌桶限速htb 做多类流量的分层调度。如果你只是给每条切片一个上限tbf 够用如果你要在一条切片内部再区分信令流和业务流就得上 htb 加分类。我一般会先用 tbf 把每条切片的出口速率锁死再用 htb 在共享网桥上做加权公平队列。# 在切片1的 veth 上做 50Mbit 限速突发 10k ip netns exec ns_slice1 tc qdisc add dev veth1 root handle 1: tbf \ rate 50mbit burst 10k latency 30ms # 在中心网桥出口做 htb给三条切片不同权重 tc qdisc add dev br-slice root handle 1: htb default 30 tc class add dev br-slice parent 1: classid 1:1 htb rate 200mbit tc class add dev br-slice parent 1:1 classid 1:10 htb rate 80mbit ceil 100mbit prio 1 tc class add dev br-slice parent 1:1 classid 1:20 htb rate 60mbit ceil 80mbit prio 2 tc class add dev br-slice parent 1:1 classid 1:30 htb rate 40mbit ceil 60mbit prio 3参数说明rate是保证带宽ceil是突发上限prio越小优先级越高。burst 10k控制令牌桶深度设太小会导致小包业务被误伤设太大会让限速形同虚设一般按 MTU 的 2 到 5 倍取。latency 30ms是 tbf 的排队上限超过就丢包这个值要和你的业务容忍度对齐。改完用tc -s qdisc show看丢包计数丢包率超过 1% 就说明 burst 或 latency 设紧了。3.2 CPU 与内存隔离cgroup v2 的写法网络隔离做完计算资源不锁业务照样互相影响。用 cgroup v2 给每条切片的业务进程限制 CPU 配额。下面以切片2的工业控制进程为例。# 创建 cgroup 并限制 CPU 为 1 核的 50% mkdir -p /sys/fs/cgroup/slice2 echo 50000 100000 /sys/fs/cgroup/slice2/cpu.max echo 512M /sys/fs/cgroup/slice2/memory.max # 把进程加入该 cgroupPID 按实际替换 echo $PID /sys/fs/cgroup/slice2/cgroup.procscpu.max的格式是「配额 周期」50000 100000表示每 100ms 周期内最多用 50ms CPU即半核。memory.max是硬上限超了会触发 OOM建议按业务峰值内存的 1.5 倍设。注意 cgroup v2 要求内核 4.15 以上且挂载点必须是 unified 层级用mount | grep cgroup2确认。3.3 把配额写进一份可复现的配置表手工敲命令容易漏我习惯把每条切片的参数固化成一张表脚本读表生成规则。这样换机器、换场景只改表不改逻辑。切片名带宽保证突发上限基础时延CPU 配额内存上限视频切片80Mbit100Mbit20ms1 核1G控制切片60Mbit80Mbit5ms0.5 核512M物联网切片40Mbit60Mbit50ms0.25 核256M这张表就是你的仿真基线任何一次实验前先确认表里的值和实际下发的一致不一致的实验结果直接作废。4. 业务流量注入与 SLA 观测怎么判断切片真的达标了4.1 用 iperf3 和 ping 构造三类典型流量切片建好之后要压业务。视频类用 iperf3 打大带宽 UDP 流控制类用高频小包物联网类用低频小包加长连接。下面是一次三切片并发的压测脚本。# 切片1视频UDP 60Mbit持续 60 秒 ip netns exec ns_slice1 iperf3 -s -D ip netns exec ns_slice2 iperf3 -c 10.0.0.11 -u -b 60M -t 60 -l 1400 # 切片2控制高频小包每秒 200 个 64 字节包 ip netns exec ns_slice2 ping -c 12000 -i 0.005 -s 64 10.0.0.11 ctrl.log # 切片3物联网低频心跳每 5 秒一次 for i in $(seq 1 12); do ip netns exec ns_slice3 ping -c 1 -s 32 10.0.0.11 iot.log sleep 5 done逻辑说明iperf3 服务端用-D后台常驻客户端-u走 UDP-b 60M指定目标带宽-l 1400控制包长接近 MTU。控制类用-i 0.005做 5ms 间隔模拟高频采样。物联网类用循环加 sleep 模拟心跳。三类流量并发时观察控制切片的 ping 时延是否被视频流带偏这是隔离是否生效的直接证据。4.2 采集哪些指标才算验证了 SLA只看平均时延会骗人。我一般采集四组P50/P95/P99 时延、丢包率、带宽达成率、以及时延抖动。用 ping 的日志算分位数用 iperf3 的输出算达成率。下面这段 Python 从 ping 日志里算 P95 和抖动。import re import statistics def parse_ping(path): rtts [] with open(path) as f: for line in f: m re.search(rtime([\d.]) ms, line) if m: rtts.append(float(m.group(1))) return rtts rtts parse_ping(ctrl.log) if rtts: rtts_sorted sorted(rtts) p95 rtts_sorted[int(len(rtts_sorted) * 0.95)] jitter statistics.stdev(rtts) if len(rtts) 1 else 0 print(f样本数{len(rtts)} P50{statistics.median(rtts):.2f}ms fP95{p95:.2f}ms 抖动{jitter:.2f}ms 丢包{12000-len(rtts)})参数说明0.95是分位点按你的 SLA 改工业控制常看 P99。statistics.stdev算标准差作为抖动近似严格做法是用相邻包时延差。丢包数用发送总数减收到数发送总数要和压测脚本里的-c对齐否则统计失真。4.3 把观测结果和配额对照拿到指标后要和第 3 章的配额表对照。控制切片承诺 5ms 基础时延实测 P95 如果到 15ms说明共享链路的 htb 权重没起作用或者视频流的突发把令牌桶打穿了。这时候先看tc -s class show dev br-slice的各类丢包和借用计数再决定是调ceil还是调prio。别一上来就加带宽很多时候是调度参数的问题。5. 避坑与排查五条我踩过的血泪记录5.1 现象切片间时延互相污染隔离形同虚设原因只在 namespace 内做了 netem没在共享网桥做队列调度所有流量还是先进先出。解决在网桥出口加 htb给每条切片独立 class 和 prio再用tc filter把 veth 的流量分类到对应 class。分类规则要按源 IP 或 veth 名匹配别用默认类。5.2 现象限速生效但吞吐远低于设定值原因tbf 的burst设太小或者latency设太紧导致大量丢包触发 TCP 拥塞退避。解决把 burst 提到 MTU 的 3 到 5 倍latency 按业务 RTT 的 2 倍设。用tc -s qdisc看 dropped 计数如果 dropped 持续增长就是参数紧了。5.3 现象cgroup 限制不生效进程照样吃满 CPU原因进程在创建 cgroup 之前就启动了或者写的是 v1 的cpu.cfs_quota_us而系统挂的是 v2。解决先确认mount | grep cgroup2v2 只认cpu.max。进程要先启动再写cgroup.procs或者用 systemd 的Slice直接托管。5.4 现象iperf3 测出的带宽忽高忽低重复性差原因压测时没固定 CPU 亲和性iperf3 进程在核间迁移加上其他切片干扰。解决用taskset -c把压测进程绑到固定核压测前清空其他切片的背景流量每轮实验前重启 namespace 保证状态干净。5.5 现象ping 显示时延正常但业务侧报超时原因ping 走的是 ICMP优先级和队列处理和业务 TCP/UDP 不同netem 的 delay 对 ICMP 和 TCP 的生效路径可能不一致。解决用业务真实协议做探针比如用hping3打 TCP SYN或者直接在应用层埋点。别拿 ping 当唯一证据。6. 进阶把仿真结果变成可复用的容量结论仿真跑通只是第一步真正有价值的是从数据里推出容量结论。我的做法是固定业务模型逐步加压找到每条切片的拐点。具体操作以控制切片为例从每秒 100 个包开始每轮加 100记录 P99 时延直到 P99 超过 10ms 或丢包超过 0.1%这个点就是该切片在当前配额下的容量上限。# 自动化找拐点循环加压并记录 for rate in 100 200 300 400 500 600; do ip netns exec ns_slice2 ping -c $((rate*10)) -i 0.01 -s 64 10.0.0.11 ctrl_$rate.log python3 calc_p99.py ctrl_$rate.log capacity.csv done跑完把 capacity.csv 画成曲线拐点一目了然。这里有个容易忽略的点拐点会随其他切片的负载漂移所以要在「背景流量固定」和「背景流量拉满」两种条件下各测一遍取更保守的那个作为规划依据。另一个进阶技巧是做故障注入。用tc qdisc change动态把某条切片的时延从 5ms 拉到 50ms观察业务是否触发切换或降级。这能验证你的切片方案有没有冗余路径。我一般会在仿真里预留一条备份切片主切片劣化时用策略路由切过去切换时间控制在 200ms 内算合格。最后说个习惯每次实验前把拓扑、配额表、压测脚本、采集脚本四样东西打成一个目录用时间戳命名实验后把原始日志和结论一起归档。我早期图省事只存结论后来要复现某个拐点时发现参数对不上只能重跑浪费了一整天。仿真这件事可复现比跑得快重要得多。希望帮到你。本文还有配套的精品资源点击获取