Cisco Cisco ASR 5700 Fehlerbehebungsanleitung
different carrier. In fact with regards to Echo responses, a node is only obligated to respond to an
Echo request - whether it receives echos or not and with what frequency is not significant - it just
needs to send an echo response for each request, and to take action if the restart counter
received changes. Of course as already mentioned, IF it is also sending echo requests and
doesn't receive timely responses, it needs to take action for that scenario as well.
Echo request - whether it receives echos or not and with what frequency is not significant - it just
needs to send an echo response for each request, and to take action if the restart counter
received changes. Of course as already mentioned, IF it is also sending echo requests and
doesn't receive timely responses, it needs to take action for that scenario as well.
Note that path failure detection can also be done over the GTP-U (user plane) connection via
Echo, but ONLY via timeout, since there is no restart counter included in GTP-U messages like
there is for GTP-C as previously discussed. GTP-U may or may not be using the same path as by
control messages. If it is the same path, then GTP-U detection may not be as valuable since GTP-
C detection should be sufficient.
Echo, but ONLY via timeout, since there is no restart counter included in GTP-U messages like
there is for GTP-C as previously discussed. GTP-U may or may not be using the same path as by
control messages. If it is the same path, then GTP-U detection may not be as valuable since GTP-
C detection should be sufficient.
In summary, here are the ways that path failure detection can be done:
Restart Counter Change (via control msg Req/Rsp or Echo)
●
GTPC Echo Req Time out
●
GTPU Echo Req Time out
●
Control Req Message Time-out (usually not configured)
●
Relevant Commands
In order to troubleshoot any kind of path issues, familiarize with the following commands.
Following is an explanation of the relevant details of each.
Following is an explanation of the relevant details of each.
show [egtpc-service | gtpu-service] all
●
show egtpc peers [egtp-service <service>]
●
egtpc test echo gtp-version {1 | 2} src-address <service address> peer-address <peer
address>
address>
●
show egtpc statistics [[[ (sgw-address | pgw-address | mme-address) <address>] [demux-
only]] [debug-only] [verbose] | path-failure-reasons]
only]] [debug-only] [verbose] | path-failure-reasons]
●
show gtpu statistics [peer-address <peer>]
●
show gtpc statistics [ggsn-service <service>] [smgr-instance <instance>]
●
show demux-mgr statistics <egtpinmgr | egtpegmgr | gtpumgr> all (SGW-egress |
GGSN/ PGW,/SGW ingress | GTPU)
GGSN/ PGW,/SGW ingress | GTPU)
●
EGTPCPathFail[Clear], EGTPUPathFail[Clear] SNMP traps
●
show session disconnect-reasons - gtpc-path-failure, gtpu-path-failure, path-failure
●
Other commands for counting subscribers related to GTP:
show sub [summary] ggsn-service <service>
show sub [summary] gtpu-service <service>
show egtpc sessions [egtp-service <service>]
The basic command to check the status and configuration of all EGTP services is "show egtpc-
service". Most of the output should be what is already known via the configuration, as well as the
status should be STARTED. The unique piece of information gleaned is the "Restart Counter"
which cannot be found anywhere else. Related command "show gtpu-service all" returns
configurables for the GTPU service(s) that are associated with the EGTPC services.
service". Most of the output should be what is already known via the configuration, as well as the
status should be STARTED. The unique piece of information gleaned is the "Restart Counter"
which cannot be found anywhere else. Related command "show gtpu-service all" returns
configurables for the GTPU service(s) that are associated with the EGTPC services.
"show egtpc peers" is very useful in identifying all of the peers, including statuses, restart
counters, and current/max subscriber counts.
counters, and current/max subscriber counts.
Note that this command covers both SGW and SGSN peers, whereas in the past there was a
separate command for SGSN/GGSN.
separate command for SGSN/GGSN.
●
Since this command includes all peer types, the peer type can be filtered on via the service
name (Even though the keyword egtpc-service deceptively also takes a GGSN service name).
name (Even though the keyword egtpc-service deceptively also takes a GGSN service name).
●
If there are no subscribers with the peer, then the status is Inactive and GTPC Echo disabled.
●