Hhhmmmmm...... it was a telco problem..... knock me over with a
feather!!!!!! :->

-----Original Message-----
From:   [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Kane, Christopher A.
Sent:   Wednesday, December 27, 2000 6:22 AM
To:     'Priscilla Oppenheimer'; Kane, Christopher A.; '[EMAIL PROTECTED]'
Subject:        RE: interface stats, physical problem or high utilization?

Thanks to everyone for the feedback. I think I have mustered enough evidence
to change my co-worker's viewpoint.

By the way, the problem was physical (telco) related. I found the problem by
running debug on  the service-module. After watching the router for 30
minutes, I saw  the following:
SERVICE_MODULE(0): detects loopback test from telco
SERVICE_MODULE(0): loopback test from telco ended after duration 00:00:00

Those debug commands really come in handy.

Later,
 Chris

-----Original Message-----
From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 26, 2000 8:38 PM
To: Kane, Christopher A.; '[EMAIL PROTECTED]'
Subject: Re: interface stats, physical problem or high utilization?


At 09:59 AM 12/26/00, Kane, Christopher A. wrote:
>I'm looking for some feedback to a discussion I had with a co-worker. I'm
>not looking for troubleshooting assistance with this problem. Rather, I
>would like to know if anyone else has experienced a similar situation in
>which a utilization problem looks like a physical problem?

Input errors, CRC errors, and carrier transitions on a WAN link seem like a
physical problem, and not a utilization problem. Dropped frames would
indicate a utilization problem.

Since I have Ethernet on the brain, I'm wondering if your co-worker who
said that high utilization can look like a physical problem was
over-generalizing? On shared Ethernet, high utilization can indeed look
like a physical problem. Collisions result in frames with bad CRCs. You
need to do more analysis to isolate whether the CRCs are a result of high
utilization or noise, cross-talk, or other physical problems. Do the CRCs
only occur in runts (<64 bytes), for example, which are usually the result
of a collision?

But on a WAN? I think high utilization versus a physical-layer problem
would manifest itself differently. On the other hand, high utilization
could trigger a bug in carrier or your own equipment which trashes frames,
resulting in CRCs.

What is your utilization, by the way? Is it high when that user is
downloading large files?

You said you weren't asking for troubleshooting tips, but please do let us
know if you solved the problem and what the cause turned out to be. Thanks.

Priscilla


>We had a customer with a 56k Frame ckt terminating into a Cisco 2524 with
an
>integrated 4-wire CSU/DSU. The end user was complaining of dropping when
>trying to pull large files (3 meg).
>The interface stats showed Input errors, CRCs and carrier transitions.
>Myself and the telco were able to test end-to-end clean several times. We
>then swapped the 2524 for fear that the integrated CSU/DSU was flaky. The
>problem remained.
>
>Then my co-worker made a statement that I am having a hard time agreeing
>with. He stated that it must be heavy utilization by the end user that is
>causing the problem. Could that be? A utilization problem that looks like a
>physical problem according to the stats provided by the serial interface?
>
>It's always fun to banter with co-workers. Round-table discussions in front
>of the whiteboard are my favorite part of the job.
>
>_________________________________
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]


________________________

Priscilla Oppenheimer
http://www.priscilla.com

_________________________________
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to