★ FEATURED ARTICLE “很多做数通设备测试的兄弟一听到‘跑个2544’就条件反射地上下行对等打流两边都拉满看最高能到多少然后丢出一句‘整机性能达标’。这套思路在对称链路上没问题但放到现网‘大下行小上行’场景里往往会得出和用户体验完全对不上的结果。所谓大下行小上行说白了就是一台设备/一条链路日常跑的流量比例严重不平衡下行可能占90%以上上行只有10%左右。信而泰的2544非对称测试就是为了在这种比例下把设备真实承载能力测出来而做的专项打流方案。这篇文章以信而泰BigTao测试仪加Renix软件为例讲讲非对称测试怎么做、参数怎么定、结果怎么判以及我在实际项目中踩过的几个坑。”1. 场景拆解为什么“大下行小上行”不能按对称模型测试1.1 现网流量模型与家宽常见配比先搞清楚被测对象长什么样。家庭宽带、企业专线、园区出口这类场景流量模型几乎都是“下行压倒性占优”。运营商千兆宽带典型签约就是1000Mbps下行、100Mbps上行10比1甚至更高。企业内部大量访问云盘、视频会议下行画面、远程桌面、软件推送上行基本只有请求和ACK之类的小流量。FTTH场景里OLT下挂几百个用户共享上行带宽上下行不平衡更是常态。这种设备在研发实验室里做性能对标时如果只按RFC 2544对称方式打流上下行各打50%负载也就是同时给设备两个方向等量压力最后得到一个“上下行HOLB阻塞临界点”的数据。但现网根本不会这么跑。用户侧的流量比例是固定的“下行大、上行小”设备里队列调度、缓存分配、QoS优先级都是按照这种比例设计的。对称测试等于把一个按非对称场景优化的设计放到一个对称的假想环境里验证结论自然没有参考价值。1.2 对称测试为什么会“测不准”我举一个真实例子。之前测一款家用路由器标称千兆口用传统对称2544测双向同时打流各方向都能跑到950Mbps以上报告很好看。但交给运营商做入网测试模拟1000Mbps下行加100Mbps上行的非对称流量模型下行实际只能到620Mbps左右。一开始大家都怀疑是路由器CPU性能不够后来抓包发现问题出在上行方向TCP下行的ACK包全挤在上行小流量里上行带宽不足导致ACK丢包TCP发送端不断降窗下行吞吐直接被卡住。对称测试时上行有足够带宽容纳ACK完全暴露不了这个问题。这类问题在数据设备上很普遍。下行大流量会占满转发队列上行的ACK、DNS查询、控制报文如果被调度器饿死用户感知就是下载速度上不去、网页转圈。对称测试测的是“设备能不能同时处理两个方向的大流量”而不是“设备在真实非对称比例下能不能保住下行带宽”。所以要想测准“大下行小上行”场景必须在测试仪表上分离控制上下行流量按业务比例打流。1.3 非对称测试到底解决什么问题非对称2544测试要回答的核心问题有三个第一上行带宽只有签约值的时候下行还能不能跑到承诺带宽第二把上行压力提上去之后下行会不会被明显拖累拖累的拐点在哪里第三不同帧长组合下上行小包会不会影响下行大包的转发时延。这三个问题都是对称测试给不了答案的。所以非对称测试的定位不是替代传统2544而是作为设备入网、版本迭代、竞品对标里的“场景化测试项”。我一般在做完整性能评估时会把对称2544作为基础指标把非对称2544作为现网映射指标两者配合起来看。只做非对称会漏掉设备对称转发上限只做对称则会漏掉用户体验瓶颈。2. 信而泰2544非对称测试的核心设计思路2.1 RFC 2544四项指标在非对称模式下怎么理解RFC 2544本身定义的是四个经典性能指标吞吐量、时延、丢包率、背靠背。标准本身没有强制要求对称但传统打流方式默认就是双向等负载。做非对称改造时四个指标的含义要重新对齐一下。吞吐量在非对称场景里要拆成“下行最大无丢包速率”和“上行最大无丢包速率”两个值。测试时通常保持一个方向固定另一个方向做二分法搜索搜出来的结果不是“整机吞吐”而是“在给定上行负载下的下行吞吐极限”。时延也要分方向看下行大帧时延和上行小ACK时延往往差了数量级分别统计才能判断设备调度是否合理。丢包率必须分方向跑多速率阶梯只看总丢包数会掩盖某个方向拥塞的问题。背靠背测试在非对称场景里参考意义相对小一些但还是可以做用来验证突发条件下双向缓存是否够用。2.2 测试拓扑与端口规划非对称2544的拓扑和对称测试没有本质区别核心还是“仪表端口A——被测设备——仪表端口B”这种穿通结构。仪表端口A模拟下行侧比如OLT/局端端口B模拟上行侧比如CPE/用户端。下行流从端口A发出经过DUT转发到端口B上行流从端口B发出经过DUT转发到端口A。两条流是同时跑的。端口规划有几个细节要注意。第一两个仪表端口速率必须匹配DUT两侧的实际接口能力如果DUT一侧是千兆一侧是百兆那就不能用千兆链路去模拟百兆上行的比例得按实际速率折算。第二DUT如果是三层设备需要提前配置好接口IP和路由保证双向报文都能正确转发如果DUT是二层交换机则要规划好VLAN和MAC表项。第三建议每个方向都独占一个物理端口不要在同一端口上用VLAN复用模拟两个方向否则打流时端口收发方向会互相干扰结果很难看。2.3 三种负载模型的选择我用信而泰平台做非对称测试时会根据验收目标选三种负载模型之一。第一种是固定上行、搜索下行。上行设置在签约带宽或者线速的10%下行从线速开始二分搜索无丢包最大速率。这种模型最贴合“用户签约1000M下行、100M上行”的验收思维适合验证下行承诺带宽。第二种是固定比例同步加压。比如下行比上行等于8比2两个方向同时按比例提高负载直到某一方向先出现丢包。这种模型能测出设备在既定业务比例下的总转发能力适合竞品对标。第三种是双向独立搜索。下行和上行各自做二分法测出两个方向的独立吞吐极限。这种模式最耗时但能画出完整的性能包络适合研发阶段定位瓶颈。具体选哪种取决于你手里设备的设计目标和测试报告要给谁看。给运营商看入网报告选第一种给产品部门看整体能力选第二种或第三种。测试之前一定要和需求方把比例定清楚我在项目里见过因为比例口径不统一测了两轮报告全推翻重来的情况。3. 实操步骤用信而泰Renix搭一次完整的非对称25443.1 建工程、绑定端口、配置链路信而泰的测试软件Renix操作路径大概这样启动软件后新建工程添加机框在机框下选择BigTao板卡对应的测试端口把端口绑定到工程里。绑定完成后先别急着配流量花两分钟做端口自检和链路协商检查。端口速率建议手动固定。特别是做非对称测试时上行方向本来流量就小如果端口自协商降到10Mbps或100Mbps整个比例全乱。我一般直接在端口属性里把速率、双工模式固定成和DUT对端一致关闭自协商关闭流控。流控这个坑后面细说测试性能时开着流控等于给设备加了一层缓冲保护测出来的吞吐会虚高不符合严苛验收口径。绑定端口后要给两个端口配置网络层地址。三层设备测试时仪表端口A配置一个IP端口B配另一个网段IP中间DUT配路由。二层设备测试时IP可以不配但MAC地址一定要规划好后面预学习阶段要用。配置完成后先发一组小流量连通性测试确认双向都能通再往下走。3.2 创建下行流和上行流两个独立流量模型Renix里创建流量模板时关键是把下行和上行拆成两条独立流。我习惯给每条流命名带上方向标识比如“DOWN_MAIN”“UP_ACK”方便后期看统计。下行流建议用UDP封装不要用TCP。2544测的是设备转发能力不是TCP协议栈行为如果用TCP打流TCP自身的拥塞控制会干扰速率模型导致发送端实际速率根本没达到设定值。UDP可以保证仪表以恒定速率发送测试结果才有对比意义。封装格式上外层Ethernet类型可以看DUT支持情况选择IPv4加UDP是最通用的组合。帧长设置也分别配下行流可以用超大帧或者典型业务帧上行流模拟ACK时用小帧比如64字节或128字节。两个方向的帧长可以完全不一样这正是非对称测试灵活的地方。源MAC、目的MAC、源IP、目的IP都要按实际转发路径填。这里注意一个常见错误有些人图省事下行和上行流共用同一组MAC地址结果DUT做MAC学习时表项不停抖动丢包率莫名升高。正确做法是下行流用一组MAC上行流用另一组让DUT的FDB表稳定下来。3.3 负载参数与二分法设置这是非对称测试最核心的一步。在Renix的RFC 2544测试配置里把两条流分别挂到测试任务下然后进入负载模型设置。如果选“固定上行、搜索下行”模式上行流负载填固定值比如100Mbps下行流负载选“二分法搜索”起始速率填端口线速最小调整步长填0.5%或者1%判断标准选“零丢包”。系统会自动执行多轮打流在成功和失败之间二分收敛最后给出达到零丢包的最大下行速率。如果选“固定比例同步加压”则给两条流配同一个比例因子Renix按比例同时调整两个方向负载。这个比例因子建议配置成百分比比如下行90%线上速率、上行10%线速然后整体乘以一个负载系数去搜。速率换算这里给一个通用公式免得现场手算出错。以太网每个帧在线路上实际占用长度等于帧长加上8字节前导码和12字节帧间隙换算成pps就是线速pps 端口速率(bps) / [8 × (帧长 8 12)]以10GE端口发1518字节帧为例单帧在线路占用就是8乘1538等于12304比特10Gbps除以12304约等于81.27万pps。配置仪表时如果你要用百分比线速做负载心里先按这个公式估算一下对应速率校验仪表填的值是否合理。3.4 帧长矩阵与测试时长设置帧长矩阵沿用RFC 2544推荐的几个标准值64、128、256、512、1024、1280、1518。非对称测试时我建议下行流至少跑全矩阵上行流可以根据业务模型精简比如只跑64和128两种小帧。因为上行小帧是ACK业务的典型形态最能暴露调度问题。每帧长的测试时长RFC 2544建议单次测试至少60秒实际工程里为了赶进度经常被压缩到10到20秒。我的经验是摸底测试可以压到20秒但出验收报告时必须跑满60秒。因为非对称场景下某些丢包属于间歇性拥塞测试时间太短根本触发不了报告上写“达标”其实站不住脚。迭代次数和收敛精度也要设置好。二分法默认一般到最小步进小于等于0.5%就停止如果设备性能抖动大建议把最小步进放宽到1%否则测试可能长时间不收敛。收敛循环次数设一个上限比如30轮超过上限自动取最近一次成功值。3.5 执行测试与结果解读配置全部完成后先跑一轮小规模的预测试把帧长矩阵缩短、时长缩短确认两条流和DUT的转发路径都没问题再跑完整测试。我每次都会先跑一轮3分钟冒烟测试这能省掉后面大量“测试跑了半小时才发现流量模型配错”的时间。正式报告出来后重点看三个维度。第一下行搜出来的最大无丢包速率和上行固定负载之间的差值这个差值如果小于预期业务带宽说明DUT在下行方向上存在瓶颈。第二不同帧长下两个方向的时延曲线注意上行小帧时延是否在下行负载提高后急剧变大或者小帧时延均匀性是否变差这些往往是调度算法的软肋。第三丢包率阶梯表看丢包是从哪个负载点开始出现这个拐点就是设备实际承载能力的边界。Renix结果面板里可以选择按方向、按帧长、按负载分层显示导出CSV后我习惯把下行和上行数据拆成两个sheet再按测试时间画趋势线。报告模板里也会把四条测试项目的通过/失败标注出来最终判定规则要事先和需求方确认好比如要求所有帧长下下行吞吐不低于签约带宽的90%且丢包率为零才算通过。4. 常见问题与排查实录4.1 双向打流时MAC地址表抖动首包丢包严重第一次做非对称2544的时候最容易撞上的问题。两条流同时打DUT的MAC表还没学习完成大量报文被当成未知单播洪泛仪表侧统计出莫名丢包。解决办法是正式测试前做一轮预学习让两条流以很低的速率跑几十秒把DUT的二层转发表填满、填稳再开始2544测试。Renix里一般都有“学习帧”或者“预打流”选项没有的话就手动发一组短时低速流。预学习之后如果还丢包检查一下是不是两条流用了同一组MAC导致表项反复漂移。4.2 速率协商不一致上行流量只有预期的一半有次测试上行搜不出速率从100M开始就往下降最后只有48M左右。排查半天发现仪表端口和DUT之间自协商到了100M全双工但DUT对端实际是千兆光口转电口模块协商结果不稳定。自协商功能在性能测试里是不可控变量特别是遇到光电转换模块、老式交换芯片、高低温环境协商结果可能和预期完全不同。做非对称测试前在所有端口上强制固定速率和双工模式不依赖协商结果。4.3 流控开启导致吞吐虚高验收数据失真这个问题比较隐蔽。FAE现场调试时为了网络稳定经常默认把端口流控打开。流控开启后DUT拥塞时会反压仪表端口仪表收到流控帧后就自动降低发送速率于是测试仪“配合”DUT把吞吐维持在高位。最终报告显示零丢包但实际业务流量是不理会流控帧的用户体验照样卡。性能测试时端口流控必须关闭两边都关不能只关仪表一侧。这是我在一次运营商验收测试里被现场老师傅点名批评后记住的教训。4.4 结果判定时容易犯的几个口径错误最后提醒一下报告口径。非对称测试结果不要简单把下行和上行的两条吞吐加起来当作“总吞吐”上下行各自独占端口资源加起来没有物理意义。判定时首先明确每个方向的最低要求比如下行必须大于等于800Mbps上行必须大于等于100Mbps然后按帧长逐项核对。别只看平均丢包率非对称场景下突发丢包集中在某个帧长上是常事平均数值一拉平就看不出来。每条流的测试时间、负载比例、帧长、迭代精度全部写清楚报告才具备可复现性不然换个测试人员结果对不上又得返工。信而泰的BigTao加Renix平台做非对称2544本质上没有太高的技术门槛难就难在把流量模型定义得和现网一致把参数收敛设置得合理。我个人在实际操作中的体会是先花十分钟把业务方的流量比例问清楚比在软件里反复试参数管用得多端口链路情况和流控状态必须测试前确认否则后面所有数据都不可信。碰到吞吐上不去的现象别急着怀疑仪表先检查DUT侧的调度、缓存和端口状态大多数瓶颈都在被测设备上。这套操作跑顺之后你会发现非对称2544的测试效率比对称测试高不少因为两个方向的负载本来就不同设备的状态更接近真实运行很多在设计阶段就能暴露的问题不用等到现网去背锅。
阅读完成 · 觉得有帮助？
