Subject: (usr-tc) TC call Barring or something

From: [email-masked]
Date: Mon, 03 Jan 2000 04:03:17 +0000

Hi!

I just want to know if the TC is capable of blocking a certain telephone
number?

Thanks.

Bert

-
 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: William M Sheeler Sr <[email-masked]>
Date: Mon, 03 Jan 2000 16:53:46 +0000

Hi:

I've been going crazy trying to figure this out, so I am now asking for 
some help.

I have 3COM/USR 2059 bundles (yep still running).

There are a couple of strange problems.

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?

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.

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?  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.

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.

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.

HELP

Frustrated in PA.

Bill

their configurations are as follows:

Card					hrdware ver	sware ver	dram	flash	
---------------------------------------------------------------------------- 
-----------------------------
Dual PRI card			4.0.0		3.0.2		4096	1024
Quad Digital Modems		3.0.0		5.10.9		
Quad Analog/Digital Modems	3.0.0		5.10.9	
Netserver card			7.0.0		3.7.24		20480	2048
NMC card				3.0		5.4.1		4096	2048

Dual 45 watt PS, no service contract. Using Windows TCM 5.5.1

-

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 03 Jan 2000 17:24:45 +0000

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.  ;)

>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
>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.

>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)

>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Greg Coffey <[email-masked]>
Date: Mon, 03 Jan 2000 21:41:20 +0000

What version of software are you running on the modems, nmc and netserver 
units?  We occasionally see a red light on the modems but nothing we have 
to hard reset.  We have been running 5.10.9 on the modems and I have 
recently been upgrading them to 6.1.6 (all of ours are single sided).  I 
have one chassis that refuses to flash on any of the modems.  We have two 
chassis sitting side by side and identical from what I can see.  The first 
one flashed just fine and all of the 2nd's modems give me a pending, then 
time out.  Wish I could get them done and I can't figure out the problem 
with them.

>         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?
>
>either, and needs
>         a hard pull to reboot it.  This causes issues with slow or no 
> logins (hangs on password
>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?  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.
>
>--------------------------------------------------------------------------- 
>- -----------------------------
>NMC 
>card                                3.0             5.4.1           4096 
 > 2048

>"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: Terry Kennedy <[email-masked]>
Date: Mon, 03 Jan 2000 22:04:10 +0000

I know a lot you are using tsmon, does anyone else have trouble
with tsmon reading the times right off the Arcs?

-

---

From: [email-masked]
Date: Mon, 03 Jan 2000 22:47:45 +0000

YES we do!  Had to shut it down...  All clients were being logged
out because they were all over the time limit!  Seems it has a problem
with subtraction and the new 2000 date.  I have already sent 2 messages to
the software editor and programmer, but have yet to hear back from him...
If any of you are using the product, you should send them email!  I hate
to see $600.00 go down the tube!

  Send it to  mailto:[email-masked]

  Hope he corrects it quickly!

==============================================================================
Phillip Ferraro				WorldNet Access, Inc
[email-masked]	Onslow County's PREMIER InterNet Service 
Voice (910) 346-0835		    824 Gumbranch Square, Suite R3
FAX   (910) 455-1933		     Jacksonville, Nc  28540-6269
==============================================================================

-

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 03 Jan 2000 22:58:43 +0000

Thus spake [email-masked]
>with subtraction and the new 2000 date.  I have already sent 2 messages
>to the software editor and programmer, but have yet to hear back from
>him...  If any of you are using the product, you should send them
>email!  I hate to see $600.00 go down the tube!

At the risk of serious flamage...I think this goes down as an example of
the danger of telnet base scripted actions.  Like I said last time
around...parsing problems will end up biting you in the end.  :/
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: "Lon R. Stockton, Jr." <[email-masked]>
Date: Tue, 04 Jan 2000 05:13:32 +0000

> around...parsing problems will end up biting you in the end.  :/

Indeed. What starts as a quick and simple winds up not so quick or simple.

But I've recently been playing around with doing various monitoring and
check tasks.....am having a good bit of fun with perl, SNMP.pl, and
CGI.pl. *grin*

-

---

From: Mark Lemmert <[email-masked]>
Date: Thu, 17 Feb 2000 20:59:08 +0000

>around...parsing problems will end up biting you in the end.  :/

I am having the same problem. I've also send two messages
to the author and heard nothing.

Does any body know of any other way to contact these
people, phone #, mailing list etc?

-MGL

Mark Lemmert
CTO
AthEnet Data Exchange
920-954-9799
[email-masked]

-

---

From: Brian <[email-masked]>
Date: Thu, 17 Feb 2000 22:51:40 +0000

Disable the Timezone offset in the config and you will be fixed.  

> people, phone #, mailing list etc?

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

-

---

From: Steve McConnell <[email-masked]>
Date: Fri, 18 Feb 2000 01:47:23 +0000

You can also get the latest version of TSMON which fixes this bug.

steve

--On Thursday, February 17, 2000 2:47 PM -0600 Brian <[email-masked]> 
wrote:

>> > >       YES we do!  Had to shut it down...  All clients were being
>> > >       logged out because they were all over the time limit!  Seems
>> > > it has a problem with subtraction and the new 2000 date.  I have
>> > > already sent 2 messages to the software editor and programmer, but
>> > > have yet to hear back from him...  If any of you are using the
>> > > product, you should send them email!  I hate to see $600.00 go down
>> > > the tube!
>> >
>> > At the risk of serious flamage...I think this goes down as an example
>> > of the danger of telnet base scripted actions.  Like I said last time
>> > around...parsing problems will end up biting you in the end.  :/ --

Steve McConnell
EMJI
919.303.3217:126
888-258-8959

-