High tx/rx load and throttles

Answered Question
Oct 3rd, 2010

Hi I have VSS running in dev. environment. I get complains about layer 4-7 connectivity issues.

In show interface output I see that something is killing the tx/rx load and also creates throttles.

1) Are throttles caused by the high tx/rx load?

2) Is there a way to see who is causing this load?

2) Is ther a way to increase the tx/rx load? Is it a good solution?

General info

The VSS is running on 2 WS-C6509-E with VS-S720-10G Sup-engines.

Show intreface output

Vlan801 is up, line protocol is up
  Hardware is EtherSVI, address is 0008.e3ff.fd90 (bia 0008.e3ff.fd90)
  Description: XXXX
  Internet address is X.X.X.X/22
  MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec,
    reliability 255/255, txload 254/255, rxload 228/255
  Encapsulation ARPA, loopback not set
  Keepalive not supported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 8w3d
  Input queue: 0/75/1443917/1 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 897409000 bits/sec, 119100 packets/sec
  30 second output rate 1035843000 bits/sec, 168806 packets/sec
  L2 Switched: ucast: 12513609156 pkt, 6053195886976 bytes - mcast: 69803869 pkt, 5556772739 bytes
  L3 in Switched: ucast: 87822918009 pkt, 75668966768217 bytes - mcast: 0 pkt, 0 bytes mcast
  L3 out Switched: ucast: 111629897353 pkt, 103915262306506 bytes mcast: 0 pkt, 0 bytes
     87882911325 packets input, 75673496228520 bytes, 0 no buffer
     Received 52863208 broadcasts (2 IP multicasts)
     0 runts, 0 giants, 4841 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     113026787681 packets output, 104367738025680 bytes, 0 underruns
     0 output errors, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out

Thanks in advance,


Correct Answer by Paolo Bevilacqua about 6 years 4 months ago

Input queue: 0/75/1443917/1 (size/max/drops/flushes);

try increasing input queue to like, 200.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Correct Answer
Paolo Bevilacqua Sun, 10/03/2010 - 07:49

Input queue: 0/75/1443917/1 (size/max/drops/flushes);

try increasing input queue to like, 200.

Timor_SSS Mon, 10/04/2010 - 07:11

Thanks Paolo,

I've raised it to 200 but the drops didn't stop. I've raised again to 500 and it looks like that the drops have stopped.

I still have very high tx/rx load utilization though...

Anyway, thanks for you advice!



Rodney Dunn Mon, 10/04/2010 - 09:55

Input queue drops are almost always indicative of process level traffic happening. You may be able to dump some of the frames utilizing the "sh buffers input-interface packet" to see what those packets are. Then you can decide on how to reduce that traffic at process level. Some platform implementations thorttle the incoming packet rate if the process level input queue is overrun.

As for the tx/rx load get a sniffer trace or try Netflow to see what the traffic is.

Timor_SSS Tue, 10/05/2010 - 00:46

Hi Rodney,

1) When I issue "sh buffers input-interface packet" I gen no output.

2) As I mentuned earlier this is not a case of classic production network but rather a Dev-QA testing network. This VSS aggregates 6 fully populated 7018 switches which serve hundreds of servers and storage systems. Its not that I can say them... "hmmm, your test is suffocating my switch, please stop it".

I know that they are "killing" their systems in this lab. This is the purpose of this lab.

My primary goal is to optimize anything I can in order not to disturb thier tests.

Making the hold-queue larger solved the queue drops and throttles but it didn't solved the high tx/rx load.

I'm thinking to devide this Vlan to several smaller Vlans in order make use of several tx/rx load (queues)

So far it seems that the complains have stopped.

Thanks for you reply!




This Discussion