- 在线时间
- 426 小时
- 最后登录
- 2013-12-24
- 威望
- 8
- 金钱
- 3676
- 贡献
- 230
- 注册时间
- 2011-7-13
- 阅读权限
- 70
- 主题
- 85
- 帖子
- 507
- 分享
- 0
- 精华
- 0
- 积分
- 4429
- 相册
- 0
|
最近这边SGSN重启后,发现到华为的H局(HSTP2)的链路不正常,告警如下。
1958 ss7Mtpl3LkOutOfServ 2012-01-11 00:49:04 ss7M3 1.3 major equipment 59031958 Signaling link on EqPos 1.3, Trunk D and Timeslot 1 is out of service. Status is 35.
1959 ss7Mtpl3LkUnavlForUP 2012-01-11 00:49:04 ss7M3 1.3 major communications 59031959 Signaling link on EqPos 1.3, Trunk D and Timeslot 1 unavailable for User Part.
1960 ss7Mtpl3LkOutOfServ 2012-01-11 00:49:07 ss7M3 1.3 major equipment 59031960 Signaling link on EqPos 1.3, Trunk D and Timeslot 17 is out of service. Status is 35.
1961 ss7Mtpl3LkUnavlForUP 2012-01-11 00:49:07 ss7M3 1.3 major communications 59031961 Signaling link on EqPos 1.3, Trunk D and Timeslot 17 unavailable for User Part.
1962 ss7Mtpl3LkOutOfServ 2012-01-11 00:49:10 ss7M3 1.3 major equipment 59031962 Signaling link on EqPos 1.3, Trunk D and Timeslot 16 is out of service. Status is 35.
1963 ss7Mtpl3LkUnavlForUP 2012-01-11 00:49:10 ss7M3 1.3 major communications 59031963 Signaling link on EqPos 1.3, Trunk D and Timeslot 16 unavailable for User Part.
1964 ss7Mtpl3LkOutOfServ 2012-01-11 00:49:10 ss7M3 1.3 major equipment 59031964 Signaling link on EqPos 1.3, Trunk D and Timeslot 2 is out of service. Status is 35.
1965 ss7Mtpl3LkUnavlForUP 2012-01-11 00:49:10 ss7M3 1.3 major communications 59031965 Signaling link on EqPos 1.3, Trunk D and Timeslot 2 unavailable for User Part.
1967 ss7Mtpl3LkOutOfServ 2012-01-11 00:49:14 ss7M3 1.5 major equipment 59031967 Signaling link on EqPos 1.5, Trunk D and Timeslot 17 is out of service. Status is 35.
1968 ss7Mtpl3LkUnavlForUP 2012-01-11 00:49:14 ss7M3 1.5 major communications 59031968 Signaling link on EqPos 1.5, Trunk D and Timeslot 17 unavailable for User Part.
SS7状态如下:
SS7_MTPL3_LINK_NB Status
--------------------------------------------------------------------------------
net nid OPC lsid SLC eqp trk ts DPC Name SSN Status
--------------------------------------------------------------------------------
CORE 0 xxxx 10 0 1.3 B 1 xxxx HSTP1 0 In Service
CORE 0 xxxx 10 1 1.3 B 16 xxxx HSTP1 0 In Service
CORE 0 xxxx 10 2 1.5 B 1 xxxx HSTP1 0 In Service
CORE 0 xxxx 10 3 1.5 B 16 xxxx HSTP1 0 In Service
CORE 0 xxxx 10 4 1.3 B 2 xxxx HSTP1 0 In Service
CORE 0 xxxx 10 5 1.3 B 17 xxxx HSTP1 0 In Service
CORE 0 xxxx 10 6 1.5 B 2 xxxx HSTP1 0 In Service
CORE 0 xxxx 10 7 1.5 B 17 xxxx HSTP1 0 In Service
CORE 0 xxxx 20 0 1.3 D 1 xxxx HSTP2 0 In Service
CORE 0 xxxx 20 1 1.3 D 16 xxxx HSTP2 0 Aligning M3 links
CORE 0 xxxx 20 2 1.5 D 1 xxxx HSTP2 0 Aligning M3 links
CORE 0 xxxx 20 3 1.5 D 16 xxxx HSTP2 0 In Service
CORE 0 xxxx 20 4 1.3 D 2 xxxx HSTP2 0 Aligning M3 links
CORE 0 xxxx 20 5 1.3 D 17 xxxx HSTP2 0 Aligning M3 links
CORE 0 xxxx 20 6 1.5 D 2 xxxx HSTP2 0 Aligning M3 links
CORE 0 xxxx 20 7 1.5 D 17 xxxx HSTP2 0 Aligning M3 links
现网配置是分号段分别平均的发向HSTP1(ASB)和HSTP2(华为),到贝尔的HSTP1每次都正常,到华为的HSTP2每次都会有异常。其中SGSN2和3一般十分钟后正常,SGSN4(MKVI,容量较大)则可能要半小时到两小时。
目前华为的说法是重启后大量用户附着,Gr口信令负荷较高,爱立信的SGSN处理能力有限,部分流程未回应
我们这边觉得这种说法不对,因为到贝尔的HSTP1完全正常。而对于这个华为的说法是贝尔的HSTP1上做了流量控制的策略,超出的流量往HSTP2上送。不过我觉得这个解释还是不准确,即使HSTP1把部分流量往HSTP2上送,影响的是HSTP2本身处理的流量,而跟SGSN本身的处理能力无关,在SGSN上看到是到HSTP1的链路正常而到HSTP2不正常。我觉得结论应该是HSTP2处理能力有限或者是HSTP1的策略不当导致HSTP2超负荷。
现在还在扯皮中,客户决定明晚挂表测,因为我对SS7流程还不是很了解,所以在这里问一下:
1、大家觉得华为的解释是否恰当?
2、挂表看信令流程时应该看那些部分来确定建立连接的流程中是哪边没有回应或者回应不当(不正确/超时)
|
|