>Hello gang,
>
>We're running 3.8.2 on four Portmaster 3s, each with two CT1s.
>All 8 T1s are hunt grouped together. We don't take ISDN calls on this
>hardware. The T1s don't generate many sync or CRC errors, and my
>customers generally seem to be able to connect well.
>
>However, we get a fairly steady stream of complaints about disconnects.
>As far as I can tell, they don't seem to have much to do with the
>modem on the customer end. I've been trying to poke at the box to
>generate some ideas for what is going on, without much success
>until tonight.
>
>I wrote a perl script to pull the following values from SNMP on a
>per modem basis: livingstonModemCalls, livingstonModemDetects, and
>livingstonModemConnects. For each modem, I subtracted Connects
>from Calls, and then displayed the percentage:
>((Connects - Calls) / Calls ) * 100
>
>When I threw out the lines for the modems that hadn't had enough
>calls to be statistically significant I saw that the percentage of
>failed calls for most modems was 7-10% (which seems like a high
>number)... However, I had several modems that were MUCH higher
>than that.
>
>The leading modem had 70% failures out of 962 calls. The next
>several highest percentages were 48%, 37% and 30%. I immediately
>turned off these modems, figuring that the modems themselves were
>bad...
>
>But I noticed that in three of the four cases, the modem was the
>25th modem on that box. (One modem is actually numbered 26, but
>there's a modem on that particular box that is already disabled,
>since it never comes out of "test" mode.)
>
>I plan on opening a trouble ticket with my circuit provider, and
>possibly one with Livingston once I convince myself that I'm not
>chasing shadows. I thought I'd throw this at the gang of you to
>see if it jogs any thoughts loose. Can anyone think of a configuration
>error of some kind that would cause a large number of failed calls
>on the first channel of the second T1 in a hunt group? I'd be
>happy to provide more details if I've generated any curiosity in
>any of you.
Interesting... I looked through my boxes (PRIs) and didnt see any pattern
that you had. One thing to note is that the actual T1 channel order does
not follow the port assignment. Try the command
munich
or
munich channels
When I walked the tree on my units, I found a few modems with a lot of
retrains. However, its hard to tell if it was caused by one really bad
user session, or its indicative of a bad DSP. By the way, what sort
disconnection stats do you see on your boxes ? I see the following
normal 80.30% 14453/17998
User Request - Call Circuit Closed 10.36% 1864/17998
Lost Carrier 7.30% 1313/17998
No Event Identified 1.28% 230/17998
User Error - PPP NCP Active to Request 0.46% 82/17998
NAS Request - PPP Maximum Retransmissions 0.17% 31/17998
User Request - PPP Term Ack 0.07% 12/17998
Port Error - Exceeded LAPM retransmission limit 0.05% 9/17998
Service Unavailable - PPP No Protocol 0.01% 1/17998
Service Unavailable - Failed to detect V.42 remote 0.01% 1/17998
User Error - LAPM negotiation timeout 0.01% 1/17998
Lost Carrier - Waiting for Filter 0.01% 1/17998
*The No Event Identified is me swapping T1 cables on a couple of new units.
I dont know why it would report ports disconnecting when there was no one
on them...
---Mike
Mike Tancsa (mdtancsa@sentex.net)
Sentex Communications Corp,
Waterloo, Ontario, Canada
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>