Re: Question about MIB-II's .. evolves into NM question/answer

Anil Rijsinghani <anil@levers.enet.dec.com> Tue, 08 June 1993 18:25 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09133; 8 Jun 93 14:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09129; 8 Jun 93 14:25 EDT
Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa17664; 8 Jun 93 14:25 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA20168; Tue, 8 Jun 93 14:00:58 -0400
X-Resent-To: fddi-mib@CS.UTK.EDU ; Tue, 8 Jun 1993 14:00:57 EDT
Errors-To: owner-fddi-mib@CS.UTK.EDU
Received: from inet-gw-2.pa.dec.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA20147; Tue, 8 Jun 93 14:00:51 -0400
Received: by inet-gw-2.pa.dec.com; id AA01055; Tue, 8 Jun 93 11:00:46 -0700
Received: by us1rmc.bb.dec.com; id AA17788; Tue, 8 Jun 93 13:58:44 -0400
Message-Id: <9306081758.AA17788@us1rmc.bb.dec.com>
Received: from levers.enet; by us1rmc.enet; Tue, 8 Jun 93 13:58:59 EDT
Date: Tue, 8 Jun 93 13:58:59 EDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Anil Rijsinghani <anil@levers.enet.dec.com>
To: magill@dccs.upenn.edu
Cc: snmp@psi.com, fddi-mib@cs.utk.edu
Apparently-To: fddi-mib@cs.utk.edu, snmp@psi.com, magill@dccs.upenn.edu
Subject: Re: Question about MIB-II's .. evolves into NM question/answer

    Token counts (see extract below) and Ring Latency together
    can be used to determine FDDI utilization. (the latter is an
    optional variable in SMT and is not specified in IETF FDDI MIB;
    it'll probably end up in vendor mibs for products which implement
    it.)

    Anil

    ps: I should have said 32-bit below, not 32-byte!


          fddimibMACTokenCts OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "A count that should as closely as possible match
                      the number of times the station has received a
                      token (total of non- restricted and restricted) on
                      this MAC (see ANSI MAC 7.4). This count is
                      valuable for determination of network load."
              REFERENCE
                      "ANSI { fddiMAC 74 }"
              ::= { fddimibMACCountersEntry 1 }

----------------------
Date: Tue, 8 Jun 93 11:46:27 -0400
From: William H. Magill <magill@dccs.upenn.edu>
To: snmp@psi.com
Subject: Question about  MIB-II's .. evolves into NM question/answer

>   Date: Mon, 7 Jun 93 14:23:24 EDT
>   From: Anil Rijsinghani <anil@levers.enet.dec.com>
>
>       As far as the question on whether in and out octet count should be
>       maintained for each FDDI: in theory, yes.  However, given that it's
>       a 32-byte counter, FDDI is fast, and there are better ways
>       to measure FDDI utilization (in a bridge, that's what octet counts
>       are most used for since it operates in 'promiscuous' mode), they
>       won't be as useful as they would be for, say, Ethernet.
>

This is the kind of information/discussion that those of us in the
"operational" end of the networking world desperately need.

I get used to counting octets 'cause they seem to be good things to count
but now that I'm pushing FDDI packets they aren't so good any more.

So what IS a better way to mesasure FDDI Utilziation? (How long the "light
is on" vs "how long it's off?")

The issue for Network Management is "interpretation" and "filtering."

Until we get this kind of informtion widely discussed and disseminated, 
everybody will continue to use ping as their network mangement tool of
first choice - It has a pretty strong concensus on meaning, it doesn't take
much interpretation, a packet either arrived or it didn't and how long it
took. 

William H. Magill                         Manager, PennNet Computing Services
Data Communications and Computing Services (DCCS)  University of Pennsylvania
Internet: magill@dccs.upenn.edu                   magill@eniac.seas.upenn.edu
          magill@upenn.edu