CR16006-F设备作为园区网接入认证路由器,承载下挂终端的IPOE WEB接入认证业务。
运维人员反应,网络中频繁有终端反馈无法完成IPOE web重定向,需要尝试多次才能完成重定向认证。
查看设备IPOE WEB认证业务板卡发现上送CPU处理的无感知重定向IP和https重定向报文持续处于较高数值。
======display hardware internal rxtx packet statistic slot 2 cpu 0======
Net port packet loss count:
code counter
Rx packets statistic:
counter success rate
NET ->RXTX : 93493 93493 3739 pps
Cpu code input list:(Mgment to L1 queue)
code counter success(whitelist/normal)
……
72 1 1(0/1)
76 186 186(0/186)
79 83 83(0/83)
106 7761 7761(0/7761)
150 20651 20651(0/20651)
152 2428 2428(0/2428)
158 34597 34597(0/34597)
176 516 516(514/2)
Cpu code input list:(L2 queue to platform)
code counter success drop rate
……
76 186 186 0 7
79 83 83 0 3
106 7761 7761 0 310
150 20652 20652 0 826
152 2428 2428 0 97
158 34598 34598 0 1383
79 RDT_CPU
158 HTTPS_DPORT443
设备业务板卡处理https重定向报文的能力有限,持续大量https报文上送时可能会出现部分https报文处理延迟或丢包,导致终端无法弹窗重定向。
检查现场IPOE前域用户数量发现,该园区网内持续有约2K用户在IPOE前域,所以会持续产生大量前域重定向报文,这与其它常见园区网络的实际情况有一些差异。
发现现场设备上还有一块支持IPOE WEB接入业务的板卡目前处于空载状态,可以将当前承载业务的RAGG成员接口从slot2槽位转移一部分到slot4槽位,使得每个槽位需要处理的https报文减少,弱化持续https报文上送的影响。
调整后,网内终端出现https弹窗重定向失败问题的频次大幅下降,很大程度上优化了用户体验。
但由于依旧存在大量前域用户持续产生的大量https、ip报文上送CPU处理,仍有出现少量用户重定向失败的可能性,解决此问题需要从终端角度筛查处理。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作