It is entirely possible that the monitoring software (Lucent Vital Net) is
showing something other than discards.  Unfortunately, that software doesn't
tell us what kind of discards.  The interface information doesn't reflect
what the monitoring sotware is showing so there is no way to confirm.

-Nate

----- Original Message -----
From: "Priscilla Oppenheimer" 
To: 
Sent: Monday, June 16, 2003 10:59 PM
Subject: RE: serial interface discards [7:70752]


> You started the thread by saying that your monitoring software is saying
> that there are discards. What monitoring software is it? Are you sure it's
> referring to the drops that "show int" is displaying? Maybe it means
> something else by "discard."
>
> Priscilla
>
> Nathan wrote:
> >
> > Basically, we have two paths:  One going to the internet, and
> > one going
> > to the Corporate WAN.  We also have redundancy so that if
> > either pipe
> > goes down, the other can be used for whatever service is
> > missing.  In
> > order to do redundancy for the pipe going to Corporate WAN, we
> > needed a
> > netscreen and a Tunnel Interface (netscreen for GRE and Tunnel
> > for
> > IPSEC).  We are also using EBGP for the Corporate WAN
> > redistributing
> > into EIGRP internally.  The access list is used so that EIGRP
> > won't
> > accept default routes from the Internet pipe going to the
> > remote site.
> > I'm not sure if there are any MTU issues with it but as far as
> > high
> > utilization, the traffic is only showing a max / day of 20-30%
> > so I
> > don't think bandwidth is the issue.
> >
> > I would agree that discards are unavoidable in a FA or GE
> > environment,
> > but prior to adding the internet circuit as the default route
> > for the
> > site, there were no discards.
> >
> > I have been to that site but the scenario is different from
> > mine.
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: Monday, June 16, 2003 4:29 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: serial interface discards [7:70752]
> >
> >
> > Nate wrote:
> > >
> > > well, it's a ESF Full T1.
> >
> > What feeds into the T1? If it's a busy Ethernet, especially
> > Fast or
> > Gigabit Ethernet, drops are unavoidable. Even though your stats
> > show
> > that the T1 utilization is only 23/255 (less than 10%), the
> > stats show a
> > moving average for the last 5 minutes, but the drops are since
> > the last
> > time you cleared the counters, 6 hours ago. So at some point,
> > you
> > probably had too much data to send over the 1.5Mbps T1.
> >
> > You need to watch it carefully to see if the drops correspond
> > with high
> > utilization. (I think you said that they do, in fact, which
> > makes
> > sense.)
> >
> > You may simply need more bandwidth. If this is an odd
> > occurence, on the
> > other hand, then perhaps you should check your IDS logs (you do
> > have
> > such a thing? :-) to determine if you were being probed or
> > something.
> >
> > You've probably been to Cisco's site already and found this
> > link:
> >
> > Troubleshooting Input Queue Drops and Output Queue Drops
> >
> > http://www.cisco.com/warp/public/63/queue_drops.html#topic4
> >
> > It says the same thing about drops being unavoidable in some
> > cases, but
> > it also has some links to congestion avoidance and congestion
> > management
> > featuers (advanced queueing) so that you can control what gets
> > dropped.
> >
> > So, what's with the tunnel? Are there any MTU issues with it?
> > Tunnels
> > add overhead and cause packets to get dropped because they
> > don't fit.
> > I'm not sure that would get displayed with the "show int" drops
> > though.
> > It's worth looking into MTU issues though since they are an
> > infamous
> > problems with tunnels, or am I misunderstanding what you're
> > using the
> > tunnel for? I've never seen it used with a distribute list. Can
> > you
> > explain what you're accomplishing with that? Thank-you very
> > much.
> >
> > Priscilla
> >
> >
> >
> > > Here's the running config for that
> > > interface:
> > >
> > > interface Serial0/0
> > >  bandwidth 1544
> > >  ip address x.x.x.2 255.255.255.0
> > >  no ip directed-broadcast
> > >  no ip mroute-cache
> > >  no fair-queue
> > >
> > > here's the config for eigrp 1
> > >
> > > router eigrp 1
> > >  redistribute static
> > >  network x.x.x.0
> > >  distribute-list 25 out Tunnel0
> > >  no auto-summary
> > >
> > > here's the tunnel0 config:
> > >
> > > interface Tunnel0
> > >  bandwidth 1544
> > >  ip address x.x.x.2 255.255.255.0
> > >  no ip directed-broadcast
> > >  tunnel source x.x.x.66
> > >  tunnel destination x.x.x.66
> > >
> > >
> > > ----- Original Message -----
> > > From: "MADMAN"
> > > To:
> > > Sent: Monday, June 16, 2003 2:35 PM
> > > Subject: Re: serial interface discards [7:70752]
> > >
> > >
> > > > I would like to see you config also.  Is this a full or
> > > fractional
> > > > T1?   I don't see any error indications, you may simply be
> > > experiencing
> > > > short, large bursts of traffic hence the output drops.
> > > >
> > > >
> > > >    Dave
> > > >
> > > > Nate wrote:
> > > > > guys,  for some reason, our monitoring software is showing
> > > a bunch of
> > > > > discards on the serial WAN circuit.  The trend of discards
> > > seems to
> > > follow
> > > > > the traffic stream.  Here's the config for the interface:
> > > > >
> > > > > (CISCO3725)
> > > > > Serial0/0 is up, line protocol is up
> > > > >   Hardware is QUICC Serial
> > > > >   Internet address is x.x.x.2/24
> > > > >   MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely
> > > 255/255, load
> > > 23/255
> > > > >   Encapsulation HDLC, loopback not set, keepalive set (10
> > > sec)
> > > > >   Last input 00:00:03, output 00:00:00, output hang never
> > > > >   Last clearing of "show interface" counters 06:29:38
> > > > >   Queueing strategy: fifo
> > > > >   Output queue 0/40, 22454 drops; input queue 0/75, 0
> > drops
> > > > >   5 minute input rate 1000 bits/sec, 0 packets/sec
> > > > >   5 minute output rate 141000 bits/sec, 50 packets/sec
> > > > >      9576 packets input, 722935 bytes, 0 no buffer
> > > > >      Received 3124 broadcasts, 0 runts, 0 giants, 0
> > > throttles
> > > > >      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored,
> > > 0 abort
> > > > >      1605454 packets output, 336655812 bytes, 0 underruns
> > > > >      0 output errors, 0 collisions, 0 interface resets
> > > > >      0 output buffer failures, 0 output buffers swapped
> > out
> > > > >      0 carrier transitions
> > > > >      DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
> > > > >
> > > > > Here's the config for the other end:
> > > > >
> > > > > (CISCO3725)
> > > > > Serial1/1 is up, line protocol is up
> > > > >   Hardware is DSCC4 Serial
> > > > >   Internet address is x.x.x.1/24
> > > > >   MTU 1500 bytes, BW 1544 Kbit, DLY 2000 usec,
> > > > >      reliability 255/255, txload 1/255, rxload 19/255
> > > > >   Encapsulation HDLC, loopback not set
> > > > >   Keepalive set (10 sec)
> > > > >   DTR is pulsed for 1672712 seconds on reset,
> > Restart-Delay
> > > is 1672712
> > > secs
> > > > >   Last input 00:00:01, output 00:00:02, output hang never
> > > > >   Last clearing of "show interface" counters 02:59:32
> > > > >   Input queue: 0/75/0/0 (size/max/drops/flushes); Total
> > > output drops: 0
> > > > >   Queueing strategy: fifo
> > > > >   Output queue: 0/40 (size/max)
> > > > >   5 minute input rate 120000 bits/sec, 53 packets/sec
> > > > >   5 minute output rate 0 bits/sec, 0 packets/sec
> > > > >      966133 packets input, 216228857 bytes, 0 no buffer
> > > > >      Received 1256 broadcasts, 0 runts, 0 giants, 0
> > > throttles
> > > > >      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored,
> > > 0 abort
> > > > >      4380 packets output, 331039 bytes, 0 underruns
> > > > >      0 output errors, 0 collisions, 0 interface resets
> > > > >      0 output buffer failures, 0 output buffers swapped
> > out
> > > > >      0 carrier transitions
> > > > >      DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
> > > > >
> > > > > If anyone could help me figure out why this is happening,
> > > I'd appreciate
> > > > it.
> > > > > Thanks.
> > > > --
> > > > David Madland
> > > > CCIE# 2016
> > > > Sr. Network Engineer
> > > > Qwest Communications
> > > > 612-664-3367
> > > >
> > > > "Government can do something for the people only in
> > > proportion as it
> > > > can do something to the people." -- Thomas Jefferson




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=70796&t=70752
--------------------------------------------------
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