[cisco-nas] Hst No Carr issue

[Aaron Leonard]

> Hi List

 

> We have deployed AS54K, IOS 12.3(4)T8, Nextport version 0.8.12

 

> I found the " Hst No Carr" number is too big (1657/11144 = 14.9%).

> We have more than half of calls (1/2) from users, using V90/V44. I have
> implemented the V.44 Nextport modem issue with V.44 Tx/Rx Codewords : 1024.

 

> Anyone has any idea about this numbers?

What makes you think that this "Hst No Carr" value is too big?
The NextPort "Hst No Carr" is basically a "network indicated
disconnect" or in other words, a circuit disconnect received
from the PSTN.  You can see a discussion of this disconnect type
at http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094ebb.shtml#table7
(0x1F06), also see the appended writeup I did on understanding
modem disconnects for a customer.

One thing I should add however to this is that there is ANOTHER
reason why a "good" voluntary client-side initiated disconnect
should show as a "network indicated disconnect" - and this is 
that some client modems will, even though they have negotiated
LAPM or MNP4, simply go on hook when they receive a hangup from
their DTE, rather than send a LAPM DISC/MNP4 LD.

The real question you should ask is: are my clients happy or sad with
the way that their modem calls are terminating?  If happy, then don't
worry.  If sad, then investigate why their calls are terminating.

Cheers,

Aaron

---

Understanding RADIUS disconnect records from Cisco NASes
  
Background:
 
Cisco Network Access Servers (NASes - e.g. the AS5300, AS5800, AS5400)
will report various information via RADIUS when a call disconnects.
Frequently a customer will be interested in understanding the reason
for the disconnects, and in classifying the call terminations into
"good" (user-initiated) ones vs. "bad" (modem link failures).
 
The main field in which the RADIUS disconnect reason is attribute
195, the Disconnect-Cause.  The causes reported by IOS are given
in Table 35 in the IOS 12.2 "RADIUS Vendor-Specific Attributes
(VSA)" documentation (http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fappendx/fradattr/scfrdat3.htm#xtocid95681).
 
In the case where IOS is informed of a disconnection due
to a hangup from the server-side modem (i.e. loss of Carrier
Detect, which IOS calls "DSR"), this will be reported as
Disconnect-Cause = 11, "Lost-Carrier".)
 
Note that it is not necessarily the case that, when a PPP
user disconnects "normally", that this will be reflected
in a Disconnect-Cause = 45, "PPP-Remote-Terminate".  For
one thing, not all PPP clients will transmit the PPP LCP TERMREQ
frame upon an orderly disconnect.  For another, even if
IOS's PPP stack does receive the PPP LCP TERMREQ, it is by
no means guaranteed that this will be processed before the
modem layer hangs up.  It should be considered to be
indeterminate whether a PPP client initiated hangup will
be logged as a cause 11 or a cause 45.
 
Note that this indeterminacy between cause 11 and 45 is
inherent in IOS and is not a function of the platform
(AS5300 vs. AS5400) nor of the modem type (MICA vs. NextPort
vs. other.)  The DSR drop indication (cause 11) will be driven
by the phase of the TTY signal poller (which runs once a second).
The LCP TERMREQ indicator (cause 45) will be driven by the
cleanup processing that IOS requires for the call, which in turn
will depend upon IOS version, configuration, load, processor
speed, etc.
 
Note well that, in IOS' interpretation of this cause code 11,
the hangup may occur before or after the call has successfully
negotiated PPP/IPCP.  And it may indicate a "good" or "bad" disconnect.
 
To tell, given a RADIUS STOP-accounting record, whether a code
11 disconnect was before or after PPP/IPCP had successfully
completed negotiation, you can use the following methods:
 
a) Examine the contents of the 196 ("Connect-Progress") attribute.
In order to use this field for PPP calls, you must be running
IOS 12.2(2) or above (DDTS CSCdr90345.)  This will support, for
PPP connections, the following Connect-Progress field values:
 
60      LAN Session up (i.e. IPCP negotiations complete)
65      LCP Open (i.e. PPP negotiations beginning)
67      IPCP Open (i.e. IPCP negotiations beginning)
 
Therefore, for PPP/IPCP calls, if attribute 196=60, then you can
infer that the disconnect happened after the call had successfully
completed.
 
In current IOS 12.2XB/12.2T (CSCdr63648), additional attribute 196
field values are provided: 10, 31 and 32 (for states that precede
the advent of LCP Open.)
 
b) Examine the contents of Framed-IP-Address (attribute 8).  If a valid
IP address is found, then you can infer that IPCP had successfully
negotiated.  This attribute is provided with RADIUS accounting records
in all IOS versions.
 
For L2x-forwarded VPN calls, the Framed-IP-Address contents will
not be available to determine that the call succeeded.  In my
research, I was unable to tell what Connect-Progress value will
be provided by the LAC for for a successful call; further research/
experimentation will be required to figure that out.
 
Now: to tell whether a cause 11 disconnect is "good" or "bad"
(for non-VPN calls), you can follow the following heuristic:
 
- if the disconnect occurred before IPCP was complete (attr 196=60
  or Framed-IP-Address valid), then you can infer that the disconnect
  was "bad".
 
- if the disconnect occurred after IPCP completed, then a cause 11
  disconnect may or may not be bad.  To further analyze the disconnect,
  you will want to examine the modem disconnect reason.
 
The modem disconnect reason is not provided to RADIUS accounting;
you can access it via "modem call-record terse", which reports to
SYSLOG, or via the Call Tracker feature (which reports to SYSLOG
and/or SNMP.)  An explanation of the MICA modem disconnect reasons
is given in the CCO Tech Note "MICA Modem States and Disconnect Reasons"
(http://www.cisco.com/warp/public/76/mica-states-drs.html.)
 
Examples of GOOD modem disconnect reasons include (here the disconnect
codes are given with the type code masked off - e.g. an 0x8220 disconnect
would be given as 0x220):
 
0x220 Received LAPM DISC frame - graceful LAPM disconnect
0x5FF Received MNP LD frame - graceful MNP disconnect
 
Other disconnects may or may not be "bad".  For example, a
 
0x1F06 Network indicated disconnect
 
which indicates that the NAS received a disconnect message from
the PSTN's signaling layer, may be a "good" disconnect if an
error control protocol was not negotiated on the modem link,
or if the end user's preferred method of call termination is to
unplug the phone cable or power off the modem.  However, if
the call did negotiate LAPM, and if the user did not abruptly
disconnect the transmission path, then an 0x1F06 disconnect is
PROBABLY "bad".  (Similarly for a DSP-layer lost carrier
disconnect, 0x100.)