ASR serie 5000 Risoluzione dei problemi relativi a GTPC e GTPU e guasti del percorso associati
Sommario
Introduzione
In questo articolo vengono illustrati la comprensione e la risoluzione dei problemi relativi al protocollo di tunneling del servizio General Packet Radio per Control Plane (EGTPC) / GTPC (3rd Generation Partnership Project Technical Specification 29.274), al protocollo di tunneling GPRS User Plane (GTPv1-U) (3GPP TS 29.281) e più rilevanti per questo articolo, alle procedure di ripristino (3GPP TS 23.007), che si basano su concetti come i contatori di riavvio, rilevamento errori di percorso ed eco richieste/risposte. Include un elenco dei comandi rilevanti e gli elementi da cercare nell'output, oltre a una spiegazione dei relativi configurabili. Si tratta certamente di un settore per il quale vengono sollevate molte questioni. Si noti che la risoluzione di problemi specifici relativi al controllo delle chiamate è di per sé un'area di interesse molto ampia, ma in questo articolo viene solo indicato come acquisire le statistiche per il controllo delle chiamate. Non vengono trattati gli altri aspetti (ad esempio i problemi relativi alla configurazione delle chiamate). In realtà questo articolo si concentra principalmente sulla risoluzione dei problemi e la verifica delle connessioni peer, senza le quali non ci sarebbe alcun controllo delle chiamate. Anche i designer / implementatori possono trarre beneficio dal contenuto, scritto per gli operatori.
In tutti gli esempi vengono utilizzati indirizzi IP falsi (modificati) provenienti dalla rete di un operatore reale.
Introduzione
Ogni lato di una connessione GTP (uno di S5 (Serving Gateway (SGW) - Packet Data Network Gateway (PGW)), S11 (Multimedia Management Entity (MME) - SGW), S4 (Serving GPRS Service Node (SGSN) - Gateway GPRS Service Node (GSN)) mantiene un contatore di riavvio progettato per avvisare il peer se il nodo di origine è stato riavviato in modo che il peer possa intraprendere l'azione appropriata. Mentre un nodo può utilizzare un contatore univoco per ogni peer con cui comunica, la struttura tende a utilizzare lo stesso contatore per tutti i peer, poiché quando il nodo viene riavviato, il contatore deve essere incrementato per tutti i peer e quindi il tracciamento di un valore separato su una base peer non offre alcun vantaggio aggiuntivo in quanto tutti devono comunque aumentare di uno. In effetti, l'utilizzo dello stesso contatore di riavvio per tutti i peer è utile per la risoluzione dei problemi di una rete di grandi dimensioni in cui è possibile controllare tutti i peer per verificare che i contatori di riavvio ricevuti abbiano lo stesso valore (singolo) per il nodo con cui stanno parlando i peer.
Il contatore di riavvio PUÒ essere incluso in tutti i tipi di messaggi di controllo, mentre il contatore di riavvio DEVE essere incluso in tutte le richieste e risposte echo. Non appena si verifica una modifica del contatore di riavvio su un nodo, i vari peer vengono informati tramite i successivi messaggi di controllo inviati ai rispettivi peer. Quando si verifica un riavvio, in base alle specifiche, il lato ricevente ha la possibilità di mantenere temporaneamente le chiamate che ha per un breve periodo o di eliminarle, il secondo che è in genere il comportamento configurato.
In caso di utilizzo delle richieste echo, il metodo consiste nell'inviare i messaggi a intervalli configurati e, se non viene ricevuta alcuna risposta dopo un numero configurato di tentativi (ciascuno dopo un timeout configurato), il percorso viene considerato inattivo e viene eseguita l'azione appropriata. La configurazione consente l'invio opzionale di pacchetti echo anche al peer, il cui approccio non deve necessariamente essere lo stesso, in particolare quando il peer può appartenere a un fornitore diverso e/o a un vettore diverso. Infatti, per quanto riguarda le risposte ECHO, un nodo è obbligato solo a rispondere a una richiesta ECHO - che riceva o meno echo e con quale frequenza non è significativa - ma deve solo inviare una risposta echo per ogni richiesta e agire se il contatore di riavvio ha ricevuto delle modifiche. Naturalmente, come già accennato, se invia richieste echo e non riceve risposte tempestive, deve intervenire anche per questo scenario.
Notare che il rilevamento degli errori di percorso può essere eseguito anche sulla connessione GTP-U (piano utente) tramite Echo, ma SOLO tramite timeout, poiché nei messaggi GTP-U non è presente un contatore di riavvio come è stato descritto in precedenza per GTP-C. Il GTP-U può utilizzare o meno lo stesso percorso dei messaggi di controllo. Se si tratta dello stesso percorso, il rilevamento GTP-U potrebbe non essere altrettanto utile in quanto il rilevamento GTP-C dovrebbe essere sufficiente.
Riepilogando, ecco i modi in cui è possibile eseguire il rilevamento degli errori di percorso:
- Riavvia modifica contatore (tramite controllo msg Req/Rsp o Echo)
- Timeout richiesta eco GTPC
- Timeout richiesta eco GTPU
- Timeout messaggio richiesta di controllo (in genere non configurato)
Comandi pertinenti
Per risolvere i problemi relativi ai percorsi, consultare i seguenti comandi. Di seguito è riportata una spiegazione dei dettagli relativi a ciascuna di esse.
- show [egtpc-service] | gtpu-service] tutto
- show egtpc peers [egtp-service <servizio>]
- egtpc test echo gtp-versione {1} | 2} src-address <indirizzo servizio> peer-address <indirizzo peer>
- show egtpc statistics [[ (indirizzo-sgw) | pgw-address | mme-address) <address>] [demux-only] [debug-only] [verbose] | percorso-errore-motivi]
- show gtpu statistics [indirizzo peer <peer>]
- show gtpc statistics [ggsn-service <servizio>] [smgr-instance <istanza>]
- show demux-mgr statistics <egtpinmgr | egtpegmgr | gtpumgr> all (SGW-In uscita) | GSN/PGW,/SGW in entrata | GTPU)
- EGTPCPathFail[Clear], EGTPUPathFail[Clear] Trap SNMP
- show session disconnect-reason - gtpc-path-failure, gtpu-path-failure, path-failure
Altri comandi per contare i sottoscrittori relativi al GTP:
show sub [summary] gsn-service <servizio>
show sub [summary] gtpu-service <servizio>
show egtpc sessions [egtp-service <servizio>]
Il comando di base per controllare lo stato e la configurazione di tutti i servizi EGTP è "show egtpc-service". La maggior parte dell'output deve essere ciò che è già noto tramite la configurazione, mentre lo stato deve essere STARTED. L'informazione unica raccolta è il "Restart Counter", che non può essere trovato altrove. Il comando correlato "show gtpu-service all" restituisce elementi configurabili per i servizi GTPU associati ai servizi EGTPC.
"show egtpc peers" è molto utile per identificare tutti i peer, inclusi gli stati, i contatori di riavvio e il numero massimo/corrente di sottoscrittori.
- Si noti che questo comando copre sia i peer SGW che SGSN, mentre in passato esisteva un comando separato per SGSN/GSN.
- Poiché questo comando include tutti i tipi peer, è possibile filtrare il tipo peer tramite il nome del servizio (anche se la parola chiave egtpc-service accetta in modo ingannevole anche un nome di servizio GSN).
- Se non sono presenti sottoscrittori con il peer, lo stato è Inattivo e Eco GTPC disabilitato. In questo stato, per EGTPC potrebbero esserci alcuni peer per i quali viene segnalato il contatore di riavvio, mentre la maggior parte potrebbe essere 0. Questo si verifica in situazioni in cui il peer invia attivamente richieste echo a cui ASR5K deve rispondere. Il contatore di riavvio può essere determinato eseguendo il comando di test EGTPC (descritto di seguito), anche se nello stato inactive il contatore non verrà aggiornato in "show egtpc peer" anche se è stato ricevuto. Nel frattempo per GSN, il contatore di riavvio non viene mai dimenticato.
[local]PGW-GGSN> show egtpc peers egtp-service GGSN1 ||||| Service Restart--+ No. of ||||| ID Counter | restarts ||||| | | | Current Max vvvvv v Peer Address v v sessions sessions ----- --- -------------------------------- --- --- ----------- -- --------- IDNKG 6 203.0.113.69 165 0 0 1 IDNKG 6 203.0.113.70 25 0 0 1 IDNKG 6 203.0.113.71 165 0 0 1 IDNKG 6 203.0.113.72 25 0 0 1 IDNKG 6 203.0.113.73 53 0 0 1 IDNKG 6 203.0.113.74 53 0 0 1 IDNKG 6 192.0.2.9 46 0 0 2 IDNKG 6 192.0.2.10 44 0 0 1 IDNKG 6 192.0.2.11 47 0 0 2 IDNKG 6 192.0.2.12 44 0 0 2 IDNKG 6 192.0.2.13 54 0 0 1 IDNKG 6 192.0.2.14 47 0 0 1 IDNKG 6 209.165.200.225 35 1 0 3 IDNKG 6 209.165.200.226 35 3 0 3 IDNK 6 198.51.100.204 156 0 0 1 IDNK 6 198.51.100.205 158 0 0 1 IDNK 6 198.51.100.211 54 0 0 1 IDNK 6 198.51.100.212 54 0 0 1 IDNK 6 198.51.100.213 56 0 0 1 IDNK 6 198.51.100.214 56 0 0 1 IDNK 6 198.51.100.215 54 0 0 1
Notate un paio di peer sotto che hanno conteggi molto più alti degli altri peer. Questi sono per i SGW che si trovano fisicamente nello stesso sito o nel sito sorella del PGW a cui l'MME incanala la maggior parte delle chiamate.
[local]PGW> show egtpc peers Monday March 30 20:10:26 UTC 2015 +----Status: (I) - Inactive (A) - Active |+---GTPC Echo: (D) - Disabled (E) - Enabled ||+--Restart Counter Sent: (S) - Sent (N) - Not Sent |||+-Peer Restart Counter: (K) - Known (U) - Unknown ||||+-Type of Node: (S) - SGW (P) - PGW ||||| (M) - MME (G) - SGSN ||||| (L) - LGW (E) - ePDG ||||| (C) - CGW ||||| (U) - Unknown ||||| Service Restart--------+ No. of ||||| ID Counter | restarts ||||| | | | Current Max vvvvv v Peer Address v v sessions sessions ----- --- --------------------------------------- --- --- ----------- ---------- IDNUS 5 198.51.100.4 0 0 0 1 IDNKS 5 198.51.100.33 75 0 0 1 IDNUS 5 198.51.100.35 0 0 0 2 IDNUS 5 198.51.100.65 0 0 0 1 IDNUS 5 198.51.100.67 0 0 0 2 IDNUS 5 198.51.100.68 0 0 0 2 IDNUS 5 198.51.100.98 0 0 0 2 IDNUS 5 198.51.100.100 0 0 0 1 IDNUS 5 198.51.100.129 0 0 0 2 IDNUS 5 198.51.100.130 0 0 0 2 IDNUS 5 198.51.100.161 0 0 0 2 IDNUS 5 198.51.100.194 0 0 0 2 IDNUS 5 198.51.100.196 0 0 0 1 IDNUS 5 198.51.100.225 0 0 0 5 IDNUS 5 198.51.100.226 0 0 0 2 IDNUS 5 198.51.100.228 0 0 0 1 IDNUS 5 198.51.100.3 0 0 0 2 IDNUS 5 198.51.100.36 0 0 0 1 IDNUS 5 198.51.100.64 0 0 0 4 IDNUS 5 198.51.100.66 0 0 0 2 IDNUS 5 198.51.100.130 0 0 0 2 IDNKS 5 198.51.100.24 2 0 0 2 AESKS 5 198.51.100.56 3 0 1 5 IDNKS 5 198.51.100.99 18 0 0 2 AESKS 5 198.51.100.100 7 0 1 3 IDNKS 5 198.51.100.131 46 0 0 2 IDNKS 5 198.51.100.132 18 0 0 2 IDNKS 5 198.51.100.163 41 0 0 3 IDNKS 5 198.51.100.164 6 0 0 2 AESKS 5 198.51.100.184 11 0 1 2 IDNKS 5 198.51.100.216 7 0 0 2 AESKS 5 203.0.113.24 5 0 3 8 IDNKS 5 203.0.113.56 3 1 0 13 IDNKS 5 203.0.113.88 2 0 0 18 IDNKS 5 203.0.113.120 6 0 0 3 IDNKS 5 203.0.113.152 3 0 0 4 AESKS 5 203.0.113.184 2 0 1 9 IDNKS 5 203.0.113.216 4 0 0 2 IDNKS 5 203.0.113.248 10 0 0 1 IDNUS 5 203.0.113.4 0 0 0 2 IDNUS 5 203.0.113.33 0 0 0 4 IDNUS 5 203.0.113.65 0 0 0 2 IDNKS 5 203.0.113.121 5 0 0 3 IDNKS 5 203.0.113.153 6 0 0 5 IDNUS 5 203.0.113.162 0 0 0 3 IDNUS 5 203.0.113.32 0 0 0 5 AESKS 5 203.0.113.35 5 1 6 37 IDNUS 5 203.0.113.64 0 0 0 1 IDNUS 5 203.0.113.66 0 0 0 4 IDNUS 5 203.0.113.97 0 0 0 1 AESKS 5 203.0.113.98 4 0 1 4 IDNUS 5 203.0.113.161 0 0 0 4 IDNUS 5 203.0.113.193 0 0 0 10 IDNUS 5 203.0.113.228 0 0 0 12 IDNUS 5 203.0.113.233 0 0 0 4 AESKS 5 192.0.2.4 9 0 3 10 AESKS 5 192.0.2.24 6 0 10 19 AESKS 5 192.0.2.32 8 0 83 116 AESKS 5 192.0.2.33 55 0 14 21 AESKS 5 192.0.2.65 18 0 1 2747 AESKS 5 192.0.2.66 4 0 3 1639 AESKS 5 192.0.2.97 44 39 33 1826 AESKS 5 192.0.2.98 5 1 6 2075 IDNKS 5 192.0.2.195 8 0 0 7 AESKS 5 192.0.2.3 46 0 3230 5346 AESKS 5 192.0.2.5 12 0 84 202 AESKS 5 192.0.2.7 2 0 31 443 AESKS 5 192.0.2.24 3 0 116 117 AESKS 5 192.0.2.36 15 0 4194 6889 AESKS 5 192.0.2.44 7 0 112 331 AESKS 5 192.0.2.68 34 0 6104 9798 AESKS 5 192.0.2.69 7 0 2259 5027 AESKS 5 192.0.2.88 17 0 3899 8880 AESKS 5 192.0.2.164 16 0 833131 1298070 AESKS 5 192.0.2.184 3 0 1437053 2153317 AESKS 5 192.0.2.193 21 0 11364 26577 AESKS 5 192.0.2.195 5 0 50 162 AESKS 5 192.0.2.226 21 0 1950 3931 AESKS 5 192.0.2.227 6 0 4348 9332
Notare che l'esecuzione di questo comando su un nodo di standby ICSR (Inter-Chassis Service Redundancy) è rilevante solo per i peer attivi, nel qual caso i numeri devono essere vicini, ad esempio nella coppia seguente:
| PGW> show egtpc peers ... 20:51:52 (ATTIVO) | PGW-ICSR> show egtpc peers ... 20:51:51 (STANDBY) | |||||||||
| Peer | RC | N. sessioni | Sess max | Peer | RC | N. sessioni | Sess max | |||
| AESKS | 192.0.2.5 | 2 | 31 | 443 | ADSK | 192.0.2.5 | 2 | 31 | 443 | |
| AESKS | 192.0.2.24 | 3 | 117 | 123 | ADNKS | 192.0.2.24 | 3 | 117 | 123 | |
| AESKS | 192.0.2.36 | 15 | 4223 | 6889 | ADSK | 192.0.2.36 | 15 | 4223 | 6889 | |
| AESKS | 192.0.2.44 | 7 | 119 | 331 | ADSK | 192.0.2.44 | 7 | 119 | 331 | |
| AESKS | 192.0.2.68 | 34 | 6174 | 9798 | ADSK | 192.0.2.68 | 34 | 6171 | 9797 | |
| AESKS | 192.0.2.69 | 7 | 2311 | 5027 | ADSK | 192.0.2.69 | 7 | 2311 | 5027 | |
| AESKS | 192.0.2.88 | 17 | 3914 | 8880 | ADSK | 192.0.2.88 | 17 | 3913 | 8874 | |
| AESKS | 192.0.2.164 | 16 | 833705 | 1298070 | ADSK | 192.0.2.164 | 16 | 832037 | 1294412 | |
| AESKS | 192.0.2.184 | 3 | 1438418 | 2153317 | ADSK | 192.0.2.184 | 3 | 1435461 | 2147280 | |
| AESKS | 192.0.2.193 | 21 | 11447 | 26577 | ADSK | 192.0.2.193 | 21 | 11443 | 26568 | |
| AESKS | 192.0.2.195 | 5 | 48 | 162 | ADSK | 192.0.2.195 | 5 | 48 | 162 | |
| AESKS | 192.0.2.226 | 21 | 1962 | 3931 | ADSK | 192.0.2.226 | 21 | 1962 | 3931 | |
| AESKS | 192.0.2.227 | 6 | 4465 | 9332 | ADSK | 192.0.2.227 | 6 | 4466 | 9332 | |
"egtpc test echo" viene utilizzato per verificare se un peer specifico è raggiungibile o meno e deve essere eseguito nel contesto in cui è definito il servizio.
- Utilizzare gtp-version 1 per le connessioni GSN-SGSN
- L'uso del comando ping non è un test valido, anche se se se il test riesce, è noto che vi è un certo livello di raggiungibilità.
- Viene visualizzato il contatore di riavvio peer (Ripristino).
- L'esecuzione di questo comando incrementa i contatori di risposta Eco Tx / Eco Rx in "show egtpc statistics"
- Il contatore di riavvio del peer viene segnalato dopo la parola chiave Recovery (11 nell'esempio seguente)
- Avviso: anche se questo non dovrebbe accadere in circostanze normali, se un'eco di prova viene eseguita su un peer e si interrompe per qualsiasi motivo (se tutto funziona allora non dovrebbe interrompersi), tutte le chiamate sarebbero scartate (anche se le cose funzionano proprio bene fino al punto di fare il test).
[Ingress]PGW> egtpc test echo gtp-version 2 src-address 209.165.201.1 peer-address 198.51.100.35
Monday November 03 15:08:12 UTC 2014
EGTPC test echo
---------------
Peer: 198.51.100.35 Tx/Rx: 1/1 RTT(ms): 1 (COMPLETE) Recovery: 11 (0x0B)
"show egtpc statistics" è per EGTPC (v2) e segnala le operazioni riuscite/non riuscite di molti messaggi di controllo EGTPC (Request/Response, Tx/Rx), tra cui creazione sessione, modifica supporto, eliminazione sessione, notifica dati downlink, release access bearer, creazione supporto, aggiornamento supporto, modifica supporto, sospensione, ecc., e le risposte associate. Include tutti i contatori di gestione dei percorsi per Richiesta/Risposta echo Tx/Rx e, in base ai timer, è possibile prevedere la crescita di questi timer e utilizzarli per risolvere i problemi, se non incrementandoli come previsto.
Nell'esempio seguente viene mostrato come avviare un'azione di eco e rispondere a un'azione di entrambi i lati. Notare che il SGW è stato configurato per inviare una volta al minuto mentre il PGW è stato configurato per una volta ogni tre minuti (non è necessario che entrambi i lati abbiano la stessa impostazione), quindi ogni tre minuti c'è il doppio del numero di pacchetti (6:16:33, 6:19:33). Tenete presente che, sebbene entrambi i lati siano sullo stesso "ciclo" in questo esempio, non devono necessariamente essere e possono funzionare indipendentemente l'uno dall'altro. I contatori di riavvio sono stati acquisiti anche in una colonna. Notare che il contatore Restart di 11 dalla risposta echo del SGW corrisponde al valore della risposta all'echo di test del PGW di cui sopra (il test è stato eseguito in un momento diverso dall'acquisizione del pacchetto, ma per la stessa coppia di peer).
L'opzione Solo demux acquisisce tutti i contatori di gestione dei percorsi (richieste/risposte echo), nonché i messaggi di controllo che non raggiungono mai un sessmgr, che in genere è Crea richiesta/risposta sessione. Demux process etpinmgr residente sulla scheda Demux è responsabile della gestione di tutte le richieste/risposte echo e della gestione iniziale di tutti i messaggi di controllo delle chiamate prima di distribuirli ai sessmgr appropriati (in modo casuale per le nuove chiamate e in particolare per le chiamate esistenti ancorate a uno specifico sessmgr). Per contro, l'opzione sessmgr-only conta solo i messaggi gestiti da sessmgrs, che NON include i contatori di gestione dei percorsi. Per impostazione predefinita, il conteggio di tutti i valori non viene eseguito specificando nessuno dei qualificatori.
"show gtpc statistics" è il comando analogo per i servizi SGSN/GSN (GTPC v1) (CPC, Aggiorna contesto PDP, ecc.)
"show gtpu statistics" segnala le statistiche sul traffico del piano utente gestito dai servizi GTP-U associati ai servizi EGTPC. Un contatore interessante è Error Indication Tx/Rx che verrebbe inviato quando il nodo ricevente non ha alcun record del sottoscrittore che dovrebbe essere associato al TEID (Terminal Endpoint Identifier) del pacchetto in questione, il che potrebbe verificarsi per una serie di motivi (Lo schema/variabile bulkstats è GTPU1/ err-ind-tx). Se l'MME/SGW non è stato informato che il PGW non ha più un collegamento con il sottoscrittore, potrebbe essere necessario cancellare manualmente le chiamate sull'MME/SGW (o attenderne il timeout) per risolvere completamente il problema delle chiamate orfane.
Le versioni specifiche per i peer dei comandi stat di cui sopra sono necessarie per la risoluzione dei problemi di peer specifici, come spesso accade.
Rilevamento errori di percorso
La trap EGTPCPathFail è la chiave per sapere quando si è verificato un errore di percorso. Tra i valori di base che si potrebbero già supporre, viene indicato il numero di chiamate non elaborate, i contatori di riavvio vecchi e nuovi e la causa dell'errore. Inoltre, il motivo di disconnessione della sessione gtpc-path-failure verrà incrementato.
La trap EGTPCPathFailClear indica il contatore di riavvio e il motivo per cui il percorso è stato cancellato. Il più recente StarOS v17 è meglio scritto per dire "chiara ragione" invece di "motivo di errore" (cancellato, non fallito!) per evitare confusione.
Di seguito vengono riportati i conteggi degli errori di percorso indicati da "show egtpc stat path-failure-REASON"
[local]PGW> show egtpc statistics path-failure-reasons Reasons for path failure at EGTPC: Echo Request restart counter change: 3 Echo Response restart counter change: 0 echo-rsp-restart-counter-change No Echo Response received: 0 no-response-from-peer Control message restart counter change at demux: 23 Create Session Req Restart Counter changed or create-sess-restart-counter-change Control message restart counter change at sessmgr: 0 cpc-restart-counter-change or upc-restart-counter-change Total path failures detected: 26
Note:
- Il contatore di riavvio dei messaggi di controllo in sessmgr potrebbe essere qualsiasi tipo di messaggio di controllo (non tutti elencati qui)
- Contatore di riavvio modificato da SGSN tramite la successiva richiesta di creazione del contesto PDP dopo la modifica (cpc-restart-counter-change)
- Contatore di riavvio modificato da SGSN tramite la successiva richiesta di aggiornamento del contesto PDP dopo la modifica (ovvero un handoff da un altro SGSN) (upc-restart-counter-change)
- Path clear failure reason sessions-add è un termine ingannevole - non è un errore ma un successo, e indica che è arrivata una nuova sessione per stabilire la connessione
- Se i valori riportati per i contatori di riavvio e i conteggi delle sessioni per le trap PathFail e PathClear non sembrano essere allineati, aprire un ticket con Cisco per ulteriori informazioni.
È importante comprendere come EGTPC/GTPC e in misura minore EGTPU/GTPU (poiché il rilevamento degli errori del piano utente non è sempre configurato) il rilevamento degli errori di percorso venga implementato per monitorare la connessione tra un GSN o PGW e i vari SGSN e SGW peer. Normalmente le connessioni all'interno di una rete di provider di servizi sono piuttosto stabili, nel qual caso gli errori di percorso sono rari. Dall'altro lato, l'esperienza ha mostrato che i percorsi GTPC tra i SGSN in roaming che si connettono ai GSN potrebbero non essere così stabili, quindi con connessioni scarse il risultato è un errore di percorso piuttosto frequente.
La seguente configurazione descrive i timer e la frequenza di trasmissione per i messaggi echo e di controllo che possono essere utilizzati per rilevare errori di percorso. Lo stesso concetto si applica ai servizi GSN, SGW, MME ed EGTP:
gsn-service GGSN1
|
retransmission-timeout 20
|
Per i messaggi di controllo GTP (rispetto ai messaggi echo)
|
|
max-ritrasmissioni 5
|
per sia il controllo GTP che i messaggi echo: quante volte ritrasmettere prima che venga attivato il rilevamento degli errori dei percorsi
|
|
intervallo echo 120
|
L'eco viene inviata ogni 2 minuti (120 secondi).
|
|
echo-retransmission-timeout 5
|
Per Echos, se non viene fornita alcuna risposta, la trasmissione viene ripetuta ogni 5 secondi
|
|
path-failure detection-policy gtp echo
|
Il rilevamento degli errori di percorso è possibile attraverso l'eco gtp (invece di usare questo metodo per rilevare gli errori di percorso (ma inviare comunque l'eco)).
|
|
associate gtpu-service GGSN1_gtpu
|
Associa il servizio GTPU denominato GSN1_gtpu al servizio GSN
|
|
binding indirizzo ipv4 209.165.201.2
|
Gli indirizzi IP di bind dell'utente e del control plane sono gli stessi nelle seguenti configurazioni di esempio, ma possono non essere necessariamente configurati come tali con implementazioni di altri provider di servizi.
|
[local]GGSN> show ggsn-service name GGSN1 Service name: GGSN1 Context: XGWin Bind: Done Local IPv4 Address: 209.165.201.2 Local IP Port: 2123 Retransmission Timeout: 20 (secs) Max Retransmissions: 5 Restart Counter: 41 Echo Interval: 120 (secs) GTPC Echo Mode : Default GTPC Echo Retransmission Timeout : 5 Guard Interval: 100 (secs) Path Failure Detection on gtp msgs: Echo
Note:
- Dato il tempo 0 all'avvio di un ciclo di richiesta Echo (ogni 2 minuti), se non vi sono risposte dopo un TOTALE di 30 secondi (6 tentativi), il percorso non riesce (0 + 5sec + (5 * 5sec))
- Il processo egtpinmgr (gtpcmgr deprecato da v14) in esecuzione sulla scheda demux è responsabile dell'elaborazione dei pacchetti echo
- "show gtp statistics", sezione "Path Management Messages" contiene le statistiche per le richieste/risposte echo per il percorso di controllo in ENTRAMBE le direzioni:
[Ingress]GGSN> show gtpc statistics Monday October 27 23:02:07 UTC 2014 Path Management Messages: Echo Request RX: 169951248 Echo Response TX: 169951248 Echo Request TX: 40838432 Echo Response RX: 40784820
Un altro metodo di rilevamento del percorso è sul piano utente invece che sul piano di controllo, ed è regolato dalla seguente configurazione.
gtpu-service GGSN1_gtpu
no echo-interval
max-retransmissions 4
echo-retransmission-timeout 5
path-failure detection-policy gtp echo
no path-failure clear-trap gtp echo
bind ipv4-address 209.165.201.2
exit
Note:
- "no echo-interval" disabilita l'invio di richieste echo per il piano utente e pertanto la CLI "path-failure detection-policy gtp echo" non ha alcuna rilevanza - NO Path failure detection is done on GTPU
- Il GSN continua a rispondere alle richieste echo provenienti dal SGSN anche se
- statistiche echo acquisizione "show gtpu stat" e "show demux-mgr stat gtpumgr"
[local]PGW-GGSN> show gtpu statistics
Wednesday October 29 23:43:22 UTC 2014
Path Management Messages:
Echo Request Rx: 84690303 Echo Response Rx: 0
Echo Request Tx: 0 Echo Response Tx: 84690043
[local]PGW-GGSN> show demux-mgr statistics gtpumgr
Wednesday October 29 23:42:04 UTC 2014
Echo stats:
Echo Req Rcvd: 84690303
Echo Rsp Sent: 84690043
Vari esempi di intercettazioni e spiegazioni degli errori dei percorsi
In genere il contatore di riavvio del peer aumenta di uno quando viene eseguito un riavvio. In questo caso, un bug in PGW ha causato l'override del contatore di riavvio sul valore della RC di un altro peer (prima trap), quindi quando il pacchetto successivo è arrivato sulla connessione, lo ha trattato come un riavvio (seconda trap) pensando che la RC fosse cambiata. Il percorso viene quindi cancellato da qualsiasi pacchetto successivo (terza trap). Il punto qui non è sapere di un bug specifico, ma piuttosto cercare di essere a conoscenza di eventuali cambiamenti del contatore che non possono essere spiegati.
Wed Jan 14 05:22:07 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 198.51.100.1, peer old restart counter 54, peer new restart counter 12, peer session count 1107240, failure reason restart-counter-change
Wed Jan 14 05:22:07 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 198.51.100.1, peer old restart counter 12, peer new restart counter 54, peer session count 1107207, failure reason create-sess-restart-counter-change
Wed Jan 14 05:22:07 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 198.51.100.1, peer restart counter 54, peer session count 1107199, failure reason sessions-add
Nell'esempio, un GSN peer ha modificato il valore RC da 66 a 67 tramite una richiesta di contesto PDP:
Mon Oct 27 11:48:54 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.201.2, peer address 209.165.200.225, peer old restart counter 66, peer new restart counter 67, peer session count 0, failure reason cpc-restart-counter-change Mon Oct 27 11:48:54 2014 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.201.2, peer address 209.165.200.225, peer restart counter 67, peer session count 1, failure reason sessions-add
Questo esempio viene da un PGW in cui l'ePDG peer ha modificato la propria RC da 69 a 70 tramite una richiesta di creazione sessione:
Fri Jun 12 05:21:54 2015 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 2001:5555:8000:fff0:132:200::, peer address 2001:5555:8000:ffe0:123:20f::, peer old restart counter 69, peer new restart counter 70, peer session count 0, failure reason create-sess-restart-counter-change Fri Jun 12 05:21:55 2015 Internal trap notification 1113 (EGTPCPathFailClear) context PGWin, service EGTP1, interface type pgw-ingress, self address 2001:5555:8000:fff0:132:200::, peer address 2001:5555:8000:ffe0:123:20f::, peer restart counter 70, peer session count 1, clear reason sessions-add
In questo esempio, l'output di vari nodi PGW tutti collegati allo stesso SGW mostra che il SGW ha smesso di diventare raggiungibile dai PGW per una trap EGTPCPathFail sui vari PGW in un breve lasso di tempo tra loro. Si noti che in tutti i nodi viene visualizzato lo stesso contatore di riavvio descritto in precedenza, in quanto normalmente un nodo utilizza lo stesso contatore per tutti i peer. In caso di mancata risposta, il nuovo contatore di riavvio visualizzato è 9, ma potrebbe essere meglio stampare il nuovo contatore come non definito, poiché la connessione è inattiva al momento dell'attivazione della registrazione e quindi avere un contatore di riavvio non ha senso.
Mon Dec 22 09:07:29 2014 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.4, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 151, failure reason no-response-from-peer Mon Dec 22 09:08:54 2014 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.5, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 634, failure reason no-response-from-peer Mon Dec 22 09:09:00 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.6, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 22, failure reason no-response-from-peer Mon Dec 22 09:07:42 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.7, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 33, failure reason no-response-from-peer Mon Dec 22 09:08:06 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.8, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 1, failure reason no-response-from-peer Mon Dec 22 09:07:34 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.9, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 725, failure reason no-response-from-peer Mon Dec 22 09:08:20 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.10, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 279978, failure reason no-response-from-peer Mon Dec 22 09:06:37 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.11, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 23, failure reason no-response-from-peer Mon Dec 22 09:07:29 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.12, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 6, failure reason no-response-from-peer Mon Dec 22 09:07:01 2014 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.13, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 5, failure reason no-response-from-peer
L'esempio seguente mostra un errore di percorso e lo stesso nuovo contatore di riavvio dell'esempio precedente, ma una mezz'ora dopo mostra quando il peer ritorna di nuovo e il contatore è aumentato di un'ora da 15 a 16. Con il passare del tempo il conteggio aumenta per il peer:
Wed Jul 22 05:07:08 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.13, peer address 198.51.100.162, peer old restart counter 15, peer new restart counter 15, peer session count 34, failure reason no-response-from-peer
Wed Jul 22 05:38:00 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.13, peer address 198.51.100.162, peer restart counter 16, peer session count 1, clear reason sessions-update
[local]PGW> show egtpc peers
Wednesday July 22 10:04:30 UTC 2015
||||| Service Restart--------+ No. of
||||| ID Counter | restarts
||||| | | | Current Max
vvvvv v Peer Address v v sessions sessions
----- --- --------------------------------------- --- --- -----------
AESKS 5 198.51.100.162 16 1 1157 2186
[XGWin]PGW> egtpc test echo gtp-version 2 src-address 209.165.201.13 peer-address 198.51.100.162
Wednesday July 22 10:52:41 UTC 2015
EGTPC test echo
---------------
Peer: 198.51.100.162 Tx/Rx: 1/1 RTT(ms): 51 (COMPLETE) Recovery: 16 (0x10)
Nell'esempio viene mostrato un errore di percorso ripetuto causato dal riavvio del CPC per 3 peer SGSN specifici del GSN. L'output seguente mostra solo uno dei peer 209.165.200.225, ma tutti hanno lo stesso problema. L'esecuzione ripetuta di "show egtpc peers" e "show gtpc stat sgsn-address" mostra anche i valori alternati. l'opzione "show gtpc status" conferma che non vi sono problemi di connettività con le richieste e le risposte echo, che in questo caso vengono avviate solo dalla rete GSN (accettabile come descritto in precedenza). Un punto da sottolineare a questo proposito è che spesso esistono più dati che possono essere raccolti e che tutti confermano la stessa conclusione: si può scegliere di raccogliere i dati che sono i più conclusivi con il minimo sforzo.
show snmp trap history verbose | grep -E "209.165.201.31|209.165.200.225|209.165.200.246"
Mon Jun 22 22:20:51 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 129, peer new restart counter 132, peer session count 3, failure reason cpc-restart-counter-change
Mon Jun 22 22:20:51 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 132, peer session count 4, clear reason sessions-add
Mon Jun 22 22:20:55 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 132, peer new restart counter 129, peer session count 3, failure reason cpc-restart-counter-change
Mon Jun 22 22:20:55 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 129, peer session count 4, clear reason sessions-add
Mon Jun 22 22:20:58 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 129, peer new restart counter 132, peer session count 3, failure reason cpc-restart-counter-change
Mon Jun 22 22:20:58 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 132, peer session count 4, clear reason sessions-add
Mon Jun 22 22:21:02 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 132, peer new restart counter 129, peer session count 2, failure reason cpc-restart-counter-change
Mon Jun 22 22:21:02 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 129, peer session count 3, clear reason sessions-add
Mon Jun 22 22:21:03 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 129, peer new restart counter 132, peer session count 4, failure reason echo-rsp-restart-counter-change
Mon Jun 22 22:21:03 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 132, peer session count 5, clear reason sessions-add
Mon Jun 22 22:21:06 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 132, peer new restart counter 129, peer session count 2, failure reason cpc-restart-counter-change
Mon Jun 22 22:21:06 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 129, peer session count 3, clear reason sessions-add
[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
||||| Service Restart No. of
||||| ID Counter restarts
||||| | | | Current Max
vvvvv v Peer Address | | sessions sessions
| | |
v v v
Monday June 22 23:09:26 UTC 2015
AESKG 6 209.165.200.225 129 86339 2 57
[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
Monday June 22 23:09:28 UTC 2015
AESKG 6 209.165.200.225 129 86341 3 57
[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
Monday June 22 23:09:29 UTC 2015
AESKG 6 209.165.200.225 132 86342 7 57
[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
Monday June 22 23:09:30 UTC 2015
AESKG 6 209.165.200.225 132 86344 9 57
[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
Monday June 22 23:09:31 UTC 2015
AESKG 6 209.165.200.225 129 86345 11 57
[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
Monday June 22 23:09:32 UTC 2015
AESKG 6 209.165.200.225 129 86345 7 57
[XGWin]GGSN> show gtpc statistics sgsn-address 209.165.200.225
Monday June 22 23:07:36 UTC 2015
SGSN Address: 209.165.200.225 Status: Active
Total Restarts: 86287 Restart Counter: 129
Session Stats:
Total Current: 2 S6b Assume Positive: 0
...
Path Management Messages:
Echo Request RX: 0 Echo Response TX: 0
Echo Request TX: 22919 Echo Response RX: 22917
Se si analizzano gli altri peer della subnet, tutti indicano sempre un valore RC = 132, mentre i peer interrotti si alternano tra 129 e 132, come illustrato in precedenza, il che indica a questi peer SGSN che potrebbero passare il valore RC errato negli scenari interrotti:
Restart
Counter
AESKG 6 209.165.200.225 129 85115 8 57 <== IDNKG 6 209.165.200.226 132 21 0 3 AESKG 6 209.165.200.227 132 60 47 92 AESKG 6 209.165.200.228 132 53 24 59 AESKG 6 209.165.200.229 132 69 92 126 AESKG 6 209.165.200.232 132 66 21 30 AESKG 6 209.165.200.236 132 43 8 21 AESKG 6 209.165.200.238 132 49 18 32 AESKG 6 209.165.200.239 132 39 1 6 AENKG 6 209.165.200.240 132 17 1 5 AESKG 6 209.165.200.241 132 67 6 43 AESKG 6 209.165.200.242 132 56 22 29 AENKG 6 209.165.200.243 132 40 2 9 AENKG 6 209.165.200.246 129 17713 3 24 <== AESKG 6 209.165.200.247 132 64 29 45 AESKG 6 209.165.200.250 132 62 42 56
Un altro approccio a problemi di questo tipo consiste nel controllare altri GSN (o PGW per LTE) per verificare se hanno lo stesso problema con i peer SGSN apparentemente problematici, e in questo caso lo fanno anche. Per GSN3 la prima esecuzione del comando ha mostrato valori 132 per entrambi i peer, mentre un'altra esecuzione ha mostrato valori 129 per uno dei peer. Se si eseguono più sequenze (non mostrate qui per brevità), verranno visualizzati tutti i numeri GSN che rimbalzano nel tempo tra le due RC per tali peer:
[local]GGSN1> show egtpc peers | grep -E "209.165.200.246|209.165.200.225" Tuesday June 23 11:37:23 UTC 2015 AENKG 7 209.165.200.246 129 20147 1 29 AESKG 7 209.165.200.225 129 92853 2 51 [local]GGSN2> show egtpc peers | grep -E "209.165.200.246|209.165.200.225" Tuesday June 23 11:37:23 UTC 2015 AENKG 6 209.165.200.246 129 20450 4 17 AESKG 6 209.165.200.225 129 94021 3 54 [local]GGSN3> show egtpc peers | grep -E "209.165.200.246|209.165.200.225" Tuesday June 23 11:37:26 UTC 2015 AENKG 6 209.165.200.246 132 20211 1 39 AESKG 6 209.165.200.225 132 91996 3 59 [local]GGSN4> show egtpc peers | grep -E "209.165.200.246|209.165.200.225" Tuesday June 23 11:37:25 UTC 2015 AENKG 6 209.165.200.246 129 20309 1 24 AESKG 6 209.165.200.225 132 92694 9 57 [local]GGSN3> show egtpc peers | grep -E "209.165.200.246|209.165.200.225" Tuesday June 23 11:44:35 UTC 2015 AENKG 6 209.165.200.246 129 20242 3 39 AESKG 6 209.165.200.225 132 92224 1 59
Infine, per confermare il problema, viene visualizzato il messaggio SGSN modifica dell'opzione di menu RC, monitor subscriber by SGSN peer che mostra la modifica delle RC. Quando cambia, tutte le chiamate vengono disconnesse con errore di percorso come motivo di disconnessione. La schermata di un'acquisizione di pacchetto mostra anche questo:
[XGWin]GGSN> mon sub
Monday June 22 23:34:22 UTC 2015
y) By SGSN IP Address
IP Address: [209.165.200.225 ]
INBOUND>>>>> 23:35:32:688 Eventid:47000(3)
GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176)
TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10)
Sequence Number:: 0x1DB8 (7608)
...
IMSI: 300420078559902
Recovery: 0x81 (129)
...
***CONTROL*** 23:36:00:363 Eventid:10285
Disconnect Reason: path-failure
INBOUND>>>>> 23:36:48:414 Eventid:47000(3)
GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176)
TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10)
Sequence Number:: 0x3E2D (15917)
...
IMSI: 300420125984926
Recovery: 0x84 (132)
...
INBOUND>>>>> 23:37:28:337 Eventid:47000(3)
GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176)
TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10)
Sequence Number:: 0x3517 (13591)
...
IMSI: 300420094205377
Recovery: 0x84 (132)
...
Monday June 22 2015
INBOUND>>>>> 23:37:40:559 Eventid:47000(3)
GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176)
TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10)
Sequence Number:: 0x4E47 (20039)
...
IMSI: 300420194755472
Recovery: 0x81 (129)
...
***CONTROL*** 23:37:40:755 Eventid:10285
Disconnect Reason: path-failure
Nell'esempio viene mostrato un errore di percorso in cui il problema si trovava effettivamente nel percorso e non nel PGW o nel SGW. Di conseguenza, quando il tracciato viene ristabilito, la RC rimane la stessa. Nel secondo esempio tra pari, la chiarezza è il risultato della definizione di una richiesta echo:
Thu May 28 20:47:47 2015 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 198.51.100.196, peer old restart counter 5, peer new restart counter 5, peer session count 549697, failure reason no-response-from-peer Thu May 28 20:49:36 2015 Internal trap notification 1113 (EGTPCPathFailClear) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 198.51.100.196, peer restart counter 5, peer session count 1, clear reason sessions-add Thu May 28 20:49:06 2015 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 203.0.113.98, peer old restart counter 4, peer new restart counter 4, peer session count 3, failure reason no-response-from-peer Thu May 28 20:50:49 2015 Internal trap notification 1113 (EGTPCPathFailClear) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 203.0.113.98, peer restart counter 4, peer session count 0, clear reason echo-req
In questo esempio viene mostrata un'altra anomalia in cui, dopo che il vecchio contatore di riavvio è stato reimpostato su 2, in qualche modo si ritrova a 0 quando il percorso non funziona. Questo si rivelò essere un bug. La lezione qui è che se qualcosa sembra strano, deve essere segnalato.
Fri Mar 27 03:13:36 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer old restart counter 0, peer new restart counter 2, peer session count 1, failure reason create-sess-restart-counter-change Fri Mar 27 03:13:37 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer restart counter 0, peer session count 1, failure reason sessions-add Sat Mar 28 02:20:45 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer old restart counter 0, peer new restart counter 2, peer session count 1, failure reason create-sess-restart-counter-change Sat Mar 28 02:20:47 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer restart counter 0, peer session count 1, failure reason sessions-add Sat Mar 28 17:14:06 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer old restart counter 0, peer new restart counter 2, peer session count 1, failure reason create-sess-restart-counter-change Sat Mar 28 17:14:06 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer restart counter 0, peer session count 1, failure reason sessions-add
Feedback