(usr-tc) TRANSMISSION PROBLEMS
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 "majordomo@xmission.com" 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.
On Tue, 30 Nov 1999, Jeff Binkley wrote:
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
These last three are kinda high, relative to blocks sent/received.
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.
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) * mandrews@dcr.net * 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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
On Wed, 9 Feb 2000 mmm3@cornell.edu wrote:
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? 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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
On Wed, 9 Feb 2000 mmm3@cornell.edu wrote:
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? 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?
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... ********************************************************* Michelle M. Mogil Network and Computing Systems 721 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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. At 03:47 PM 2/10/00 -0500, you wrote:
On Wed, 9 Feb 2000 mmm3@cornell.edu wrote:
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? 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?
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...
********************************************************* Michelle M. Mogil Network and Computing Systems 721 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu **********************************************
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
--- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
On Thu, 10 Feb 2000 mmm3@cornell.edu wrote:
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...
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
********************************************************* Michelle M. Mogil Network and Computing Systems 721 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu **********************************************
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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 "majordomo@xmission.com" 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.
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.
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 any IP addy changes in TCM...
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? ********************************************************* Michelle M. Mogil Network and Computing Systems 721 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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) * mandrews@dcr.net * 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." On Wed, 9 Feb 2000 mmm3@cornell.edu wrote:
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: mmm3@cornell.edu **********************************************
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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 "majordomo@xmission.com" 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.
On Fri, 11 Feb 2000, Mike Andrews wrote:
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... :)
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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
participants (8)
-
Aaron Nabil -
Charles Sprickman -
Clayton Zekelman -
jeff.binkley＠asacomp.com -
Lists -
Martin Lathoud -
Mike Andrews -
mmm3＠cornell.edu