Mailing List Archive

> In one of our AS5300 (mica 2.9.4.0) we get a lot of such disconnects:

> Disconnect Reason Info: (0xDF06)
> Type (=6 ): Tx (host to line) data flushing - OK
> Class (=31): Requested by host
> Reason (=6 ): network indicated disconnect

> These disconnects can happen 5 mins after the user has connected or 30 mins after.

> The strange thing is that we don't see any errors on the E1 circuit (neither telco does).

> Any idea what might be going on?

This just means that we got a hangup signal from the TDM network for
that call. (For example, if you're using ISDN, this would be
receipt of a Q.931 DISCONNECT.)

If the user at the other end of the circuit INTENDED to hang up,
then of course this is not a problem. If he did NOT intend to
hang up, then this is a problem.

Such a problem could be caused by poor circuit quality and/or by
bad client modem behavior.

Aaron

Dear Aaron,

Thank you for your help. The grounding method is working for me.

Regards,
Souphonh
----- Original Message -----
From: "Aaron Leonard" <Aaron@cisco.com>
To: "Anastassios Chatzithomaoglou" <achatz@forthnet.gr>
Cc: <cisco-nas@puck.nether.net>
Sent: Thursday, September 18, 2003 11:41 PM
Subject: Re: [cisco-nas] MICA disconnect reason 0xDF06 while connected


> > In one of our AS5300 (mica 2.9.4.0) we get a lot of such disconnects:
>
> > Disconnect Reason Info: (0xDF06)
> > Type (=6 ): Tx (host to line) data flushing - OK
> > Class (=31): Requested by host
> > Reason (=6 ): network indicated disconnect
>
> > These disconnects can happen 5 mins after the user has connected or 30
mins after.
>
> > The strange thing is that we don't see any errors on the E1 circuit
(neither telco does).
>
> > Any idea what might be going on?
>
> This just means that we got a hangup signal from the TDM network for
> that call. (For example, if you're using ISDN, this would be
> receipt of a Q.931 DISCONNECT.)
>
> If the user at the other end of the circuit INTENDED to hang up,
> then of course this is not a problem. If he did NOT intend to
> hang up, then this is a problem.
>
> Such a problem could be caused by poor circuit quality and/or by
> bad client modem behavior.
>
> Aaron
> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas
>

Aaron Leonard wrote:

>> In one of our AS5300 (mica 2.9.4.0) we get a lot of such disconnects:
>
>
>> Disconnect Reason Info: (0xDF06)
>> Type (=6 ): Tx (host to line) data flushing - OK
>> Class (=31): Requested by host
>> Reason (=6 ): network indicated disconnect
>
>
>> These disconnects can happen 5 mins after the user has connected or 30
>> mins after.
>
>
>> The strange thing is that we don't see any errors on the E1 circuit
>> (neither telco does).
>
>
>> Any idea what might be going on?
>
>
> This just means that we got a hangup signal from the TDM network for
> that call. (For example, if you're using ISDN, this would be
> receipt of a Q.931 DISCONNECT.)
>
> If the user at the other end of the circuit INTENDED to hang up,
> then of course this is not a problem. If he did NOT intend to
> hang up, then this is a problem.
>
> Such a problem could be caused by poor circuit quality and/or by
> bad client modem behavior.
> Aaron
>

We also sometimes get " %CONTROLLER-5-CALLDROP: Controller E1 0, Call DROPPED due to
excessive errors" on the specific router. But we still don't get any errors on the E1.
Could it be caused by poor circuit quality? If yes, how can we check it?


--
***********************************
Chatzithomaoglou Anastasios
Network Design & Operations Center
FORTHnet S.A.
<achatz@forthnet.gr>
***********************************

> > This just means that we got a hangup signal from the TDM network for
> > that call. (For example, if you're using ISDN, this would be
> > receipt of a Q.931 DISCONNECT.)
> >
> > If the user at the other end of the circuit INTENDED to hang up,
> > then of course this is not a problem. If he did NOT intend to
> > hang up, then this is a problem.
> >
> > Such a problem could be caused by poor circuit quality and/or by
> > bad client modem behavior.

> We also sometimes get " %CONTROLLER-5-CALLDROP: Controller E1 0, Call DROPPED due to
> excessive errors" on the specific router. But we still don't get any errors on the E1.
> Could it be caused by poor circuit quality? If yes, how can we check it?

Yes, this would be caused by a sync HDLC/PPP call having excessive errors.
This is most likely caused by a poor circuit.

The first thing you might check would be for BRI errors on the client
side. If this shows as clean, and if your E1 is clean, then the errors
are evidently here:
|
v
[ AS5000 ]--E1 PRI--[switch]-{PSTN}-[switch]--bri--[ client]

In order to troubleshoot the PSTN, you will first want to get a
map of the TDM network (i.e. the part between the AS5000's
switch and the client's switch.) Then make numerous test calls
using different circuit paths through the PSTN, to try to find
a pattern for where the errors are being introduced.

Aaron