Showing the Current Input/Output Rate on a Cisco Device

ciscointerfacejuniper

Is there a way to check the current interface output/input rate on Cisco devices? the interface statistics only give the average over 5 minutes, and monitoring the interface seems to have a very long lag (as it also only shows the updated value over 5 minutes).

When I do a show interface on a Juniper device, it gives the current input/output rate.. is there a way to do this on a Cisco device?

Best Answer

An I/O rate must be over some time period since it is a number of bits per time period, just like your speed in a car is an average of the number of miles per hour. The Cisco device can change the time period for the average of a particular interface with the interface command, load-interval.

Your Juniper has to have a time period over which it averages the number of bits. It may be a one second time period, but you can't get bits per second unless you count the over a one second (or longer) time period.

Normally, you do want an I/O rate averaged over a time period longer than 1 second since it smooths out bursts and gives you a more accurate picture of throughput on an interface.

Related Solutions

Cisco – What causes total output drops on a cisco switch interface

Unless someone is clearing counters you should never see any odometer-type counters (those that increment based on a packet action) decrease, they should always increase. That part sounds like a bug.

As far as what causes output drops in particular, there are so many different causes that it's very difficult to pinpoint it exactly. Sometimes there is congestion inside the switch's backplane and those might show up as output drops on the outgoing interface. In rare circumstances you can also get microbursts that don't show up when polled at 1 minute intervals that quickly overload the interface, but then drop back down very quickly. I would suggest grabbing the SNMP OID for output drops and then graphing that and see how it corresponds to the CLI counter.

Generally speaking, you don't want any output drops as they indicate a packet that did not make it to its destination. But, if you're running your links hot (which you say you're not) they're unavoidable to an extent, mostly due to interior switch buffering, etc.

Cisco – Output Drops on Serial interface: Better queueing or Output queue size

You're right, you wouldn't really see the burstiness easily on SNMP. 1GE can send 1.48Mpps, so it takes very very little time to congest the the 45Mbps, which can handle less than 75kpps.

If your ingress is 1GE and egress is 45Mbps, then obviously the congestion point of 45Mbps will need to drop packets. This is normal and expected. If you increase buffers you'll introduce more delay.
1GE takes 0.45ms to send 40 1500B IP frames, which is right now the amount of burst you can handle. However dequeueing them on the 45Mbps already takes 10ms.

If you don't have any acute problem, I would probably not do anything about it. But if some traffic is more eligible for dropping than other, then you should replace FIFO with class-based queueing. Say maybe you want to prioritize so that more ftp is dropped and less voip.
Then it'll also make more sense to add more buffering on the ftp traffic, as it's not really sensitive to delay.

If you want to try your luck with deeper buffers, something like this should suffice:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

This would cause 50ms buffers on the Serial1 and would allow you to handle up-to 2.25ms burst from single Gige interface.

Best Answer

Related Solutions

Cisco – What causes total output drops on a cisco switch interface

Cisco – Output Drops on Serial interface: Better queueing or Output queue size

Related Topic