For a research project I need low timescale interface utilization measurement on a Cisco Nexus 5000 devices and some fabric extenders.

Background: The switch is used to "simulate" an optical network, and traffic is forced pass this switch. I can then simulate fiber cuts by simply shutting down the interface.

To measure results, I need to measure interface utilization in a rather timescale. Sub-second would be ideal, but is not necessary. Getting utilization in 1 second intervals is however the goal.

My first idea was to use IFMIB and query the Interface the Byte Counter. Doing this on a regular interval allows me to calculate the average utilization in the last timeframe. I however observed that counters do not get updated in realtime, but instead each 10 seconds or so, which definitely is not fine-grained enough. Further, if the switch even has little load, the SNMP responses may get in irregular time intervals, which distorts the results.

Another idea was to query the device via Netconf / XML, however the agent is too slow. Second interval polling is not possible here.

My final idea is to use ERSPAN and capture the different VLAN traffic and send it to a management station. There, the VLAN tag can be used to distinguish the Interface, and I need to write some utility which actually counts the packet sizes. In my opinion this may allow second level measurements, but represents some overhead on the other hand (additional machine, and I don't know if Nexus will forward ~7GB/s ERSPAN traffic).

Do you have any other idea how to measure bandwidth on an interface?

2 Answers 2


Your best bet is to tap the links themselves. Use an in-line optical tap or a powered copper tap. This will split the connection off to a secondary cable, which you can then plug into your server for monitoring. You'll have an instantly-accurate, infinitely-granular picture of what's going across the wire.

Edit: If you've got too many links to tap, your only other option I can think of is to SPAN all the ports to a single 10G or 40G interface and monitor that. Keep in mind that you're adding in the processing time for the SPAN, and you may drop traffic depending on oversubscription ratios, etc. Just depends on how much accuracy you really need.

The only way to get a 100% complete, guaranteed measurement of the bandwidth crossing a given link is to tap the link.

  • Hi Keller, thank you for your advice. Unfortunately I need to monitor 19 links in total. While I have one Copper tap, I cannot afford to buy another 18.
    – Daniel
    Aug 11, 2015 at 13:13
  • If you need/want sub-second monitoring, that's the only way I know of to do it. The Nexus platform itself isn't going to be able to give you that level of granularity, not using any method I've ever seen. As you mentioned, you could ERSPAN the traffic to another node, but now you're adding in the switch processing, ERSPAN encapsulation time, and the delivery of those packets. Just depends on how much accuracy you need.
    – Keller G
    Aug 11, 2015 at 13:20

I have found no way to do this on the Nexus 5000s we use. On the Cisco 6500 and 7600 platform, I was able to use rmon history for this (which the Nexuses don't support), as follows:

  1. Enable the SNMP server and define a community for this use: "snmp-server community X RO 3" (RO means read-only, 3 is the snmp version)
  2. On the interface, enable "rmon collection stats Y owner X" where X is the community you set up previously, and Y is a low number index of the stats table, different for each interface (I don't know the max off the top of my head)
  3. On your collection server use SNMP to poll the RMON data at .

I wrote a script that polls it every 60 seconds using something like snmpbulkwalk -Oqn -m '' -v 2c -c X $ip . and puts that data in an RRD, then uses RRD::graph to generate an image of fine-grained usage. There is some intricate logic around getting the "next" 60 seconds of data (IIRC it stores 5 mins of data), which I will leave as an exercise for the reader (or you can message me and I can share my very-me-specific script with you).

I gather Arista has another approach to this, which is called "LANZ" and is described at https://www.arista.com/assets/data/pdf/Whitepapers/Arista_LANZ_Overview_TechBulletin_0213.pdf

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.