★ FEATURED ARTICLE 简介Attero损伤仪中文使用手册面向网络性能测试工程师、网络运维及实验室技术人员围绕网络设备与服务在故障和劣化条件下的评估需求提供一份可直接对照操作的中文说明。压缩包内仅含1个docx文档大小约838KB以文字与界面示意为主便于随查随用。手册从接口分布讲起说明100M、1G、10GE光/电接口及LED状态显示并梳理链路闪断、物理层误码、L2L7流量劣化、时延、抖动、丢包、乱序、PDV、流量捕获与G.1050模型等损伤能力同时给出PC控制终端连接、.NET Framework与Visual C 2012等运行环境准备以及Start Up、SETUP INTERFACE、内存分配、双方向损伤和时延、抖动、丢包、带宽控制等配置顺序。已有445人学习适合需要快速上手该仪表、建立测试流程与排错思路的读者参考。1. 一台仪表压住整条链路的坏脾气Attero 损伤仪手册能解决什么实验室里最贵的不是设备是「复现不出来」。业务方说视频卡顿、语音断续、文件传输偶发超时你回到工位用 ping 一看 0% 丢包、平均时延 12ms一切正常——问题就此变成玄学。Attero 损伤仪就是冲着这类场景来的它串在链路中间把时延、抖动、丢包、乱序、带宽限制、物理层误码、链路闪断这些「真实网络里的坏脾气」按你设定的参数稳定注入让不可复现的故障变成可重复的实验条件。这份 Attero 损伤仪中文使用手册价值不在文字量而在于它把接口定义、损伤模型配置顺序、客户端安装依赖这些最容易翻车的环节摊开写清楚了——尤其是默认 100M 工作模式、光模块型号匹配、双向损伤分别加载这几条不看手册直接上手测试数据基本作废。适合谁做网络设备验收、音视频质量评估、专线交付验证、车载与工业以太网测试的工程师手上有一台机器但英文界面啃得累的人。2. 接口与光模块先落地从 100M 电口到 10GE 光口的接法接线这一步看着最没技术含量实际上是整个测试里返工率最高的环节。仪表端口多、形态杂光口电口混着来一个模块插错后面的损伤参数配得再漂亮都是白忙。手册里那张接口示意图不是摆设它决定了你的流量从哪个口进、从哪个口出、管理面走哪条路。2.1 端口清单先对上号哪些口跑业务哪些只是占位先把机框背板的端口功能梳理成一张表贴在手边接线时逐条对。手册给出的端口划分比较清晰但「保留接口目前暂不使用」这一条尤其要注意——现场有人看到空着的口就想插插完发现没反应再怀疑设备坏了浪费半天。端口标识速率/形态介质要求用途注意事项1保留无当前版本不启用不要插模块不要接线210GEXFP 或 SFP 光模块高速业务口仅 Attero-X 提供非 X 型号无此口310GEXFP 或 SFP 光模块高速业务口仅 Attero-X 提供与端口 2 成对使用4LED 显示屏无显示系统状态与管理 IP、端口号上电后第一手信息来源5以太网电口连接 PC 控制终端管理面专用不承载业务流量61G / 100MSFP 光模块常规速率业务口光口必须装模块才通71G / 100MSFP 光模块常规速率业务口与端口 6 成对使用看清楚一件事业务流量走 2/3 或 6/7管理流量走 5。这两条路径在物理上是分开的配置时也应该是分开的。我见过有人把 PC 插到 6 号口上试图管理设备然后开始怀疑客户端软件有 bug。2.2 光模块选型XFP、SFP、SFP 三者别插错10GE 口写的是「XFP 或 SFP」这两个封装外形尺寸、引脚定义都不同虽然都是 10G但插槽不通用——准确说同一个笼子通常只支持其中一种具体以机框丝印为准。1G/100M 口写的是 SFP那是千兆及以下的标准封装。三者的对应关系搞混轻则插不进去重则把笼子里的引脚顶变形。选模块时按这四步走确认对端设备的接口速率和封装是 10GBASE-SR/LR 还是 1000BASE-SX/LX确认传输距离与光纤类型多模短距用 SR 类单模长距用 LR 类多模模块接单模光纤是常见翻车点两端模块的波长必须一致1310 对 1310、850 对 850不要跨波长凑合插模块前断电或至少确认端口未启用热插拔在部分老机框上会触发端口异常。提示模块插上后 LED 无任何变化先别怀疑模块坏。拔下来换个已知能用的口试一次能排除掉一半的「模块故障」。2.3 电口与自协商10/100/1000Mbps 怎么定手册写明支持 10/100/1000Mbps 电接口。电口的好处是不用操心模块坏处是自协商。两端设备如果一端强制千兆全双工、另一端自协商协商结果经常落在一个「半双工千兆」的奇怪状态上表现为大包丢、小包通速率测试数据非常难看。稳妥的做法是两端保持一致的策略要么都自协商要么都手工锁定速率和双工。测试专线质量时我更倾向后者把链路条件钉死排除协商过程带来的抖动。锁定后从 PC 侧做一次基础连通性验证# 从 PC 侧确认链路速率与双工状态Linux 环境网卡名为示例 ethtool eth0 | grep -E Speed|Duplex|Link detected # 输出应类似Speed: 1000Mb/s Duplex: Full Link detected: yes这段命令干的事很简单读取网卡驱动上报的链路协商结果。Speed是实际协商速率Duplex是双工模式Link detected是物理层是否有信号。三个值里任何一个不符合预期都说明物理层没谈拢此时去配损伤参数毫无意义。Windows 侧对应的是在网卡属性里看「链接速度」或者用wmic nic where NetEnabledtrue get Name,Speed查速率。2.4 接线顺序与上电自检LED 上的 IP 是第一手信息手册把 LED 显示屏列在第 4 项作用写得很克制——「指示系统状态和 IP 地址」。实际这是排障时最有用的信息源机框管理 IP 是多少、端口号是哪个全在这块小屏上滚动。接线与上电建议按固定顺序来别图快先接管理口端口 5到 PC此时不接业务口上电等 LED 稳定显示 IP 与端口号抄下来配好 PC 的 IP 使其与机框管理 IP 同网段ping 通再关电或保持通电插业务口光模块与光纤确认业务口 LED 状态正常后才进客户端做 Start Up。这个顺序的好处是每次只引入一个变量。管理面不通的时候你只需要怀疑 IP、掩码、防火墙业务面不通的时候你只需要怀疑模块、光纤、速率。两个面同时不通排查成本翻倍。3. 客户端从装到通.NET、VC 运行库与 Start Up 连接链路控制软件装不上、装上了连不上是新手最先撞上的两堵墙。手册在这一块的描述只有三行但每一行背后都对应一个具体的失败场景。这一段把安装文件、依赖顺序、连接逻辑拆开讲。3.1 运行库依赖.NET Framework 与 VC 2012 的安装次序手册点名的安装文件有三个Microsoft.NET.exe、Visual C2012、AtteroInstaller_40.02.52_131113.exe。原文说得很直接——如果 PC 以前没装过 .NET Framework 和 VC 2012先装这两个再装控制软件。这个次序不是形式主义。控制软件是托管代码加原生库的混合体.NET 负责界面与业务逻辑VC 运行库支撑底层抓包与网卡驱动调用。先装主程序后装运行库注册表项和并行程序集缓存的状态可能不对典型的症状是双击图标闪一下就没了或者弹出「无法加载 DLL」但不说清是哪个 DLL。装之前建议先检查现有环境避免重复安装冲突# Windows CMD 下查看已安装的 .NET Framework 版本注册表方式 reg query HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full /v Release # Release 值对应版本例如 528040 表示 4.8若提示找不到项说明未装 4.xRelease是一个十进制数字微软用它在注册表里标记版本号值越大版本越新。查不到v4\Full这一项说明这台机器上根本没有 4.x 版本必须先跑Microsoft.NET.exe。VC 2012 对应的包名一般是vcredist_x86.exe或vcredist_x64.exe注意控制软件是 32 位还是 64 位——不少测试仪表的上位机仍然是 32 位程序这时装 x64 版的运行库是不够的需要把 x86 版本一并装上。这是最容易漏的一条。3.2 AtteroInstaller 安装与首次启动依赖装完再跑主安装包。安装路径尽量别带中文和空格某些老版本安装器在拼接路径时对非 ASCII 字符处理不干净会把配置文件写到奇怪的位置。默认路径就挺好。安装完成后首次启动正常表现是直接进入控制界面左侧工具栏按顺序排列 Start Up、SETUP INTERFACE、损伤配置等节点。如果启动后界面空白、工具栏灰掉第一反应是去设备管理器看网卡是否正常识别——注意控制软件不一定依赖专用驱动但它会枚举本机所有网卡某块虚拟网卡或已禁用网卡状态异常时枚举过程可能异常退出。启动成功的判断标准不是「窗口出来了」而是 Start Up 页面里能看到等待连接的状态且本机网卡列表完整。3.3 Start Up 连不上机框时的四条链路检查手册的第一步写得很简「Start Up连接 Attero 机框机框的 LED 显示屏会显示机框的管理 IP 和端口号」。真连不上的时候按下面四条顺序查不要跳步物理链路PC 网口灯亮不亮网线是直通还是交叉现代网卡自适应但老设备未必管理口是不是插到了端口 5。网段一致性PC 的 IP 与机框管理 IP 必须在同一网段。机框显示192.168.1.100PC 配192.168.1.50/24是对的配成10.0.0.50/24就一定不通。连通性验证用 ping 打一次别只看软件界面。主机侧拦截Windows 防火墙对私有网络默认放行 ICMP但对第三方程序的出站连接可能弹窗拦截装完软件第一次启动时留意有没有被静默拒绝。ping 通之后软件还连不上问题往往出在端口号上。机框 LED 上显示的不只是 IP还有端口号客户端里如果支持手工指定端口务必和屏上一致。我遇到过屏上显示的是非默认端口操作者按默认端口连耗了半小时。# 连通性验证-n 指定次数-w 指定超时毫秒-S 指定源地址多网卡机器必加 ping -n 4 -w 1000 -S 192.168.1.50 192.168.1.100-n 4发四个包够判断基本连通-w 1000把单包等待压到 1 秒避免卡住-S在多网卡机器比如同时接了办公网和测试网上非常关键——不指定源地址系统可能从办公网卡发出请求包到了错误的网段。多网卡环境是「ping 通但软件连不上」的头号原因。3.4 Setup Interface 与 Throu Mode为什么默认 100M 会骗人第二步 SETUP INTERFACE手册给了一句关键提醒仪表默认工作在 100M 速率模式下如果连接千兆交换设备需要调整损伤加载测试环境中仪表工作在 Throu Mode直通模式。这两句话翻译成操作就是两件事。第一默认值是 100M接千兆设备不改成 1G你测出来的一切都是百兆链路的性能跟被测设备的能力无关而且表现形式往往是「大量丢包」——因为千兆流量灌进百兆管道超出部分直接被丢弃。第二要做损伤注入必须选 Throu Mode这个模式下流量真实穿过仪表并被修改如果选成其他模式损伤参数可能根本不生效或者只在特定方向生效。注意每次换被测设备、换速率都要回头检查 SETUP INTERFACE。这个页面的值不会跟着你换光模块自动变它是纯手工配置项。4. 损伤参数怎么填时延、抖动、丢包、乱序、带宽与误码的取值逻辑参数配置是整台仪表的核心价值所在也是最容易「配了个寂寞」的地方——参数填了流量也过了但测出来的结论站不住脚因为参数之间互相污染或者数量级选错了。这一章按手册的配置顺序把每个损伤项的取值逻辑说清楚。4.1 内存分配与双向损伤先算容量再谈参数手册第三步的第一条是「查看内存分配情况如果不对请到 memory allocation 重新分配」。这条放在最前面是有道理的损伤引擎需要为时延队列、乱序缓存、抓包缓冲预留内存分配不足时表现为参数改了不生效、时延抖动明显偏大、或者大流量下大量非预期丢包。内存怎么算一个粗糙但够用的估算是时延损伤所需的缓存 ≈ 链路速率 × 最大时延。举个例子1Gbps 链路加 200ms 固定时延单向缓存需求大约是 1Gbit/s × 0.2s 200Mbit ≈ 25MB双向再加倍还要留出抖动分布的余量。10Gbps 链路配 100ms 时延单向就是 125MB 量级。所以高速率大时延的组合是最吃内存的配置前先看一眼预期值别等到跑流量时才发现引擎在丢包。第二条是「分别加载双方向损伤」。手册用「分别」两个字说明 A→B 和 B→A 是两套独立配置。测试语音和视频时这点很关键真实网络的上行下行劣化程度往往不对称只配单向就把双向都当成一样的结论会偏乐观。我的习惯是先配 A→B验证生效后再照抄一份到 B→A需要不对称就只改其中一侧。4.2 时延与抖动三种分布模型对应什么真实场景时延损伤一般是固定值单位毫秒。抖动则是时延的变化量手册明确支持高斯、伽马、矩形三种分布模型。这三者不是随便选的它们对应不同的真实网络行为分布模型数学特征对应真实场景参数关注点高斯正态围绕均值对称分布尾部快速衰减队列调度稳定、背景流量平稳的骨干链路均值 标准差伽马右偏、长尾偶发大偏移无线回传、拥塞链路的排队时延形状参数 尺度参数矩形均匀上下界内等概率最坏情况边界测试、设备容限验证上界 下界高斯分布适合做基线它描述的是一条「总体健康但有微小波动」的链路用它验证设备在正常抖动下是否稳定。伽马分布的右偏长尾更贴近真实拥塞——大部分包时延不高少数包被队列拖了很久这种「少数派」恰恰是音视频卡顿的元凶。矩形分布是工程上的保守选择我不预测分布形状我只保证抖动不超过上下界用它做容限测试最直接。配置时有个顺序问题抖动建立在时延之上先给一个基础时延再叠加抖动量。基础时延为 0 时配抖动某些版本上表现不稳定因为抖动偏移可能算出负值引擎会做钳位实际分布就被截断了。我一般至少给 510ms 的基础时延再配抖动。4.3 丢包、乱序与带宽控制三个容易被互相污染的参数这三个参数放在一起讲因为它们会互相干扰而且干扰方式很隐蔽。丢包。配置项通常是丢包率百分比或万分比。给个参考量级0.01% 的丢包足以让 TCP 吞吐明显下滑1% 会让实时语音出现可感知的断续5% 以上基本属于链路不可用。测试时不要一上来就 10%那样除了证明「链路废了」之外得不到任何有用信息。建议做阶梯0.001% → 0.01% → 0.1% → 1%每个台阶跑够时长。乱序。乱序的本质是「包晚到」不是「包丢失」。乱序率配得太高时接收端可能把晚到的包当成重复包丢掉表现出来跟丢包一模一样你却在丢包统计里看不到数字。乱序参数通常有两个乱序比例和乱序延迟偏移。偏移量必须大于接收端重排序窗口的容忍度才有意义太小了协议栈自己就消化掉了测试等于没做。带宽控制。这是限速不是丢包。但限速一旦触发超出令牌桶的包会被丢弃或排队于是你在丢包计数上看到了数字误以为是丢包损伤在起作用。排查办法很简单把丢包和乱序全部关掉只留带宽控制看丢包计数是否归零。如果还涨那就是限速导致的跟丢包参数无关。提示每加一类损伤就跑一次基线。三类一起开再去看结果等于把自己扔进黑匣子。4.4 物理层误码与链路闪断把故障做在更底层手册里「在以太网接口上加载物理层误码」和「模拟网络链路的闪断情况」这两条是很多纯软件损伤工具做不到的。物理层误码直接作用在比特流上表现形式是 CRC 错误、帧校验失败上层看到的可能是丢包也可能是乱序但根因在底层。配置时用误码率表示常见量级 10⁻⁹ 到 10⁻⁵10⁻⁵ 已经是相当恶劣的链路测设备容限时才用。链路闪断模拟的是端口 up/down 翻转参数一般包括闪断持续时间和闪断间隔。这个功能对验证路由收敛、链路备份切换、业务重连逻辑特别有用。配的时候注意两点闪断持续时间太短比如几十毫秒时部分设备的光模块可能根本来不及上报 down 状态等于白闪间隔太短则会让设备一直在收敛过程中永远测不到稳态。4.5 过滤规则智能与手工两种打流方式的选择手册功能清单第一条是「智能或手工方式过滤需要加载网络质量问题的目标流量」。这条决定了损伤的作用范围也决定了测试的可信度。智能过滤通常基于流特征自动识别目标流量比如按五元组、按协议、按 VLAN 打标。手工方式则是你自己写匹配规则精确到 IP、端口、DSCP 或 MAC。做多业务混合场景测试时我倾向手工规则把要劣化的那一股流单独框出来其余流量原样透传这样才能回答「视频劣化时数据业务是否受影响」这类问题。智能过滤省事但你得先确认它识别的流跟你理解的流是同一股否则损伤打在了错误的流量上结果全错。配置完过滤规则务必用抓包验证一次命中情况——手册提到的流量捕获功能正好派上用场抓一段下来在 Wireshark 里看被打标的流和预期是否一致。5. 避坑与排查五条把测试结果做废的踩坑记录这一章全是血泪经验每一条都对应一次测试数据作废。按现象、原因、解决的顺序写遇到相似症状可以直接对号入座。第一条千兆链路测出大量丢包丢包率高达 30% 以上但设备本身没有告警。现象接上千兆交换设备不做任何损伤配置纯透传就丢包。原因仪表默认工作在 100M 速率模式SETUP INTERFACE 没有改成 1G千兆流量灌进百兆管道超出部分被直接丢弃。解决进 SETUP INTERFACE 把接口速率改成与对端一致同时确认工作模式为 Throu Mode改完重新跑一次纯透传基线丢包归零再继续。第二条时延参数配了 200ms抓包实测只有 20ms 出头改了也不变。现象参数生效但不完全生效实测值远小于配置值或者大流量下时延分布明显发散。原因memory allocation 分配的内存不足以支撑「速率 × 时延」所需的缓存引擎在内部做了截断或提前出队。解决按链路速率估算缓存需求高速率大时延场景把内存重新分配后再加载损伤配完先小流量验证实测时延再逐步加压。第三条只在一个方向看到劣化反方向干干净净。现象视频单向卡顿复现成功但双向通话测试时只有一侧有问题。原因双向损伤需要分别加载只配了 A→BB→A 还是纯净链路。解决两条方向各配一份需要不对称就只改其中一侧的参数配完用双向同时打流验证别用单向结果推断双向表现。第四条丢包率设为 0丢包计数却在涨。现象丢包损伤关闭统计里仍有丢包。原因带宽控制把链路限到了实际流量以下超出令牌桶的包被丢弃或者乱序率过高接收端重排序窗口溢出后按丢包处理。解决先关掉带宽控制和乱序只留透传确认丢包归零再逐个打开每开一项跑一次定位到底是哪一项在制造丢包。第五条客户端连不上机框ping 通、防火墙已关还是连不上。现象物理链路正常网段也对软件就是停在 Start Up。原因多网卡机器上 ping 从错误的网卡发出比如办公网卡或者机框 LED 上显示的端口号与客户端里填的默认端口不一致。解决ping 时用-S指定源地址锁定测试网卡逐一核对屏上显示的 IP 与端口号客户端里对应填写多网卡环境临时禁用无关网卡是最快的排除法。6. 进阶闭环G.1050 模板、PDV 采集与抓包反算参数配完、损伤生效只完成了一半。真正让测试结论站得住的是闭环验证注入的损伤是不是你以为的那个损伤接收端测出来的数据能不能反算出你配置的参数。手册里有两个功能专门服务这件事——G.1050 网络质量模型模板和 PDV时延变化模型采集。6.1 G.1050 模板不是万能钥匙G.1050 模板的价值在于它给了一套「动态网络损伤环境」的预设组合时延、抖动、丢包不是固定值而是随时间变化的模型比手工配一组静态参数更接近真实广域网。用它的正确姿势是当基线不是当答案——先选模板跑一轮看趋势再把模板里的关键参数比如丢包率的波动范围、时延的均值与峰谷抄出来手工复现一遍做对照。两次结果如果差异很大说明模板里有你没理解的动态行为这时候别急着下结论先搞清楚差异来源。6.2 PDV 采集与抓包反算PDV 采集抓的是时延随时间的变化曲线配合流量捕获可以把「配置值」和「实测值」对上。常见做法是用仪表抓包导出再在外部算一遍包间隔变化。下面这段脚本读 tshark 导出的 CSV按包序号算相邻包的时延差也就是 IPDV 的简化版import csv # 输入为 tshark 导出的两列 CSVframe.number, frame.time_relative # 导出命令示例tshark -r cap.pcapng -T fields -e frame.number -e frame.time_relative -E separator, ts.csv rows [] with open(ts.csv, newline) as f: for r in csv.reader(f): if len(r) 2 or not r[1]: continue try: rows.append((int(r[0]), float(r[1]))) except ValueError: continue # 跳过表头或异常行 # 相邻包发送间隔与到达间隔之差取绝对值即为单包 IPDV ipdv [] for i in range(1, len(rows)): d_send 0.0 # 发送端等间隔假设实际可用发送侧抓包替换 d_recv rows[i][1] - rows[i - 1][1] ipdv.append(abs(d_recv - d_send)) if ipdv: ipdv_sorted sorted(ipdv) n len(ipdv_sorted) p95 ipdv_sorted[int(n * 0.95) - 1] * 1000 print(f样本数{n} 均值{sum(ipdv)/n*1000:.3f}ms P95{p95:.3f}ms 最大{max(ipdv)*1000:.3f}ms)这段代码的逻辑是先剔除 CSV 里的表头和空行把序号和时间戳转成数值然后逐对计算相对到达间隔d_send在接收侧单点抓包时无法获知简化为 0此时算出的其实是到达间隔的波动量用于看趋势足够做精确 IPDV 需要发送侧同步抓包。输出取均值、P95 和最大值三个统计量P95 比均值更能反映「少数包被拖慢」的程度而卡顿往往就藏在这 5% 里。参数上注意两点抓包点要放在被测设备的接收侧放在仪表出口侧只能验证注入值验证不了设备处理后还剩多少抓包缓冲要开够大流量长时长抓包时缓冲溢出会静默丢帧算出来的统计全是错的。验证项配置值实测参考指标偏差可接受范围固定时延200ms中位到达间隔±5%高斯抖动均值 10ms / 标准差 3msIPDV 均值与标准差±15%丢包率0.1%序号缺口比例数量级一致限速500Mbps稳态吞吐±3%从那以后我每次上机无论多急都强制走一遍「纯透传基线 → 单项损伤 → 抓包反算 → 再叠加下一项」的流程宁可多花二十分钟也不愿再对着一份不知道错在哪的数据写报告。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
