Cisco Cisco ASR 5500 Guía Para Resolver Problemas
Commands
monitor subscriber (mon sub)
This is probably one of the most well known commands on the platform and the most amount of
time is spent here documenting and explaining its usage. Depending on the settings chosen, it has
the potential to display all of a particular subscriber’s control/signaling and payload data for all
interfaces, services, protocols, etc. Some considerations in running the command and interpreting
output include the following:
time is spent here documenting and explaining its usage. Depending on the settings chosen, it has
the potential to display all of a particular subscriber’s control/signaling and payload data for all
interfaces, services, protocols, etc. Some considerations in running the command and interpreting
output include the following:
Based on investigation up to a point in time, if a problem is suspected but a particular
subscriber having an issue is not yet known, then attempting capture by “next-call”, possibly
trying many times, may result in capturing a failure if the issue is frequent enough. If the
problem is rare, this approach may not be feasible.
subscriber having an issue is not yet known, then attempting capture by “next-call”, possibly
trying many times, may result in capturing a failure if the issue is frequent enough. If the
problem is rare, this approach may not be feasible.
●
For known call types (Closed RP, Open RP, Evolution Data Optimized (EVDO), 1X-EVDO,
Layer 2 Tunnelling Protocol (L2TP), Home Agent (HA), Long Term Evolution (LTE), etc.),
especially those that are a low percentage of the overall volume, or those where the peer
Packet Control Function (PCF) or peer L2TP Access Concentrator (LAC) is where the
problem is suspected to be, then the monitor subscriber menu option allows qualifying the
next call by such criteria, which will increase hit rate significantly. If all calls on the node are of
the same type, then this approach adds no value (except for the peer address versions just
mentioned) since doing so doesn't narrow down the possibilities.
Layer 2 Tunnelling Protocol (L2TP), Home Agent (HA), Long Term Evolution (LTE), etc.),
especially those that are a low percentage of the overall volume, or those where the peer
Packet Control Function (PCF) or peer L2TP Access Concentrator (LAC) is where the
problem is suspected to be, then the monitor subscriber menu option allows qualifying the
next call by such criteria, which will increase hit rate significantly. If all calls on the node are of
the same type, then this approach adds no value (except for the peer address versions just
mentioned) since doing so doesn't narrow down the possibilities.
●
There are various levels of verbosity 1 to 5. Do not turn on higher levels of verbosity if not
needed, as it makes reading the trace (quickly) more difficult. Usually increasing to verbosity 2
(default = 1) is sufficient.
needed, as it makes reading the trace (quickly) more difficult. Usually increasing to verbosity 2
(default = 1) is sufficient.
●
By default, most, but not all, of the protocols that would be interesting to view are turned ON
by default
by default
●
Besides the actual packet data, sometimes special CONTROL messages are displayed that
may explain what action is being taken under the covers – this information is often useful. This
includes the call statistics displayed at the end of a call. Here is an example control message:
may explain what action is being taken under the covers – this information is often useful. This
includes the call statistics displayed at the end of a call. Here is an example control message:
●
If Enhanced Charging Service (ECS) is configured on the gateway nodes, then turning on
option 34 (CSS Data) allows for viewing all packets being sent to and from the ECS module,
which can be helpful for troubleshooting packet drops and Network Address Translation
(NAT). For example here is a subscriber Internet Control Message Protocol (ICMP) packet
that is NAT'd by ECS from private IP 10.251.88.68 to public IP 209.165.201.1
option 34 (CSS Data) allows for viewing all packets being sent to and from the ECS module,
which can be helpful for troubleshooting packet drops and Network Address Translation
(NAT). For example here is a subscriber Internet Control Message Protocol (ICMP) packet
that is NAT'd by ECS from private IP 10.251.88.68 to public IP 209.165.201.1
●
If it is not obvious from the trace why the ASR is exhibiting a particular behavior, then viewing
the internal processing for the subscriber might have value (interpreting such output which
includes state machine info and the like is difficult but can be done by engineering), and so
logging monitor or logging trace commands may be considered (discussed later).
the internal processing for the subscriber might have value (interpreting such output which
includes state machine info and the like is difficult but can be done by engineering), and so
logging monitor or logging trace commands may be considered (discussed later).
●
The timestamps displayed are fairly accurate, but, because various facilities are all writing to
the screen real-time, it cannot be authoritatively concluded that the order of packets displayed
is the actual order that the packets are being processed in, but it will be close.
the screen real-time, it cannot be authoritatively concluded that the order of packets displayed
is the actual order that the packets are being processed in, but it will be close.
●
On the ingress side for Packet Data Switching Network (PDSN) or High Rate Packet Data
Serving Gateway (HSGW) nodes, in order to view all of the A11 messaging (if that is
Serving Gateway (HSGW) nodes, in order to view all of the A11 messaging (if that is
●