[Asterisk-Users] HDLC bad FCS

Mike M no-linux-support at earthlink.net
Tue Jul 5 12:17:51 MST 2005


Comments throughout.

-- 
Mike

On Mon, Jul 04, 2005 at 08:23:55PM -0400, Carlos Alperin wrote:
> That has nothing to do with the fact that you 're going to check what is
> going on on that line.
> 
> You're going to check BER (Bit Error Rate) to see if you have line problems.

FCS is indication of frame checksum error which can be caused by bit
errors.  BERT is a level 1 test.
> 
> When I asked you for location, I was asking if your Asterisk box was in your
> Computer Room, away from your TELCO provider. If you have everything on the
> same location, then much better. 

> Now you mention a DMS-100, is that the
> Siemens one? 

Nortel: DMS-100
Siemens: EWSD

> If that is the case, better because the line analyzer is a
> function on that switch.
> 
> Carlos
> 
> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com
> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Rod Bacon
> Sent: Monday, July 04, 2005 8:10 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [Asterisk-Users] HDLC bad FCS
> 
> I think I need some help here. I didn't understand much of what you just
> said there.
> 
> I though HDLC was a Layer 2 protocol? How can it have a "location"? FCS is a
> frame check sequence.. right? So I'm getting data out of sequence (or 
> frames are missing from the sequence?)
> 
> My gear is in a data centre, with the DMS-100 switch in the next room. Does
> this help?

It simplifies the troubleshooting scenario.  At least you don't have
outside plant support ignoring your problem.
> 
> What is BER?

Bit Error Rate: bi-polar violations, jitter, etc.; put circuit into
loop-around; tester generates and receives pattern and indicates sent
versus received results; try it if you have the equipment and
cooperation of the DMS handlers
> 
> 
> Carlos Alperin wrote:
> > I believe that you need to analyze the packets at your provider site. They
> > should be able to do that. Is your HDLC located on your location or on
> your
> > provider. This test should be done where Asterisk is running, because is
> > where the problem is reported.
> > 
> > Start to look for Line Analyzers for HDLC, in order to check BER.
> > 
> > If BER is high enough, then the problem is internal on your server.
> > 
> > Regards,
> > 
> > Carlos Alperin
> > Senior System Engineer 
> > Seneca Communications, LLC
> > Calperin at senecacom.net 
> > 
> > -----Original Message-----
> > From: asterisk-users-bounces at lists.digium.com
> > [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Rod Bacon
> > Sent: Monday, July 04, 2005 7:27 PM
> > To: asterisk-users at lists.digium.com
> > Subject: [Asterisk-Users] HDLC bad FCS
> > 
> > I have 2 servers, configured identically. Each has a TE405P and 2 PRIs.
> One
> > server was experiencing crackly audio on one circuit, accompanied by HDLC 
> > bad FCS messages. The telco recabled and moved me to another port on the
> > DMS-100. The audio is better, but there are still bad FCS problems on the 
> > span. I have moved the PRI in question to the other server, and the
> problem
> > does indeed move with the circuit.

That's pretty damning in my opinion.  Did you do this demonstration for
the DMS handlers?
> > 
> > There are no zaptel timing/interrupt problems present on either server.
> The
> > fact that 3 PRIs are error free and that the problem moves with the 
> > circuit tells me that there is still a problem on the circuit.
> > 
> > The telco believes that there is nothing more that they can do (provision
> a
> > complete new circuit?).

Provisioning a new circuit sounds like a good idea.  You might ask to
see the DMS config tables for all four circuits.  Keep an eye on
clocking choices.

> > 
> > I don't get HDLC aborts, so the problem may not be _that_ serious. Does
> > anyone have any comments? Would a newer (unstable) version of Zaptel
> drivers
> > 
> > help? Would line-build-out parameter in zaptel.conf make any difference?

LBO is probably not going to help.  Your 3 other circuits work fine and
are probably cabled over the same distance.  Use lowest value LBO.

I would not settle for a circuit that regulary pops FCS errors.  In a
close connection like you have FCS should occur rarely.  You are at the
end of the food chain so you'll have to prove the DMS is screwing up.

Trying running your PRI circuits back-to-back to further ensure that
your equipment is operating correctly.  You'll have to show the DMS
handlers your demonstrations and gently ask for help.  You'll have to
help them establish confidence in your equipment.

You should also use the cables from the 3 good circuits to connect to
the suspected bad port of the DMS.  Use the cable on the bad circuit to
connect good DMS ports to *. This might help point the finger at
a bad DMS port or at  a bad cable.  Make a spreadsheet
of various combinations of DMS ports, * ports, and cables.  Enlist DMS
handlers to help cycle through the variations.

Good luck,
-- 
Mike



More information about the asterisk-users mailing list