Re: RMON in hardware

Michael Scanlon <scanlon@ftp.com> Mon, 11 April 1994 22:53 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13456; 11 Apr 94 18:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13452; 11 Apr 94 18:53 EDT
Received: from jarthur.cs.hmc.edu by CNRI.Reston.VA.US id aa00826; 11 Apr 94 18:53 EDT
Received: from jarthur by jarthur.cs.hmc.edu id ad23460; 11 Apr 94 15:26 PDT
Received: from wd40.ftp.com by jarthur.cs.hmc.edu id aa21339; 11 Apr 94 14:34 PDT
Received: from ftp.com by ftp.com ; Mon, 11 Apr 1994 17:34:18 -0400
Received: from mailserv-D.ftp.com by ftp.com ; Mon, 11 Apr 1994 17:34:18 -0400
Received: from scanlon.128.127.127.91 by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA08122; Mon, 11 Apr 94 17:33:20 EDT
Date: Mon, 11 Apr 1994 17:33:20 -0400
Message-Id: <9404112133.AA08122@mailserv-D.ftp.com>
To: karl@empirical.com
Subject: Re: RMON in hardware
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Michael Scanlon <scanlon@ftp.com>
Cc: tomb@hicomb.hi.com, mark@csn.org, snmp@psi.com, rmonmib@jarthur.cs.hmc.edu
X-Orig-Sender: scanlon@mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Mon Apr 11 17:33:13 1994]
Originating-Client: 128.127.127.91
Content-Length: 1517

==>From karl@empirical.com  Mon Apr 11 16:39:18 1994
==>
==>When there are a zillion packets flying across the net and many have
==>to be routed, which does the box drop first?  The routable packets or
==>the packets for the RMON engine?
==>
==>In other words, when a box has two distinct duties, which does it
==>prefer when placed under load?
==>
After having developed networked MAC level bridges (and I would assume the
same would go for the router space).  When push comes to shove and the
router is banging up against its limit, *and it has the smarts to know the
difference*, it should handle its own management traffic.  It could be that
the reason the traffic level is so high is that it is misconfigured and
the only way to correct the problem (easily) is through network management
(rmon being a specific example).  In the real world, no one will know if
you are forwarding at 65 instead of 68% maximum throughput, they will know
if you are not doing the right thing wrt SNMP.

I have had to hack in gaps in forwarding routines at high volume long
duration scenarios such that management traffic can be accepted and 
executed which then fixed network problems.  

My 2 cents,


==>                --karl--
==>

Mike
--
Mike Scanlon                FTP Software, Inc.            voice: (508) 685-4000
scanlon@ftp.com             2 High Street                 fax:   (508) 659-6105
                            North Andover, MA 01845

______________________________________________________________________