NE40E IP-TRUNK配置为逐流负载分担方式导致GPRS业务拥塞

发布时间:  2012-12-14 浏览次数:  97 下载次数:  0
问题描述
 

版本:NE40E V300R003C02B697

组网概述:

Internet--SW1--FW1--NE40E-A1--7×STM1(IP-TRUNK)--NE80E-B1---NE40E-B1--FW2--GGSN

                                                                                |

                                                                              SCG

故障现象:客户投诉GPRS上网业务缓慢,打开网页慢。

处理过程
 

1、GGSN上网业务需要通过SCG中转才到Internet,从GGSN上ping SCG相关IP,出现延迟和丢包。
2、从GGSN上ping NE40E-A1,没有延迟和丢包;初步怀疑问题在NE40E-A1和SCG之间。
3、SCG通过相关交换机连到NE40E-A1,登录查看相关交换机,从交换机ping NE40E-A1,没有延迟和丢包;从交换机ping SCG也正常。
4、从SCG ping NE40E-A1,亦正常。
5、在NE40E-A1、NE80E-B1和NE40E-B1上针对GGSN和SCG的IP分别进行流统,最终发现丢包发生在NE80E-B1和NE40E-A1之间。
6、在NE80E-B1和NE40E-A1上使用命令display interface brief查看流量占有率,发现从NE40E-A1到NE80E-B1方向上的IP-TRUNK的7个成员之一端口流量达到97%,已经符合流量拥塞情况,但其他6个成员端口流量只有40%~50%。
7、怀疑是流量HASH问题,咨询GGSN工程师其GPRS流量模型,得知GGSN和SCG间建立了一个GRE Tunnel,所有GPRS流量承载在此GRE Tunnel上,而其流量由于最近频繁扩容,已超出155M(STM-1)。
8、查看NE40ENE80E IP-TRUNK端口配置,默认为逐流HASH,问题明了,GPRS流量附着在此GRE Tunnel上,从NE40ENE80E看,只有一对Tunnel源和目的IP,所以NE40E把此流量HASH到了一个成员端口上了,导致了此流量拥塞。

根因

流量模型导致hash不开

解决方案
 

在NE40E上IP-TRUNK端口下通过命令 load-balance packet-all修改NE40E为逐包负载分担方式后,GPRS流量分担到其他成员端口,GPRS流量拥塞消除,业务恢复正常

建议与总结
注意查看流量模型

END