Re: RMON in hardware

"Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl@empirical.com> Thu, 14 April 1994 02:32 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16118; 13 Apr 94 22:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16112; 13 Apr 94 22:32 EDT
Received: from jarthur.cs.hmc.edu by CNRI.Reston.VA.US id aa24306; 13 Apr 94 22:32 EDT
Received: from jarthur by jarthur.cs.hmc.edu id ac19664; 13 Apr 94 18:56 PDT
Received: from pax.empirical.com by jarthur.cs.hmc.edu id aa17057; 13 Apr 94 17:56 PDT
Received: from karl.william-j-le-petomaine.empirical.com by empirical.com (4.1/SMI-4.1) id AA02926; Wed, 13 Apr 94 17:56:28 PDT
Date: Wed, 13 Apr 1994 17:56:28 -0700
Message-Id: <9404140056.AA02926@empirical.com>
To: steveg@novell.com
Subject: Re: RMON in hardware
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl@empirical.com>
Reply-To: karl@empirical.com
Cc: ppmorris@mailbox.syr.edu, steveg@novell.com, mark@csn.org, snmp@psi.com, rmonmib@jarthur.cs.hmc.edu
X-Orig-Sender: karl@empirical.com
Repository: empirical.com
Originating-Client: william-j-le-petomaine.empirical.com

 > > How can a manger know that the counts that the rmon then gives are
 > > skewed because the agent is only running part time in promiscous
 > > mode? 
 > 
 > It uses the DropEvents object and the captureBufferPacketStatus to indicate
 > that packets have been missed.  It's analogous to a dedicated probe
 > being overrun by more packets than it can process.

Ah.  But overrun situations presumably would lose a random sample (?)
which would average over time.  Going out of promiscous mode would
bias the data towards packets aimed at the MAC/Ethernet address of
the rmon/router.

In other words, I still suspect that a dedicated rmon would give a
better statistical sample than one that goes in/out of promiscous
mode. 

			--karl--