From: Robert Watson (watson.robert@gmail.com)
Date: Tue May 16 2006 - 17:37:38 ART
If you get to the stage where you t1 is up you have LMI and your PVC is
active and your sending traffic down the dlci but not recieving then you
have a pretty good case to build for your provider to work out an internal
network problem on their part. Many times if you cross lata's you will be
dealing with FRATM internetworking in the provider cloud as well in which
case you must have the IETF keyword appended to your interface config like "
encapsulation frame-relay ietf" . At that point I usually run a continuous
ping across the cloud with some heavy traffic and tell them to call you back
when they get 2 way on the pvc.
_____
From: CCIEin2006 [mailto:ciscocciein2006@gmail.com]
Sent: Tuesday, May 16, 2006 2:47 PM
To: Robert Watson
Cc: ccielab@groupstudy.com
Subject: Re: OT - Frame Relay Troubleshooting in the Real World
Awesome - thanks.
Now if the problem was between the service provider's frame relay switches
would they be able to provide you a loop from there as well or does your
visibility end at your connection to the frame relay switch?
Is the carrier pretty good at finding problems between the frame relay
switches? I know with point to point T1's they often blame the customer's
equipment until you can prove them wrong with loopback testing.
On 5/16/06, Robert Watson <HYPERLINK
"mailto:watson.robert@gmail.com"watson.robert@gmail.com> wrote:
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: HYPERLINK "mailto:nobody@groupstudy.com"nobody@groupstudy.com
[mailto:HYPERLINK "mailto:nobody@groupstudy.com"nobody@groupstudy.com] On
Behalf Of
CCIEin2006
Sent: Tuesday, May 16, 2006 9:11 AM
To: HYPERLINK "mailto:ccielab@groupstudy.com"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