4G优化案例：定位并解决4G融合防火墙备内部均衡问题，提升移动用户感知.docxVIP

定位并解决4G融合防火墙备内部均衡问题，提升移动用户感知 XX XX年XX月 目 录 TOC \o 1-2 \h \z \u 一、 问题描述 3 二、 分析过程 3 三、 解决措施 4 四、 经验总结 5  定位并解决4G融合防火墙备内部均衡问题，提升移动用户感知 XX 【摘要】通过小时颗粒度分析了核心网感知时延，挖掘设备隐患，发现部分UGW在不存在能力瓶颈的情况下，存在忙时时延较高问题。通过分析设备日志、采集流量比对，定位是默认hash算法引起流量不均导致。通过修改hash算法，实现背板流量均衡。 【关键字】4G、感知时延、NAT、hash 【业务类别】核心网、参数优化 问题描述 通过小时颗粒度分析核心网感知时延，挖掘设备隐患，发现在同一机房出口的UGW4忙时时延增长89%，UGW5增长39%。UGW5闲时时延较高，由于当时防火墙横穿链路拥塞导致，后续马场新上防火墙优化解决。但UGW4从KPI看不存在能力瓶颈，需要重点排查UGW4忙时时延较高的问题。这两台UGW机房、机构一致，KPI性能正常，但分别使用不同厂家的融合防火墙进行NAT，初步怀疑UGW4对应的防火墙存在问题。对应的FW4的KPI性能正常，需要深入协同厂家分析。 分析过程 FW4设备检测日志 深入诊断并分析设备诊断日志，发现业务忙时，存在部分内部接口超带宽告警。 联系设备厂家研发分析 根据采集信息分析，发现背板4*10G接口流量分担不均。（背板接口流量主要为从该板卡物理接口上来的流量及从该板卡物理接口出去的流量） 检查接口分流算法，该接口分担方式为按源IP hash： 问题原因 新版本内部默认算是按源IP hash，而该网络中大部分为下行流量，大流量IP集中，如游戏、视频等服务器IP，导致hash后分担不均。 而老版本默认算法为按源目IP hash，分担相当较均。 解决措施 修改防火墙内部分担算法，按自定义（五元组）hash后恢复。 hig-trunk?set?slot?4?group?0?load-sharing?custom? hig-trunk?set?slot?5?group?0?load-sharing?custom? hig-trunk?set?slot?8?group?0?load-sharing?custom? hig-trunk?set?slot?9?group?0?load-sharing?custom? hig-trunk?set?slot?44?group?0?load-sharing?custom? hig-trunk?set?slot?45?group?0?load-sharing?custom? hig-trunk?set?slot?48?group?0?load-sharing?custom hig-trunk?set?slot?49?group?0?load-sharing?custom? 经验总结 单纯通过KPI无法发现该网络隐患，KPI均正常，用户能成功访问业务。 结合业务感知DPI的时延，选取核心网往上的HTTP GET时延作为绝对分析指标，可以屏蔽核心网网元SGW往下的无线基站、IPRAN的影响，能更聚焦问题。 核心网覆盖广，如果单纯全天平均时延容易遗漏细节。本次通过小时颗粒度，发现闲忙时设备符合的差异。 核心网网元、防火墙网元量日益增加，不同的厂家内部算法各异。本案例的算法固化到业务感知系统上，更好地对比和发现现网设备是否存在影响业务感知的薄弱点。