本帖最后由 qnchenying 于 2026-3-27 21:00 编辑
一、问题现象 PPPoE 接口进行高速流量打流时,运行几分钟后会自动断联、掉线,业务中断。 二、问题根因 PPPoE 的 LCP 协商报文不经过内核标准的 netfilter hook 点,iptables 无法识别、匹配该报文。在高速流压占带宽的情况下,LCP 保活报文无法及时发送 / 接收,最终因链路协商超时导致 PPPoE 自动断开。 三、解决方案
1.核心思路 不在内核 iptables 层处理,改为在 CFE 出口点挂载钩子,专门识别 PPP LCP 报文并提升其发送队列优先级,确保保活报文优先传输。 2.具体修改 2. 1新增 CFE 出口钩子在代码中注册一个 CFE 发送方向钩子,挂载在出口预处理点: - <font size="3">static struct hi_cfe_hook g_tx_pritag_hook = {
- .pos = HI_CFE_HOOK_EGR_PRE_LRN,
- .cb = hi_netif_add_ppplcp_pq,};</font>
复制代码 2.2新增 LCP 报文识别函数实现 hi_netif_add_ppplcp_pq 函数,对出方向报文进行解析,精准识别 PPP LCP 协议报文。 2.3提升 LCP 报文队列优先级识别到 LCP 报文后,强制配置高优先级队列: - <font size="3">skb->hi_ext_skbuff->qos.pq = 7; // 设置最高优先级队列
- skb->hi_ext_skbuff->qos.pq_en = 1; // 开启优先级生效</font>
复制代码 四、原理说明 1. 优先级 7 为系统最高队列,高速流不会抢占 LCP 报文带宽; 2. 保活报文优先发送、及时交互,PPPoE 链路不会因 LCP 超时断联。 五、验证方法 1. 编译并加载修改后的驱动 / 固件; 2. 在 PPPoE 接口上进行高速打流测试(持续 30 分钟以上); 3. 观察 PPPoE 链路状态,无断联、无掉线; 4. 查看 LCP 报文统计,收发正常、无超时。 六、总结 1. 问题:高速流 → LCP 保活报文被阻塞 → PPPoE 超时断联; 2. 原因:LCP 不走 iptables hook,无法做流量优先级保障; 3. 方案:CFE 出口挂载钩子 → 识别 LCP → 强制设为最高优先级; 4. 效果:高速流场景下 PPPoE 链路稳定不掉线。
|