STP-congestie, IMSIMGR over state en SCTP-linkflaps in SGSN als gevolg van HLR MAP_RESET
Inhoud
Inleiding
Dit document beschrijft een probleem dat zich voordoet op het Serving General Packet Radio Service (GPRS) Support Node (SGSN) van Cisco 5000 Series geaggregeerde services router (ASR). Er worden ook enkele mogelijke omzeilingen voor dit probleem beschreven.
Achtergrondinformatie
Deze specifieke reeks gebeurtenissen op het ASR SGSN wordt in dit document beschreven:
- 21 nov, 6:25 AM: Een MAP_RESET werd verzonden door het Home Location Register (HLR).
- 21 nov, 8:13 AM: Een congestiealarm wordt opgeheven voor Signal Transfer Point 2 (STP-2).
- 21 nov, 8:23 AM: Er wordt een congestiealarm gegeven voor STP-1 en STP-2.
- 21 nov, 8:48 AM: De International Mobile Subscriber Identity Manager (IMSIMGR) gaat over in de waarschuwingsstaat.
- 21 nov, 10:07 AM: De links worden gereset van STP-2 naar de SGSN.
- 21 nov, 10:15 AM: Verbetering wordt waargenomen in de SGSN Location Update (LU) statistieken.
- 21 nov, 10:00 â 10:30 AM: De statistieken beginnen te verbeteren om 10:00 uur.
- 21 nov. 11:15 : Er is een daling waargenomen in de SGSN LU-stats.
- 21 nov, 11:41 AM: Het STP-team meldt dat Signaling Link Code (SLC)-1 van STP-2 geen verkeer ontvangt, de SLC wordt gereset en het verkeer keert terug naar normaal.
- 21 nov. 11:42 AM: Op SGSN wordt een congestiealarm gegeven voor SLC-1 van de STP.
- 21 nov, 12:00 PM: Nadat SLC-3 is gereset, verbeteren de GPRS LU stats.
Probleem
Wanneer de HLR het MAP_RESET bericht ontvangt, stelt het een vlag in voor een GPRS Location Update (GLU). Wanneer de Gebruikersapparatuur (UE) zijn eerste uplinkpakketten verstuurt, verstuurt de SGSN een GLU-bericht naar de HLR.
At 7 AM SGSN , Nov 21st 2014 had
******** show subscriber summary *******
Total Subscribers: 2386266
Active: 2386266
sgsn-pdp-type-ipv4: 942114
Zoals in de voorbeelduitvoer wordt getoond, zijn er 950.000 Packer Data Protocol (PDP)-contexten aanwezig op het SGSN en proberen de UE’s door deze te bladeren naarmate de dag vordert.
Wanneer de eerste uplink pakketten worden ontvangen, activeert het SGSN een GLU-bericht. Aangezien er honderdduizenden UE’s zijn, kan STP niet omgaan met de hoeveelheid verkeer die wordt gegenereerd en beweegt het naar een vaste congestiestaat.
Berichten worden in de wachtrij geplaatst bij de SGSN en er treedt een maximale doorlooptijd op. Aangezien alle GLU-berichten niet van de SGSN naar de HLR gaan, wordt de SGSN gedwongen de mobiele abonnees te ontkoppelen en te vragen dat ze weer worden bevestigd. Alle losstaande abonnees proberen dan om vast te maken, wat een plotselinge stijging van het aantal inkomende bijlageverzoeken veroorzaakt. Aangezien de bescherming van de netwerkoverbelasting wordt toegepast, worden de meeste pogingen om vast te maken verworpen wegens congestie en de mobiele abonnees worden gedwongen om een nieuwe poging te doen.
Als deze keten van gebeurtenissen zich ontvouwt, veroorzaakt het cascade-effecten. Veel Send Authenticatie Informatie (SAI) berichten, GLU berichten en MAP-IMEI_CHECK berichten zitten vast in de SGSN wachtrij of zijn gevallen. Om deze reden bereiken alle STP-1 en STP-2 links een congestiestaat. Elke STP heeft vier signaleringskoppelingen, maar in dit scenario herstellen de eerste drie koppelingen van STP-2 niet voor zeer lange tijd.
Hier zijn de congestiealarmen, waarin u kunt zien dat alle STP-links naar de congestiestatus op STP-2 gaan:
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
Zoals getoond, werd alleen Peer Server Process (PSP) 4 gewist, en de rest bevindt zich nog steeds in de congestiestatus:
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
Oplossing
In deze sectie wordt beschreven hoe u problemen kunt oplossen bij het probleem dat in de vorige sectie wordt beschreven.
STP-link ontvangt te veel verkeer
Zoals in de vorige paragraaf is beschreven, ontvangt één bepaalde link in de STP een grote hoeveelheid verkeer. U kunt zien dat de eerste drie koppelingen in STP-2 naar de congestiestatus gaan en nooit herstellen, dus er is maar één link beschikbaar en het congestielampje wordt gewist op SLC-3 (of peer-server-2-peer-server-process-4).
In overeenstemming met het SGSN load sharing mechanisme, moet het de Message Transfer Part (MTP) Level 3 (MTP3) User Adaptation Layer (M3UA)-pakketten gelijkelijk verzenden op alle vier de koppelingen. Vanaf de SNMP-traps (Simple Network Message Protocol) zijn de eerste drie STP-2-links echter permanent verstopt, wat betekent dat al het verkeer is gerouteerd naar de SLC-3-link (de enige beschikbare STP-link naar routeverkeer). Dit verklaart waarom de verkeersverdeling tussen de STP-2-verbindingen is scheefgetrokken.
In congestiesituaties schakelen een of meer koppelingen tussen staten met en zonder congestie, zodat alleen de beschikbare koppelingen het verkeer delen. Daarom is er meer gebruik in een van de koppelingen. Dit vereist een link reset om de koppelingen te kunnen herstellen.
De volgende output laat de statistieken op M3UA-niveau zien en maakt statistieken los. De belangrijke statistieken die in overweging moeten worden genomen zijn STP-2 PSP instantie 4, waar abnormaal verkeer kan worden gezien:
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
Hier zijn de STP-gegevens:
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
Deze output toont de details per seconde op het tijdstip van de kwestie:
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
Deze uitvoer toont de bijlagen per seconde, per 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
IMSIMGR in waarschuwingsstaat
Elke nieuwe vraag IMSI/Packet Temporary Mobile Subscriber Identity (P-TMSI) attach and Routing Area Update (RAU) moet worden verwerkt door de IMSIMGR.
Met een conservatieve observatie ontvangt het systeem een piekwaarde van 6.850 2-G verzoeken per seconde en ongeveer 5.313 3-G verzoeken per seconde. De maximumwaarde die u kunt instellen voor de bescherming tegen netwerkoverbelasting is 5.000 verzoeken per seconde toevoegen. Om de IMSIMGR in een opereerbare staat te houden, kan het systeem niet zo'n groot aantal oproepen vanuit de EU verwerken.
Deze kwestie begint na 8 uur 's ochtends, wanneer de wachtrijgrootte 1500 verzoeken per seconde bereikt:
network-overload-protection sgsn-new-connections-per-second 500 action
reject-with-cause congestion queue-size 1500 wait-time 5
Aangezien er ongeveer 12.000 verzoeken per seconde vastleggen, worden bijna 9.000 oproepen verwerkt door de IMSIMGR en afgewezen. Dit zorgt ervoor dat de IMSIMGR CPU verwerking een hoge status bereikt.
Als SGSN in een seconde meer dan het geconfigureerde aantal aanhechtingsverzoeken ontvangt, worden de verzoeken in de wachtrij opgeslagen en worden ze alleen geannuleerd als de buffer overstroomt als gevolg van een hoge aanhechtingssnelheid. Berichten in de wachtrij worden verwerkt in overeenstemming met een First-In, First-Out (FIFO) proces tot ze verouderen wanneer de wachttijd van het bericht in de wachtrij doorloopt in de ingestelde wachttijd.
Wanneer u de opties voor afwijzen of neerzetten kiest op basis van uw voorkeur, raadt Cisco u aan een oorzaakcode voor afwijzen te gebruiken om congestie in het netwerk aan te geven, zodat u de netwerkvoorwaarden kunt begrijpen voordat u een uplinkprocedure probeert.
HLR-fout
In overeenstemming met 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 23.060 wordt in dit deel het SGSN-gedrag tijdens een herstart van de HLR beschreven. Wanneer de SGSN een MAP reset ontvangt, wordt verwacht dat het een UL-verzoek naar de HLR stuurt voor zijn abonnees.
Wanneer een HLR opnieuw start, stuurt het een reset-bericht naar elk SGSN waarin een of meer van zijn mobiele stations (MS's) zijn geregistreerd. Dit zorgt ervoor dat de SGSN de relevante mobiele beheercontexten als ongeldig aanduidt als er een associatie bestaat tussen SGSN-to-Mobile Switching Center (MSC) en Visiting Location Register (VLR). Na ontvangst van het eerste geldige LLC-frame (Logical Link Control) (voor A/Gb-modus) of na ontvangst van het eerste geldige GPRS Tunneling Protocol User (GPT-U)-pakket- of uplink-signaleringsbericht (voor Iu-modus) van een gemarkeerd Mobile Station, voert de SGSN een UL uit naar de HLR, zoals in de bijlageaanvraag of de RA-procedures (Inter-SGSN Routing Area). Als ook de waarschuwingsvlag voor niet-GPRS (NGAF) wordt ingesteld, wordt de procedure in de clausule voor niet-GPRS-waarschuwingen gevolgd. De UL-procedure en de procedure naar de MSC/VLR kunnen door de SGSN worden vertraagd voor een maximale configuratie van de operator, afhankelijk van het gebruik van de middelen op dat moment om een hoge signaalbelasting te voorkomen.
Aanbevelingen
Cisco raadt u aan deze stappen te voltooien om dit probleem op te lossen:
- Verhoog het aantal nieuwe verbindingen per seconde. Dit kan worden berekend op basis van het gemiddelde aantal bijlageverzoeken.
- Verhoog de Transacties per seconde (TPS) in de STP-link naar een ideale waarde.
- Wijzig de standaard SCTP-RTO-MAX waarde van 600 (600*100 = 60.000) in 5 (5*100 ms). Bijvoorbeeld, voor twee STP's met 4.000 TPS, kunt u tot 1.000 verzoeken per seconde van SGSN ondersteunen.
Idealiter heeft elke STP vier koppelingen, zodat 125 verzoeken per STP link kunnen worden verwerkt. Dit wordt gelijk verdeeld over alle STP-koppelingen. Echter, als een van de koppelingen naar beneden gaat, worden veel herverbindingspogingen gezien, wordt de wachtrij vol, en pakketverwerpingen gebeuren. Als er meer koppelingen naar beneden gaan, dan is het verkeer ongelijkmatig verdeeld.
Traffic Flow
Het verkeer van de EU volgt geen lineaire manier. Dit gebeurt meestal bij een barst en bij veel herverbindingspogingen. De SGSN stuurt verkeer in bundels naar de STP. Op dat moment overschrijden de verkeersstromen de geconfigureerde TPS op de STP. Dit veroorzaakt sommige verbindingen in STP beginnen te adverteren lage venstergrootte als zij reeds meer vraag verwerken, en SGSN begint de gegevensbrokken van SCTP een rij te vormen die een rij worden gevormd. Daarna wordt gewacht tot de RTO MAX-timer is verlopen.
Als de STP periodiek een goede geadverteerde venstergrootte verzendt, dan zou u meer SCTP gegevensbrokken moeten kunnen verzenden als de waarde SCTP_RTO_MAX tot vijf seconden of minder wordt verminderd. De wachtrij wordt sneller gewist en er wordt geen M3UA congestiealarm geactiveerd. Bovendien, zou u niet de Interne die vlag moeten zien van de Debietcontrole door SCTP wordt teweeggebracht om de pakketstroom te controleren.
SGSN verstuurt alleen pakketten in de hoeveelheid die STP kan accepteren, die is gebaseerd op de geadverteerde venstergrootte. Als u de TPS per STP link verhoogt, helpt het om STP congestie te voorkomen en vermindert het de SCTP_RTO_MAX timer.
Triggers voor M3UA Verstopt Alarmsignaal in SGSN
Als de geadverteerde venstergrootte in het bericht van de Transmissie van de Controle van de Stroom van het Protocol (SCTP) Selectieve Erkenning (ZAK) dichtbij nul (of nul) is, dan heft SGSN een alarm M3UA op om erop te wijzen dat de berichten niet voor dat peer eindpunt zouden moeten worden verzonden. Dit zorgt ervoor dat de koppeling naar flap gaat of naar een toestand met congestie gaat. Aangezien SGSN een hogere venstergrootte verzendt, blijft u gegevens van M3UA van de peer-knooppunten ontvangen, en die pakketten zouden in de wachtrij kunnen worden gelaten vallen als de peer puntcode nooit uit de verstopte staat komt.
Hierna volgt een voorbeeld:
- SCTP stuurt een stroomregelingstartindicatie naar de M3UA.
- M3UA stelt de congestieactieve vlag voor de vereniging in en begint het SCTP periodiek te pollen over de status van zijn flowcontrole.
- Terwijl een vereniging in flow control is, vormt het toekomstige gegevensverzoeken om die vereniging een rij tot QUEUE_SIZE 8.000 heeft bereikt. Op dat punt worden toekomstige berichten voor de vereniging verworpen.
- Als STP een juiste geadverteerde venstergrootte verzendt, dan probeert M3UA om de berichten te legen die worden een rij gevormd tot het 5.000 bereikt. De RTO-timer speelt hier ook een rol in.
De SCTP-berichten worden alleen in de wachtrij geplaatst voor die verenigingen waar de flow control-vlag True wordt, en de SGSN verwerkt vervolgens in overeenstemming met de STP-respons:
*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
Zoals getoond, is de reden achter de congestie dat het totale aantal uitgaande stukken de 5.000 grens (8050+143=8193) overschrijdt en de 60 tweede RTO maximumtijdopnemer raakt, die in verworpen SCTP gegevensverzoeken resulteert. Er is ook een hogere RTO-timer.
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
16-Apr-2015 |
Eerste vrijgave |
Feedback