本文档介绍在Cisco 5000系列聚合服务路由器(ASR)的服务通用分组无线业务(GPRS)支持节点(SGSN)上遇到的问题。 此外,还描述了解决此问题的一些可能的解决方法。
本文档介绍ASR SGSN上的此特定事件链:
当HLR收到MAP_RESET消息时,它会为GPRS位置更新(GLU)设置标志。 当用户设备(UE)发送其第一个上行链路数据包时,SGSN向HLR发送GLU消息。
At 7 AM SGSN , Nov 21st 2014 had
******** show subscriber summary *******
Total Subscribers: 2386266
Active: 2386266
sgsn-pdp-type-ipv4: 942114
如示例输出所示,SGSN上存在950,000个封隔器数据协议(PDP)环境,UE会尝试在日后浏览这些环境。
收到第一个上行链路数据包时,SGSN会触发GLU消息。由于有数十万个UE,STP无法处理生成的流量,因此会进入常年拥塞状态。
消息在SGSN中排队,并且出现最大重传超时。由于所有GLU消息不会从SGSN传递到HLR,因此SGSN被迫断开移动用户并请求重新连接。然后,所有分离的用户都尝试连接,这会导致入站连接请求数突然激增。由于应用了网络过载保护,大多数连接尝试都因拥塞而被拒绝,移动用户被迫进行新尝试。
随着这一连串事件的展开,它产生了连锁效应。许多发送身份验证信息(SAI)消息、GLU消息和MAP-IMEI_CHECK消息滞留在SGSN队列中或被丢弃。因此,所有STP-1和STP-2链路都进入拥塞状态。每个STP有四条信令链路,但在本场景中,STP-2的前三条链路恢复时间不长。
以下是拥塞警报,您可以在其中看到所有STP链路在STP-2上进入拥塞状态:
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-1 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-2 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-3 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:29 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:18:48 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:20:00 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:22:52 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:22:55 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:23:22 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:26:33 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:28:06 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:28:45 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 09:27:27 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
如图所示,仅清除了对等服务器进程(PSP)4,其余仍处于拥塞状态:
Fri Nov 21 08:18:47 2014 Internal trap notification 1075 (M3UAPSPCongestionCleared)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congestion cleared congLevel-0
本节介绍如何对上一节所述的问题进行故障排除。
如上节所述,STP中的一条特定链路接收大量流量。您可以看到STP-2中的前三条链路进入拥塞状态,且永远不会恢复,因此,只有一条链路可用,并且SLC-3(或peer-server-2-peer-server-process-4)上的拥塞警报会被清除。
根据SGSN负载共享机制,它必须在所有四条链路上均等地发送消息传输部分(MTP)第3级(MTP3)用户适配层(M3UA)数据包。但是,从简单网络消息协议(SNMP)陷阱中,前三个STP-2链路常年拥塞,这意味着所有流量都路由到SLC-3链路(唯一可用的STP链路来路由流量)。 这解释了为什么STP-2链路之间的流量分布是扭曲的。
在拥塞情况下,一个或多个链路在拥塞和非拥塞状态之间切换,因此只有可用链路共享流量。因此,其中一条链路的利用率更高。这需要重置链路以恢复链路。
下一个输出显示M3UA级别统计信息和分离统计信息。需要考虑的重要统计信息是STP-2 PSP实例4,其中可以看到异常流量:
Time #1:ss7rd-m3ua-psp-data-tx #2:ss7rd-m3ua-psp-error-tx #3:ss7rd-m3ua-psp-data-rx
21-11-14 7:30 37409 0 37942
21-11-14 8:00 43677 0 43866
21-11-14 8:30 190414 0 71844
21-11-14 9:00 547418 0 104135
21-11-14 9:30 536019 0 102477
21-11-14 10:00 376797 0 132227
21-11-14 10:30 100394 0 97302
21-11-14 11:00 119652 0 114809
21-11-14 11:30 107073 0 95354
以下是STP数据:
DATE TIME LSN LOC SLC LINK TX % RX %
11/21/2014 9:00 sgsncisco 5216 3 A IPVL 11.26 62.07
11/21/2014 9:00 sgsncisco 5213 0 A1 IPVL 11.29 4.86
11/21/2014 9:00 sgsncisco 5214 1 A1 IPVL 11.27 4.85
11/21/2014 9:00 sgsncisco 5215 2 A IPVL 11.23 4.7
此输出显示出问题时每秒的解除次数:
Time #13:2G-ms-init-detach #14:2G-nw-init-detach
21-11-14 6:30 136465 7400
21-11-14 7:00 149241 9557
21-11-14 7:30 165788 12630
21-11-14 8:00 179311 16963
21-11-14 8:30 125564 44759
21-11-14 9:00 112461 95299
21-11-14 9:30 240341 112461
21-11-14 10:00 288014 116298
21-11-14 10:30 203261 123300
21-11-14 11:00 67788 122945
此输出显示每秒的连接数(根据WEM):
Time #3:2G-total-attach-req-all Request/Second
21-11-14 8:00 738279 205.078
21-11-14 9:00 14053511 3903.753
21-11-14 10:00 24395071 6776.409
21-11-14 11:00 24663454 6850.959
21-11-14 12:00 17360687 4822.413
每个新呼叫IMSI/数据包临时移动用户身份(P-TMSI)连接和路由区域更新(RAU)请求必须由IMSIMGR处理。
根据保守的观察,系统每秒接收6,850个2-G连接请求的峰值,每秒接收约5,313个3-G连接请求。您可以为网络过载保护设置的最大值是每秒5,000个连接请求。为了使IMSIMGR保持可操作状态,系统无法处理来自UE的如此大量的呼叫。
当队列大小达到每秒1,500个附加请求时,此问题在上午8点后开始:
network-overload-protection sgsn-new-connections-per-second 500 action
reject-with-cause congestion queue-size 1500 wait-time 5
由于每秒大约有12,000个连接请求,因此IMSIMGR处理并拒绝了近9,000个呼叫。这会导致IMSIMGR CPU处理达到高状态。
如果SGSN在一秒内收到的连接请求数超过配置数量,则请求会缓冲到步调队列,并且仅在缓冲区因高入站连接率而溢出时才会丢弃。队列中的消息根据先进先出(FIFO)过程进行处理,直到排队的消息生存期超过所配置的等待时间时其过期。
当您根据您的偏好选择拒绝或丢弃选项时,思科建议您使用拒绝原因代码来指示网络拥塞,这样您就可以在尝试上行链路过程之前了解网络状况。
根据第3代合作伙伴项目(3GPP)技术规范(TS)23.060,本节介绍HLR重启期间的SGSN行为。每当SGSN收到MAP重置时,它都会向HLR发送UL请求,供其用户使用。
当HLR重新启动时,它会向其一个或多个移动站(MS)注册到的每个SGSN发送重置消息。如果存在SGSN到移动交换中心(MSC)/访问位置寄存器(VLR)关联,这会导致SGSN将相关移动管理情景标记为无效。在收到第一个有效逻辑链路控制(LLC)帧(用于A/Gb模式)或从标记的移动站收到第一个有效GPRS隧道协议用户(GPT-U)数据包或上行链路信令消息(用于Iu模式)后,SGSN执行UL到HLR,如连接请求或SGSN间请求中所述路由区域(RA)更新过程。此外,如果设置了非GPRS警报标志(NGAF),则遵循非GPRS警报子句中的步骤。SGSN可延迟UL过程和向MSC/VLR的过程以实现最大操作员配置,这取决于当时资源的使用,以避免高信令负载。
思科建议您完成以下步骤以解决此问题:
理想情况下,每个STP有四条链路,因此每条STP链路可处理125个连接请求。这在所有STP链路上均等分布。但是,如果其中一条链路断开,则会看到许多重新连接尝试,队列将变满,并会发生数据包丢弃。如果更多链路断开,则流量分配不均。
UE流量不遵循线性方式。它通常发生在突发中,并且多次尝试重新连接。SGSN以捆绑形式将流量发送到STP。当时,流量超过STP上配置的TPS。这会导致STP中的某些链路开始通告窗口大小较低(如果它们已处理更多呼叫),并且SGSN开始对排队的SCTP数据块排队。然后,它会等待RTO MAX计时器过期。
如果STP定期发送一个良好的通告窗口大小,则如果SCTP_RTO_MAX值缩小到五秒或更短,您应该能够发送更多SCTP数据块。队列清除速度更快,且不会触发M3UA拥塞警报。此外,您不应看到SCTP触发的内部流控制标志以控制数据包流。
SGSN仅发送STP可以接受的数据包量,这取决于通告的窗口大小。如果增加每个STP链路的TPS,则有助于避免STP拥塞并减少SCTP_RTO_MAX计时器。
如果流控制传输协议(SCTP)选择性确认(SACK)消息中通告的窗口大小接近零(或零),则SGSN会发出M3UA警报,以指示不应为该对等终端发送消息。这会导致链路抖动或进入拥塞状态。由于SGSN发送的窗口大小更高,因此您会继续从对等节点接收M3UA数据,如果对等点代码从未出现拥塞状态,这些数据包可能会被丢弃到等待队列中。
示例如下:
SCTP消息仅排入流量控制标志变为True的关联的队列,然后SGSN根据STP响应进行处理:
*Peer Server Id : 2 Peer Server Process Id: 2
Association State : ESTABLISHED
Flow Control Flag : TRUE
Peer INIT Tag : 20229
SGSN INIT Tag : 3315914061
Next TSN to Assign to
Outgoing Data Chunk : 3418060778
Lowest cumulative TSN acknowledged : 3418060634
Cumulative Peer TSN arrived from peer : 103253660
Last Peer TSN sent in the SACK : 103253658
Self RWND : 1048576
Advertised RWND in received SACK : 8
Peer RWND(estimated) : 8
Retransmission counter : 0
Zero Window Probing Flag : FALSE
Last Tsn received during ZWnd Probing : 0
Bytes outstanding on all
addresses of this association : 19480
Congestion Queue Length : 143
Ordered TSN assignment Waiting QLen : 8050
Unordered TSN assignment Waiting QLen : 0
Total number of GAP ACKs Transmitted : 279
Total number of GAP ACKs Received : 58787
Path No. : 1
Current CWND : 11840
SSThresh : 11840
Partial Bytes Acked : 0
Bytes Outstanding for this Path : 19480
Current RTO for this Path(in ms) : 60000
如图所示,拥塞的原因是出站数据块总数超过5,000个限制(8050+143=8193)并达到60秒RTO最大计时器,从而导致丢弃的SCTP数据请求。此外,还有更高的RTO计时器。
版本 | 发布日期 | 备注 |
---|---|---|
1.0 |
16-Apr-2015 |
初始版本 |