[c-nsp] Frame Circuit Not Cooperating

[Chad Whitten]

I have finally managed to determine the cause of this problem.

It wasnt a configuration issue.
It wasnt a circuit issue.
It wasnt an NIU issue.
It wasnt a remote end issue.

It was a power issue.  You see, the location where the circuit terminates
is a lumber mill.  The electric power for the mill feeds to the mill then
to the office where the router is located.  The router was plugged into a
standard small apc ups.  Well, whenever the mill would startup, the
voltage would drop down throughout the office - albeit slightly and only
for a few seconds - which would cause the router to throw generate crc
errors.  It probably wouldnt have been noticed if this were a full t1 with
1.5 megabit of bandwidth but since there was only 256k, there wasnt much
room for discarded packets or errored packets.

The way I finally stumbled onto this problem is I noticed that all the
pc's in the office were on abnormally large ups units - the kind with a
voltage regulator that normally run about $250 to $300.  I inquired as to
why they used such high end batteries for pc's that get very minimal use
and was told "oh, when the mill starts up, our pcs would shut down unless
we got the special batteries that regulate voltage".

So there you go, after 4 trouble tickets in two months with the local lec
and three onsite tech visits by the lec, we finally resolved the issue by
just looking under a desk and asking a simple question.  sometimes the
hardest questions have the easiest solutions.

by the way, there were alot of replies to this thread, some discussing how
bad the LEC's can be, how incompetent, etc.  I have to say that this has
not been the case for me.   We have well over 100 t1 circuits and some ds3
circuits and i have never had a problem getting Bellsouth to respond to
trouble.  Of course I am paying them a helluva lot each month as well.

Thanks for the troubleshooting tips - and add this one to your notes in
case you ever see something strange like it.


John Neiberger said:
>> The second NIU I had that failed in this way passed the hard loopback
>> plug test.  I suspect it's output drivers were damaged to the point
>> that they could produce enough signal to make it work on 2 inches of
>> wire in a loopback plug, but not enough signal to make it up 1 story
>> to the next floor where the router was.  Swapping the NIU fixed the
>> problem of course.
>
> The weirdest NIU failure I ever had went like this:
>
> 1. Users complain that some file transfers are failing to a remote site
> 2. Further investigation shows that it is only one particular file that
> will not transfer
> 3. I try testing across the link with various payloads and sizes and I
> can't get it to fail, not a single error, yet this one particular file
> will fail every single time.
>
> I ended up using a hex editor to split the file into successively
> smaller parts. I eventually found an 18-byte pattern that could not pass
> through this NIU. Anything less than that particular 18-byte
> pattern would succeed with no problem. Qwest wasn't able to replicate
> this during testing because their test equipment won't allow test
> patterns that big. I convinced them to swap out the NIU and that
> solved our problem.
>
> John


-- 
Chad Whitten