[mrtg] Re: Cisco switch backplane traffic

Wed Apr 10 22:17:44 MEST 2002

A few 6500 utilization items of interest that I've run 
across while working in the CLI on native IOS are..

switch#sho fab util all
 slot    channel  Ingress %   Egress %
    1          0          1          2
    2          0          0          0
    3          0          1          1
    3          1          1          0
    4          0          0          0
    4          1          1          0

switch#

and

switch#sho cat traf
  traffic meter = 1%   peak = 8%  at  00:04:50 CST Tue Mar 26 2002
switch#

Why the first command only shows numbers for the first
four slots, I don't know. It might have something to do
with the fact that the above switch is equipped with
SFM-128's in slots 5 & 6. Slots 7 and 8 are empty,
but 9 does have a 48 port 10/100 mb RJ45 card. I haven't
gotten around to mapping the 'sho fab util all' 
information to any specific OIDs - no time recently.

For the second command, I am relatively certain that 
.1.3.6.1.4.1.9.5.1.1.32.1.1.1 = traffic meter %
.1.3.6.1.4.1.9.5.1.1.32.1.3.1 = peak %

which match the OIDs that you originally sent out below.

I'm not sure what .1.3.6.1.4.1.9.5.1.1.32.2.1 is.

Since this is native IOS, the good old 1.3.6.1.4.1.9.2.1.57.0 
and 1.3.6.1.4.1.9.2.1.58.0 still mimic the CPU util
numbers found in 'sho proc' however I'm not sure what
these mean in the context of a 6500 running native. I
know they didn't mean much on a hybrid catos-ios 6500.

One caveat I've run into is that the SNMP counters 
where portchannels are involved seem to be quite bogus
on nativ IOS 12.1(8a)E3. There is a known cisco bug, 
CSCdv86024, that confirms problems with output-discard 
counters on 12.1(8a)E3 and I have a hunch that it may 
have implications for other snmp counters on the switch
as well.

Finally, something I've been toying around with in my
head is to write a script that walks all the interfaces,
and summs the input octets and plot that number. Do the
same for output octets and you may actually get some
solid number of what kind of traffic the entire switch
is really seeing. Alas, time constraints have prohibited
me from working on this.

> 
> I am trying to monitor backplane traffic in some of our core Catalyst switches.
> We are trying to answer the question about whether we can add more devices to
> these switches without danger of overloading them.
> 
> The information below is from Cisco's web site and is for the Catalyst 5000, but
> seems to work for the 65xx series as well.  Everyone is responding on the .1.1.8
> OID.
> 
> ================
> 
> > Cisco's documentation indicates that sysTraffic (.1.3.6.1.4.1.9.5.1.1.8) is
> > the OID to watch for backplane utilization.  I was unable to find any
> > instances of the multiple backplane values on the core switches.  I have setup
> > an MRTG to track this on the ten core switches.  If this proves to be a useful
> > metric, we will probably add it to the template for the switches.
> > 
> For traditional Cisco switches that have a single backplane such as the Catalyst
> 5000 series, sysTraffic from the CISCO-STACK-MIB provides the system backplane
> utilization. The sysTraffic measurement equates roughly to the meter of the same
> name on the supervisor card. 
>     .1.3.6.1.4.1.9.5.1.1.8 
>     sysTraffic OBJECT-TYPE 
>     -- FROM CISCO-STACK-MIB 
>     SYNTAX Integer (0..100) 
>     MAX-ACCESS read-only 
>     STATUS Current 
>     DESCRIPTION "Traffic meter value, i.e. the percentage of bandwidth
> utilization for the previous polling interval." 
>     ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1)
> cisco(9) workgroup(5) ciscoStackMIB(1) systemGrp(1) 8 } 
> For switches that contain multiple backplanes, such as the Catalyst 5500, use
> the sysTrafficMeterTable from the CISCO-STACK-MIB. 
>     .1.3.6.1.4.1.9.5.1.1.32 
>     sysTrafficMeterTable OBJECT-TYPE 
>     -- FROM CISCO-STACK-MIB 
>     DESCRIPTION "The system traffic meter table. This table lists the
> traffic meters available in the system." 
>     ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1)
> cisco(9) workgroup(5) ciscoStackMIB(1) systemGrp(1) 32 } 
> 
> ================
> 
> However the numbers are very low.  
> 
>  <<...OLE_Obj...>> 
> 
> We suspect that the peaks are backup traffic at night.  The backplanes are 32
> gbps full duplex, or 16 gbps each direction.  1 percent of that is 160 mbps
> which is a lot of traffic, but we thought there might be more considering the 3
> or 4 to 1 oversubscription we are running on the switches (total bandwidth of
> all active ports is 3 to 4 times the bandwidth of the backplane).
> 
> Has anyone tried this?  Is there a better approach?  Other variables to watch?
> 
> Mike Starkweather
> Anheuser-Busch
> 
> --
> Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
> Archive     http://www.ee.ethz.ch/~slist/mrtg
> FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
> WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi
> 

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi