From netramet-owner  Sat Nov  2 18:41:40 1996
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.7.6/8.7.3-ua) id SAA26489 for netramet-outgoing; Sat, 2 Nov 1996 18:36:41 +1300 (NZDT)
Received: from ccu1.auckland.ac.nz (ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.7.6/8.7.3-ua) with ESMTP id SAA26478; Sat, 2 Nov 1996 18:36:38 +1300 (NZDT)
Received: (from nevil@localhost) by ccu1.auckland.ac.nz (8.7.3/8.7.3) id SAA23148; Sat, 2 Nov 1996 18:36:36 +1300 (NDT)
From: J Nevil Brownlee <[email protected]>
Message-Id: <[email protected]>
Subject: Re: rules.rc.ip.new
To: [email protected] (George Tsirtsis)
Date: Sat, 2 Nov 1996 18:36:36 +1300 (NDT)
Cc: [email protected] (NeTraMet mailing list)
In-Reply-To: <Pine.SOL.3.95.961022133559.1781E-100000@gideon> from "George Tsirtsis" at Oct 22, 96 01:38:54 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hello George:

> What I dont understand about  this rule file  (rules.rc.ip.new) is the
> effect that the
> 'tcp_udp' set of rules has. I put # in front of every SourceTranseAddress
> and DestTransAddress and nothing changes at the output.

If one of the 'SourceTransAddress' rules matches, its PushtoAct rule
pushes the port number as SourceTransAddress, then goes to the action
of c_trans_source (where its SourceTransType is pushed).

Commenting out the SourceTrans and Dest Trans rules (as in you note)
will force all packets to the c_bad rule, where both source and dest
ports are pushed.  The point of these rules is to aggregate all
flows to a well-konwn port; if you don't do this you get lots of
flows from a well-known port to lots of randomly-chosen ports.

>                     Furthermore I do
> not understand what any of the  'DestTransAddress & 255.255 = domain:
> Retry, 0;' is used for. Why retry?

The idea of the rule set is to have the well-kown port to be counted as
the source of the flow.  To achieve this, the first group of rules
test the source.  If there is a well-known port as destination (and
not as source) the Retry action forces the meter to try matching
the packet with its direction reversed.

If neither source or destination is well-known, the rule just before
c_bad causes the following two rules to push both source and dest
port numbers from the packet.

> Finally, on 'SourceTransAddress & 255.255 = www:     PushtoAct,
> c_trans_source;'  the packet goes to c_trans_source which does not contane
> any rules. So, the data are lost, is that correct?

c_trans_source and c_trans_only are two labels for the same rule,
the one whivh executes the CountPkt action, i.e. pushes SourceTransType
from the packet and actually counts the flow.

Cheers, Nevil

PS: For more comments on 'writing rules,' have a look at the Internet
   Draft 'Experiences with NeTraMet.'  It's on your favourite ftp
   archive; retrieve it using mget draft-rtfm*

+-----------------------------------------------------------------------+
| Nevil Brownlee                       Director, Technology Development |
| Phone: +64 9 373 7599 x8941          ITSS, The University of Auckland |
|   FAX: +64 9 373 7425        Private Bag 92019, Auckland, New Zealand |
+-----------------------------------------------------------------------C

From netramet-owner  Sat Nov 16 00:29:47 1996
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.7.6/8.7.3-ua) id AAA20240 for netramet-outgoing; Sat, 16 Nov 1996 00:24:57 +1300 (NZDT)
Received: from mailhub.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by mailhost.auckland.ac.nz (8.7.6/8.7.3-ua) with SMTP id AAA20235 for <[email protected]>; Sat, 16 Nov 1996 00:24:54 +1300 (NZDT)
Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by mailhub.axion.bt.co.uk with SMTP (PP);
         Fri, 15 Nov 1996 11:24:06 +0000
Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA06098; Fri, 15 Nov 1996 11:19:50 GMT
Date: Fri, 15 Nov 1996 11:19:49 +0000 (GMT)
From: George Tsirtsis <[email protected]>
To: NeTraMet <[email protected]>
Subject: NeTraMet on FDDI
Message-Id: <Pine.SOL.3.95.961115111641.5988A-100000@gideon>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk

Hello everyone,

I would like to try and use NeTraMet on a FDDI based network. Is that
possible?

Cheers

George Tsirtsis
[email protected]


From netramet-owner  Sat Nov 16 14:09:46 1996
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.7.6/8.7.3-ua) id OAA10885 for netramet-outgoing; Sat, 16 Nov 1996 14:08:48 +1300 (NZDT)
Received: from singapura.singnet.com.sg (singapura.singnet.com.sg [165.21.10.10]) by mailhost.auckland.ac.nz (8.7.6/8.7.3-ua) with ESMTP id OAA10880 for <[email protected]>; Sat, 16 Nov 1996 14:08:45 +1300 (NZDT)
Received: from localhost (jas@localhost) by singapura.singnet.com.sg (8.7.3/8.7.2) with SMTP id JAA07730; Sat, 16 Nov 1996 09:08:36 +0800 (SST)
Date: Sat, 16 Nov 1996 09:08:35 +0800 (SST)
From: Jason Lim <[email protected]>
X-Sender: [email protected]
To: George Tsirtsis <[email protected]>
cc: NeTraMet <[email protected]>
Subject: Re: NeTraMet on FDDI
In-Reply-To: <Pine.SOL.3.95.961115111641.5988A-100000@gideon>
Message-ID: <Pine.OSF.3.93.961116090726.20684D-100000@singapura.singnet.com.sg>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk

Hi,
    It's certainly do-able, we are using it to monitor our FDDI backbone.


On Fri, 15 Nov 1996, George Tsirtsis wrote:

|Hello everyone,
|
|I would like to try and use NeTraMet on a FDDI based network. Is that
|possible?
|
|Cheers
|
|George Tsirtsis
|[email protected]
|


Regards
Jason Lim
SingNet
Singapore Telecoms


From netramet-owner  Mon Nov 18 16:13:22 1996
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.7.6/8.7.3-ua) id PAA23129 for netramet-outgoing; Mon, 18 Nov 1996 15:56:12 +1300 (NZDT)
Received: from ccu1.auckland.ac.nz (ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.7.6/8.7.3-ua) with ESMTP id PAA23124 for <[email protected]>; Mon, 18 Nov 1996 15:56:10 +1300 (NZDT)
Received: (from nevil@localhost) by ccu1.auckland.ac.nz (8.7.3/8.7.3) id PAA09661 for [email protected]; Mon, 18 Nov 1996 15:56:09 +1300 (NDT)
From: J Nevil Brownlee <[email protected]>
Message-Id: <[email protected]>
Subject: NeTraMet on FDDI
To: [email protected] (NeTraMet mailing list)
Date: Mon, 18 Nov 1996 15:56:09 +1300 (NDT)
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hello all:

I've thoroughly tested NeTraMet with FDDI on a Solaris system.
In fact you can use it on any interface which works properly with
libpcap (there were some problems with earlier releases of libpcap,
but they were fixed promptly by the lbl people).

To specify which interface you want to meter, use the -i command-line
option.  For example, on my SPARCStation, I say

  ./NeTraMet -c60 -inf0 -rrules.x_ip    ...

'nf0' is the FDDI interface on this system.

BTW, NeTraMet V3.4 allows you to meter up to four interfaces
at a time, e.g.  ./NeTraMet -c60  -inf0 -ile0   ...

Cheers, Nevil

+-----------------------------------------------------------------------+
| Nevil Brownlee                       Director, Technology Development |
| Phone: +64 9 373 7599 x8941          ITSS, The University of Auckland |
|   FAX: +64 9 373 7425        Private Bag 92019, Auckland, New Zealand |
+-----------------------------------------------------------------------C

From netramet-owner  Thu Nov 28 10:56:08 1996
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.3/8.7.3-ua) id KAA27792 for netramet-outgoing; Thu, 28 Nov 1996 10:39:31 +1300 (NZDT)
Received: from bill-graham.nfic.com (bill-graham.nfic.com [205.231.86.32]) by mailhost.auckland.ac.nz (8.8.3/8.7.3-ua) with ESMTP id KAA27740 for <[email protected]>; Thu, 28 Nov 1996 10:39:05 +1300 (NZDT)
Received: (from rramstad@localhost) by bill-graham.nfic.com (8.7.3/8.7.3) id QAA10434; Wed, 27 Nov 1996 16:38:09 -0500 (EST)
Date: Wed, 27 Nov 1996 16:38:09 -0500 (EST)
Message-Id: <[email protected]>
From: Bob Ramstad <[email protected]>
To: [email protected]
cc: [email protected]
Subject: 3Com SuperStacker 1000 anyone?
Sender: [email protected]
Precedence: bulk

howdy.  i used NeTraMet 3.2 a while back on SunOS when we were
purchasing additional Internet bandwidth and was really pleased when
experimenting with NeTraMet 3.4 on Solaris today.  great package with
many improvements since the earlier rev.

anyhoo, our situation is that we've got a bunch of different equipment
running through a 3Com SuperStacker 1000 12 port switch.  we'd really
like to be able to monitor the inflow and outflow of packets to and
from the Internet through our Cisco routers.  it would also be cool to
be able to access information about how the switch is performing.

in this particular case, because of the switch, there are no suitable
computers to run NeTraMet on the segments where the routers are, i.e.
everything is isolated from each other.

the 3Com SuperStacker 1000 switch supports SNMP RMON from RFC 1271 and
RFC 1757.

question (the obvious) is there any easy way to use NeMaC or nifty to
gather data from this switch?  if not, is there some other freely
available solution which could be used?

this is really my first experimentation with SNMP and any/all help and
pointers more than appreciated.  i'm not a subscriber to this list so
please respond to me directly.  thanks!

-- Bob

PS "nifty" rocks!

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.