Subject: (usr-tc) TRANSMISSION PROBLEMS

From: [email-masked]
Date: Wed, 01 Dec 1999 15:19:50 +0000

We have a user who has been having problems with their dialup connection
from the day they started with us.  They are complaining about the typical
"stalling problem" and their application (a stock tracking application)
dying which is causing them to have to do a reboot on Win95.  To make
matters worse they have a Lucent Winmodem.  I have sent them the latest
software but it doesn't seem to help.  They are getting a solid 28.8kbs
connection. I looked at theor modem stats in TCM, when they were
connected, and the analog stats look fine.  However, when I look at Call
Stats I am seeing some strange numbers:

Number of characters sent        2664304
Numebr of charcters received      398400
Number of blocks sent              37255
Number of blocks received          19320
Numebr of retrains requested           0
Number of characters lost              0
Link block errors                   1160
Number of link protocol timeouts     265
Number of NAKS sent                 1919
Gain recalculation count               0

Do these numbers seem normal ?  I checked other calls and the results
of my observations are unconclusive.  I am open to suggestions.  Of
course with their other ISP (where they lived previously) they didn't
have this problem.

Jeff Binkley
ASA Network Computing

-
 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: Mike Andrews <[email-masked]>
Date: Wed, 01 Dec 1999 19:42:32 +0000

> Number of link protocol timeouts     265

These last three are kinda high, relative to blocks sent/received.

> course with their other ISP (where they lived previously) they didn't

I think the key here is "where they lived previously"...  I bet if they
called their other ISP from their current location they might run into the
same problems.

Looks like a line problem.  Though maybe if they connected at 26400
instead of 28800 it'd clear things up...  you might have them try that.
You can find the init string for that on http://808hi.com/56k somewhere.

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
"With sufficient thrust, pigs fly just fine." -- RFC 1925

-

---

From: [email-masked]
Date: Wed, 09 Feb 2000 16:14:24 +0000

I'm having a problem with my 486 NMCs that seems to be getting
progressively worse. They will be humming along in TCM just
fine, then suddenly decide to stop doing SNMP. The ping returns
tend to fluctuate all over the place, too, but I thought this
was more or less "normal" for these guys:

> ping -c50 -C dwan5
PING DWAN5.DIALUP.CORNELL.EDU (132.236.102.11): 64 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
----DWAN5.DIALUP.CORNELL.EDU (132.236.102.11) PING Statistics----
50 transmitted, 50 received, 0.00% packet loss.
round-trip (ms) min/avg/max = 2.298/83.612/113.953
                 var/sdev/skew/kurt = 1244.830/35.282/-1.685/3.983

I have to telnet into my console switch to reset the cards in
order to get them back on-line. They behave for a while, then
drop off again. I'm hoping we can dig up the bucks for HiPerNMCs
to replace all these bastards at some point. Anyone got a quick
fix meanwhile?
*********************************************************
Michelle M. Mogil
Network and Computing Systems
721 Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8420
email: [email-masked]
**********************************************

-

---

From: Martin Lathoud <[email-masked]>
Date: Thu, 10 Feb 2000 19:03:16 +0000

> to replace all these bastards at some point. Anyone got a quick
Same problem here. It sometimes even won't answer ping at all, but will
come back online by itself (no reboot, the nic just reappears).
My problem is probably to insufficient power (45Ax2 -is the backup used?-
for 14 Quads).
Do you have a 70A to check for this?

Martin

-

---

From: [email-masked]
Date: Thu, 10 Feb 2000 22:52:54 +0000

>Do you have a 70A to check for this?

Most of the chassis have redundant 70A PSUs. Some of the NMCs that are
dropping are on chassis that aren't taking a lot of calls, either.
This is what is so puzzling about it. My paranoia says they're doing
this to encourage the purchase of HiPerNMCs...

-

---

From: Clayton Zekelman <[email-masked]>
Date: Thu, 10 Feb 2000 23:41:07 +0000

I've got one NMC card in a remote POP that stops responding.  Interesting
to note, if I log on to the gateway router at that particular POP, and ping
the card from there, it comes back to life, and is visible on the network
again.  After a short period of time (10 minutes?), it stops responding
again.  I wonder if this is some sort of strange ARP issue.

>this to encourage the purchase of HiPerNMCs...
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6

tel. 519-985-8410
fax. 519-258-3009

-

---

From: Lists <[email-masked]>
Date: Thu, 10 Feb 2000 23:54:19 +0000

> Same problem here. It sometimes even won't answer ping at all, but
> will come back online by itself (no reboot, the nic just reappears).
> My problem is probably to insufficient power (45Ax2 -is the backup
> used?- for 14 Quads).

Missed the start of this thread - but we have several chassis with a
single E1 card, 14 quads, NETserver and NMC.  I have had two of them run
on single 45A power supplies for a week or two until I got on-site to
replace the failed supply.  No problems.

------------------------------------------------------------------------
Bob Purdon,                          Ground Floor, Marine Board Building
Technical Manager (Tas/Vic),                  1 Franklin Wharf, Tas 7000
Southern Internet Services.                            +61 (3) 6234 7444

-

---

From: Charles Sprickman <[email-masked]>
Date: Fri, 11 Feb 2000 01:58:51 +0000

> this to encourage the purchase of HiPerNMCs...

This might be off base, but I seem to recall a similar problem long
ago...  I believe that there is a setting (at least at the console) to set
the ether to BNC or 10BT or auto.  If it's not locked to what you're
using, try locking it in.

Another thing to check is the uptime.  Is it possibly rebooting?  I can
make my test chassis (45A, 4M NMC) reboot easily by tossing in a DSP and
trying to hit the chassis with TCM.  I assume that's not the issue, but
maybe you're settings aren't being saved properly and it loses part/all of
it's config on boot.  Make sure you pick "Save UI to EEPROM" after making
any IP addy changes in TCM...

Charles

-

---

From: [email-masked]
Date: Fri, 11 Feb 2000 15:10:36 +0000

>using, try locking it in.

Where would I find this? On the console, under the 'Configuration'
menu, I have:

  1 Local LAN IP Address
  2 Local WAN IP Address
  3 Local Gateway IP Address
  4 Local Token Ring IEEE Address
  5 Local SNMP Community Strings
  6 Local LAN Enable/Disable on Power-up
  7 RADIUS Secret Key
  8 Reinitialize Authorized Access List
  9 Save Configuration To Non-Volatile Memory
  10 Enable/Disable Routing between LAN & WAN
  11 UI/SLIP Port Selection
  12 Local WAN2 IP Address
  13 Local INACTIVITY TIME
  14 PASSWORD Screen Enable/Disable

I've checked and double-checked the LAN settings; all is good.

>Another thing to check is the uptime.  Is it possibly 
>rebooting?[...]  Make sure you pick "Save UI to EEPROM" after making

Was there, did that. After being burned once, I make *sure* I save the
config. 8-) Cards are not rebooting, apparently. If they were, wouldn't
they come back on their own eventually?

-

---

From: Mike Andrews <[email-masked]>
Date: Sat, 12 Feb 2000 01:28:13 +0000

Something *completely* different to look at...

Some older NMC revs would lose IP connectivity if you sent an SNMP request
that was too large.  If the response packet was bigger than 1500 bytes,
the IP stack on the card would crash, and you'd have to reboot the card to
get it to wake up again.  Apparently it didn't deal with IP fragmentation
very well...

I think they finally did fix that bug somewhere in the 6.x.x NMC code.

If you want to check, start a continuous ping up, then do a snmpget for
several large string variables at once.  Or maybe just the same integer
variable repeated a bunch of times...  but have it try to snmpget about 50
or 60 variables at once.  If the card stops responding to pings, you need
newer NMC code.  If pings keep working, but the SNMP query just times out,
then you're OK.

I found this when writing a bulk chassis config tool (which I'm in the
middle of rewriting from scratch today)... it essentially snmpwalks the
whole box and compares the values to a list in a config file.  I had to
cut back the number of simultaneous snmpget requests it did at a time to
about 10 to keep it from killing the boxes as I was programming them... :)

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: Aaron Nabil <[email-masked]>
Date: Sat, 12 Feb 2000 03:53:55 +0000

> about 10 to keep it from killing the boxes as I was programming them... :)

That's mostly how I configure mine, except I only check and change the
values that vary from the default, no snmpwalk.  Single threaded, one
chassis at a time, takes about 10 mins to do a chassis w/6 DSP's.  I've
never bothered speeding it up since I use it so infrequently.  Certainly
much less error-prone than using TCM.

--
Aaron Nabil

-