RE: Serial interface error.

David,

" the problem is not that big of a deal, the site is a low priority,"

I pay for the Smartnet and lots of other support stuff and I cannot
tolerate even a small financial loss anywhere because a "technical"
person wants to judge on the importance of my "business" in different
locations. My engineer will be reassigned because of these words ;-)

HTH

--------------------------

Kambiz Agahian

CCIE (R&S), CCSI, WAASSE, RSSSE

Technical Instructor

CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)

Email: kagahian_at_ccbootcamp.com

Toll Free: 877-654-2243

International: +1-702-968-5100

Skype: skype:ccbootcamp?call

FAX: +1-702-446-8012

YES! We take Cisco Learning Credits!

Training And Remote Racks: http://www.ccbootcamp.com

From: David Bass [mailto:davidbass570_at_gmail.com]
Sent: Monday, May 17, 2010 3:44 PM
To: Kambiz Agahian
Cc: GAURAV MADAN; Mahmoud Nossair; ccielab_at_groupstudy.com
Subject: Re: Serial interface error.

I have to disagree with you. So, what you're saying is:

1. Don't think.

2. Ask somebody else to solve your problems for you if you can't
immediately figure it out.

You should know that the only way you are truly going to understand this
stuff is from working thru problems by trying stuff, doing research,
etc.

There are several factors that go in to troubleshooting a problem on an
enterprise network such as: the problem is not that big of a deal, the
site is a low priority, the site doesn't have somebody dedicated to IT
and you have to work on it as they are available if you need them to do
something with the physical side, etc, etc, etc (there are a million
reasons).

What you are recommending might work, or be "best practice" in a large
service provider network, but in a small/medium/large enterprise network
things are not so cut and dry.

On to the problem...

I would agree with the guys who are saying that the errors are very
minor. FYI, when troubleshooting errors on an interface first thing I
do is clear the counters if the router has been up for any decent period
of time. It's not all that uncommon to see errors on an serial
interface... If the errors are incrementing, then you need to have the
carrier take a look at the line. However, the majority of the drops
you're seeing indicate that the circuit is being overwhelmed and so the
router is dropping some of the traffic. It also looks like you may have
some form of QoS configured...can you post those configs and the output
of a "sh policy-map int s1/3"

HTH

On Sat, May 15, 2010 at 1:42 PM, Kambiz Agahian
<kagahian_at_ccbootcamp.com> wrote:

Guys,

I was not chasing this up very actively but now I guess 2 points should
be mentioned:

1- Although technical skills including the bingo bang magic type of them
to know every single "issue" sound great (this could be an easy one
though), but as you will see in CCNA/CCIE SP Operations there is a point
in the troubleshooting process at which a smart engineer needs to
escalate the case. So from a technical point of view it's impressive
that a network engineer spends 2 weeks and all of a sudden yells "Hey
folks that was a hardware problem..that's why you had all those CRC
errors". From a business and best practices point of view, however,
after the second hour of observing the issue we've been paying
unnecessary costs and inflicting some irreversible damages to the
business.

2- There are many issues that I can assure you Cisco TAC, your vendor
and your provider are very well aware of them but not necessarily
publicize them.

So based on experience, in cases like this if the first few
troubleshooting techniques do not do the trick, it's absolutely
recommended that you decide to escalate the case and document whatever
action you've taken so far and whatever steps they ask you to take.

HTH

--------------------------
Kambiz Agahian
CCIE (R&S), CCSI, WAASSE, RSSSE
Technical Instructor
CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
Email: kagahian_at_ccbootcamp.com
Toll Free: 877-654-2243
International: +1-702-968-5100
Skype: skype:ccbootcamp?call
FAX: +1-702-446-8012

YES! We take Cisco Learning Credits!

Training And Remote Racks: http://www.ccbootcamp.com

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of

GAURAV MADAN
Sent: Saturday, May 15, 2010 11:25 AM
To: Mahmoud Nossair
Cc: ccielab_at_groupstudy.com
Subject: Re: Serial interface error.

I will be interseted in knowing if this line evr worked fine .. i mean
does this started all of sudden .
Or Is this a new line from telco ?

Gaurav

2010/5/15 Mahmoud Nossair <mahmoud.nossair_at_gmail.com>:
> So did you mean that the problem may be physically, like an
interference or
> something like that? Causing all the errors.
>
>
> Best Regards,
>
> ==============================
> Mahmoud Nossair
>
>
>
> -----Original Message-----
> From: GAURAV MADAN [mailto:gauravmadan1177_at_gmail.com]
> Sent: Saturday, May 15, 2010 9:08 PM
> To: Mahmoud Nossair
> Cc: rdarsey_at_gmail.com; ccielab_at_groupstudy.com
> Subject: Re: Serial interface error.
>
> Guess .. this is not a clock issue .
> This is a V.35 cable .. can go high speeds ( unlike RS232 ) and also
> if there is a clocking problem .. it shd have shown clock not recieved
> ..
>
> DCE is probably configured for 256kbps and DTE is approximately
getting that
> .
>
> Thnx
> Gaurav Madan
> CCIE
>
> On Sat, May 15, 2010 at 11:26 PM, Mahmoud Nossair
> <mahmoud.nossair_at_gmail.com> wrote:
>> Please find the "Show controllers serial 1/3"
>>
>> M4T: show controller:
>> PAS unit 3, subunit 3, f/w version 1-45, rev ID 0x2800001, version 3
>> idb = 0x6256E6E4, ds = 0x625704EC, ssb=0x625708A0
>> Clock mux=0x0, ucmd_ctrl=0xC, port_status=0x74
>> Serial config=0x8, line config=0x200
>> maxdgram=1608, bufpool=78Kb, 120 particles
>> DCD=up DSR=up DTR=up RTS=up CTS=up
>> line state: up
>> cable type : V.35 DTE cable, received clockrate 255840
>>
>> base0 registers=0x3D000000, base1 registers=0x3D002000
>> mxt_ds=0x626EF858, rx ring entries=78, tx ring entries=128
>> rxring=0x3B6CE20, rxr shadow=0x62576E94, rx_head=0
>> txring=0x3B6D0C0, txr shadow=0x62577268, tx_head=34, tx_tail=34,
> tx_count=0
>> throttled=0, enabled=0
>> halted=0, last halt reason=0
>> Microcode fatal errors=0
>> rx_no_eop_err=0, rx_no_stp_err=0, rx_no_eop_stp_err=0
>> rx_no_buf=0, rx_soft_overrun_err=0, dump_err= 0, bogus=0,
mxt_flags=0x0
>> tx_underrun_err=1, tx_soft_underrun_err=1, tx_limited=1(2)
>> tx_fullring=13147591, tx_started=17925099 mxt_flush_count=0
>> rx_int_count=34348762, tx_int_count=31081383
>>
>> Best Regards,
>>
>> ==============================
>> Mahmoud Nossair
>>
>>
>>
>> -----Original Message-----
>> From: rdarsey_at_gmail.com [mailto:rdarsey_at_gmail.com]
>> Sent: Saturday, May 15, 2010 8:49 PM
>> To: Mahmoud Nossair; ccielab_at_groupstudy.com
>> Subject: Re: Serial interface error.
>>
>> What does a "show controllers" show? Any slips? If so clocking may
be an
>> issue. Verify that clock is either provided by the ISP or in the
case of
> a
>> point to point circuit that one side is set to clock source internal
and
> one
>> is set to clock source line.
>>
>> Rick
>> -----Original Message-----
>> From: "Mahmoud Nossair" <mahmoud.nossair_at_gmail.com>
>> Date: Sat, 15 May 2010 19:24:31
>> To: <ccielab_at_groupstudy.com>
>> Subject: Serial interface error.
>>
>> Dear Experts
>>
>> We have some branches connecting to the Head Quarter through a
telecom
>> company, when I running "show interface serial 1/3" I found there are
many
>> errors,
>>
>> I know that there is an errors on the fastethetnet interfaces happens
from
>> collisions duplex mismatch, but I am wondering what is the kind of
the
>> errors will be occurred on the serial interfaces .
>>
>> There is one thing also , we never reach the maximum bandwidth,
although
> we
>> are suffering from a congestion.
>>
>>
>>
>> Here is show interface output:
>>
>>
>>
>> ======================================
>>
>> Serial1/3 is up, line protocol is up
>>
>> Hardware is M4T
>>
>> Internet address is x.x.x.x/30
>>
>> MTU 1500 bytes, BW 2000 Kbit, DLY 20000 usec,
>>
>> reliability 255/255, txload 21/255, rxload 16/255
>>
>> Encapsulation HDLC, crc 16, loopback not set
>>
>> Keepalive set (10 sec)
>>
>> Restart-Delay is 0 secs
>>
>> Last input 00:00:00, output 00:00:00, output hang never
>>
>> Last clearing of "show interface" counters never
>>
>> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:
>> 1154031
>>
>> Queueing strategy: weighted fair
>>
>> Output queue: 0/1000/64/1154031 (size/max total/threshold/drops)
>>
>> Conversations 0/36/256 (active/max active/max total)
>>
>> Reserved Conversations 0/0 (allocated/max allocated)
>>
>> Available Bandwidth 1900 kilobits/sec
>>
>> 30 second input rate 133000 bits/sec, 245 packets/sec
>>
>> 30 second output rate 165000 bits/sec, 134 packets/sec
>>
>> 31407760 packets input, 2687152838 bytes, 0 no buffer
>>
>> Received 41308 broadcasts, 0 runts, 0 giants, 0 throttles
>>
>> 27636 input errors, 27635 CRC, 0 frame, 1 overrun, 0 ignored, 0
abort
>>
>> 16397297 packets output, 3885690293 bytes, 1 underruns
>>
>> 1 output errors, 0 collisions, 3 interface resets
>>
>> 0 output buffer failures, 0 output buffers swapped out
>>
>> 4 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
>>
>> ==============================================================
>>
>>
>>
>> Please any help regarding this issue.
>>
>> Thanks in advance.
>>
>>
>>
>> Best Regards,
>>
>> Mahmoud Nossair
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>>
Received on Mon May 17 2010 - 14:16:43 ART