Thus spake William M Sheeler Sr
I have 3COM/USR 2059 bundles (yep still running).
Bah...quads...not that old...we've got dual's with 35Amp power supplies still running. ;)
1. Sometimes a modem card goes red lite on a modem, and a software reset won't work and I have to pull the card and reseat it. When this happens callers can not consistently connect. They get messages saying that the number is blocked, or not available, or even a busy signal. They are configured roundrobin as I was told to do 3 years ago. Sometimes people get past, other times not. Bad thing is that this usually happens on the 1st rack and really causes havoc, and I don't know what to do, how to stop it or just how to watch it so that if and when it happens, something pages us to let us know. Thing is, how do you check for an error message on a phone line?
Sometimes quads do just loose it...we have that happen occasionally around here...a "hard reset" from TCM should revive them without requiring a full reseat of the card (a life-saver if its at a remote POP :). To get the hard reset (note, this will reset the whole card, not just that one modem), select the card rather than the modem and go to actions.
2. Sometimes the NMC card goes red, and won't take a software reset either, and needs a hard pull to reboot it. This causes issues with slow or no logins (hangs on password authentication using Lucent Radius), and or not being able to go to any sites.
Not sure about the NMC...haven't run into that. If its the hub status light, it could be other things that are causing it to go red...though since it doesn't take a soft reset, its seems there really might be a problem with the NMC. For example, a power supply problem will be indicated by a red hub status light on the NMC...there is an SNMP OID somewhere (and I can't remember where off the top of my head) that will tell you the reason for the hub status light being red...this assumes that the NMC itself is actually healthy enough to respond.
3. We are also having problems with disconnects, and long retrains, etc., and what appears to be noise on the lines, but we are on a fiber OC-3 ring for our PRIs, so where is noise being generated?
Well...its possible that its on the customer's end...their analog loop...but if its widespread, that casts some doubt on that...as does the information below.
People are getting low connect speeds, tons of retrains, and I noticed a lot of Bipolar violations (400+ in less than 24hours), code violation error events, errored seconds, etc., across multiple PRIs using the TCM performance monitor.
You need to scream and yell at the telco to get someone clueful on the line. If you can get a PRI cleared off, do so and have them run some test patterns at a loop on it...they will almost assuredly find that something there is misprovisioned...quite possibly a mux (DDM-2000's are commonly a culprit here) will be provisioned as AMI rather than B8ZS (apparently DDM-2000's default to AMI rather than B8ZS...why? I don't know...they can be set in software, but will revert to AMI on its next reset if the hardware switch isn't set on it). Having something like that set to AMI when the circuit is supposed to be running B8ZS (and everything else is running B8ZS) will result in at least BPV's...likely other problems as well. I've generally found that on a circuit misprovisioned like this you can get the D channel up (at least temporarily), but will be unable to bring up the B's. If the circuit is already up...all bets are off as to what will happen. You might want to particularly insist that they run an "all-zero's" pattern as that will definitely catch AMI/B8ZS misprovisioning.
HELP.... This is driving me crazy. Customers are getting too many disconnects, slow connects, retrains, etc, and this did not happen before. It is almost like the telco (not BA but a CLEC) has problems with the B8ZS line encoding, but there is no one with clues there that can figure it out.
You've got to find someone there with clue...you will not get this resolved any other way if its a misprovisioning problem at the telco (and based on your description, it almost assuredly is)
Also, how can I set cause codes in the PRIs so that the Telco switch knows when there is a modem problem and can move around that modem? Am I on the right track or blowing smoke.
Cause codes don't do anything to cause the switch to skip a modem...they just change what indication is returned to the dialing user when a problem is seen. Cause code 17 is a normal user busy...anything else will likely generate some sort of reorder tone/reorder message/fast busy for the user...which would be appropriate in this case as the circuit is hosed. You might see if the telco can go to a round-robin hunt on their system (we did this recently), and you go to fixed assignment...then you could use auto-response to detect when a modem has gone south and busy out the ds0 on the PRI. This also requires that you not be using the brain-damaged NI-2 (National) translation on the PRI as whoever came up with that protocol was dain bramaged enough to *not* put in service messages in it. Good luck...feel free to followup with requests for clarification in any of this...I've tried to make it clear...but I don't always do too well at that. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - 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.