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