09-08-2015 08:42 PM - edited 03-08-2019 01:42 AM
Hi , i have the following counters when i run 'sh int' , Whenever the txload goes high ping gets dropped .
but there is 0 frame and 0 ignored .
only time i got a crc error
reliability 255/255, txload 150/255, rxload 45/255
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Please help
09-08-2015 10:48 PM
Hello
The ping might be getting dropped due to interface congestion. With growing traffic, the TX load increases and soon you are unable to send all traffic over the link, especially in a bottleneck situation (e.g. 1 Gb/s LAN link and 10 Mb/s WAN uplink). You should also check the total output drops statistic.
I recommend you apply a QoS policy to limit certain greedy traffic and provide bandwidth guarantees to important traffic.
For reference please see this: http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfcbshp.html
Best regards,
Martin
09-09-2015 09:19 PM
Hi martin ,
The device connected (100Mb ) to gig port ,and the switch up link is 10Gb. the device is working like an tv receiver .
Thanks
09-09-2015 11:50 PM
share the total output of "show interface" of that particular port on which you observed the tx load..
09-09-2015 11:58 PM
GigabitEthernet8/27 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is ()
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 134/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, link type is auto, media type is 10/100/1000-TX
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:06:10, output never, output hang never
Last clearing of "show interface" counters 1d19h
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 316921
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 7000 bits/sec, 2 packets/sec
5 minute output rate 52638000 bits/sec, 5049 packets/sec
5008083 packets input, 2686831711 bytes, 0 no buffer
Received 5006918 broadcasts (4711232 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
661272685 packets output, 844044173824 bytes, 0 underruns
0 output errors, 0 collisions, 4 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
09-11-2015 04:01 AM
As per the above output over the txload, i find that you are transmitting traffic of around 52% currently and rxload which is the receiving traffic of 0.4% which seems to be normal currently. are you facing any packet drops now at this point of time ?
09-14-2015 06:06 AM
Hi
When i reset the device will come up , after sometime i am loosing the icmp reply
Thanks
09-09-2015 12:02 AM
Hi,
When the amount of traffic is more than the interface bandwidth through which the traffic has to pass through then the congestion happens leading to the "Requested timeout's" and packet drops. In that case atleast you need to prioritize the applications that you need to use so as to reduce the bandwidth utilization or else have you proceed with respect to the QOS policy as suggested by Martin..
09-10-2015 06:08 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
As other posters have noted, when you transmission load goes high, you're likely to queue packets, and if the queue overflows, you drop packets. Ping packets, without special QoS, would be as likely as any other packets to be dropped.
For 100 Mbps, you default queue of 40 is probably too shallow. So, besides the option of using QoS, you might try increasing your queue limit.
09-10-2015 06:43 AM
Hi
Thanks , can you share some sample configuration .
How can i know the problem from the device itself or from the switch .
As far as i know since the switch did not ignored any frame , means switch is ok ?
Please correct me if i am wrong
Thanks
09-10-2015 04:49 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
A sample configuration to show what and for what kind of device?
You might try to see if the hold-queue out is accepted on your interface. If so, try a value of 128, and see if that helps.
Sorry, I'm unclear what the other device is.
09-14-2015 06:02 AM
I am using 3650x and 4510r+e Switch
09-14-2015 10:14 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Ah. Well switches often have specific cans, or cannots, for their QoS tuning; as QoS is often implement in hardware. I'm not familiar with new (to me) 3650 switches, and the 4500's QoS will also depend on the supervisor being used.
09-16-2015 08:52 PM
Hi ,
How can i decide whether i really require a qos or not ?. Normally switch will do everything correct ?
Thanks
09-17-2015 02:12 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
I'm unsure what you mean by a switch will do everything.
Regarding whether you need QoS or not, that depends on the needs of your traffic, the mixture of your traffic and the volume of your traffic.
For example, if your traffic was only VoIP, there probably wouldn't be any advantage to having QoS. If your traffic was only FTP, your traffic might or might not benefit from QoS. If your traffic were both VoIP and FTP, often you'll need QoS to "protect" your VoIP traffic from the concurrent FTP traffic.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide