Re: RMON in hardware

Stephen Grau <steveg@novell.com> Thu, 14 April 1994 21:27 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15772; 14 Apr 94 17:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15768; 14 Apr 94 17:27 EDT
Received: from jarthur.cs.hmc.edu by CNRI.Reston.VA.US id aa19705; 14 Apr 94 17:27 EDT
Received: from jarthur by jarthur.cs.hmc.edu id ab27055; 14 Apr 94 13:16 PDT
Received: from newsun.Novell.COM by jarthur.cs.hmc.edu id aa23179; 14 Apr 94 11:36 PDT
Received: from na.SJF.Novell.COM by newsun (4.1/SMI-4.1) id AA00788; Thu, 14 Apr 94 11:36:47 PDT
Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA13488; Thu, 14 Apr 94 11:36:45 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Stephen Grau <steveg@novell.com>
Message-Id: <9404141836.AA13488@na.SJF.Novell.COM>
Subject: Re: RMON in hardware
To: karl@empirical.com
Date: Thu, 14 Apr 1994 11:36:44 -0700
Cc: steveg@novell.com, ppmorris@mailbox.syr.edu, mark@csn.org, snmp@psi.com, rmonmib@jarthur.cs.hmc.edu
In-Reply-To: <9404140056.AA02926@empirical.com> from "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" at Apr 13, 94 05:56:28 pm
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Content-Length: 1441

> 
> 
>  > > 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. 
> 
The idea is to have ample hardware power so you don't expect the probe to
regularly get into this situation.  This feature is intended to preserve
the functionality of core services on the network.  If the probe is regularly
dropping packets you should upgrade the hardware, put it on its own dedicated
machine, etc., so this doesn't happen.

BTW, I don't think you would get a random sample of dropped packets when
a dedicated probe overruns.  All of it's receive buffers would get filled
at the start of a burst of transactions and it would always lose the end
of the burst.  For example, in a broadcast storm, the probe would regularly
lose the end of the storm.

Steve