简介面向P4可编程数据平面开发者与SDN实验学生的离线安装包合集涵盖behavioral-model、gmock-1.7.0、p4c、protobuf-3.2.0、thrift-0.9.2等关键组件用来解决P4语言工具链因版本严格匹配而难以独立装配的问题。压缩包采用gz格式整体约147.8MB下载页未提供文件总数与具体类型明细但从标题可以确认其中包含上述多款核心依赖的安装文件适用于Linux下构建BMv2软件交换机与P4编译环境。目前已有609人学习下载说明该资源在P4入门和SDN实验场景中具备一定关注度。获取后可按配套教程快速完成各组件版本对齐与部署省去逐一下载源码、排查protobuf/thrift依赖冲突的麻烦。该合集将分散的指定版本依赖集中打包便于离线安装、版本复现与项目迁移适合需要搭建可复现P4开发环境的初学者与研究人员。1. P4 环境配置最容易被版本搭配拖垮的一套流程做 P4 数据平面开发的都知道最折磨人的不是写 P4 代码本身而是把 behavioral-modelbmv2、p4c、protobuf 这些基础组件凑成一套能跑通的环境。这套环境有多常见只要你要跑 P4 教程、做 bmv2 模拟实验、或者调试自己写的 P4 程序就绕不开这几个组件之间的版本配合。装不好会怎样最常见的翻车现场就是 p4c 编译出来的 JSON 和 behavioral-model 的运行时版本对不上报一堆莫名其妙的 thrift 错误、protobuf 符号找不到然后你会在网上翻到各种玄学答案最后发现是基础版本的问题。这篇文章就是来帮你把这条链路一次走通的。我会把 behavioral-model、p4c、protobuf-3.2.0、thrift-0.9.2、gmock-1.7.0 这几个组件的版本选择逻辑、编译顺序、关键参数和踩坑修复过程全部梳理一遍。不管你是刚接触 P4 的新手还是已经在这套环境里折腾过几次的开发者照着这个流程走能省下大量来回试错的时间。2. 环境准备与版本选择先搞清组件之间怎么配套2.1 为什么 protobuf 3.2.0 和 thrift 0.9.2 是这套组合的关键先说结论这套环境里protobuf 和 thrift 是 behavioral-model 的两个基础依赖它们的版本直接决定 bmv2 能不能编译通过、运行时能不能正常通信。protobuf 3.2.0 是 bmv2 的 PIProgrammable Infrastructure模块早期适配的版本而 thrift 0.9.2 则是 bmv2 用来做 gRPC 和 thrift RPC 通信的基础库。这两个版本不是随便选的——高于或低于这些版本都可能出现 API 不兼容的问题。比如你把 protobuf 装成 3.6.0 或更高版本编译 bmv2 时常常会遇到google::protobuf::Arena相关接口的报错原因是 bmv2 有些代码路径还在用旧的内存管理 API。thrift 如果用了 0.11.0 之后的版本编译时同样会因为TSSLSocket的构造函数签名变化而失败。所以我一般会严格按 protobuf-3.2.0 thrift-0.9.2 这个组合来装不要看到版本老就想换新。2.2 操作系统与依赖包清单这套环境在 Ubuntu 16.04 和 18.04 上跑得最顺20.04 及以上版本需要额外处理一些 Python 和 gcc 的兼容问题。我推荐 Ubuntu 18.04理由很实际它的 gcc 7.5 和 bmv2 早期的代码能很好地配合同时系统自带的 Python 2.7 还能满足部分脚本的需求。# 系统基础包 sudo apt-get update sudo apt-get install -y \ git autoconf automake libtool curl \ build-essential cmake g python2.7 python-dev \ libgc-dev bison flex libfl-dev \ libgmp-dev libboost-dev libboost-iostreams-dev \ libboost-system-dev libboost-thread-dev \ libssl-dev libpcap-dev libevent-dev \ pkg-config libjudy-dev # 需要单独检查的工具 cmake --version # 要求 3.8 以上否则后续编译 p4c 会失败 gcc --version # 建议 7.x不是必须但最省心注意如果你用的是 Ubuntu 20.04 及以上python2.7 和 python-dev 已经不在官方源里了需要手动下载 deb 包或改用 Python3 兼容分支这部分后面会专门讲。这一步的逻辑是先把编译链路的“地基”打牢。p4c 依赖 cmake 和 bison/flex 来做语法解析部分而 bmv2 依赖 boost 和 libpcap 来处理网络包。任何一个包缺失后面编译到一半都会卡住回头再补基础包是最浪费时间的。2.3 下载资源包尽量用离线安装包减少变数实际部署时我不太建议直接从 GitHub 最新分支拉代码因为 master 分支随时可能变更和这套固定版本组合没准哪天就对不上了。更稳的方式是把这套配置安装包先在本地准备好里面已经包含了 behavioral-model、p4c、protobuf-3.2.0、thrift-0.9.2、gmock-1.7.0 的对应源码和安装脚本这样既能保证版本一致也方便在没有外网的环境下复现。我一般会在自己的工作目录下建立一个p4-env文件夹把下载好的压缩包都放进去然后按protobuf → thrift → gmock → behavioral-model → p4c的顺序编译。这个顺序是有讲究的先装底层依赖再编译 bmv2最后编译 p4c 这种上层编译器。3. 编译安装 protobuf 3.2.0 和 gmock 1.7.0打好底层基础3.1 编译 protobuf 3.2.0 的完整流程与参数选择protobuf 是第一个要装的组件因为 bmv2 的 PI 模块和 p4c 的 IR 序列化都依赖它。编译参数上我最关心的是把/usr/local作为安装前缀同时确保-fPIC被正确开启否则后续 bmv2 编译时链接静态库会报relocation错误。cd ~/p4-env tar -xzf protobuf-3.2.0.tar.gz cd protobuf-3.2.0 # 生成 configure 文件 ./autogen.sh # 配置安装参数 ./configure --prefix/usr/local CXXFLAGS-fPIC # 编译和安装 make -j$(nproc) sudo make install # 刷新动态库链接缓存 sudo ldconfig这里的关键参数是CXXFLAGS-fPIC。bmv2 和 p4c 编译时都会生成动态链接库如果 protobuf 的静态库本身没有位置无关代码链接阶段会直接报错。另外--prefix/usr/local是系统默认路径如果后面编译 p4c 时出现找不到 protobuf 的情况多半是路径没对上可以用sudo ldconfig先刷新一下再试。3.2 gmock 1.7.0 的作用与安装方式gmock 是 Google 的 C 测试框架它不是 P4 运行时的直接依赖而是 behavioral-model 编译单元测试时要用的库。如果你只想跑 P4 程序不打算编译 bmv2 的测试用例理论上可以跳过但现实是 bmv2 的 CMake 配置里经常默认探测 gmock缺了它会在配置阶段直接报错。所以我还是建议按步骤装上省得后面卡住。cd ~/p4-env unzip gmock-1.7.0.zip cd gmock-1.7.0 # 编译 gtest 和 gmock 的源码 g -I./include -I./gtest/include -I./ \ -c src/gmock-all.cc -o gmock-all.o g -I./include -I./gtest/include -I./ \ -c gtest/src/gtest-all.cc -o gtest-all.o # 生成静态库 ar -rv libgmock.a gmock-all.o gtest-all.o # 把库和头文件拷贝到系统目录 sudo cp libgmock.a /usr/local/lib/ sudo cp -r include/gmock /usr/local/include/ sudo cp -r gtest/include/gtest /usr/local/include/注意gmock 1.7.0 的年代比较早如果你用 gcc 8 以上编译可能需要加-Wno-error之类的参数。这里用的 g 命令是绕过 CMake 直接编译简单直接但如果你更习惯规范流程也可以把 gmock 的 CMakeLists.txt 单独跑一遍效果一样。3.3 验证底层依赖是否装好装完 protobuf 和 gmock 后建议做一次快速验证别急着往下走。因为我见过太多次“以为装好了”结果实际链接失败的案例所有组件的坑里这种沉默失败最消耗时间。# 检查 protobuf 版本 protoc --version # 应该输出: libprotoc 3.2.0 # 检查 gmock 库文件 ls -la /usr/local/lib/libgmock.a ls /usr/local/include/gmock/gmock.h # 检查动态库链接 ldconfig -p | grep protobuf如果protoc --version输出的是系统自带的旧版本比如 2.x说明configure时没有正确覆盖系统路径。这种情况可以把/usr/local/bin加到 PATH 最前面或者用which protoc查看实际调用的路径。通常我加的是一行环境变量export PATH/usr/local/bin:$PATH写入~/.bashrc后source ~/.bashrc。4. 编译安装 thrift 0.9.2 与 behavioral-model搭建运行环境4.1 thrift 0.9.2 编译时的坑有哪些thrift 0.9.2 的编译相对顺利但它有个很容易忽略的问题默认编译会带上 Java、Python、Ruby 等一大堆语言绑定这不仅慢还容易因为缺某个语言的依赖而整体失败。我一般会显式禁用不需要的语言绑定只保留 C 和 Python。cd ~/p4-env tar -xzf thrift-0.9.2.tar.gz cd thrift-0.9.2 # 显式只启用 cpp 和 python ./configure \ --with-cpp \ --with-python \ --without-java \ --without-ruby \ --without-go \ --without-nodejs \ --with-c_glibno make -j$(nproc) sudo make install sudo ldconfig参数说明--with-cpp是必须的因为 bmv2 本身就是 C 写的--with-python是给后续可能用到的 P4 运行时控制脚本准备的。其他语言绑定全部关闭这样能避开很多不必要的系统依赖比如 Java 的 ant 环境、Node.js 的头文件等。如果这一步在make时报libevent找不到回到第 2 章把libevent-dev补装上就好。4.2 behavioral-model 编译的关键分支和参数behavioral-model即 bmv2是 P4 虚拟交换机的基础运行时。编译时它最重要的参数是--disable-pi和--without-gtest这两个开关它们决定了你编译的简化程度。我的做法是保持默认开启 PI 和 gtest但前提是 protobuf 和 gmock 都已经就位。cd ~/p4-env tar -xzf behavioral-model.tar.gz cd behavioral-model # 先安装 Python 依赖 sudo pip2 install setuptools ryu # 或者用 pip3 install ryu取决于你的 Python 版本 # 从 autogen 开始生成配置 ./autogen.sh # 配置编译参数 ./configure --prefix/usr/local --with-pi make -j$(nproc) sudo make install sudo ldconfig这个编译过程通常会吃掉不少内存建议机器至少 4GB。如果make中途被杀进程检查一下 dmesg 里有没有 OOMOut of Memory记录有的话就把-j$(nproc)改成-j2或者-j1慢一点但能稳定跑完。另外--with-pi参数很关键它会把 PI 模块编译进来这个模块负责和 p4c 生成的 JSON 配置对接如果关闭后面跑 P4 程序时会有运行时通信问题。4.3 编译 p4c 并配置环境变量p4c 是 P4 语言的编译器它把 P44 源码编成 bmv2 能识别的 JSON 描述文件。p4c 的编译依赖 protobuf 和 grpc所以必须是等前面全部装完后最后编译它。这里我建议直接用官方仓库里对应的 release 分支而不是 master。cd ~/p4-env unzip p4c.zip # 假设 zip 包中已经是正确的 release 分支 cd p4c # 创建构建目录保持源码目录干净 mkdir -p build cd build # 配置 CMake 构建 cmake .. \ -DCMAKE_BUILD_TYPERELEASE \ -DCMAKE_INSTALL_PREFIX/usr/local \ -DBUILD_GRPCOFF \ -DENABLE_GTESTSON make -j$(nproc) sudo make install这里我把BUILD_GRPC关闭了因为我当前场景只需要 p4c 生成 bmv2 JSON 格式不需要和 gRPC 服务器对接。如果需要用 P4Runtime 做控制面通信这里要改成-DBUILD_GRPCON并且额外安装 grpc 依赖。ENABLE_GTESTSON会编译并运行一部分测试可以顺便验证 p4c 本身的正确性。编译完成后记得把关键路径写入环境变量。这一步不少人会忘记然后运行p4c提示找不到命令其实只是 PATH 没加对而已。# 编辑 ~/.bashrc echo export PATH/usr/local/bin:$PATH ~/.bashrc echo export LD_LIBRARY_PATH/usr/local/lib:$LD_LIBRARY_PATH ~/.bashrc source ~/.bashrc # 验证 which p4c p4c --version which simple_switch simple_switch --help 21 | head -20两个命令都能正常显示信息的话就说明 p4c 编译器已经就位simple_switch这个 bmv2 的核心交换机可执行文件也编译成功环境的主链路已经通了。5. P4 环境配置常见问题汇总翻车现场与自救指南5.1 “configure: error: C compiler cannot create executables”一出现就无从下手现象在执行./configure时直接报错提示编译器无法生成可执行文件。原因有两类一是 g 本身没装好二是环境变量 CC/CXX 被设置成了不存在的编译器。解决方法是先检查编译器再清理环境变量重新跑。# 确认 g 已安装且可用 g --version echo $CC $CXX # 如果显示奇怪路径unset 掉 # 清理缓存后重试 unset CC CXX make distclean 2/dev/null ./configure5.2 编译 bmv2 时报 “undefined reference to google::protobuf::…” 的链接错误现象bmv2 的链接阶段出现一大堆 protobuf 相关的 undefined reference。原因是 protobuf 库没有正确链接或者安装路径不在默认搜索路径里。解决时首先确认protoc --version是不是 3.2.0然后确认/usr/local/lib是否在LD_LIBRARY_PATH中。# 检查实际链接的库路径 ldd $(which simple_switch) 2/dev/null | grep protobuf # 如果为空或路径不对手动二次链接 export LD_LIBRARY_PATH/usr/local/lib:$LD_LIBRARY_PATH我在实际部署中最常见的情况是系统/usr/lib里有一个旧版 protobuf而/usr/local/lib里是新版。编译时用到的头文件是新的链接库时却优先找到了旧的这种冲突就会表现为千奇百怪的错误。处理方式是暂时隐藏旧版本用configure时的LDFLAGS参数强制指定路径。5.3 “thrift.h: No such file or directory” 的编译失败现象bmv2 编译到 thrift 相关源文件时找不到 thrift 的头文件。原因往往是 thrift 实际没装成功或者安装前缀和 bmv2 搜索路径不一致。解决时我最先检查 thrift 安装目录如果确认/usr/local/include/thrift存在多半是 pkg-config 路径没配好。# 检查 thrift 头文件 ls /usr/local/include/thrift/Thrift.h # 手动设置 include 路径 export CPLUS_INCLUDE_PATH/usr/local/include:$CPLUS_INCLUDE_PATH5.4 simple_switch 运行时提示 “thrift: error: Could not connect to ….9090”现象启动 simple_switch 后或者尝试用命令行工具连接交换机时端口 9090 连不上。原因通常是运行时 thrift 服务没有启动或者防火墙拦截了本机端口。bmv2 默认在 9090 端口开启 thrift RPC 服务这个服务本身由simple_switch进程内嵌。如果提示连接失败看看进程是不是真的起好了然后检查ss -lnt | grep 9090有没有监听。# 确认端口监听 ss -lnt | grep 9090 # 如果没监听用后台方式启动 simple_switch sudo nohup simple_switch --thrift-port 9090 /path/to/switch.json /tmp/simple_switch.log 21 # 查看日志定位问题 tail -50 /tmp/simple_switch.log5.5 p4c 生成 JSON 文件后 simple_switch 无法加载如果 p4c 能正常编译出 JSON 文件但 simple_switch 加载时报版本不匹配那基本可以断定是 p4c 和 bmv2 版本不一致导致的。一个常见场景是 p4c 是最新 master而 bmv2 是稳定的旧版本分支。我的建议是回到这套安装包里的 p4c 和 behavioral-model它们已经是互相适配过的版本组合不要自己混合不同源的文件。6. 装完怎么验证跑通从 P4 源码到交换机转发一个包环境装好之后最直接的验证方式是跑通一个最简单的 P4 程序——单交换机转发。这个验证能同时确认 p4c 编译、JSON 加载、thrift 服务、simple_switch 转发链路全部正常。我用一个极简的 P4 程序来测试代码只有几行故意跳过复杂逻辑只保留关键结构。先写一个最小 P4 程序demo.p4核心逻辑是对所有包都从端口 1 转发到端口 2。#include core.p4 #include v1model.p4 header ethernet_t { dst_addr : bit48; src_addr : bit48; ether_type : bit16; } struct headers_t { ethernet_t ethernet; } struct metadata_t { } parser demo_parser(packet_in pkt, out headers_t hdr, inout metadata_t meta, inout standard_metadata_t sm) { state start { pkt.extract(hdr.ethernet); transition accept; } } control demo_ingress(inout headers_t hdr, inout metadata_t meta, inout standard_metadata_t sm) { apply { sm.egress_spec 2; } } control demo_egress(inout headers_t hdr, inout metadata_t meta, inout standard_metadata_t sm) { apply { } } control demo_verify(inout headers_t hdr, inout metadata_t meta) { apply { } } control demo_update(inout headers_t hdr, inout metadata_t meta) { apply { } } V1Switch(demo_parser(), demo_verify(), demo_ingress(), demo_egress(), demo_update()) main;注意代码里sm.egress_spec 2是 P4 的 standard metadata 字段simple_switch 会据此决定包的出口端口。V1Switch(...)是 v1model 架构的固定入口顺序对应解析、校验、入口、出口、更新五个阶段少一个都会编译报错。然后执行验证流程# 第 1 步用 p4c 编译为 bmv2 JSON p4c --std p4-16 --target bmv2 --arch v1model demo.p4 \ -o demo.json # 第 2 步确认生成结果 ls -la demo.json # 第 3 步启动 simple_switch sudo simple_switch --log-console --thrift-port 9090 \ --interface 0veth0 --interface 1veth1 demo.json # 第 4 步用传入的 CLI 工具下发一条转发规则 sudo ~/behavioral-model/tools/runtime_CLI.py --thrift-port 9090 \ table_add demo_ingress 2 1 2 # 第 5 步抓包确认 veth1 上有数据 sudo tcpdump -i veth1 -c 5如果第 4 步返回空结果或报Invalid table name通常是 p4c 编译时把控制块名字做了扁平化处理。先在 CLI 里用tables命令查看当前表名再按实际表名下规则。这个步骤被很多人忽略导致前几步全部正确但怎么都通不了包。我在日志被坑过几次后养成了一个习惯每次装完环境都要跑一遍这个 demo从p4c编译到simple_switch加载 JSON再用 CLI 下发规则最后确认 tcpdump 抓到包。整套链路能串起来环境才算真正配好了。如果中间哪个环节断了就用第 5 章的排查方法逐个定位通常都能快速找到问题。希望这套流程能帮你少踩一些我当年踩过的坑一次把 P4 开发环境搭顺。本文还有配套的精品资源点击获取