[c-nsp] Frame Circuit Not Cooperating

[Mark Rogaski]

An entity claiming to be Chad Whitten (cwhitten at nexband.com) wrote:
: 
: ive checked clocking - its set to line
: ive checked line code - its set to b8zs
: ive checked framing - its set to esf
: all of which are the same for my other circuits and what Bell BNIS says are 
: correct
: 
: the router is a 2610xm, and ive also use a 1720 & 1750, all with different wic 
: cards and same results
:
[snip]
: 
: Bell does see errors coming from the csu and therefore tells me its my 
: equipment or configuration.
: 

The first thing you need to determine is the type of errors seen on either 
end of the circuit.  Getting specifics from the SP or LEC might be difficult,
most of the first line techs you talk to know just enough to open a ticket
and click on an auto-test button.  Before you engage the SP or LEC, there are
some things you can do to narrow the scope of the trouble.

First, do a quick "show log | i T1" ... if you see AIS (blue alarm) 
received, it's a problem with an upstream section in the path and it's 
the Telco's problem (this does not apply to leased line).  LOS (red alarm) 
is most likely a problem in the cabling, and LOF (red alarm) or RAI 
(yellow alarm) can be a number of issues and require more investigation.

Next, look at the output of "show controllers t1 0/0".  Here's what you can
do based upon what errors you see.

1) Slip secs

Just having the timing set to "line" may not be sufficient.  You should
also have åt least one line that is traceable to Stratum 1 reference
(i.e. the line from the LEC) and is also selected at the timing reference
for the router itself via the network-clock-participate and
network-clock-select commands.  Without this, the router is a free-running
device and the integrity of the data is at the mercy of the accuracy of the
router's internal oscillator.  Data is more tolerant of slippage than voice
is, but there's only so much slippage that can be tolerated.

Keep in mind, a test to a loopback will NOT detect a a timing problem on
your equipment ...  even if you run the test.

2) Path code violations (PCV's) without line code violations (LCV's)

This means that either the CRC6 check failed or there was some other error
in the ESF framing.  If you get Fr Loss Secs, it was bad enough that the
WIC lost framing completely.  Without LCV's or slips, this could be a line
build-out problem.  Try toggling the line build-out ... short to long or
vice-versa.  If that doesn't work, it's probably the Telco.

If the provider says they test clean to the smartjack but you don't see
LCV's or slips, be skeptical.  Make sure they run all-1's, all-0's, QRSS or
DALY, 1:7, and 3:24 for 5 minutes each.  If the tech can't do it, escalate
until you find someone who can.


3) PCV's with LCV's

When you see LCV's it's almost always a local problem.  There is a remote
chance that the Telco has AMI coding leaving the smartjack ... but it's not
likely.  LCV's usually indicate bad cable or a bad connector, but line
build-out could also be the problem.

Mark

-- 
[]                     |
[] Mark Rogaski        |   The limits of tyrants are prescribed by the
[] wendigo at pobox.com   |   endurance of those whom they oppress.
[] mrogaski at cpan.org   |                 -- Frederick Douglass, Aug. 4, 1857
[]                     |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20050915/a92d603a/attachment-0001.bin