上一篇记了买下 WE-101-N4G 之后的测试安排。这篇接着聊怎么用。我觉得最应该先弄明白的不是把丢包率调到多少而是让哪些报文进入弱网。只测会议媒体、测整台终端、把登录和媒体一起测是三种不同的用法。网准通NetAccura混沌之桥 ChaosBridge WE-101 的过滤器、双向虚拟链路和抓包分析正好可以把这些事拆开处理。我们的对象还是用于卫星通信的视频会议软件。下面按 WE-101 的 DPDK 软件功能记设置方法地址、端口和时延是为了说明配置关系不是某次通话的成绩。先弄清楚测的是整台终端还是其中一项业务“给视频会议加弱网”实际配置时还得多问一句从登录开始所有网络访问都要变差还是已经进入会议以后只改变媒体传输的条件如果目标是模拟一台卫星终端的整个接入环境那登录、鉴权、域名解析、音视频、心跳和重连都应该处在相应网络条件下。只要终端其他出口没有绕过设备把这条接入路径的两个方向都送入损伤链路就比较接近这个目的。如果目标是看媒体拥塞控制例如上传受限以后视频是否降码率、声音是否还能维持事情就不一样了。登录接口先超时会议都没建立起来反而看不到媒体阶段的问题。此时可以先把目标媒体流送进弱网其他报文旁通等媒体专项做清楚再补完整接入环境的测试。这不是把测试条件放宽而是分清本轮在测什么。我会把用例直接写成“终端全部流量”“已确认的会议媒体流”“会议建立流程”这类名字不统一叫“卫星弱网”。以后看到结果至少知道受影响的范围。WE-101-N4G 有四个千兆业务口可以组成两对双向链路。上一篇安排两对分别接会议两端这里先看其中一对。管理电脑仍走独立管理口不把设备管理界面也放进正在折腾的业务路径。虚拟链路配了参数流量还得有规则带进去WE-101 里虚拟链路和过滤器是两件事。前者保存延迟、丢包、限速等条件后者决定哪些报文使用这些条件。建好一条链路再填上延迟并不意味着经过设备的所有报文自动受损伤。当前 DPDK 的处理方式是按报文进入的物理端口查规则优先级数字越小越先检查命中第一条就执行动作。没有命中任何启用规则的流量默认旁通。刚搭环境时我会先用最简单的配置把这层关系核对清楚建一条有明确名字的虚拟链路在端口对两侧各建一条“全流量”规则动作都指向它。暂时不加随机丢包只用固定时延检查方向确认流量确实经过目标链路再把规则收窄到业务。“全流量”要选对应类型不是随便选个 TCP 或 IPv4再把输入框全部留空。后两种仍然带着协议或地址类型的含义换个人接手很容易误读。这里也要看仿真开关。Bypass 状态下流量直接旁通切到 Emulation并在损伤页面点击“应用”才进入本轮需要的仿真配置。规则启用、链路选对、仿真打开是三个不同的检查点。只测会议业务时先写清楚上下行分别匹配什么拿一组便于说明的地址来说终端是192.0.2.10媒体服务器是198.51.100.20已经确认服务器这一项业务使用 UDP/5004。假设终端接端口对的 A 侧服务器方向接 B 侧而且设备在这里看到的就是这组地址没有发生地址转换。这时两侧规则可以这样写规则建在哪里匹配条件送到哪里A 侧入口源IP为终端目标IP为服务器UDP目标端口5004会议链路 A→BB 侧入口源IP为服务器目标IP为终端UDP源端口5004同一会议链路 B→A注意第二行是“源端口5004”不是把第一行原样复制过去。上传报文的服务端端口在目的端返回报文的服务端端口在源端。终端临时端口如果会变化规则里就不要无依据地固定它。同时限制 IP、协议和端口时用“高级”过滤器比较直接。单独的 IPv4 类型没有端口输入框UDP 类型适合只按 UDP 端口分流。选对表单比先填一堆字段再猜它们有没有生效省事。图1产品使用手册中的高级过滤器界面。图内是手册示例值不是上表的会议配置不同字段同时填写时要同时满足。字段也不是越多越好。源IP、目标IP、端口、MAC、VLAN 都填上得到的是这些条件的交集不是任选一个命中就算。实际报文没带 VLAN却额外填了 VLAN ID规则自然匹配不上。5004 只是这里的示例不能当成所有视频会议软件的固定端口。真正使用时要先看当前会话的抓包。软件可能换媒体节点、走中继或者改变传输协议多个业务也可能共用同一连接。按一个端口筛出来的流量不能未经确认就叫“全部音视频”。如果想覆盖两台不同服务器可以各建一条指向同一链路的规则。不要试图把“服务器一或服务器二”塞进两个本来表示不同含义的字段。IPv6 流量也需要相应规则IPv4 条件不会自动覆盖它。精确规则要放在全流量规则前面规则顺序是一个很容易忽略的地方。假设第一条已经是“全流量→会议链路”后面再加一条“指定管理连接→旁通”后者就没有机会执行。报文在第一条已经被接走了。只让指定业务受损伤时我会把需要单独处理的精确规则放前面最后才放兜底规则。比如先保护经过业务口的那条管理连接再把已确认的媒体流送到会议链路其余流量旁通。这里保护的是确实穿过业务口的连接独立带外管理口不用这样绕一圈。图2同一入口端口按顺序检查规则第一条命中后就停止。另一侧入口有自己的规则列表也要单独核对。“其余旁通”可以依靠未匹配默认旁通也可以显式建一条最后的全流量旁通规则。调试环境里我更喜欢把这个选择写在规则列表里别人打开页面就能看懂本轮到底覆盖哪些流量。以后要改成整个接入环境都受损伤再把兜底动作改为对应链路并重新考虑之前保留的例外。否则媒体流测得很仔细登录和重连却一直走旁通最后得出的结论就不完整。规则调整后同一端口的优先级会重新连续编号。所以记录时不能只写“用了第3条”还要保留名称、条件、动作和当时的顺序。不想手抄五元组可以从抓包生成过滤器草稿这是我觉得值得单独记下来的功能。知道会议正在发流量却不确定该填哪组 IP、哪边是服务端端口时可以先在 Port RX 抓包再从真实报文往回建规则。这里优先抓入口而不是一开始就只抓虚拟链路内部。如果业务根本没有被规则送进去链路抓点可能看不到它入口抓包才能先回答“设备实际收到了什么”。在 Captures 里建立任务选相关入口的 Port RX采集包含目标业务的短片段。打开分析页后找到相应方向的报文查看 Packet Decode 中的协议字段再检查过滤器草稿候选。需要按帧内特定字节筛选时Hex Dump 也支持选择字节范围作为草稿依据。当前软件提供的不只是把字段复制到输入框。草稿会结合报文上下文建议入口、条件和优先级保存前还会读取现有规则检查重复或重叠。有启用的无条件兜底规则时建议位置会放在它前面避免新规则刚建出来就被挡住。草稿创建后仍是未启用状态。这个细节很实用分析报文和改变正在运行的流量是两回事。先检查目标虚拟链路、入口方向、匹配范围再决定启用不会因为在分析窗口点了一次创建就立刻改变测试条件。图3抓包生成的是待检查的规则草稿不是自动识别后直接施加损伤。创建草稿和启用规则分开进行。草稿的“命中范围”也要看统计对象。当前实现区分已加载报文的完整评估、抽样评估和只确认选中报文这几种情况。需要深入解析时默认从已加载列表中最多选取50个报文作确定性抽样并包含当前选中的报文。这50个不是设备只能抓50包更不是从整场会议里挑出50个“最典型”的包。它是这个预览步骤控制解析量的办法。若页面只加载了会议建立阶段就不能拿这里的覆盖比例代表后面十分钟的媒体流量。另外临时端口、IP分配、媒体服务器切换之后上一轮的精确五元组不一定继续适用。自动生成的规则省的是抄写和组合字段的工夫不会替人决定哪些字段应该固定、哪些应该放宽。配了弱网却看不出变化我会按这个顺序查第一眼先看入口端口 RX。如果这里没有目标流量就先查接线、路由、终端出口别急着把丢包率从1%改成10%。尤其终端还有 Wi-Fi 或其他网卡时业务不一定走自己以为的那条路径。端口 RX 有流量再看目标虚拟链路对应方向的 RX。前者增加、后者不动优先查规则所在端口、启用状态、条件、处理动作以及前面是否有更宽的规则抢先匹配。不是先怀疑“延迟设置太小”。链路 RX 已经增加再看仿真模式和应用状态并对照链路出口、物理端口 TX 和抓包。这里看的是目标业务不是端口上所有流量的总和其他旁通业务还在传输端口总速率当然不一定等于这条会议链路的限速值。还得选对探测方式。只配置 UDP 媒体规则却用普通 ping 去验证ICMP 可能走的是旁通RTT 没变化并不能证明规则无效。要么观察已经命中的 UDP 流要么为这次方向核对单独安排 ICMP 或全流量规则做完再恢复。比如去程固定增加80ms、回程增加120ms在探测报文确实命中这两侧规则、没有额外排队等变化的前提下RTT 的配置增量应约为200ms。它是两个方向相加不是看到80ms就要求往返也只增加80ms。抓包里有 Port RX、Port TX以及虚拟链路损伤前、损伤后几个位置。同一个包可以在不同位置留下多条记录核对数量时要分抓点不能把所有记录相加当成业务发送包数。当前 Web 页面也不提供单条过滤器的独立命中计数。目标链路 RX 能帮助判断流量是否进来若多条规则都指向同一链路仅凭这个总数还不能说明究竟是哪条命中了需要结合报文字段继续核对。域名过滤和 App ID留到基础规则清楚之后再用如果服务端 IP 经常变化域名过滤值得考虑。但“DNS过滤器”和“域名过滤器”不是一个功能。前者处理 DNS 报文本身例如给解析请求加延迟后者利用可见域名、SNI 或 DNS 关联等信息识别业务流。只损伤 DNS不等于后面的媒体和 HTTPS 连接也进入了弱网。反过来域名规则利用 DNS 信息建立关联也不代表它会把 DNS 报文本身送进去。App ID 则需要目标应用的签名库和可用识别证据。自研会议软件不能因为属于“视频会议”就默认能按一个通用名称完整识别。没有合适签名时先用已确认的终端、地址、端口、VLAN 等条件更容易解释结果。对卫星会议的分阶段测试我会先保证能准确控制一条已知业务再逐步加入更多连接。要测整个卫星接入环境则回到整条接入路径的覆盖问题不能把精确筛选媒体的用例冒充完整网络环境。这也是我看重 WE-101 这套软件功能的原因可以从整条接入链路开始再收窄到一组业务发现条件不对又能回到抓包里核对不需要把每轮测试都做成同一种粗放的全流量损伤。测完恢复网络不一定要点 Reset临时取消这轮损伤时可以把当前测试对象切回 Bypass。它不删除已有规则和链路切回 Emulation 后配置会恢复生效。第二天继续测试前要先看当前选中了哪个引擎和端口对再看它处在哪个状态。Reset 不是同一件事。它会删除当前端口对的虚拟链路、过滤器和 QoS 通道不适合当作日常的“暂停”按钮。要保留的配置先导出再决定是否清理。有抓包结果需要留存时也先下载到电脑再删除任务。按当前使用手册删除抓包任务还会删除该任务已经保存到设备磁盘的文件和下载缓存不能以为按过一次“保存”就永远还在。顺带说一句按业务分类不是网准通才有。Apposite Netropy 的公开资料同样列了 IP、VLAN、TCP/UDP 端口等分流条件以及延迟、丢包、队列和 REST 自动化。拿四口配置对照Netropy 10G2 是四个1/10G SFP口、两个引擎WE-101-N4G 是四个千兆电口、两对双向链路。Netropy公开按每端口对最多30条WAN链路介绍网准通资料列系统全局最多4096条虚拟链路统计范围不同不能直接相除当性能倍数。Netropy具体芯片路线在这里不作推定本文操作针对网准通的DPDK功能。已经选了 WE-101后面更值得花时间的是把这套用法固定下来先确定测试范围让正确的流量进入正确的方向再用抓包生成和检查规则最后拿对应的统计、报文和应用表现一起判断。网络损伤仪的价值不只是能把网络调差还在于能说清楚这一次究竟把哪部分网络调差了。