jvltech
join:2001-11-06
Charter-WI | receive discards
solarwinds is showing alot of receive discards on a gig 0 interface. What causes these and how do I troubleshoot? |
|
aryoba
Premium,MVM
join:2002-08-22 | Mismatch speed between devices perhaps?  |
|
Covenant
Premium,MVM
join:2003-07-01
England
| reply to jvltech
I am not 100% certain what discards are on SolarWinds but on our SNMP monitoring software, discards are due to either input and/or output drops on an interface. Basically, the hold-queue is getting maxed out and you are dropping packets as a result.
Check your hold-queue setting on the gig interface by the command, show int gig x/x where ever the port/slot is and look for something similar to below:
Input queue: 0/4096/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/4096 (size/max)
In the above example. looking at the first line, there is nothing currently in the hold queue, the max number of packets it can store is 4096 (configured as so and not default) and the number of drops or discards is none.
Flushes is is the number of high-precedence packets that are normally queued over the normal input hold queue limit and that are dropped.
No packets were dropped from the output queue which we will get to later.
On the second line, it just advises that the queueing method is first in first out, hence no fancy queueing going on here.
The third line basically advises the same thing as the input queue, hence how many packets are currently in the queue and what the queue limit is. It is used in association with the output drops seen in the first line above.
So it looks like you are receiving a lot more traffic than the router can handle so you might want to take a look at the type of traffic coming through and working out your action plan from there.
--
If only my employers can see how much effort I put into the Cisco forum. They would then understand why I sleep at my desk. :p |
|
smp606
join:2002-01-16
PA | Excellent information!
Quick question, i am getting a good deal of output drops on my t1 serial interface. Is there a way to tell which device on the network is causing this? |
|
Covenant
Premium,MVM
join:2003-07-01
England
| It may be a number of devices, if you are getting loads of output drops, you can configure "ip accounting" under the serial interface but that just shows you what hosts were the biggest talkers and may not always pin point the culprit as it may also be due to "bursts" in traffic from the least talkative hosts. IP accounting looks at traffic going OUT from an interface.
You can also configure ip route-cache flow under the LAN interface which shows traffic coming IN to the router. That will tell you the hosts, ports in hexadecimal and the number of packets in each flow but it is not cumulative like ip accounting unless the flow is consistent and still active. Once the flow is over, it will disappear from the output.
Depending on how time sensitive your traffic is or how tolerant it is to drops, you may want to implement some type of QoS/traffic-shaping under the serial interface with WRED to not tail drop traffic but randomly drop packets depending on precedence/DSCP but that requires you to mark packets coming in on the LAN interface using a policy-map to mark with high precedence/DSCP packets that are important to the function of the business and then low mark the packets such as internet/ftp/email, and anything else you think should be classified as that.
If your traffic is not latency sensitive, then you can just increase the hold queue but that just increases the delay for the packets at the end of the queue to be sent out (serialisation) so to work out what the middle ground is, is going to require a lot of effort and trial and error unless you get a traffic analyser SPANing the router's LAN interface to see what is actually going through the router and then configuring CBWFQ with WRED combined with traffic-shaping and packet marking on the LAN interface to intentionally drop non-important packets and not drop others unless it has to.
Sorry to go on, but this is a big topic which can't be fully justified in the short paragraphs written above.
Hope it's useful anyhow.
--
If only my employers can see how much effort I put into the Cisco forum. They would then understand why I sleep at my desk.  |
|
smp606
join:2002-01-16
PA
| Great!! Thanks for the info. It all makes sense, as i was seeing a few output drops every once and a while, then when i implemented some QOS for my VoIP traffic, i saw the output drops go way up (because of the service policy out??).
I am sure my QOS setup needs some help as well. Sorry to tie up this thread i will start anothoer more specific one. Thanks for all the help!! |
|
