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
> >>
> >>
> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >>
> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon May 17 2010 - 15:44:21 ART