简介P4数据平面编程环境离线安装包集成behavioral-modelBMV2软件交换机、p4c编译器、protobuf 3.2.0序列化库、thrift 0.9.2 RPC框架与gmock 1.7.0测试工具等核心组件适用于SDN、可编程网络设备开发及高校网络课程实验面向需要在本地快速搭建P4开发与测试环境的开发者、科研人员与学生。压缩包采用gz格式体积约147.8MB文件数量和具体类型未在资源页完整标注但各组件版本已匹配整合下载后无需再逐个寻找安装包或处理版本兼容问题可显著减少环境部署成本。已有609人学习/浏览适合希望高效复现P4实验、进行BMV2行为仿真或数据平面功能验证的中级用户。获取后可直接得到一套可离线安装的P4软件栈降低依赖冲突概率节省源码编译时间支持快速进入p4c编程、交换机行为模拟及网络可编程研究等实操环节。1. 标题里这串版本号是 P4 入门路上最该先抄的作业P4 环境安装是劝退新手最多的一道坎。很多人第一次看到 behavioral-model、p4c、protobuf、thrift 这一堆名字时以为照着最新教程装一遍就能跑结果卡在编译错误里好几天出不来。标题里这串版本号看起来又老又偏但它其实是一张经过实践验证的版本锁定表protobuf-3.2.0 管序列化、thrift-0.9.2 管控制面 RPC、gmock-1.7.0 管测试、p4c 管编译、behavioral-model 管软件交换机。这套组合能让你绕开“版本矩阵地狱”把时间留给 P4 程序本身而不是浪费在配对依赖上。适合三类人刚开始接触可编程数据平面的开发者、需要复现论文实验的学生、要快速搭一套可编程交换机测试平台的网络工程师。2. 这套环境背后的依赖逻辑五个组件各管哪一段为什么顺序不能乱2.1 从 .p4 源码到数据平面转发p4c、bmv2 与运行时组件各管哪一段P4 的开发和传统网络设备配置完全不同。你写的不是配置文件而是一份描述“数据平面如何处理报文”的程序。.p4 源码先由 p4c 编译输出 bmv2 能加载的 JSON 格式目标文件behavioral-modelbmv2再把这份 JSON 跑起来模拟一台可编程交换机而控制平面比如下发转发表项通过 thrift 或 P4Runtime 接口和 bmv2 通信。这个链路里protobuf 负责 P4Runtime 消息的序列化和反序列化gmock 则是 bmv2 编译测试组件时需要用到的 mock 框架。关键要理清的是p4c 和 bmv2 是“编译期”和“运行期”的关系。p4c 把 P4 程序翻译成 bmv2 能理解的指令集bmv2 是这个指令集的解释器。如果你只装了 p4c 没装 bmv2程序编译出来没人执行只装 bmv2 没有 p4c源码变不成 JSON。标题把两个都列出来是因为它们天然成对。而 protobuf、thrift、gmock 是它们共同的依赖基础先编译它们后面两个主组件才有地基。安装顺序我一般固定为protobuf → thrift → gmock → p4c → bmv2。protobuf 和 thrift 在最前面因为 p4c 的 P4Runtime 后端编译时要链接 protobufbmv2 的 thrift 控制面要链接 thrift。gmock 是独立的测试库顺序上可以插在靠前的位置方便后续 bmv2 跑单元测试时能找到头文件。这个顺序不是随便排的你从后往前装就会反复遇到“找不到符号”“找不到头文件”的报错。2.2 为什么 protobuf 3.2.0 和 thrift 0.9.2 必须锁死很多人会问protobuf 现在都出到 3.2x 了为什么标题里还要用 3.2.0这背后是二进制兼容性的问题。protobuf 小版本之间并不保证二进制兼容用新版本编译出来的库老头文件编译出来的代码链接时经常报一堆 undefined reference。p4c 在那个时期的主干代码是基于 protobuf 3.2.0 的接口写的你用系统默认的 protobuf 3.6 以上版本去编译它C 接口层就已面目全非。thrift 0.9.2 的情况更典型。bmv2 的 simple_switch_CLI 靠 thrift 协议和交换机进程通信这个接口的 IDL 定义和 0.9.2 的代码生成器绑定得比较深。升级到 thrift 0.12 之后生成的 C 代码风格变了bmv2 旧代码编译不过。所以这套环境的关键不在“谁的版本新”而在“谁能和源码里 include 的头文件对上”。锁死版本不是保守而是把这些隐式契约固定下来。还有一层原因这些老版本依赖当时的编译器和系统库。thrift 0.9.2 依赖 boost彼时配套的是 boost 1.58 左右protobuf 3.2.0 的 configure 脚本对新的 autoconf 也有兼容问题。综合下来我建议在 Ubuntu 18.04 或同期的发行版上搭这套环境越新的系统意味着你要额外处理越多的老代码兼容问题。这不是玄学是版本链路的实测结果。2.3 动工前的自检清单内存、交换分区、编译工具链编译这套环境对机器的要求不高但有几个硬指标提前确认能省掉许多麻烦。第一个是内存。p4c 和 bmv2 的编译非常吃内存实测 4GB 内存机器用make -j4很容易被 OOM kill。我一般建议至少 8GB 物理内存不够就提前加 4GB 交换分区后面make才安心。第二个是编译工具链。安装前先确认 gcc、g、make、autoconf、automake、libtool 都在版本不要追求最新能用就行。Python 环境也要检查一下bmv2 的构建脚本和测试脚本有一部分依赖 Python 2 的语法系统默认 Python 3 的环境下某些旧的 setup 脚本需要显式指定解释器。这个倒不算阻塞项但提前知道比卡住了再查要省时间。# 快速自检命令 gcc --version g --version make --version autoconf --version automake --version libtoolize --version python --version free -h参数说明free -h看内存和交换分区总量重点看 available 和 swap 两列。如果 swap 是 0建议先执行fallocate -l 4G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile临时加上。其余命令只是确认存在缺失的用系统包管理器补上即可。3. 从源码编译整套 P4 开发环境五步命令与参数说明3.1 安装系统级依赖编译开始前先安装一批系统包。不同发行版的包名略有差异Ubuntu 下我习惯直接用 apt 把常见依赖一次性装齐省得编译到一半再回头补。sudo apt update sudo apt install -y build-essential cmake git autoconf automake libtool \ libboost-dev libboost-system-dev libboost-filesystem-dev \ libssl-dev libpcap-dev libnanomsg-dev libjudy-dev \ pkg-config flex bison libgmp-dev libgc-dev参数说明libboost-dev是 thrift 和 bmv2 的硬依赖缺了 thrift 的 configure 会直接失败libnanomsg-dev是 bmv2 的 packet mirror 功能依赖libjudy-dev是 bmv2 的精确匹配表实现依赖漏掉它 configure 阶段不会报错但运行时创建表会崩溃。flex和bison是 p4c 解析 P4 语法时需要用到的词法/语法分析器生成器少了它们 p4c 的编译半路就会停下。3.2 编译 protobuf-3.2.0先解决序列化层protobuf 是这条依赖链的最底层必须先装。这里强烈建议用源码编译而不是系统包管理器因为系统仓库里的 protobuf 版本太新跟 p4c 的老接口对不上。tar xzf protobuf-cpp-3.2.0.tar.gz cd protobuf-3.2.0 ./configure --prefix/usr/local make -j$(nproc) sudo make install sudo ldconfig参数说明--prefix/usr/local让头文件落在/usr/local/include/google/protobuf库文件落在/usr/local/lib。不要改 prefix 到/usr否则后续卸载或版本切换时容易跟系统文件混在一起。make -j$(nproc)用满所有 CPU 核心能明显加速但如果内存只有 4GB 建议改成-j2。最后的ldconfig必须执行否则后面链路找不到libprotobuf.so。3.3 编译 thrift-0.9.2RPC 层的版本敏感点thrift 的 configure 选项很多但这里只需要它的 C 库其他语言的绑定全部关掉能显著缩短编译时间。tar xzf thrift-0.9.2.tar.gz cd thrift-0.9.2 ./bootstrap.sh ./configure --prefix/usr/local \ --without-java --without-python --without-nodejs \ --without-csharp --without-erlang --without-perl \ --without-php --without-ruby \ --with-boost/usr make -j$(nproc) sudo make install sudo ldconfig参数说明./bootstrap.sh会先生成 configure 脚本这一步如果报缺少 autoconf/automake回 3.1 补包。--without-python关闭 Python 绑定不是问题因为 bmv2 的 thrift 接口走的是 C。--with-boost/usr显式指定 boost 安装位置避免 configure 误判。编译时注意观察输出如果中途出现‘memset’ was not declared这类报错说明编译器太新解决办法写在后面避坑章节。3.4 编译 gmock-1.7.0让 bmv2 的测试组件顺利通过检查gmock 1.7.0 是老项目的经典测试框架版本bmv2 的源码在编译测试时会引用它的头文件。它依赖同目录下的 gtest但 1.7.0 的源码包已经自带了不需要额外下载。tar xzf gmock-1.7.0.tar.gz cd gmock-1.7.0 ./configure make -j$(nproc) sudo make install sudo ldconfig参数说明gmock 的 configure 没有太多可调选项默认安装到/usr/local即可。安装完成后检查一下/usr/local/include/gmock目录里是否有gmock.h有时候老版本的 make install 不会自动把头文件复制完整缺了的话把include/gmock整个目录手动拷贝过去。这一步别跳过因为 bmv2 编译到测试子模块时找不到 gmock 头文件会直接中断。3.5 编译 p4c 与 behavioral-model核心组件的顺序与构建参数p4c 用 cmake 构建相比 autotools 的老工程干净不少但有几个 cmake 参数需要留意。这里的要点是让 cmake 能找到刚装好的 protobuf。git clone https://github.com/p4lang/p4c.git cd p4c mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERELEASE \ -DCMAKE_INSTALL_PREFIX/usr/local \ -DPROTOBUF_INCLUDE_DIR/usr/local/include \ -DPROTOBUF_LIBRARY/usr/local/lib/libprotobuf.so make -j$(nproc) sudo make install参数说明如果 cmake 探测不到 protobuf 或者探测到系统里的其他版本就用-DPROTOBUF_INCLUDE_DIR和-DPROTOBUF_LIBRARY强制指定。p4c 编译时间较长中途卡住不要急着 Ctrl-C先确认是不是内存不足。编译完检查/usr/local/bin/p4c是否存在。behavioral-model 紧跟其后构建方式和 p4c 正好相反用的是 autotools。git clone https://github.com/p4lang/behavioral-model.git cd behavioral-model ./autogen.sh ./configure --prefix/usr/local \ --with-pi --with-thrift --with-nanomsg make -j$(nproc) sudo make install sudo ldconfig参数说明--with-pi开启 P4Runtime 支持这是现代 P4 控制面的事实标准建议保留--with-thrift是 simple_switch_CLI 需要的传统控制接口标题里专门有 thrift-0.9.2这个选项必须开。--with-nanomsg对应 packet mirror 功能开上可以避免运行时某些测试脚本报功能缺失。configure 如果在这里报找不到 thrift多半是 pkg-config 路径问题避坑章节细说。4. 跑通一套最小转发链路p4c 编译 .p4 到 simple_switch 下发流表4.1 一个最小可用的 P4 程序环境搭好之后第一个验证动作不是写复杂逻辑而是让一个最小 P4 程序完整走一遍“编译 → 加载 → 下发规则 → 转发”。下面这份代码基于 v1model 架构实现一个最简单的 MAC 地址转发。#include core.p4 #include v1model.p4 typedef bit48 macAddr_t; typedef bit9 egressSpec_t; header ethernet_t { macAddr_t dstAddr; macAddr_t srcAddr; bit16 etherType; } struct headers { ethernet_t ethernet; } struct metadata { } parser MyParser(packet_in pkt, out headers hdr, inout metadata meta, inout standard_metadata_t sm) { state start { pkt.extract(hdr.ethernet); transition accept; } } control MyIngress(inout headers hdr, inout metadata meta, inout standard_metadata_t sm) { action forward(macAddr_t dst, egressSpec_t port) { hdr.ethernet.dstAddr dst; sm.egress_spec port; } table mac_table { key { hdr.ethernet.dstAddr: exact; } actions { forward; NoAction; } size 1024; default_action NoAction(); } apply { mac_table.apply(); } } control MyEgress(inout headers hdr, inout metadata meta, inout standard_metadata_t sm) { apply { } } control MyVerifyChecksum(inout headers hdr, inout metadata meta) { apply { } } control MyDeparser(packet_out pkt, inout headers hdr) { apply { pkt.emit(hdr.ethernet); } } V1Switch(MyParser(), MyVerifyChecksum(), MyIngress(), MyEgress(), MyDeparser()) main;逻辑说明入口 parser 只做一件事提取以太网头Ingress 里定义了一个精确匹配表mac_table命中后调用forward动作修改目的 MAC 并设置出端口。这个程序虽然简单但完整包含了 parser、match-action 表、动作、deparser 四个 P4 核心概念足够验证链路是否通畅。4.2 编译 .p4 并用 simple_switch 加载把上面的代码保存为basic.p4接下来用 p4c 编译成 bmv2 的 JSON 格式。这里同时会生成 P4Info 文件和运行时上下文为控制面程序做准备。p4c --target bmv2 --arch v1model basic.p4 -o basic.json ls -lh basic.json参数说明--target bmv2指定编译后端是 behavioral-model--arch v1model指定用 v1model 可移植架构。如果编译报错找不到core.p4或v1model.p4说明 p4c 安装时头文件路径有问题常见做法是设置P4C_INCLUDE_PATH指向/usr/local/share/p4c/p4include或者直接指定-I参数。编译通过后创建两个 veth 虚拟网卡对分别模拟连接交换机的两台主机然后启动 simple_switch 加载 JSON。sudo ip link add veth0 type veth peer name veth1 sudo ip link add veth2 type veth peer name veth3 sudo ip link set veth0 up sudo ip link set veth1 up sudo ip link set veth2 up sudo ip link set veth3 up sudo simple_switch --log-console --thrift-port 9090 \ -i 0veth0 -i 1veth2 basic.json参数说明--thrift-port 9090指定控制面 RPC 端口默认 CLI 会连这个端口-i 0veth0表示交换机的 0 号端口接到 veth0-i 1veth2表示 1 号端口接到 veth2。简单交换机内部没有端口号约定这个映射完全由你决定。--log-console把报文日志打印到终端方便观察报文是不是真的被处理了。4.3 用 CLI 下发规则并验证连通性交换机跑起来之后再开一个终端用 bmv2 自带的 CLI 连进去下发一条转发规则。simple_switch_CLI --thrift-port 9090 table_add mac_table forward 00:00:00:00:00:01 00:00:00:00:00:0a 1 table_add mac_table forward 00:00:00:00:00:02 00:00:00:00:00:0b 0参数说明table_add的格式是“表名 动作名 匹配键 动作参数”。第一条的意思是收到目的 MAC 为00:00:00:00:00:01的报文改写目的 MAC 为...0a从端口 1 送出。这是 bmv2 CLI 的经典格式和 OpenFlow 的flow_mod思路类似但语法不同。下发成功后可以用table_dump mac_table查看规则是否生效。验证连通性时给 veth1 和 veth3 配好 IP从一侧 ping 另一侧观察 simple_switch 的--log-console输出里是否出现对应端口的收发记录。sudo ip addr add 10.0.0.1/24 dev veth1 sudo ip addr add 10.0.0.2/24 dev veth3 ping -I veth1 10.0.0.2到这里整套环境就算真正跑通了p4c 把源码编译成了 JSONbmv2 解释执行控制面通过 thrift 下发规则数据面完成了实际转发。这套最小链路也是后续所有 P4 实验的基础框架。5. P4 环境搭建避坑指南五条血泪踩坑记录5.1 protobuf 版本被系统包管理器覆盖p4c 链接阶段报错现象p4c 编译到 linking 阶段终端刷出一大片undefined reference to google::protobuf::...的报错而且报错符号明显来自 protobuf 新版本才有的命名空间。原因系统里原本有更高版本的 libprotobufcmake 优先找到了它和你在 /usr/local 下新装的 3.2.0 头文件混用。解决彻底卸载系统自带的 protobuf 运行时或者在 p4c 的 cmake 参数里强制指定/usr/local路径最稳妥的做法是把系统库清掉后重新编译 p4c并检查pkg-config --modversion protobuf输出的是 3.2.0。5.2 thrift-0.9.2 在新编译器下报 memset 未声明现象thrift make 过程中报错‘memset’ was not declared in this scope随后编译中断。原因新版本 GCC 的头文件不再间接包含cstringthrift 0.9.2 的某个源文件用了memset却没显式引入。解决修改报错文件在文件顶部加一行#include cstring也可以用CXXFLAGS-include cstring重新配置编译后者适用于多个文件同时报错的情况。5.3 bmv2 configure 提示找不到 thrift现象./configure执行到检查依赖时提示cannot find thrift或者thrift not found但你明明已经编译安装过 thrift。原因bmv2 的 configure 通过pkg-config找 thrift 的.pc文件而 thrift 默认安装在/usr/local/lib/pkgconfigpkg-config 的搜索路径里没有这个目录。解决执行export PKG_CONFIG_PATH/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH再重新跑 configure。如果还不认直接看thrift.pc是否存在确认后把该路径写进~/.bashrc。5.4 编译进程被 OOM kill现象make -j8跑了一阵后终端出现Killed没有任何具体报错dmesg里能看到Out of memory。原因p4c 和 bmv2 的某些编译单元尤其是带模板的 C 文件单文件内存占用极高并发编译直接吃满物理内存。解决make -j2降并发同时按 2.3 的方法加 4GB swap。如果公司服务器有内存限制还可以用systemd-run --pty --scope -p MemoryMax8G make限制编译子进程总量避免影响同机其他人。5.5 装完之后 ldconfig 没执行运行时找不到动态库现象所有编译安装都成功但执行simple_switch或p4c时报错error while loading shared libraries: libprotobuf.so.12: cannot open shared object file。原因动态库装到了/usr/local/lib但系统的动态链接器缓存里没有这个路径的信息。解决执行sudo ldconfig重建缓存如果发行版默认不扫描/usr/local/lib在/etc/ld.so.conf.d/下新建一个local.conf写入该路径再执行ldconfig。这个问题最容易被人忽略因为安装阶段全程没有报错。6. 把整套 P4 环境固化成镜像一次安装的复用技巧6.1 用 Dockerfile 记录环境消灭重建成本每次换机器都要重新编译一遍这套环境耗时两到三个小时还随时可能踩到前面章节里的坑。我现在的做法是第一次装完后立刻固化成 Docker 镜像后续无论换开发机还是给同事搭环境都是分钟级的事。Dockerfile 的核心思路很简单基础镜像选和本机一致的发行版然后把第 3 章的安装命令逐条搬进 RUN 指令。FROM ubuntu:18.04 RUN apt update apt install -y build-essential cmake git autoconf \ automake libtool libboost-dev libssl-dev libpcap-dev \ libnanomsg-dev libjudy-dev pkg-config flex bison \ libgmp-dev libgc-dev COPY protobuf-cpp-3.2.0.tar.gz /opt/ COPY thrift-0.9.2.tar.gz /opt/ COPY gmock-1.7.0.tar.gz /opt/ RUN cd /opt tar xzf protobuf-cpp-3.2.0.tar.gz \ cd protobuf-3.2.0 ./configure --prefix/usr/local \ make -j2 make install ldconfig # thrift、gmock、p4c、bmv2 依次照抄第 3 章的编译命令 ENV PKG_CONFIG_PATH/usr/local/lib/pkgconfig参数说明基础镜像选 ubuntu:18.04 而不是更新的版本是为了避开 5.2 里的 thrift 编译问题make -j2而非-j$(nproc)是为了避免容器构建时 CPU 核数过高触发 OOM。构建成功后的验证动作是这个技巧最关键的一环不要跳过。执行docker build -t p4-dev .之后用docker run --rm p4-dev p4c --version和docker run --rm p4-dev simple_switch --version两条命令确认主组件都可用。6.2 没有 Docker 的环境tar 包迁移也能应急如果目标机器不能用容器还有一招土办法把/usr/local/bin、/usr/local/lib、/usr/local/include以及/usr/local/share里跟 p4c、bmv2 相关的目录打包拷贝到同发行版机器上再执行ldconfig。这个做法只适用于系统版本差距不超过一个主版本的情况跨大版本迁移时 glibc 不一致会引入新的玄学问题。所以我的习惯是镜像为第一方案tar 包为应急方案源码重编为最后手段。固化环境这步做得越早越好。我吃过一次亏花两小时装完环境后直接开始写 P4 程序三个月后换电脑重复踩了一遍所有编译坑才想起来当初没做镜像。从那以后任何环境装完的第一件事都是固化而不是急着跑 demo。这套方法同样适用你之后搭建的其他复杂依赖栈。希望帮到你。本文还有配套的精品资源点击获取