Nate wrote: > > It is entirely possible that the monitoring software (Lucent > Vital Net) is > showing something other than discards.
Your monitoring software probably uses the word "discard" for "drop" and is just doing what you have already done, which is "show int." As we have all said, output drops on a serial interface are almost always caused by simply too much traffic. You said that bandwidth usage wasn't the issue, but I agree with the other poster that you may not be getting an accurate picture because of the 5-minute exponential nature of the load stat. See Brad's excellent advice about changing this. You said something about 2 redundant links. Which link is actually getting used? Is load balancing supposed to be occuring? Maybe only one link is getting used and it's overwhelmed. Trace-route might help you with that. Also examining the routing table should help. Your monitoring software may mean something else by "discard." I'm still worried about the tunnel. If I understand it correctly, you've added headers to the traffic to support IPSec. That can cause packets to be too big to support the MTU of the interface. These packets must get "discarded." Unfortunatlely, the only way I know to determine if packets are getting discarded due to an MTU issue is with "debug ip packet detail" which is risky on a production network. Well, the other way, is a WAN sniffer or Ethernet sniffers on both ends of the WAN link to see what's getting across and what isn't and to monitor for any ICMP errors. Folks, how else could he determine if there's an MTU issue? Finally, one last comment to echo Brad's comment. If users aren't complaining, don't worry about the drops! Seriously. As HCB would say, "what problem are you trying to solve?" Good luck with it, regardless. :-) Priscilla > 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=70804&t=70752 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
