>
>Network wide for us, yesterday:
>
>
>
>0% 1 User Error - LAPM negotiation timeout
>0% 2 Service Unavailable - Failed to detect V.42 remo
>0% 9 Host Request
>0% 11 User Request - Normal Modem Disconnect
>0% 19 User Request - PPP Term Ack
>0% 30 Port Error - Exceeded LAPM retransmission limit
>0% 44 Admin Reset
>0% 95 User Request - Admin Quit
>0% 178 User Error - PPP NCP Active to Request
>1% 411 Session Timeout
>1% 466
>2% 702 Lost Carrier
>4% 1763 User Request - Normal LAPM Disconnect
>6% 2652 Idle Timeout
>17% 7173 User Request - Call Circuit Closed
>69% 29537 User Request - PPP Term Req
Oh statistical joy! Finally, some baselines to compare how we are doing!
One thing that john@netrom.com correctly pointed out, that these statistics
include failed calls that never got completed. Although this skews the
results somewhat, it does provide an interesting insight. Assuming that
your hunt pool is not one digit off the local pizza parlor, the difference
in the disconnect rates between *all* attempted and completed calls shows
that some modems cannot connect at all on the first try. When I ran my
script against my Cistron Radius output, I saw a fairly nice difference.
For example, looking at the syslog disconnect reasons on one particular PM3
I get
normal 83.24% 1828/2196
Lost Carrier 8.70% 191/2196
User Request - Call Circuit Closed 7.38% 162/2196
User Error - PPP NCP Active to Request 0.55% 12/2196
User Error - LAPM negotiation timeout 0.05% 1/2196
Service Unavailable - PPP No Protocol 0.05% 1/2196
NAS Request - PPP Maximum Retransmissions 0.05% 1/2196
Looking at the completed calls disconnect summary (based on RADIUS output),
I get
normal 91.26% 6846/7502
"User Request - Call Circuit Closed" 7.29% 547/7502
"Lost Carrier" 0.75% 56/7502
"User Error - PPP NCP Active to Request" 0.65% 49/7502
"User Error - LAPM negotiation timeout" 0.04% 3/7502
"Service Unavailable - Failed to detect V.42 remote" 0.01% 1/7502
So, it would seem once you get connected, ~92% make a 'normal'
disconection, which is... I dont know. Unfortunately, I only started using
Cistron RADIUS a couple of months ago, and I dont have any 3.8 detail files
to compare to. However, the syslog TE info, was about the same. On over
100,000 records both before and afterwards, there was about a 2% difference
in disconnects, primarily Call Circut Closed errors. Its difficult to
clearly draw conclusions out of this, because the 3.8.2 release coincided
with xmas where a lot of users no doubt got v.90 modems, and no doubt had
old crappy firmware... (We *STILL* see people buy USR Winmodems with Feb
1998 (98, not 99) firware revisions!)...
Now, what would REALLY be nice is to compare similar statistics to other
vendor's boxes. A friendly competitor of ours in another city was kind
enough to give me access to his RADIUS logs on a
Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.7.24
I was sadly disappointed to see farily limited disconnection info.
However, based on less than a days logs, here is what I have found so far
on looking at the stats on disconnects for completed calls.
# Reason
7 Acct-Terminate-Cause = Session-Timeout
34 Acct-Terminate-Cause = Lost-Carrier
327 Acct-Terminate-Cause = User-Request
... Thats almost 10%. (These are PPP calls only... they dont support slip)
Also, I have no idea how accurate / complete the "User-Request" reason is..
After all, the regular Livingston "User Request" is quite misleading,
because the dreaded "Call Circut Closed" gets lumped in there as well. As
to the version of that TC, I have no idea if that is current or not. Does
anyone have a Cisco that they could post results from? How about some of
the Ascend gear ? I will wait another couple of days until the TC generates
a few more records...
---Mike
Mike Tancsa (mdtancsa@sentex.net)
Sentex Communications Corp,
Waterloo, Ontario, Canada
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>