Subject: Re: (usr-tc) To many drops after connect

From: Steve Valiunas <[email-masked]>
Date: Fri, 21 Jan 2000 20:03:38 +0000

This might not be the case in your situation since you say the same user
dials many times in a row,  but just because a call has less than a minute of
connect time doesn't necessarily mean that it is a failed call.  If your
customers are set to automatically connect/check Email/drop as with AOL
FlashSessions, CC-Mail, LotusNotes etc., then this is normal.   A misconfigured
dial-on-demand  connection might account for it as well, as might a user not
satisfied with 44K and trying for that 53K connection.   If there was a large
jump in the percentage of short calls after changing codes that might be another
story though.  You might want to also look at some of your other accounting
data, such as  Do these session stops have normal disconnect reasons?  Did the
user get assigned a valid IP?  Was any data passed on the sessions?

Steve

"The NOC \(COX Internet\)" <[email-masked]> on 01/21/2000 11:04:53 AM

Please respond to [email-masked]

Sent by:  "The NOC \(COX Internet\)" <[email-masked]>

To:   [email-masked]
cc:    (Steve Valiunas/MW/US/3Com)
Subject:  Re: (usr-tc) To many drops after connect

Paul,

How did you find out this information on Total calls lost?  Is it possible
to find this out on the old Total Control equipment also?

Bryan
NOC Technician
COX Internet

----- Original Message -----
From: "Paul Farber" <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 21, 2000 9:40 AM
Subject: (usr-tc) To many drops after connect

> hello all
>
> still fighting with TC to try and get decent connection performance out of
> the thing.
>
> flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some
> frighting stats:
>
> Total Calls (from radius): 66212
> Calls of < 1 minute in length: 9266
>
> Thats a 14% drop rate! It seems to hit some people in bulk... it they dial
> in 5-10 times and then they just give up.
>
> I tried to narrow it down to a specific slot/channel but thier dosen't
> seem to be a pattern.
>
> Anyone else seeing similiar results???  All circuits are PRI.
>
>
>
> Paul Farber
> Farber Technology
> [email-masked]
> Ph  570-628-5303
> Fax 570-628-5545
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[email-masked]"
>  with "unsubscribe usr-tc" in the body of the message.
>  For information on digests or retrieving files and old messages send
>  "help" to the same address.  Do not use quotes in your message.
>

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Alan Martin <[email-masked]>
Date: Fri, 21 Jan 2000 20:12:37 +0000

Every once in awhile sanity reigns.

-

---

From: Brian <[email-masked]>
Date: Fri, 21 Jan 2000 20:29:49 +0000

You all using 3Com Total Control NAS's over there at Nortel Networks? :)

Brian

>  "help" to the same address.  Do not use quotes in your message.

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-

---

From: Paul Farber <[email-masked]>
Date: Fri, 21 Jan 2000 22:24:09 +0000

Because the call up and complain.  I know what you are saying.. it might
be the software... but it's been happening far to often to to many people.

Paul Farber
Farber Technology
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: Scot Desort <[email-masked]>
Date: Sat, 22 Jan 2000 03:51:27 +0000

Paul,

Have you tried 2.0.51 on the DSP's? I know it was really only intended for
.54/.55 rev cards, but there are some fixes for Rockwell in there. Might be
worth a shot to load it on some cards and see if it makes any difference.

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Paul Farber
>Sent: Friday, January 21, 2000 3:28 PM

-

---

From: Brian <[email-masked]>
Date: Sat, 22 Jan 2000 03:58:26 +0000

is 2.0.51 really only for .54/.55?  I mean reading the pdf, I see a fix
for .54/.55 cards, but the rest of the issues looked like they applied to
any DSP.

Brian

-

---

From: Scot Desort <[email-masked]>
Date: Sat, 22 Jan 2000 04:21:13 +0000

Well, it was released in _response_ to the .54/.55 problem, but it obviously
corrects other issues that apply to any DSP rev, as I stated. I just flashed
my last 2.0.81 card to 2.0.51. We'll see what happens. The last card was a
.54 card that I got on a trade-up from 3COM. It definitely experienced some
weird stuff on 2.0.81.

>[mailto:[email-masked]]On Behalf Of Brian
>Sent: Friday, January 21, 2000 8:55 PM
>Subject: RE: (usr-tc) To many drops after connect
>
>
>

-

---

From: Mike Andrews <[email-masked]>
Date: Sat, 22 Jan 2000 04:37:55 +0000

2.0.51 runs on cards other than .54/.55; it's what we run here...

Mike Andrews (MA12) * [email-masked] * http://www.bit0.com/
VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville
"Don't sweat the petty things, and don't pet the sweaty things."

-

---

From: Terry Kennedy <[email-masked]>
Date: Sun, 23 Jan 2000 00:08:27 +0000

I'l chime in here. Just recently we put together the stats to confirm the
same drop rates, at the same time we implemented a survey to our customers.
Guess what? they get dropped all the time. Different ones at different times
in differing amounts. This by and large the single greatest complaint
against this ISP. A lot of these same people have more than one one accont
and are glad to point out the it doesn't happen with their "other" ISP.
These are people who connect, auth and pass data. I haven't had the chance
yet to together stats on the disconnect reason tied directly to calls, I can
tell you that I see a lot of v42DisconnectCmd. I am thinking of disabling
it.

4.2.32-1
2.0.51
6.2.17

-----Original Message-----
Sent: Friday, January 21, 2000 12:28 PM

Paul Farber
Farber Technology
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

-

---

From: Greg Coffey <[email-masked]>
Date: Sun, 23 Jan 2000 00:33:46 +0000

We're running the same software except that I have 6.1.17 on our NMC.  I've 
had numerous recent complaints about disconnects and having to dial 5-6 
times to connect.  Actually, the complaints have existed since we upgraded 
to the Hiperarc and DSP's.  There have been more just over the last week or 
so it seems.  We're running channelized T1's from USWorst.  I did change 
the db level to 13 but that was several weeks ago.  I'm not sure if it 
helped or not.

>  "help" to the same address.  Do not use quotes in your message.

Thanks, Greg Coffey                     <[email-masked]>
Visionary Communications V 307-234-5443 F 307-234-5446
100 N. Center #100, Casper, WY  82601        www.vcn.com

-

---

From: Brian Elfert <[email-masked]>
Date: Sun, 23 Jan 2000 01:19:43 +0000

> against this ISP. A lot of these same people have more than one one accont

I always question why some many people claim to have multiple accounts.

> and are glad to point out the it doesn't happen with their "other" ISP.

Have you checked what type of modems these other ISPs use?

> tell you that I see a lot of v42DisconnectCmd. I am thinking of disabling

This disconnect reason is not generally a problem.  This is the way most
modems request a normal disconnect.  

Brian

-

---

From: Paul Farber <[email-masked]>
Date: Sun, 23 Jan 2000 01:25:34 +0000

I just went DOWN to 2.0.19 from 2.0.80 (or back or however the hell 3Com
came up with the ass backward numbering scheme) to try and keep users
connected.

CONNECTING is not a problem.... saying CONNECTED is.

I'm trying to duplicate the drops with my laptops and support dial ups.
After the downgrade to the previous 2.0.19 code it seems to be a bit
better.

Paul Farber
Farber Technology
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: Mike Andrews <[email-masked]>
Date: Sun, 23 Jan 2000 03:13:29 +0000

> tell you that I see a lot of v42DisconnectCmd. I am thinking of disabling

Disable v.42?  Uh...  not a good idea.  v.42bis maybe, if your DSP cards
have a dead CPU (like one of mine appears to), but not v.42.

To really get to the bottom of the disconnect stuff, you have to look at
BOTH disconnect reasons -- one logged by the ARC, one logged by the
modems.  You have to look at the two together to see why the connection
dropped...  otherwise you'll NEVER be able to figure out what to blame on
the customer, or the customer's modem, or 3Com's code, or your own setup.

Here's an abridged version of something I wrote for our support people
that might help.  If anyone's got any corrections I'd like to hear 'em...

----------------

ARC disconnect reasons:

User-Request:
  NORMAL disconnect -- the user's computer specifically requested to shut
the PPP session down gracefully.  If the user did not, maybe Windows did
without their consent.  Check the "idle timeout" setting, because on many
versions of Windows 95/98 it's broken and disconnects non-idle sessions.
Also Outlook Express 5 seems to default to "hang up after sending and
receiving mail" for some dumb reason.  There are other reasons Windows can
hang up when it shouldn't, but I won't get into the rest of these here --
the point is the Total Control thinks it's a clean disconnect so it's not
at the ISP end generally.

Lost-Carrier:
  Customer's modem hung up unexpectedly, without requesting a clean
shutdown of the PPP session.  See the modem disconnect reason (below) for
why.

Idle-Timeout:
  Self explanatory, I hope.

Session-Timeout:
  Also self explanatory, I hope.

PAP-Auth-Failure:
  They connected and started PPP negotiation but never entered a correct
username/password.

CHAP-Auth-Failure:
  If you are like us and don't support CHAP, tell the user to turn off
"require encrypted password" in their Dial-Up Networking settings.

Admin-Reboot:
  You rebooted the ARC.

Admin-Reset:
  You rebooted a modem card.

NAS-Request:
  You typed "disconnect user jimbob".

NAS-Error:
  PPP negotiation failed.  This can be lots of things...  user trying to
use a specific IP address instead of the one you assign them, screwed up
TCP/IP stack, screwed up dial-up networking, connecting without error
correction, trying to use SLIP...

Radius-Timeout:
  The ARC can't talk to your Radius server.

User-Error:
  Not sure.

-----------------

Modem disconnect reasons:

v.42 Normal Disconnect Command Received
MNP Normal Link Disconnect Command Received
Gateway Disconnect Command Received
Normal User Call Clearing
DTR Dropped
   These are all NORMAL.  The first two indicate the customer's modem
requested a disconnect (usually DTR was dropped to their modem), the
others indicate the ARC specifically dropped DTR to your modem card.
Almost always this is paired with "User-Request" from the ARC, and the
same gotchas apply if the user insists they did not disconnect.

Carrier Loss
DS0 Teardown
v.32/GSTN cleardown
   These mean the user's modem hung up abruptly.  If this is paired with
"User-Request" from the ARC, then it's normal.  (Sometimes the line drops
before the v.42 disconnect command arrives, and that's normal.)  
Otherwise it could be almost anything: Call Waiting, computer got turned
off/rebooted, unplugged the phone, or sometimes a cheap Winmodem will do
this too.

Retransmit limit
Unable to Retrain
v.42 SABME Timeout
   These mean there was too much noise on the line to successfully send
data -- it kept retrying and failed, so it gave up and hung up.  Again,
Call Waiting or phone line problems can cause this.

Protocol Error Event
   95% of the time this is a Rockwell HCF modem.  Send the user to
http://808hi.com/56k/rockhcf.htm and have them download newer drivers.

DSP Reboot
   Obvious.

v.42 Invalid Codeword
v.42 Invalid Command
v.42 String Too Long/rootless tree
Link Security Abort
   This is a v.42bis compression problem.  Turn off v.42bis hardware
compression, or have the user do it.  According to 3Com, this means you've
got a blown CPU on your DSP card, so if you see this on either the first
12 or last 12 modems of a DSP card, get it replaced -- but until you can
do that, disabling compression will solve it.

Packet bus generic error
Packet bus received LS while link up
   Something got screwed up between the DSP and the ARC.  We don't see
this much but it is a 3Com-related problem.

-

---

From: "Lon R. Stockton, Jr." <[email-masked]>
Date: Sun, 23 Jan 2000 03:44:28 +0000

On Sat, 22 Jan 2000, Mike Andrews wrote:

> modems.

Is there a way to get the hub to send both reasons to the radius
accounting server as part of the acct-stop message?

If not, I'm going to have to reveal my lack of clue by asking how to
get ahold of these reasons (aside from using prescience to determine
when the call is going to drop and then doing rapid-fire snmp queries.
*grin*)

This would be nice...the current choices of 'lost-carrier' and
'user-disconnect' that I get in my radius are about worthless.

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sun, 23 Jan 2000 04:35:39 +0000

Thus spake Lon R. Stockton, Jr.
>> BOTH disconnect reasons -- one logged by the ARC, one logged by the

Good list Mike...thanks!

>accounting server as part of the acct-stop message?

No...basically because the Arc is sending the acct-stop message, and it
only has the Arc disconnect reason...the modem disconnect reason is only
accesible via a modem event.  The modem will send the event to the NMC,
and the NMC can generate either one or both of an SNMP trap, or a RADIUS
accounting request.  Note, this is a *seperate* RADIUS accounting
request from the Arc's.  It is configured on the NMC, and is configured
as "enablelog" rather than "enabletrap".  You'll also need to set up the
log server on the NMC.  You can send these RADIUS accounting logs to
your main RADIUS server, but I tend to send them to a seperate one to
keep the information seperate, and easier to handle (if you enable logs
on your modems for even a small number of events you're going to have
some rather large log files)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-