I have a Cisco Catalyst 6500 with the 720 Supe card. I would like to get the upload and download utilization of a specific port. I would like it from SNMP, I have looked for the correct MIB but no luck. The port I am trying to see is gi2/23.
Cisco – Bandwidth Speeds
bandwidthciscointernetsnmp
Related Solutions
Have you tried walking the MIB/OIDs in question from a management station? After having spent a lot of time w/firmware QA, I've noticed things like show commands are likely to not display correct info, even when the OIDs are poll-able. I recommend using and knowing Net-SNMP tools and utils as debug before trying to poll the information in cacti, observium, etc.
e.g. snmpwalk -v2c -c <community> <routername> 1.3.6.1.4.1.9.9.91 will say "No Such Object available on this agent at this OID" if it's not there
Walking 1.3.6.1.4.1.9 on my IOS-XE box gives a lot (I just need to add the MIBs for description). Then I have something to work with (including other gems that might benefit me for monitoring)
snmpwalk -v2c -c <community> <routername> 1.3.6.1.4.1.9
Check out the MIBs available for 4.2.x on the ASR 9000 @:
That link says that the CISCO-ENTITY-SENSOR-MIB is available, and hasn't been updated since 2007. Edit: it appears that the asr9k-mgbl-p.pie package was not available on the router, as mapped in the ASR9000 MIB list above.
Supplemental info:
Cisco's MIB Locator tool is IOS-only, so check out the directories above above the asr9000 on the FTP link for more info.
Tool: http://tools.cisco.com/ITDIT/MIBS/MainServlet
SNMP ftp dir: ftp://ftp.cisco.com/pub/mibs/supportlists/
For more information on loading MIBs: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00800b4cee.shtml
A really good Cisco SNMP links page: http://www.cisco.com/en/US/tech/tk648/tk362/tk605/tsd_technology_support_sub-protocol_home.html
So first of all show fabric utilization all shows fabric utilization, not CPU utilization. Fabric doesn't have CPU component per se, and you can go all up to 100% of fabric utilization without any adverse effects similar to what CPU causes when nearing to the full load.
Next, the WS-X6548-GE-TX is 8Gbit/s card, so "old" fabric attached LC with 8Gbit/s channel. Internally, it shares buffers per 8 ports on card, so given you're getting 'overrun' errors that typically point to a problem with receiving traffic in timely manner and handing it over to other ports, first thing I'd do is separate incoming 8-port group on the card to separate group. In other words, if there is specific port/group of ports receiving high-volume multicast traffic, I'd move it to separate group on the card - and please rememeber, each consecutive 8 ports is one "group":
This means, among other things, that the 8Gbit/s interface to fabric is statically sliced in 6 groups of 8 ports, out of which each group gets 1Gbit/s maximum. So, if in any given port group (of 8x 10/100/1000 ports) you have ports receiving traffic over 1Gbit/s you'll hit exactly problems you're encountering. That's why my proposal is to move any other ports out of the 8-port group apart from the one interface receiving massive amounts of multicast traffic (it seems it's GigabitEthernet 2/4 in your case). You can find this information literally stated in the release notes:
The aggregate bandwidth of each set of 8 ports (1–8, 9–16, 17–24, 25–32, 33–40, and 41–48) is 1 Gbps."
For better utilization of the physical ports, I'd recommend you take a look at the WS-X6748-GE-TX card, that also has 48 10/100/1000 ports but has also two 20Gbit/s fabric connections. Those 20Gbit/s fabric channels are split between ports 1-24 and 25-48, so you get still oversubscription, but only 24Gbit/s over the 20Gbit/s supported by channel, not 8Gbit/s over 1Gbit/s as in 6548 (so, effectively, 1.2:1 oversubscription in 6748 vs 8:1 in 6548). This should give you space to burst traffic over the link from the sending station and distribute it across the system.
Best Answer
A quick-and-dirty way to get the current utilization would be to poll these OIDs from OLD-CISCO-INTERFACES-MIB:
These give you the same numbers as the "input rate" and "output rate" lines from the output of
show interface. Just replace the "x" with the interface index for Gig2/23 shown inshow snmp mib ifmib ifindex. The MIB states that it's the "five minute exponentially-decayed moving average", but the actual rate matches whatever you've configured withload-intervalon the interface (which defaults to 5 minutes).These OIDs will give you a pretty good point-in-time measurement of the interface's utilization without requiring an external system to keep track of deltas between measurements. However, since it's an exponentially-decayed moving average, it may not be as accurate.