在路由器、BRAS、家庭网关等具备WAN-LAN转发架构的网络设备测试中，“打流”远不止“插上网线、点开始”那么简单。WAN侧和LAN侧的协议栈差异、地址分配机制的不同、以及流量在穿越设备时的NAT/路由行为，决定了打流配置需要在协议层做精细设计。本文从拓扑模型出发，逐步深入到封装配置、流模板设计和双向流量验证，覆盖PPPoE和IPoE两种主流接入方式。

一、先理解拓扑：WAN-LAN打流到底在测什么

在配置任何参数之前，需要先明确测试仪两个端口在拓扑中扮演的角色。以路由器测试为例，测试仪的Port1连接路由器的WAN口，模拟运营商侧或上级网络设备；测试仪的Port2连接路由器的LAN口，模拟局域网内的终端设备。流量上行方向为LAN→WAN（终端向公网发起请求），下行方向为WAN→LAN（公网向终端返回数据）。

这个拓扑看似简单，但WAN口和LAN口在协议栈上的行为完全不同。LAN口通常是无状态的二层桥接或三层路由接口，IP地址分配以静态配置为主；WAN口则需要完成PPPoE拨号、DHCP获取地址或静态路由配置，涉及PPP、DHCP、ARP等有状态协议的交互。测试仪必须能够模拟这些协议的对端行为，才能让流量真正“穿透”被测设备。

如果被测设备是ONU或家庭网关，WAN侧可能涉及VLAN标签处理。例如在PON组网中，ONU的WAN连接需要建立一条VLAN ID为203的通道，测试仪接OLT上联口的端口需要配置同VLAN的IP地址，而接ONU LAN口的端口则配置与LAN侧同网段的IP。VLAN ID配错是打流不通特别常见的原因之一。

二、WAN口配置的核心差异：PPPoE vs IPoE

WAN口的配置深度取决于接入方式。PPPoE和IPoE在封装结构和状态机行为上有本质区别，配置逻辑也完全不同。

PPPoE场景下的WAN口配置。 测试仪需要模拟PPPoE Client（即路由器WAN口的上游Server）或者被配置为PPPoE Server（即路由器WAN口本身充当Client时，测试仪扮演运营商侧Server）。在信而泰BigTao220的实操中，当测试仪模拟PPPoE Server时，需要配置认证方式（通常为CHAP MD5）、用户名密码和地址池，然后启动协议仿真等待路由器WAN口完成拨号。协议协商成功后，测试仪会获取到Session ID、对端MAC地址和分配的IPv4地址，这些参数是后续构造数据流的依据。

这里有一个容易被忽略的细节：PPPoE打流时，WAN侧的数据流封装需要包含完整的PPPoE头部和PPP头部。从LAN口向WAN口发送的流量，在到达路由器WAN口后需要被重新封装为PPPoE帧；而测试仪从WAN口侧接收到的下行流量，其原始封装就是PPP over Ethernet。测试仪在构造WAN→LAN方向的Raw Stream时，帧结构应为：Ethernet II头部 + PPPoE头部 + PPP头部 + IPv4头部 + UDP/TCP头部 + 载荷。如果漏掉了PPP头部中的协议标识字段（通常为0x0021表示IPv4），路由器将无法正确解封装。

IPoE场景下的WAN口配置。 IPoE不需要PPP协商，测试仪WAN口只需通过DHCP获取IP地址或配置静态IP即可。配置流程相对直接：设置WAN口的IP地址、子网掩码和网关（网关地址通常指向测试仪WAN口自身的IP，如果测试仪模拟的是上游网关的话），然后为LAN口配置一个与被测设备LAN侧同网段的IP。IPoE场景下，WAN口的流量封装更简单，直接是以太网帧承载IPv4/IPv6报文，不需要额外的PPP头部。

选择哪种方式取决于被测设备的WAN接入配置。如果路由器WAN口设置为“宽带拨号上网”，测试仪必须模拟PPPoE Server；如果设置为“自动获取IP”或“静态IP”，则使用IPoE模式。

三、LAN口配置与流模板设计

LAN口的配置相对简洁，但流模板的设计直接决定测试的有效性。在Spirent TestCenter中，创建流量的方式有两种：Bound Stream和Raw Stream。

Bound Stream基于“对象”建流，流量的源和目的节点绑定到测试仪端口上已创建的Endpoint对象（如Device、路由协议发布的Route、DHCP分配的地址等）。这种方式的优势是测试仪会自动处理ARP解析、MAC地址学习等底层细节，适合在已有协议仿真基础上快速生成流量。Raw Stream则完全手动构造每一层协议头部，从Ethernet II开始逐层定义源/目的MAC、IP地址、端口号和载荷内容。Raw Stream的控制粒度更细，适合需要精确控制每一层封装字段的场景。

在WAN-LAN打流中，推荐的策略是：LAN→WAN方向使用Bound Stream（因为LAN侧通常有明确的IP地址和网关），WAN→LAN方向使用Raw Stream（因为WAN侧的封装可能涉及PPPoE或VLAN标签，需要手动构造）。

流模板中的Modifier是提升测试覆盖度的关键工具。Modifier允许对流中指定字段进行自动递增、递减或随机变化。例如，在模拟多个终端并发访问的场景中，可以为源IP地址添加INCR类型的Modifier，让每个数据包的源IP按步长变化，从而生成大量“不同用户”的流量。在NAT场景下，WAN→LAN方向的流需要将目的IP设置为WAN口的公网IP，并使用Modifier动态修改目的端口号，以匹配NAT会话表。如果WAN连接启用了NAT，流量配置中必须添加IPv4 Modifier来修改目的地址，否则下行流量会因为NAT映射缺失而被丢弃。

四、双向打流与RFC2544的非对称问题

WAN-LAN打流通常需要双向同时进行。测试仪Port2（LAN侧）向Port1（WAN侧）发送上行流量，同时Port1向Port2发送下行流量，两个方向的流量同时施加，才能真实反映设备的双向转发能力。

但在RFC2544框架下，双向打流会遇到一个结构性限制。RFC2544要求所有测试端口的速率必须相同，如果WAN口和LAN口的物理速率不同（例如WAN口为100M、LAN口为1000M），双向吞吐量测试的结果不会超过特别小端口速率的值。更关键的是，RFC2544的二分法算法在双向同时测试时，只要有一个方向出现丢包，就会降低速率继续查找，特别终双向的测试结果会被“拉平”到同一个数值，无法反映两个方向各自的实际性能。

对于WAN-LAN速率不对称的设备（这在家庭网关和中小企业路由器中非常普遍），更合理的做法是分别测试上行和下行方向的单向吞吐量，而不是依赖RFC2544的双向测试模式。可以先暂停一个方向的流量，测出另一个方向的单向特别大吞吐量，然后交换方向再测。如果确实需要双向性能数据，可以使用非对称测试模式，分别设置每个方向的发送速率，观察在给定速率组合下的丢包情况。

五、实战中容易踩的坑

WAN-LAN打流配置中特别常见的故障不是参数配错，而是流量收不到。TestCenter发出流的每个数据包都含有一个20字节的特别技术签名字段，测试仪依靠这个字段来识别和统计接收到的数据包。当帧长设置过小（例如小于64字节的载荷被截断）或过大（超过端口MTU导致分片）时，这个签名字段可能被破坏，测试仪会判断为“没有收到数据包”，表现为大量丢包。排查时可以先检查帧长是否在合法范围内，再检查端口MTU配置是否与对端一致。

另一个高频问题是VLAN标签不匹配。如果被测设备在WAN侧或LAN侧使用了VLAN，测试仪端口上必须配置对应的VLAN ID和优先级。Spirent TestCenter中VLAN的配置位置在端口的L2/L3协议编辑界面，可以同时配置单层VLAN和QinQ双层标签。如果流量在测试仪侧不带标签发出，但被测设备端口配置为Access模式并期望接收带标签的帧，流量会在入口被直接丢弃。

WAN-LAN打流配置的核心逻辑可以概括为：先让WAN口的协议仿真“跑起来”（PPPoE协商成功或DHCP获取到地址），再用LAN口的地址和路由信息构造绑定流，特别后在WAN侧用Raw Stream补全封装细节。把这三步分开验证，比一次性配完再排查效率高得多。

武汉康芯源技术有限公司

服务热线：17092617859（罗经理）

邮箱：sales@consenstar.com

官网：www.consenstartech.com

地址：湖北省武汉市东湖新技术开发区长城园路精工科技园A603号