Thanks Greg. I'm seeing similar behavior on my router. Apparently I need to do some reading the Cisco docs to understand what these represent.
SNMPv2-SMI::enterprises.9.9.166.1.5.1.1.2.34.4419217 = Gauge32: 1593 SNMPv2-SMI::enterprises.9.9.166.1.5.1.1.2.34.14664689 = Gauge32: 1593 SNMPv2-SMI::enterprises.9.9.166.1.7.1.1.1.1593 = STRING: "class-default" SNMPv2-SMI::enterprises.9.9.166.1.7.1.1.2.1593 = "" SNMPv2-SMI::enterprises.9.9.166.1.7.1.1.3.1593 = INTEGER: 3 -----Original Message----- From: Volk,Gregory B [mailto:[email protected]] Sent: Wednesday, September 24, 2014 9:48 AM To: Alan Lehman; [email protected] Subject: RE: DSCP/COS stats on Cisco router The existence of multiple class-default graphs has to do with the cbQosParentObjectsIndex table. This table allows the script to derive the class map name to index number relationship for obtaining the actual qos stat OIDs but it also has functionality concerning match statement and policy map relationships. Because of this the name "class-default" effectively gets overloaded. The choice from the MRTG target generation perspective was either ignore everything named "class-default" or create multiple targets as "class default.<indexnum>". I chose the latter path because my network engineers tell me that the class-default stats are very useful to them even with the ambiguity of multiple class name, index number pairs. The obvious down side is which class-default means what and that is something I leave up to the qos experts who actually configure the routers in my network. My area of focus is stats collection, export, graphing, and alarming, not qos. Sorry I can't provide a more useful answer. Since you probably have more qos background than I do, it may be useful for you to execute some snmpwalk commands and observe the output. Notice in this command that class-default belongs to index number 1593 mrtg@myserver> snmpwalk -v2c -c public myrouter .1.3.6.1.4.1.9.9.166 SNMPv2-SMI::enterprises.9.9.166.1.7.1.1.1.1593 = STRING: "class-default" SNMPv2-SMI::enterprises.9.9.166.1.7.1.1.2.1593 = "" SNMPv2-SMI::enterprises.9.9.166.1.7.1.1.3.1593 = INTEGER: 3 mrtg@myserver> However, in the next command, index number 1508241 gets associated with index number 1593 which we established above as class-default. mrtg@myserver> snmpwalk -v2c -c public myrouter .1.3.6.1.4.1.9.9.166 SNMPv2-SMI::enterprises.9.9.166.1.5.1.1.2.66.15082481 = Gauge32: 1593 <- class-default association to 1593 and 15082481 SNMPv2-SMI::enterprises.9.9.166.1.5.1.1.3.66.15082481 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.166.1.5.1.1.4.66.1907667 = Gauge32: 15082481 <- additional unique index to index associations SNMPv2-SMI::enterprises.9.9.166.1.5.1.1.4.66.9319458 = Gauge32: 15082481 <- additional unique index to index associations SNMPv2-SMI::enterprises.9.9.166.1.5.1.1.4.66.9918016 = Gauge32: 15082481 <- additional unique index to index associations <actual qos counter stats for 15082481 begin here> SNMPv2-SMI::enterprises.9.9.166.1.5.1.1.4.66.15082481 = Gauge32: 66 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.1.66.15082481 = Counter32: 13 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.2.66.15082481 = Counter32: 3097686382 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.3.66.15082481 = Counter64: 58932261230 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.4.66.15082481 = Counter32: 12885 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.5.66.15082481 = Counter32: 783527026 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.6.66.15082481 = Counter64: 55341437135986 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.7.66.15082481 = Gauge32: 23843000 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.8.66.15082481 = Counter32: 12884 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.9.66.15082481 = Counter32: 865096188 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.10.66.15082481 = Counter64: 55337223737852 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.11.66.15082481 = Gauge32: 23823000 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.12.66.15082481 = Counter32: 0 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.13.66.15082481 = Counter32: 2883500 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.14.66.15082481 = Counter64: 2883500 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.15.66.15082481 = Counter32: 0 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.16.66.15082481 = Counter32: 4213398134 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.17.66.15082481 = Counter64: 4213398134 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.18.66.15082481 = Gauge32: 20000 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.19.66.15082481 = Counter32: 0 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.20.66.15082481 = Counter32: 0 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.21.66.15082481 = Counter64: 0 mrtg@myserver> >There are no drops showing up, but the two Pre/Post graphs appears to >be the same. >Can you help me understand what these represent? Just fyi, my multiple class-default graphs on the same router are indeed significantly different. It is also interesting to note that the only class map name that I have seen that leads to multiple name-index pairs is "class-default". This leads me to believe that there is something special about the "class-default" name since it never happens with other class-map/policy-map names. -----Original Message----- From: Alan Lehman [mailto:[email protected]] Sent: Wednesday, September 24, 2014 8:50 AM To: Volk,Gregory B; [email protected] Subject: RE: DSCP/COS stats on Cisco router Greg, Thank you again for sharing your script. It seems to work well with my 2901. I do have a question regarding something I'm seeing in the output. I get four graphs for class-default: class-default.4419217 drops class-default.4419217 Pre/Post Policy bit rate class-default.14664689 drops class-default.14664689 Pre/Post Policy bit rate There are no drops showing up, but the two Pre/Post graphs appears to be the same. Can you help me understand what these represent? -----Original Message----- From: Volk,Gregory B [mailto:[email protected]] Sent: Monday, September 22, 2014 7:44 AM To: Alan Lehman; [email protected] Subject: RE: DSCP/COS stats on Cisco router I've attached cbqos-cfgmaker.txt. This is a perl script that I wrote using mib variables defined in CISCO-CLASS-BASED-QOS-MIB and CISCO-CLASS-BASED-QOS-CAPABILITY. I've had reasonably good luck with it running against several Cisco models including 2900, 6509, 7304, ASR1003, and even all the way back to 7206XVR. One downside to it is that the cbQosIfIndex instance numbers are not necessarily static through some config changes and reboots, but those are rare enough in my environment that it hasn't been a major issue for me. If you are not the intended recipient of this message (including attachments), or if you have received this message in error, immediately notify us and delete it and any attachments. If you do not wish to receive any email messages from us, excluding administrative communications, please email this request to [email protected] along with the email address you wish to unsubscribe. For important additional information related to this email, visit www.edwardjones.com/US_email_disclosure. Edward D. Jones & Co., L.P. d/b/a Edward Jones, 12555 Manchester Road, St. Louis, MO 63131 © Edward Jones. All rights reserved. -----Original Message----- From: mrtg [mailto:[email protected]] On Behalf Of Alan Lehman Sent: Friday, September 19, 2014 3:44 PM To: [email protected] Subject: [mrtg] DSCP/COS stats on Cisco router Hello, I’m new to this list, but have been using mrtg for ages. Recently we implemented COS on our MPLS network. I would like to be able to see traffic on our Cisco 2901 broken down by COS/DSCP classification. Has anyone been able to accomplish this? Thanks, Alan CONFIDENTIALITY NOTICE: This e-mail message including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. _______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg _______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
