From: Robert Watson (watson.robert@gmail.com)
Date: Tue May 16 2006 - 16:17:50 ART
Troubleshooting Frame-relay circuits in the real world is a little
different. You would want to run your loopbacks if your not seeing LMI from
the provider frame switch. If LMI is down have your provider first attempt
a loop to the smartjack and run several patterns when looped. IE qasi all
1's and 0's etc. If this is successful then reconfigure your interface for
HDLC and do 2 things, 1rst plug hard loop into t1 card and run your
extended ping test off cisco's t1 troubleshooting page then drop the plug
normalize the circuit and see if you provider can loop the csu. If step 1
fails replace the t1 card/open tac case. If step 2 fails and your
condition is provider can loop smartjack but not csu and you have proved out
your t1 card look at physical layer issues such as cabling/ extended demarc
or possible polarity being reversed out of the smartjack to the 48c biscuit
at the bottom of the card (reverse polarity will still result in successful
loop as they just run back to themselves by simulating closed pairs.).
This is assuming that all your settings match up with th circuit like ...
Framing
Linecode
Channels
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
CCIEin2006
Sent: Tuesday, May 16, 2006 9:11 AM
To: ccielab@groupstudy.com
Subject: OT - Frame Relay Troubleshooting in the Real World
Gents,
When troubleshooting frame-relay circuit failures in the real world, is it
possible to do loopback tests as you would do with a plain T1 with HDLC
encapsulation?
With HDLC encapsulation I know that by putting up different loops in the
network you can run extended pings to those loops and see which loops run
dirty.
Can a similar technique be used for frame-relay? If not how would you
isolate a circuit failure?
Thanks
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:21 ART