Skip to content

Cisco 6509 Temperature Monitoring with Cacti

Hey Everyone,

I wanted to get some simple intake/exhaust temperatures monitored with Cacti, but I hit a few snags. While I realize perfectly well that this is extremely old information, I couldn’t find anything about it on the InterTubes, so I’m going to post it to this little blog.

I have several 6509 engines, some with slightly varying physical configurations. For example, one particular switch has 6408 blades in slots 3 and 4, and a SUP720 in slot 5. Another has only one 6408, in slot 2, and a SUP720 in slot 5. I was assuming that pulling these values would be a simple cake[snmp]walk, but it turns out things aren’t so simple.

This is the relevant portion of the output from `sh env temp` on switch 1 (slots 3,4,5 populated) :

module 3 outlet temperature: 32C
module 3 inlet temperature: 27C
module 4 outlet temperature: 33C
module 4 inlet temperature: 27C
module 5 outlet temperature: 36C
module 5 inlet temperature: 29C

And this is the output from Switch 2 (slots 2 and 5 populated) :

module 2 outlet temperature: 31C
module 2 inlet temperature: 25C
module 5 outlet temperature: 37C
module 5 inlet temperature: 29C

Things are still hopeful at this point, but when I tried to create data templates for the OIDs, it got a little more interesting.  Using the OIDs returned from an snmpwalk of switch 2, I created data templates (and graph templates) in Cacti to graph the intake and exhaust temperatures for both slots. I discovered that these graphs were either inaccurate or broken when I applied them to switch 1.

I have since discovered that the OID indexing is done by the number of slots populated, and not by the slot number itself. Even if every one of your switches has a SUP720 in slot 5, the correct OIDs to monitor any of the temperature sensors for slot 5 may be different depending on what is in slots 1-4.

Here is the relevant output (with colors & comments) from an snmpwalk of switch 1 (slots 3,4,5 populated) :

enterprises.9.9.91.1.1.1.1.4.1001 = 1  <-- Value for 1st populated slot (6408)
enterprises.9.9.91.1.1.1.1.4.1002 = 32 <-- Value for 1st populated slot
enterprises.9.9.91.1.1.1.1.4.1003 = 27 <-- Value for 1st populated slot
enterprises.9.9.91.1.1.1.1.4.2001 = 1  <-- Value for 2nd populated slot (6408)
enterprises.9.9.91.1.1.1.1.4.2002 = 33 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2003 = 27 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.3002 = 1  <-- Value for 3rd populated slot (SUP720)
enterprises.9.9.91.1.1.1.1.4.3003 = 35 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3004 = 29 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3005 = 41 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3006 = 42 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3007 = 30 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3008 = 30 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3009 = 30 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3010 = 31 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3011 = 31 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3012 = 30 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3016 = 38 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3017 = 37 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3020 = 45 <-- Value for 3rd populated slot
enterprises.9.9.91.1.1.1.1.4.3021 = 25 <-- Value for 3rd populated slot

Let’s compare this output to the same relevent section from switch 2 (slots 2,5 populated) :

enterprises.9.9.91.1.1.1.1.4.1001 = 1  <-- Value for 1st populated slot (6408)
enterprises.9.9.91.1.1.1.1.4.1002 = 29 <-- Value for 1st populated slot
enterprises.9.9.91.1.1.1.1.4.1003 = 23 <-- Value for 1st populated slot
enterprises.9.9.91.1.1.1.1.4.2002 = 1  <-- Value for 2nd populated slot (SUP720)
enterprises.9.9.91.1.1.1.1.4.2003 = 37 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2004 = 29 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2005 = 43 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2006 = 43 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2007 = 30 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2008 = 29 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2009 = 29 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2010 = 29 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2011 = 30 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2012 = 30 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2016 = 35 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2017 = 35 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2020 = 45 <-- Value for 2nd populated slot
enterprises.9.9.91.1.1.1.1.4.2021 = 26 <-- Value for 2nd populated slot

A few things to note here:

  • The index number for the SUP module changes depending on which slots above it are populated.
  • The temperature values returned for the SUP module are significantly more comprehensive than those of the 6408 (this is a no-brainer, but it bears mentioning for ease of reading the output above.)
  • The first entry for each of the 6408 OIDs is “x001” and the value is 1. The temperature readings are “x002” (exhaust) and “x003” (intake), but this is not the case for the SUP720. For the SUP270, the first OID returned is “x002”, and that value is 1. The temperature sensors for egress and ingress return on “x003” and “x004”, respectively. This throws a particularly nasty monkey wrench into the mix when trying to plot these values using data templates.

Now that I know this information, I’m still stuck with a relatively kludgy solution: create individual data templates for each scenario and apply graphs on a per-device basis.  Since I like to automate things, this does stick in my craw, but because I have a fairly low number of 6509s and, as it turns out, only two different physical configuration layouts, it’s acceptable. For now.