Re: RMON in hardware

[[e-mail]]

>>>> 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.

I am still very skeptical.

To get accurate RMON data you are going to have to avoid dropping out
of promiscous mode.

You say, that you can throw hardware at the problem.  Indeed you'd
have to throw enough hardware to do *both* full Ethernet speed routing
plus RMON.

If that's the case then there would be no need for the mechanism to
drop out of promiscous mode, would there?

If you *do* drop out of promiscous mode, the data will become highly
skewed very quickly because a router is usually the focus of a lot of
traffic.  And that traffic will be counted by the RMON while the other
traffic would not.

As for your point that the packets at the end of the buffer are lost
-- I don't get why that somehow changes my conclusion.

Essentially, my point, is that you should label the RMON in your
product with a warning to its users that says "The data collected by
this RMON device can be highly inaccurate under the following
conditions..."

I don't mind that you are building such a product.  I just feel that
you ought to make sure that users don't start believing that it can
offer many significant digits of accuracy in all situations.
Furthermore I believe it is incumbent upon vendors that make gear of
this nature to give the users all the caveats necessary to know when
the data is questionable.

			--karl--