Thanks for all the advice. I'm going to definitely use most of what was posted. I appreciate the help.
-Nate ----- Original Message ----- From: "Priscilla Oppenheimer" To: Sent: Tuesday, June 17, 2003 11:50 AM Subject: Re: serial interface discards [7:70752] > 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=70828&t=70752 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
