TRex跑起来之后我的习惯动作是先看对端回包而不是先看线速。早期拿TRex做转发测试时总觉得只要端口up了、流量发出去了链路就算通了。但遇到真实DUT防火墙、路由器或者运营商级转发设备时我经常发现发出去的流量到了DUT就被悄悄丢掉因为DUT的路由表里压根没有目的网段。TRex是数据面流量工具不负责路由学习也不参与BGP/OSPF它只能“把包发出去”不能“让包被选路”。要模拟接近生产环境的转发行为就得有一个控制面对等体来做路由注入。这也是我在研读《TRex设计与实现》过程中把BIRDBIRD Internet Routing Daemon拉进测试栈的根本原因。这篇笔记并不是什么高大上的架构方案就是我在学习TRex路由相关能力时把BIRD作为BGP控制面接入TRex测试环境的过程、配置、踩坑和可以复现的配置参考。如果你正在做TRex功能验证、想搞大规模前缀注入或者想理解BGP控制面和数据面压测是怎么联动起来的这篇笔记应该对你有用。1. 为什么TRex测试都要配一台BIRD控制平面短板与补位思路1.1 数据面打流不等于真实流量行为先泼一盆冷水TRex能给你的是“极端数据面的确定性”不是“路由行为”。你用STL模式打一个UDP包包到了DUTDUT转发不转发取决于它自己路由表里有没有这一条。没有路由再高的线速也没有意义。我最早做的一个测试场景是这样的DUT是一台防火墙TRex两个口分别接在防火墙的inside和outside口。我满心以为两边都upUDP双向打流就能通结果第一个包就丢了。进控制台一看inside口没有默认路由outside口没有回程路由。防火墙就是这么实在——你路由表不告诉它怎么走它就真的不走。当时我直接在DUT上敲了静态路由问题也确实解决了。但等到后面做压力测试需要模拟几千个、几万个不同目的网段的流量时手工敲静态路由就成了噩梦。你不可能一条条把2万条静态路由写进配置而且即使写了后续删减、变更、模拟路由抖动全都变成了体力活。在这个时候用BGP来注入前缀是明显更合理的方案。1.2 BIRD为什么适合做这个“路由注入器”BIRD是一个轻量级路由守护进程在Linux/Unix上跑支持BGP、OSPF、RIP、Babel等协议。和Quagga/FRR相比它的特点是单个可执行文件配置是纯文本修改后重启或者SIGHUP重载都很快内存占用和启动速度在大量前缀场景下表现很好配置逻辑清晰适合自动化生成和批量管理支持把静态路由、内核路由重发布到BGP会话里天然适合做前缀注入。在TRex测试拓扑里BIRD不负责真正的数据面转发它只干一件事作为BGP对等体建立会话后向DUT通告路由让DUT“认为”网络里存在大量前缀。TRex再根据这些前缀构造流量的目的地址DUT的数据面就会去查路由、做动作这时候整个转发语义才完整。我画过一张很简化的图来说明控制面和数据面的分工[控制面] BIRD ----BGP---- DUT | [数据面] | TRex p0 --- DUT ---- TRex p1BIRD只在控制面和DUT打交道TRex在数据面从DUT的一侧打到另一侧。两者各司其职。1.3 最小验证拓扑我实际搭的最小环境是这样的TRex服务器双口10G网卡两个口分别连接DUT的inside和outsideDUT一台支持BGP的防火墙/路由器开启BGP能力BIRD服务器和DUT建BGP邻居用来注入路由。BIRD和DUT之间的连接不一定非要走独立物理口可以用DUT上专门的带外/管理口也可以复用一个数据口。我建议第一次实验时单独用一个口或者一个VLAN避免BGP会话跟数据面流量互相干扰排查问题的时候也清爽。三个节点之间网络规划得越简单越好我第一次实验时用了下面这套地址TRex p010.0.12.1/24网关指向DUT inside口 10.0.12.2TRex p110.0.15.1/24网关指向DUT outside口 10.0.15.2BIRDeth0接DUT的BGP口IP为10.0.13.1/24对端DUT是10.0.13.2AS规划DUT用AS 65000BIRD用AS 65001建立的eBGP会话。这个拓扑跑通之后后面做大规模前缀注入其实只是把BIRD通告的“路由条数”从几条改成几万条拓扑本身不用动。2. 环境准备与第一对BGP邻居的建立2.1 编译BIRD时的取舍BIRD目前主流是2.x版本2.x对IPv4/IPv6、BGP、OSPF的支持都更完整。我在实验环境里没有直接用发行版的包而是自己编译了一份因为后续我想把路由注入规模拉到几十万条用发行版老版本容易撞上各种限制自编译还可以按需裁剪。编译步骤不复杂wget https://bird.network.cz/download/bird-2.15.1.tar.gz tar xf bird-2.15.1.tar.gz cd bird-2.15.1 ./configure --prefix/usr/local/bird --enable-ipv4 --enable-ipv6 make -j$(nproc) make install--enable-ipv4 --enable-ipv6可以同时保留双栈如果你确定只做IPv4测试只开ipv4也够。编译完的二进制是/usr/local/bird/sbin/bird我习惯再做个软链后面启动方便。一个容易忽略的细节BIRD的配置文件路径默认是/etc/bird.conf但如果你用自己指定的prefix需要用-c参数指定配置路径。另外BIRD会把socket放在/run/bird下如果权限不对会出现无法连接birdctl的情况启动前确认目录存在且可写。2.2 用BIRD向DUT通告第一个前缀BIRD的配置语法第一次接触的人会觉得有点“跳”但结构其实很清晰。我最简配置是这样# /usr/local/bird/etc/bird.conf router id 10.0.13.1; protocol device { } protocol static stub_routes { ipv4; route 10.42.1.0/24 blackhole; route 10.42.2.0/24 blackhole; } protocol bgp bgp_lab { local as 65001; neighbor 10.0.13.2 as 65000; source address 10.0.13.1; multihop; ipv4 { import none; export filter { if net.type NET_IP4 then accept; }; }; }配置里最关键的两行是import none和export filter。import none表示不从DUT学路由避免把实验网的路由表搞乱export filter只把静态路由里的IPv4前缀发布给对端。启动BIRD后用birdc查状态/usr/local/bird/sbin/bird -c /usr/local/bird/etc/bird.conf /usr/local/bird/sbin/birdc show protocols all bgp_lab看到Established状态基本上第一对BGP邻居就通了。如果不通优先检查DUT侧有没有开BGP、AS号对不对防火墙有没有放行TCP 179端口源地址是否配置为10.0.13.1DUT能不能路由到该地址。2.3 用TRex验证通告前缀的真实语义BIRD通告了10.42.1.0/24和10.42.2.0/24之后DUT的路由表里应该能查到B 10.42.1.0/24 [BGP] 00:00:xx via 10.0.13.1 B 10.42.2.0/24 [BGP] 00:00:xx via 10.0.13.1这时候用TRex构造目的地址为10.42.1.1的流量DUT就不会再丢弃了。我用的TRex脚本片段大致是这样from trex_stl_lib.api import * c STLClient(server127.0.0.1) c.connect() c.acquire(ports[0, 1]) c.reset(ports[0, 1]) c.add_port_ip(port0, ip10.0.12.1, gw10.0.12.2) c.add_port_ip(port1, ip10.0.15.1, gw10.0.15.2) stream STLStream( packetSTLPktBuilder( pktEther(dst00:11:22:33:44:55)/IP(src10.0.12.1, dst10.42.1.1)/UDP(dport1234)/Raw(btest), ), modeSTLTXSingleBurst(pps1000, total_pkts1000), ) c.add_streams(stream, ports[0]) c.clear_stats() c.start(ports[0]) c.wait_on_traffic(ports[0]) print(c.get_stats())如果DUT转发正常TRex p0的opackets和p1的ipackets数字会一致。这里有一个容易误导新人的地方add_port_ip只是让TRex端口能解析网关IP让数据链路层能正确填MAC并不代表DUT一定会回包。真正决定流量通不通的还是DUT路由表里那一行BGP路由。3. 大规模前缀注入从千条路由到线速转发3.1 用脚本批量生成路由段并include进来单条前缀只能验证“通不通”大规模前缀注入才是BIRD集成学习的重头戏尤其是用来模拟互联网路由表规模、验证DUT路由引擎能力和TRex流量的组合压力。我在BIRD里批量注入路由用的是“脚本生成静态路由块 include导入”的方式。先生成一个包含大量route语句的片段for i in $(seq 1 253); do for j in $(seq 0 253); do echo route 10.$i.$j.0/24 blackhole; done done /usr/local/bird/etc/stub_routes_64k.conf然后主配置文件里include它protocol static stub_routes { ipv4; include /usr/local/bird/etc/stub_routes_64k.conf; }这样一下子就能产生6万多个前缀。blackhole关键字表示这些路由不会真正对应一个接口BIRD只负责把它们放进路由表并对外通告。有人会问为什么不用BIRD的管道去OSPF或者用现成的Internet路由表文件原因很简单静态路由块的行为最可控我可以精确控制前缀数量和分布后续做撤回、抖动测试也很方便。如果想模拟更真实的路由表也可以用birdc把MRT文件导入但学习阶段先跑脚本生成方式理解起来更快。3.2 BGP更新风暴下DUT收敛观测当BIRD配置了6万条静态路由并重载配置后BGP会话会立刻开始发送Update报文。在DUT上看路由表会像瀑布一样增长BGP neighbor is 10.0.13.1 BGP state Established Route refresh request has been received Total number of prefixes received 64738这个阶段我最关心的是DUT的收敛时间和CPU占用。用show bgp neighbor X routes可以观察前缀持续增长用show process cpu看路由引擎的负载。如果是真实的路由器/防火墙这个阶段很容易暴露出控制平面处理能力不足的问题——之前遇到的某个型号设备跑到2万条前缀时BGP进程就直接重启了。对TRex侧来说BGP更新风暴阶段不需要急着打流。我一般是等DUT路由表完全收敛后再启动TRex流量。否则数据面流量和控制面Update报文同时压过来出了问题很难分清是路由没收敛还是转发能力不够。3.3 为TRex流设置目标“路由命中”的检查收敛之后让TRex流量的目的IP动态命中多个前缀是验证“配角路由真的进入数据面”的关键。我用STLVmFlowVar让目的IP在一个范围内递增这样流量可以均匀命中不同前缀vm STLScVmRaw([ STLVmFlowVar(dst_ip, ipv4, min_value10.42.0.1, max_value10.42.255.254, size1, opinc), STLVmWrFlowVar(fv_namedst_ip, pkt_offsetDST_IP), STLVmFixIpv4(offsetIP), ])STLVmFixIpv4(offsetIP)很关键它让TRex在修改目的IP后自动重算IP头校验和。如果漏掉这一项DUT可能会因为校验和错误把包丢掉这时候你排查半天往往会怪到BGP头上实际上问题出在包本身。数据面的验证逻辑很简单TRex p0发出去的包最终要能从p1收回来。如果p0的opackets远大于p1的ipackets排查方向通常是DUT有没有将前缀正确放进转发表TRex目的IP范围是否完全落在BGP注入的前缀内DUT的回程路由是否生效防火墙策略是否放行了目标端口协议。我习惯在DUT上再抓一次路由表统计一下命中前缀的条目数确保TRex循环的IP范围和BIRD注入的前缀范围是重合的。这一步看起来琐碎但是整个压测里最容易翻车的地方之一。4. 实测中容易翻车的细节与排查链路4.1 下一跳自改为什么BIRD默认下一跳在数据面会“出不出去”BGP通告路由时默认“下一跳”是建立会话的邻居接口地址。在很多实验环境里BIRD和DUT之间的BGP连接网段和TRex的数据面网段并不在同一个二层域结果DUT虽然学到了前缀但转发时发现下一跳不可达流量一样出不去。我遇到的问题是BIRD通过10.0.13.1和DUT建BGP通告了10.42.0.0/16。DUT路由表里显示via 10.0.13.1但这个10.0.13.1所在的网段和数据面根本不连通。TRex打流过来DUT查路由后把包转发给10.0.13.1数据就死在BIRD这台“非转发设备”上了。解决办法是让BIRD在通告时把下一跳改成自身让DUT知道自己就是终点protocol bgp bgp_lab { ... next hop self; }实际上next hop self在eBGP场景里很常见。它把通告路由的下一跳改成BIRD自己的接口地址这样DUT路由表里显示的就是BIRD接口地址如果这个地址和DUT的接口地址在同一个直连网段转发语义就对了。更稳妥的做法是让BIRD的接口地址和DUT的BGP连接网段一致并且确保该网段的数据面路径是回环可通的。排查链路一句话先确认DUT路由表里的下一跳再确认下一跳是否真的存在于数据面可达路径。两个条件都满足TRex流量才会乖乖穿过去。4.2 keepalive、hold time和DUT高负载下的BGP抖动大规模压测时还会有个很隐蔽的问题DUT控制平面负载过高导致BGP keepalive消息没被及时处理。结果就是BGP会话频繁Established - Idle - Established路由表跟着抖TRex流量也时通时断。BIRD默认的keepalive和hold time分别是多少BIRD 2.x的默认行为是keepalive是hold time的三分之一。如果DUT在压测中CPU被打满哪怕只是短暂卡几百毫秒就可能超过hold time导致会话被重置。我的处理办法有两个思路把BIRD的会话计时器放宽一些。在实验环境里hold time 90或keepalive time 30比较安全不会因为DUT偶尔的CPU毛刺就抖动。反过来如果就是要测试DUT在极端负载下能否维持BGP会话则可以故意把hold time调小比如hold time 9、keepalive time 3观察会话稳定性。这是压力测试里一种常见的负面用例。配置示例protocol bgp bgp_lab { ... hold time 30; keepalive time 10; }另外如果DUT的BGP进程因为内存不足崩溃TRex数据面往往还在继续打流这时候看起来像是“DUT转发挂了”但实际上根因在控制面。排查时先看DUT的BGP邻居状态再看TRex的丢包统计顺序不能反。4.3 持续压测时的磁盘I/O与存储健康这个坑也是真实存在的。我在做长时间压测时TRex经常会开启抓包保存或者用--pcap把异常报文落盘。TRex服务跑在普通的x86服务器上如果系统盘满了或者磁盘I/O出现坏道TRex的捕获线程会卡住连带着吞吐统计出现毛刺非常影响压测结论。所以我在TRex服务器上养成了固定检查磁盘的习惯使用smartctl定期查看NVMe/SSD健康状态重点关注Media and Data Integrity Errors预留至少20%的磁盘剩余空间pcap抓包文件统一放到独立数据盘避免和系统日志抢占I/O压测期间用iostat -x 1观察磁盘利用率如果%util持续超过80%就考虑缩短抓包时长或改用过滤抓包。这一点虽然不是BIRD集成的核心内容但长时间压测时恰恰是它最能拖后腿。TRex服务所在机器本身不稳定整个实验结论都会打折扣。5. 从学习走向工程故障转移、流量规格与有状态联动5.1 用BGP Flowspec给TRex流量“划边界”BGP FlowspecRFC 8955允许通过BGP传递流量规则让路由器对特定流量做丢弃、限速等动作。BIRD 2.x对这个协议有实现基础我在实验环境里试过用BIRD向DUT下发一条Flowspec规则让DUT对某个前缀的流量直接丢弃。这种能力配合TRex做DDoS防护验证特别方便TRex负责打流量BIRD负责下发“哪些流量算攻击”的规则DUT负责执行。配置Flowspec时BIRD里要单独开一个flowspec通道并在导出过滤器里放行Flowspec路由。不过不同厂商DUT的Flowspec兼容性并不一致先用小规模前缀测通再上量否则背景流量很容易把实验环境打崩。5.2 多BIRD对等体做故障转移实验生产环境的BGP往往不止一个对等体。我后来在实验里起了两个BIRD实例分别用不同的配置文件、不同的socket路径模拟两个上游AS让DUT同时从两个邻居学路由再用TRex打流验证主备路径切换。BIRD多实例启动命令大致是bird -c /usr/local/bird/etc/bird-1.conf -s /run/bird-1.ctl bird -c /usr/local/bird/etc/bird-2.conf -s /run/bird-2.ctl两个实例分别通告相同或不同的前缀。如果通告相同前缀DUT通过BGP选路规则优先选择最优路径此时把其中一个BIRD实例停掉DUT会自动切换到另一条路径。TRex在数据面连续打流就能直观地看到丢包窗口和收敛时间。这类实验对理解BGP的选路、故障收敛和TRex在长稳场景下的表现很有帮助。5.3 ASTF有状态流量与BIRD路由注入的组合拳STL模式是无状态包只管发不管会话。TRex的ASTF模式可以模拟真实的TCP三次握手和会话行为这在做应用层设备和业务链路测试时更贴近生产。我在ASTF场景里同样接入了BIRD路由注入——先让BIRD向DUT通告客户端/服务端网段再用ASTF模板模拟真实应用流量。ASTF的配置会比STL复杂一些但核心思路一致控制面路由让DUT“认得路”数据面流量让链路“跑起来”。这两个能力一旦打通很多业务仿真就能落地了。比如模拟一个HTTP服务客户端从BIRD通告的客户端网段发起访问请求服务端在另一个网段DUT按路由规则转发ASTF完成真正的TCP握手。这个组合在验证防火墙状态检测、负载均衡会话保持等场景时效果非常直观。我在实际使用中的体会是BIRD与TRex的组合本质上是把“控制面可控性”注入到“数据面高压环境”里。纯粹的数据面压测能暴露性能上限但只有在控制面真正参与的情况下测试结果才接近生产环境里设备真实的行为。一开始花一晚上调通BGP邻居和TRex流后面所有路由相关实验都会顺畅很多。最后再分享一个小技巧那几万条静态路由文件千万别手写全部用脚本生成在BIRD里用include统一管理这样从几十条到几十万条切换只是改一行include的事。
