Cisco Cisco ASR 5000 Guide De Dépannage
Contents
Introduction
Background
Relevant Commands
Path Failure detection
Various Examples of path fail traps and explanations
Related Cisco Support Community Discussions
Introduction
This article covers understanding and troubleshooting Evolved General Packet Radio Service
Tunneling Protocol for Control Plane (EGTPC) / GTPC (3rd Generation Partnership Project
Technical Specification
Tunneling Protocol for Control Plane (EGTPC) / GTPC (3rd Generation Partnership Project
Technical Specification
), GPRS Tunnelling protocol User Plane (GTPv1-U) (3GPP TS
which revolve around such concepts as restart counters, path failures detection, and echo
requests/responses. It includes a list of relevant commands and what to look for in the output,
along with explanation of related configurables. This is certainly an area for which a lot of
questions are raised. Note that troubleshooting specific call control issues is in itself a very
extensive area of interest, but this article only mentions how to capture statistics for call control -
anything beyond that (i.e. call setup issues) is not covered. Really this article focuses mainly on
troubleshooting and verifying the peer connections, without which there would be no call control.
While written for operators, designers / implementers could also benefit from the content here.
requests/responses. It includes a list of relevant commands and what to look for in the output,
along with explanation of related configurables. This is certainly an area for which a lot of
questions are raised. Note that troubleshooting specific call control issues is in itself a very
extensive area of interest, but this article only mentions how to capture statistics for call control -
anything beyond that (i.e. call setup issues) is not covered. Really this article focuses mainly on
troubleshooting and verifying the peer connections, without which there would be no call control.
While written for operators, designers / implementers could also benefit from the content here.
Examples all use fake (changed) IP addresses from a real operator's network.
Background
Each side of a GTP connection (one of 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 (GGSN)) maintains a restart counter that
is designed to alert the peer if the originating node has restarted so that that peer can take the
appropriate action. While a node can use a unique counter for each peer it talks to, the design
tends to be to use the SAME counter for all the peers, since when the node restarts, the counter
needs to be incremented for all peers, and so tracking a separate value on a peer basis serves no
extra benefit since they all need to increase by one anyway. In fact using the same restart counter
for all peers is helpful in troubleshooting a large network where all the peers can be checked to
make sure that the restart counters received have the same (single) value for the node those
peers are talking to.
Gateway (PGW)), S11 ( Multimedia Management Entity (MME) - SGW), S4 ( Serving GPRS
Service Node (SGSN) - Gateway GPRS Service Node (GGSN)) maintains a restart counter that
is designed to alert the peer if the originating node has restarted so that that peer can take the
appropriate action. While a node can use a unique counter for each peer it talks to, the design
tends to be to use the SAME counter for all the peers, since when the node restarts, the counter
needs to be incremented for all peers, and so tracking a separate value on a peer basis serves no
extra benefit since they all need to increase by one anyway. In fact using the same restart counter
for all peers is helpful in troubleshooting a large network where all the peers can be checked to
make sure that the restart counters received have the same (single) value for the node those
peers are talking to.
The restart counter CAN be included in all types of control messages, while the restart counter
MUST be included in all echo requests and responses. As soon as a restart counter change
occurs on a node, the various peers are informed about it via the next control messages sent to
the respective peers. When a restart occurs, per specification, the receiving side has the option of
temporarily maintaining the calls it has for a short while or in dropping them, the latter which is
typically what is the configured behavior.
MUST be included in all echo requests and responses. As soon as a restart counter change
occurs on a node, the various peers are informed about it via the next control messages sent to
the respective peers. When a restart occurs, per specification, the receiving side has the option of
temporarily maintaining the calls it has for a short while or in dropping them, the latter which is
typically what is the configured behavior.
In the case of using echo requests, the method is to send the messages on a configured interval,
and if no response is received after a configured number of retries (each after a configured
timeout), the path is considered to be down and the appropriate action taken. Configuration allows
for echos to be optionally sent, and this would apply to the peer as well, whose approach doesn't
necessarily have to be the same, especially when the peer could be from a different vendor and/or
and if no response is received after a configured number of retries (each after a configured
timeout), the path is considered to be down and the appropriate action taken. Configuration allows
for echos to be optionally sent, and this would apply to the peer as well, whose approach doesn't
necessarily have to be the same, especially when the peer could be from a different vendor and/or