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
- RMON in hardware Mark A. Miller
- Re: RMON in hardware Karl Auerbach, Empirical Tools and Technologies, 408/457-6302
- Re: RMON in hardware Frank Kastenholz
- Re: RMON in hardware Michael Scanlon
- Re: RMON in hardware Andrew Bierman
- Re: RMON in hardware Bhushan Kanekar
- Re: RMON in hardware karl
- Re: RMON in hardware Peter P Morrissey
- Re: RMON in hardware Stephen Grau
- Re: RMON in hardware Peter P Morrissey
- Re: RMON in hardware Karl Auerbach, Empirical Tools and Technologies, 408/427-5280
- Re: RMON in hardware Stephen Grau
- Re: RMON in hardware Karl Auerbach, Empirical Tools and Technologies, 408/427-5280
- Re: RMON in hardware Stephen Grau
- Re: RMON in hardware karl
- Re: RMON in hardware Stephen Grau
- Re: RMON in hardware karl