From netramet-owner  Tue Jul  4 13:38:24 1995
Received: (from tac@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id NAA08446 for netramet-outgoing; Tue, 4 Jul 1995 13:21:24 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id NAA08130 for <[email protected]>; Tue, 4 Jul 1995 13:19:15 +1200
Received: from ccu1.auckland.ac.nz by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Tue,
4 Jul 1995 13:18:55 GMT+1300
Received: (from nevil@localhost) by ccu1.auckland.ac.nz (8.6.12/8.6.12)
id NAA09021; Tue, 4 Jul 1995 13:18:48 +1200
Date: Tue, 04 Jul 1995 13:18:47 +1200 (NZT)
From: J Nevil Brownlee <[email protected]>
Subject: New version of NeTraMet now available
To: [email protected] (iawg mailing list),
       [email protected] (NeTraMet mailing list),
       [email protected] (ietf mailing list),
       [email protected] (opstats WG mailing list),
       [email protected], [email protected] (IEPG mailing list)
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: ELM [version 2.4 PL23]
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Content-length: 1048
Sender: [email protected]
Precedence: bulk

A new version of NeTraMet, the first implementation of the Internet
Accounting Architecture (outlined in RFC 1272, "Internet Accounting
Background") is now available.

Version 3.2 uses libpcap to access packet headers.  This greatly
increases the range of operating systems on which the NeTraMet meter
can run; binary distribution files are available for Solaris, SunOS,
Irix and linux.  Libpcap also supports FDDI interfaces; this option is
implemented for NeTraMet, but not completely tested.

The full release note (including a brief system description and ftp
distribution sites) is available as

  http://www.auckland.ac.nz/net/Accounting/ntm.Release.note

Cheers, Nevil

+-----------------------------------------------------------------------+
| Nevil Brownlee       [email protected]        Deputy Director |
|   FAX: 64 9 373 7425      Computer Centre, The University of Auckland |
| Phone: 64 9 373 7599 x8941   Private Bag 92019, Auckland, New Zealand |
+-----------------------------------------------------------------------C

From netramet-owner  Wed Jul  5 06:36:30 1995
Received: (from tac@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id GAA25945 for netramet-outgoing; Wed, 5 Jul 1995 06:21:34 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id GAA25442 for <[email protected]>; Wed, 5 Jul 1995 06:07:35 +1200
Received: from nrnsinc.on.ca (rads.dnd.ca)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Wed,
5 Jul 1995 06:07:29 GMT+1300
Received: from nrnsinc.on.ca by nrnsinc.on.ca id <[email protected]>; Tue,
4 Jul 1995 14:07:17 -0400
Date: Tue, 04 Jul 1995 14:07:15 -0400 (EDT)
From: Ken Robinson <[email protected]>
Subject: 4 Gig limits and resetting flows.
To: [email protected]
Reply-to: [email protected]
Message-id: <[email protected]>
Organization: DREnet Network Coordination Centre, 1-613-599-7860, 1-613-990-9302
MIME-version: 1.0
X-Mailer: ELM [version 2.4 PL21]
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Content-length: 1546
Sender: [email protected]
Precedence: bulk

Hello All

Nevil, last week I sent you a message about the 4 Gig limit you have on
the octect counts (and in other places).  I haven't received a reply on
that problem, but when ahead with what I had thought was going to be a
solution.

I have a problem in that I am counting bytes for various TCP/IP services
going through 3 different gateways.   The Rule file is working great now,
except when I have more then 4 gigs pass by the meter.  Eg,  2-3 days of
Usenet News will top 4Gigs, and cause the counter to role over.

I had thought that using the option of Restarting the Flow Data files
(with the NeMaC.flag file) that the counters would also be reset.  This
turns out not to be true.  If they did, this would be a solution to my
problem though.  Each day I reset the flow data files, and never top 4
gigs for any one flow.   Unfortunately the flow information is being
carried over and I am rolling the flow counters.    This makes tallies
difficult as I will have to watch for that roll over and multiply the
number of rollovers by 2^32 to get the real total bytes each month.

Is there any way to reset the flows?

What are others doing about this 4 gig limit?  Or has it not affected
anybody yet?

I've managed to get so close to having this all working perfectly, a
solution to this last problem would clear the way.

Thanks,

--
Ken Robinson
DREnet Network Coordination Centre (NCC)
NRNS Incorporated
Phone: 613.599.7860  Fax: 613.599.7739
135 Michael Cowpland Dr., Suite 302
Kanata, Ontario K2M 2E9

From netramet-owner  Wed Jul  5 20:51:52 1995
Received: (from tac@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id UAA17395 for netramet-outgoing; Wed, 5 Jul 1995 20:36:57 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id UAA16945 for <[email protected]>; Wed, 5 Jul 1995 20:23:44 +1200
Received: from ccu1.auckland.ac.nz by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Wed,
5 Jul 1995 20:23:32 GMT+1300
Received: (from nevil@localhost) by ccu1.auckland.ac.nz (8.6.12/8.6.12)
id UAA25810; Wed, 5 Jul 1995 20:23:28 +1200
Date: Wed, 05 Jul 1995 20:23:27 +1200 (NZT)
From: J Nevil Brownlee <[email protected]>
Subject: Re: 4 Gig limits and resetting flows.
In-reply-to: <[email protected]> from "Ken Robinson" at
Jul 4, 95 02:07:15 pm
To: [email protected]
Cc: [email protected] (NeTraMet mailing list)
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: ELM [version 2.4 PL23]
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Content-length: 2607
Sender: [email protected]
Precedence: bulk

Hello all:

I'm responding to Ken Robinson's note (sorry I didn't manage to do
this earlier).

> I have a problem in that I am counting bytes for various TCP/IP services
> going through 3 different gateways.   The Rule file is working great now,
> except when I have more then 4 gigs pass by the meter.  Eg,  2-3 days of
> Usenet News will top 4Gigs, and cause the counter to roll over.
>
> I had thought that using the option of Restarting the Flow Data files
> (with the NeMaC.flag file) that the counters would also be reset.  This
> turns out not to be true.  If they did, this would be a solution to my
> problem though.  Each day I reset the flow data files, and never top 4
> gigs for any one flow.   Unfortunately the flow information is being
> carried over and I am rolling the flow counters.    This makes tallies
> difficult as I will have to watch for that roll over and multiply the
> number of rollovers by 2^32 to get the real total bytes each month.
>
> Is there any way to reset the flows?
> What are others doing about this 4 gig limit?  Or has it not affected
> anybody yet?

1) No, there's no way to reset the flow counters.  They're SNMP counters,
  which implies they are 32-bit unsigned integers which wrap around.
  This isn't a problem, as long as you collect the flow data at least
  once during each cycle of the counter.

2) To compute the number of counts for a flow between two consecutive
  collections, all you have to do is to read the counter values into
  two unsigned (32-bit) integers and subtract them, **ignoring any
  overflow**.  If you try a few examples you'll see that this gives
  the correct difference between the two counts, even if the counter
  wraps so that the second count is less than the first.  Of course if
  the counter has cycled more than once between samples, you can't
  tell this from the counter values!

3) At Auckland we collect traffic flows every 15 minutes, use the flag
  file to start a new flow data file each day, and run each day's
  flow data file through fd_filter to compute the difference in counts
  for each samples.  You probably don't want to collect that often,
  but what about doing it say every 8 hours?

Cheers, Nevil

+-----------------------------------------------------------------------+
| Nevil Brownlee       [email protected]        Deputy Director |
|   FAX: 64 9 373 7425      Computer Centre, The University of Auckland |
| Phone: 64 9 373 7599 x8941   Private Bag 92019, Auckland, New Zealand |
+-----------------------------------------------------------------------C

From netramet-owner  Thu Jul  6 01:51:55 1995
Received: (from tac@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id BAA27719 for netramet-outgoing; Thu, 6 Jul 1995 01:36:58 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id BAA27560 for <[email protected]>; Thu, 6 Jul 1995 01:32:47 +1200
Received: from nrnsinc.on.ca (rads.dnd.ca)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Thu,
6 Jul 1995 01:32:38 GMT+1300
Received: from nrnsinc.on.ca by nrnsinc.on.ca id <[email protected]>; Wed,
5 Jul 1995 09:32:28 -0400
Date: Wed, 05 Jul 1995 09:32:26 -0400 (EDT)
From: Ken Robinson <[email protected]>
Subject: Re: 4 Gig limits and resetting flows.
In-reply-to: <[email protected]> from
"J Nevil Brownlee" at Jul 5, 95 08:23:27 pm
To: [email protected] (J Nevil Brownlee)
Cc: [email protected], [email protected]
Reply-to: [email protected]
Message-id: <[email protected]>
Organization: DREnet Network Coordination Centre, 1-613-599-7860, 1-613-990-9302
MIME-version: 1.0
X-Mailer: ELM [version 2.4 PL21]
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Content-length: 2165
Sender: [email protected]
Precedence: bulk

Hello all:

> I'm responding to Ken Robinson's note (sorry I didn't manage to do
> this earlier).

Ok.

> 1) No, there's no way to reset the flow counters.  They're SNMP counters,
>    which implies they are 32-bit unsigned integers which wrap around.
>    This isn't a problem, as long as you collect the flow data at least
>    once during each cycle of the counter.

DRATS.

>
> 2) To compute the number of counts for a flow between two consecutive
>    collections, all you have to do is to read the counter values into
>    two unsigned (32-bit) integers and subtract them, **ignoring any
>    overflow**.  If you try a few examples you'll see that this gives
>    the correct difference between the two counts, even if the counter
>    wraps so that the second count is less than the first.  Of course if
>    the counter has cycled more than once between samples, you can't
>    tell this from the counter values!

The problem is that I am not looking for flow rates between two days.
I'm looking for total flows for a month.   My total flow for News in a
month may be 45-55 Gigs.  I need to be able to say at the end of the
month that we transfered 47.5 Gigs of news within the DREnet, 13 Gigs
came in from our World link, and 12 Gigs came in from our Canadian link.

> 3) At Auckland we collect traffic flows every 15 minutes, use the flag
>    file to start a new flow data file each day, and run each day's
>    flow data file through fd_filter to compute the difference in counts
>    for each samples.  You probably don't want to collect that often,
>    but what about doing it say every 8 hours?

I collect every 1 hour (in case of a crash), and turn the files over
every day.  In one day, no single field tops 4 Gigs, but after 2 or 3
days, News will, and a day or two later, the Mbone traffic will.

I think I'm just going to have to figure out a way of finding how many
times I topped the 4 Gig mark and use that for my final calculations.

--
Ken Robinson
DREnet Network Coordination Centre (NCC)
NRNS Incorporated
Phone: 613.599.7860  Fax: 613.599.7739
135 Michael Cowpland Dr., Suite 302
Kanata, Ontario K2M-2E9

From netramet-owner  Fri Jul  7 05:24:39 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id EAA02418 for netramet-outgoing; Fri, 7 Jul 1995 04:24:20 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id DAA01112 for <[email protected]>; Fri, 7 Jul 1995 03:27:04 +1200
Received: from nrnsinc.on.ca (rads.dnd.ca)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
7 Jul 1995 03:26:57 GMT+1300
Received: from nrnsinc.on.ca by nrnsinc.on.ca id <[email protected]>; Thu,
6 Jul 1995 11:26:46 -0400
Date: Thu, 06 Jul 1995 11:26:44 -0400 (EDT)
From: Ken Robinson <[email protected]>
Subject: A couple of Bugs?
To: [email protected]
Cc: [email protected] (Network Coordinator)
Reply-to: [email protected]
Message-id: <[email protected]>
Organization: DREnet Network Coordination Centre, 1-613-599-7860, 1-613-990-9302
MIME-version: 1.0
X-Mailer: ELM [version 2.4 PL21]
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Content-length: 1893
Sender: [email protected]
Precedence: bulk

Hello Nevil and all.

I think I've come across a couple of bugs in version 3.2.

1)  I collect every hour, start a new log file every day and do a keep
alive every 10 minutes.   Every 10 minutes after the log file is restart
for the first hour, I get a new flow file with just the headers in it.  Eg:

##NeTraMet v3.2:   -c3600 -r rules.ncc  128.43.254.254 �  3200 flows  starting a
t 00:50:01 Thu  6 Jul 95
#Format: flowruleset flowindex firsttime sourceadjacentaddress destadjacentaddre
ss  sourcetranstype     sourcetransaddress      tooctets        fromoctets

After a new hourly read is done, it stops.   Bug?

2) I've had problems with one adjacent (ethernet) address.

This address is a bit different has it has a value other then 0 in it's
second byte.   If I have a statement like:

SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-80-2D-00-9A-A6 : Pushto, c_pkt;

I get an error like the following:

NeMaC -f NeMaC.nrns.cfg
NeMaC: NeTraMet Manager & Controller V3.2
Using MIB file: mib.txt
rules.nrns   45: SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-80-2D-00-9A-A6 :
Pushto, c_pkt;
Rule index required !!!
No meters to monitor !!!


If I change the above address to 00-00-2D-00-9A-A6 there are no
complaints.  Unfortunately, that's not the address I need.

Comments?  Solutions?

Thanks,

--
Ken Robinson
DREnet Network Coordination Centre (NCC)
NRNS Incorporated
Phone: 613.599.7860  Fax: 613.599.7739
135 Michael Cowpland Dr., Suite 302
Kanata, Ontario K2M-2E9

From netramet-owner  Fri Jul  7 07:24:25 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id GAA05267 for netramet-outgoing; Fri, 7 Jul 1995 06:24:28 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id GAA04983 for <[email protected]>; Fri, 7 Jul 1995 06:16:35 +1200
Received: from Thuban.AC.HMC.Edu by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
7 Jul 1995 06:16:25 GMT+1300
Received: from THUBAN.AC.HMC.EDU by THUBAN.AC.HMC.EDU (PMDF V4.3-7 #9728)
id <[email protected]>; Thu, 6 Jul 1995 11:16:14 PDT
Date: Thu, 06 Jul 1995 11:16:14 -0700 (PDT)
From: Andy Davenport <[email protected]>
Subject: FWD: A couple of Bugs?
To: [email protected]
Message-id: <[email protected]>
X-VMS-To: IN%"[email protected]"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE
Sender: [email protected]
Precedence: bulk

> I think I've come across a couple of bugs in version 3.2.
>
> 1)  I collect every hour, start a new log file every day and do a k=
eep=20
> alive every 10 minutes.   Every 10 minutes after the log file is re=
start=20
> for the first hour, I get a new flow file with just the headers in =
it.  Eg:
>
> ##NeTraMet v3.2:   -c3600 -r rules.ncc  128.43.254.254 =F8  3200 fl=
ows  starting a
> t 00:50:01 Thu  6 Jul 95                                           =
           =20
> #Format: flowruleset flowindex firsttime sourceadjacentaddress dest=
adjacentaddre
> ss  sourcetranstype     sourcetransaddress      tooctets        fro=
moctets     =20
>
> After a new hourly read is done, it stops.   Bug?=20

I seem to be having the same (or a very similar) problem. I get sever=
al rounds
of just headers after which it begins logging real data. It did not b=
egin working
right on the hour, but later it stops working again, and that occurs =
on the hour.

#Time: 18:11:08 Mon 19 Jun 95 meter Flows from 1 to 172191
#Stats: aps=3D380 apb=3D5 mps=3D753 mpb=3D11 lsp=3D0 avi=3D98.7 mni=
=3D96.3 fiu=3D182 frc=3D0 gci=3D10 rpp=3D26.4=20
tpp=3D0.9 cpt=3D1.1
#Time: 18:15:00 Mon 19 Jun 95 meter Flows from 172190 to 195336
#Stats: aps=3D395 apb=3D5 mps=3D866 mpb=3D15 lsp=3D0 avi=3D98.6 mni=
=3D96.1 fiu=3D319 frc=3D0 gci=3D10 rpp=3D26.4=20
tpp=3D0.9 cpt=3D1.5
#Time: 18:20:00 Mon 19 Jun 95 meter Flows from 1 to 24674
#Stats: aps=3D518 apb=3D9 mps=3D1097 mpb=3D22 lsp=3D0 avi=3D98.3 mni=
=3D96.1 fiu=3D5 frc=3D0 gci=3D10 rpp=3D2.0=20
tpp=3D1.0 cpt=3D1.0 5
#monitor(): frst_row=3D1, nrows=3D20, nxt_row=3D21, end_mark=3D0
1 2 8 2 0.0.0.0 0.0.0.0 0 0 0 126218 0 42972811 0
1 3 8 6 0.0.0.0 0.0.0.0 0 0 0 2470 0 414332 0
1 4 8 12 00-00 00-00 0 0 0 1991 0 274270 0
[...]

I have not been switching to a new file each day. After a few hours o=
r days
it seems to get unhappy again:

#Time: 17:55:00 Tue 20 Jun 95 meter Flows from 8484542 to 8514485
#Stats: aps=3D376 apb=3D5 mps=3D878 mpb=3D18 lsp=3D0 avi=3D98.7 mni=
=3D96.2 fiu=3D185 frc=3D56 gci=3D10 rpp=3D28.1=20
tpp=3D0.9 cpt=3D17
#monitor(): frst_row=3D1, nrows=3D79, nxt_row=3D832, end_mark=3D968
2 7 25981 2 134.173.254.252 134.173.254.250 17 161 0 8697 8699 375820=
8 900341
2 12 25981 2 134.173.4.0 134.173.254.250 17 53 0 86819 173646 1165098=
7 15063830
2 13 25981 2 134.173.32.0 127.0.1.0 0 0 0 3583920 3099505 1433098093 =
337641966
[...]
2 2751 4652177 2 127.0.1.0 134.173.254.20 1 3 1 844 0 59080 0
2 2907 4884162 2 127.0.1.0 134.173.4.23 6 0 25 4424 3722 1197053 2681=
68
2 2960 4969697 2 134.173.64.0 134.173.32.0 0 0 0 39421 37369 4224304 =
30631585
#Time: 18:00:00 Tue 20 Jun 95 meter Flows from 8514484 to 8544538
#Stats: aps=3D448 apb=3D6 mps=3D969 mpb=3D37 lsp=3D0 avi=3D98.4 mni=
=3D95.1 fiu=3D208 frc=3D1 gci=3D10 rpp=3D30.4=20
tpp=3D0.9 cpt=3D1.9
#Time: 18:05:00 Tue 20 Jun 95 meter Flows from 8544537 to 8574453
#Stats: aps=3D315 apb=3D5 mps=3D952 mpb=3D43 lsp=3D0 avi=3D98.9 mni=
=3D95.7 fiu=3D222 frc=3D0 gci=3D10 rpp=3D28.1=20
tpp=3D0.9 cpt=3D1.9
#Time: 18:10:00 Tue 20 Jun 95 meter Flows from 8574452 to 8604472
#Stats: aps=3D380 apb=3D6 mps=3D917 mpb=3D41 lsp=3D0 avi=3D98.7 mni=
=3D96.1 fiu=3D233 frc=3D0 gci=3D10 rpp=3D28.7=20
tpp=3D0.9 cpt=3D1.0

It does not appear to have recovered after another seven days of runn=
ing.
This was using the pre-release 3.2.

                                                   Andy


From netramet-owner  Fri Jul  7 13:15:58 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id MAA25458 for netramet-outgoing; Fri, 7 Jul 1995 12:24:22 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id LAA22564 for <[email protected]>; Fri, 7 Jul 1995 11:45:10 +1200
Received: from mippet.ci.com.au by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
7 Jul 1995 11:42:49 GMT+1300
Received: by mippet.ci.com.au id AA22346 (5.67b/IDA-1.5/CE-1.2); Fri,
7 Jul 1995 09:41:58 +1000
Date: Fri, 07 Jul 1995 09:41:57 +1000 (EST)
From: Munro Saunders <[email protected]>
Subject: Re: 4 Gig limits and resetting flows.
In-reply-to: <[email protected]> from "Ken Robinson" at
Jul 5, 95 09:32:26 am
To: [email protected]
Cc: [email protected], [email protected],
       [email protected] (Richard Perini)
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: ELM [version 2.4 PL24]
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Content-length: 2297
Sender: [email protected]
Precedence: bulk

N.Brownlee:
> > 1) No, there's no way to reset the flow counters.  They're SNMP counters,
> >    which implies they are 32-bit unsigned integers which wrap around.

K.Robinson:
> The problem is that I am not looking for flow rates between two days.
> I'm looking for total flows for a month.   My total flow for News in a
> month may be 45-55 Gigs.  ...
..
> I collect every 1 hour (in case of a crash), and turn the files over
> every day.  In one day, no single field tops 4 Gigs, but after 2 or 3
> days, News will, and a day or two later, the Mbone traffic will.
>
> I think I'm just going to have to figure out a way of finding how many
> times I topped the 4 Gig mark and use that for my final calculations.

I collect every 90 seconds (overkill ?) and these figures are keep for
a month (for trouble shooting - if anything 'unusual' happens they will
include everything known about the flow including ethernet addresses).

Once a day a program produces a compressed form of this data.  At this
point the flow volume from each 90 second interval is rescaled to
kilobytes (rounded up).  The interval is then aggregated to 7.5 minutes.
More intelligent tests are done on what is really 'unusual' and less
data is maintained for 'usual' cases.  This data is not kept in Netramet
format and we may keep in for up to a year.

The rounding up does not appear to produce significant changes.  Our
customers pay fixed fees (so do we this week, I think) so we do not bill
our customers directly on these figures. Although we might negotiate a
change in contract based on them.

We get (only :-) about 1Gb of news a week. So by rescaling down by 1K our
32 bit counters will not overflow for 78 years. (For K.Robinson that
would be less than 2 years.) So with exponential growth this may only be
a short term solution.

(As you might guess although accounting is our primary use for Netramet
trouble shooting is a secondary use.  We have just reengineered our backup
programs to cope with the same problems in the same way, with minimal
consequences due to the rounding up.)

--
Munro Saunders                                          P.O. Box 192,
[email protected]   I am not an official spokesperson for ERSKINEVILLE 2043
61 2 564 6368     IBM, Elvis or Corinthian Engineering. AUSTRALIA

From netramet-owner  Sat Jul  8 03:16:27 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id CAA16174 for netramet-outgoing; Sat, 8 Jul 1995 02:15:36 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id BAA13251 for <[email protected]>; Sat, 8 Jul 1995 01:16:03 +1200
Received: from nrnsinc.on.ca (rads.dnd.ca)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Sat,
8 Jul 1995 01:15:59 GMT+1300
Received: from nrnsinc.on.ca by nrnsinc.on.ca id <[email protected]>; Fri,
7 Jul 1995 09:15:46 -0400
Date: Fri, 07 Jul 1995 09:15:45 -0400 (EDT)
From: Ken Robinson <[email protected]>
Subject: Re: FWD: A couple of Bugs?
In-reply-to: <[email protected]> from "Andy Davenport" at
Jul 6, 95 11:16:14 am
To: [email protected] (Andy Davenport)
Cc: [email protected]
Reply-to: [email protected]
Message-id: <[email protected]>
Organization: DREnet Network Coordination Centre, 1-613-599-7860, 1-613-990-9302
MIME-version: 1.0
X-Mailer: ELM [version 2.4 PL21]
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Content-length: 1174
Sender: [email protected]
Precedence: bulk

> I seem to be having the same (or a very similar) problem. I get sever=
> al rounds
> of just headers after which it begins logging real data. It did not b=
> egin working
> right on the hour, but later it stops working again, and that occurs =
> on the hour.

What are your options for pickup, etc?  You seem to be picking up the
stats every 5 minutes, with only 2xx flows.  That's definately
overkill.   Doing it every hour might be pushing it a bit though if the
meter is a PC.

Are you doing Keepalives?  That seems to be what's causing my extra
logs.

I don't see anything that could be causing your problem from your logs.
A couple of questions:  You said you were running pre-3.2.  Is that the
3.2 beta, or 3.1 release?  The 3.2 release did take some steps to prevent
accidental resets of the meter by other SNMP traffic.   Do you have any
other SNMP traffic?

If it's loosing it's ruleset, perhaps using keep alives to reload the
ruleset would be a good idea.

--
Ken Robinson
DREnet Network Coordination Centre (NCC)
NRNS Incorporated
Phone: 613.599.7860  Fax: 613.599.7739
135 Michael Cowpland Dr., Suite 302
Kanata, Ontario K2M-2E9

From netramet-owner  Sat Jul  8 03:19:02 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id CAA16230 for netramet-outgoing; Sat, 8 Jul 1995 02:16:17 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id BAA13635 for <[email protected]>; Sat, 8 Jul 1995 01:31:12 +1200
Received: from nrnsinc.on.ca (rads.dnd.ca)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Sat,
8 Jul 1995 01:31:03 GMT+1300
Received: from nrnsinc.on.ca by nrnsinc.on.ca id <[email protected]>; Fri,
7 Jul 1995 09:29:52 -0400
Date: Fri, 07 Jul 1995 09:29:51 -0400 (EDT)
From: Ken Robinson <[email protected]>
Subject: Re: 4 Gig limits and resetting flows.
In-reply-to: <[email protected]> from "Munro Saunders" at
Jul 7, 95 09:41:57 am
To: [email protected] (Munro Saunders)
Cc: [email protected], [email protected], [email protected],
       [email protected]
Reply-to: [email protected]
Message-id: <[email protected]>
Organization: DREnet Network Coordination Centre, 1-613-599-7860, 1-613-990-9302
MIME-version: 1.0
X-Mailer: ELM [version 2.4 PL21]
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Content-length: 2495
Sender: [email protected]
Precedence: bulk

> I collect every 90 seconds (overkill ?) and these figures are keep for
> a month (for trouble shooting - if anything 'unusual' happens they will
> include everything known about the flow including ethernet addresses).

90 seconds!  How many flows is that?  So long as you keep your flow
counts below ~3000 peak (for the PC meter), you could expand the time.  I
do a lot of consolidation of the data before sending it off, so I keep my
flows down to <90 always.  In theory, I only need to pick up once a
month.  Of course if the meter crashes, I loose that month's data.

> Once a day a program produces a compressed form of this data.  At this
> point the flow volume from each 90 second interval is rescaled to
> kilobytes (rounded up).  The interval is then aggregated to 7.5 minutes.

Does this not cause 64 byte pings to be shown as 1 K of data?  I guess on
the grand scheme of things it doesn't make much difference in comparison
to WWW traffic.

So every 90 seconds you collect the data, pass it though the filters to
get a flow rate, round the values up, and then save that to disk?
Hmm.  I hadn't previously considered running the filters every collection
(actually, I could do it every time I restarted the logs (1/day)).  Hmm.
This may be the solution.  I was going to do a grand total every month,
but if I instead do a total every day (and /1K), then total those totals
at the end of the month, I should have a working solution.

> The rounding up does not appear to produce significant changes.  Our
> customers pay fixed fees (so do we this week, I think) so we do not bill
> our customers directly on these figures. Although we might negotiate a
> change in contract based on them.

All we're looking for is to watch trends and gauge what bandwidth we
need.  We don't bill anybody, but we do need some justification for
requesting additional bandwidth.

> We get (only :-) about 1Gb of news a week. So by rescaling down by 1K our
> 32 bit counters will not overflow for 78 years. (For K.Robinson that
> would be less than 2 years.) So with exponential growth this may only be
> a short term solution.

We re-transmit the news from a central server to each of the sites
interested (currently 12 running their own servers) which is why we show so
much news traffic.

--
Ken Robinson
DREnet Network Coordination Centre (NCC)
NRNS Incorporated
Phone: 613.599.7860  Fax: 613.599.7739
135 Michael Cowpland Dr., Suite 302
Kanata, Ontario K2M-2E9

From netramet-owner  Sat Jul 15 00:15:02 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id XAA29529 for netramet-outgoing; Fri, 14 Jul 1995 23:07:22 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id WAA27594 for <[email protected]>; Fri, 14 Jul 1995 22:23:02 +1200
Received: from Thuban.AC.HMC.Edu by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
14 Jul 1995 22:22:56 GMT+1300
Received: from THUBAN.AC.HMC.EDU by THUBAN.AC.HMC.EDU (PMDF V4.3-7 #9728)
id <[email protected]>; Fri, 14 Jul 1995 03:22:18 PDT
Date: Fri, 14 Jul 1995 03:22:18 -0700 (PDT)
From: Andy Davenport <[email protected]>
Subject: MIB problems
To: [email protected]
Cc: [email protected]
Message-id: <[email protected]>
X-VMS-To: IN%"[email protected]"
X-VMS-Cc: roger
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

I use HP OpenView which has a MIB browser. You can load MIBs into it.
When I try to load mib/meter-mib-32.txt, OpenView complains. I had to
make two changes to the MIB file to make it load:

(1) At line 354 I changed   STATUS  current   to   STATUS  mandatory

(2) I changed every occurance of   AddressType   to   acctAddressType


                                        Andy

From netramet-owner  Mon Jul 17 16:53:39 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id QAA00987 for netramet-outgoing; Mon, 17 Jul 1995 16:50:16 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id QAA27640 for <[email protected]>; Mon, 17 Jul 1995 16:11:53 +1200
Received: from planet.natlib.govt.nz by ccvcom.auckland.ac.nz
(PMDF V4.3-7 #2864) id <[email protected]>; Mon,
17 Jul 1995 16:11:34 GMT+1300
Received: from baxter.natlib.govt.nz (baxter.natlib.govt.nz [192.122.171.166])
by planet.natlib.govt.nz (8.6.11/8.6.9) with ESMTP id QAA07045 for
<[email protected]>; Mon, 17 Jul 1995 16:11:32 +1200
Received: from NLS1/SpoolDir by baxter.natlib.govt.nz (Mercury 1.21)
; 17 Jul 95 16:17:14 +1200
Received: from SpoolDir by NLS1 (Mercury 1.21); 17 Jul 95 16:17:11 +1200
Date: Mon, 17 Jul 1995 16:17:07 +1200
From: Simon Blake <[email protected]>
Subject: Netramet v3.2 for Linux seg faults?
To: [email protected] (NeTraMet mailing list)
Message-id: <[email protected]>
Organization: National Library of New Zealand
X-Mailer: Pegasus Mail for Windows (v2.01)
Content-transfer-encoding: 7BIT
Priority: normal
Sender: [email protected]
Precedence: bulk

Hi Folks

There's probably a simple answer to this...

I'm trying to get Netramet to work on a Linux box - kernel v1.2.11,
486 33, NE2000 card.

Typing 'NeTraMet -w snmp_name -k' gives me:

NeTraMet: Network Traffic Meter V3.2
Running on mir, interface eth0
Segmentation fault

and NeTraMet exists, not surprisingly...  This happens regardless of
whether I use the precompiled distribution, or my own compilation.
Libpcap is going OK, because TCPDump is working fine on this machine.

Any bright ideas?

Cheers
Si
--
Simon Blake                                         Ph:  +64 4 474-3000 x8674
Datacommunication Analyst                           Fax: +64 4 474-3161
National Library, Molesworth St, Wellington, NZ
Email: [email protected]
This is opinion

From netramet-owner  Mon Jul 17 22:07:50 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id VAA16119 for netramet-outgoing; Mon, 17 Jul 1995 21:07:51 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id UAA14304 for <[email protected]>; Mon, 17 Jul 1995 20:33:40 +1200
Received: from Thuban.AC.HMC.Edu by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Mon,
17 Jul 1995 20:33:32 GMT+1300
Received: from THUBAN.AC.HMC.EDU by THUBAN.AC.HMC.EDU (PMDF V4.3-7 #9728)
id <[email protected]>; Mon, 17 Jul 1995 01:32:58 PDT
Date: Mon, 17 Jul 1995 01:32:58 -0700 (PDT)
From: Andy Davenport <[email protected]>
Subject: What are "tts" and "tsu"?
To: [email protected]
Message-id: <[email protected]>
X-VMS-To: IN%"[email protected]"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

I am still having problems with 3.2.  The meter (running on a PC) seems to
get confused after a period of time. It always seems to break in less than
one day. NeMaC (Solaris) is apparently still able to query the meter, but
it only records the Time and Stats lines in the file. Recovery only occurs
by ESCaping the PC and restarting NeTraMet.

Also, I am concerned about the numbers being reported for "tts" and "tsu".
The manual says "tts" is total count tables allocated, and "tsu" is count
tables in use. I find that "tts" rises quickly to 3584, but "tsu" seems
to increase monotonically forever. When it gets past 32767 it reports
values like 4294934550. Is this a feature or a bug?

                                              Andy

P.S. the meter PC is a Pentium if it matters.

P.P.S. Nevil, Could we have a brief explanation of the MIB files found
      in the /mib directory? Thanks.


Here are some Stats lines after starting:

#Stats: aps=462 apb=7 mps=1069 mpb=21 lsp=0 avi=98.3 mni=94.5 fiu=150 frc=0
gci=10 rpp=24.8 tpp=0.9 cpt=1.0 tts=3072 tsu=137
#Stats: aps=361 apb=5 mps=986 mpb=18 lsp=0 avi=98.7 mni=94.2 fiu=181 frc=0
gci=10 rpp=27.0 tpp=0.9 cpt=1.0 tts=3584 tsu=164
#Stats: aps=419 apb=6 mps=1117 mpb=42 lsp=0 avi=98.5 mni=92.8 fiu=179 frc=13
gci=10 rpp=25.6 tpp=0.9 cpt=1.1 tts=3584 tsu=172
#Stats: aps=438 apb=6 mps=920 mpb=36 lsp=0 avi=98.4 mni=95.7 fiu=163 frc=46
gci=10 rpp=25.6 tpp=0.9 cpt=1.1 tts=3584 tsu=200


Here are some as we go past the value of "tts":

#Stats: aps=446 apb=5 mps=852 mpb=14 lsp=0 avi=98.4 mni=96.4 fiu=223 frc=0
gci=10 rpp=36.4 tpp=1.0 cpt=1.0 tts=3584 tsu=3537
#Stats: aps=464 apb=5 mps=872 mpb=16 lsp=0 avi=98.3 mni=96.1 fiu=248 frc=0
gci=10 rpp=35.8 tpp=1.0 cpt=1.0 tts=3584 tsu=3561
#Stats: aps=440 apb=6 mps=905 mpb=25 lsp=0 avi=98.4 mni=95.9 fiu=264 frc=3
gci=10 rpp=36.8 tpp=1.0 cpt=1.0 tts=3584 tsu=3578
#Stats: aps=461 apb=5 mps=887 mpb=13 lsp=0 avi=98.3 mni=96.0 fiu=232 frc=58
gci=10 rpp=34.2 tpp=0.9 cpt=1.0 tts=3584 tsu=3600
#Stats: aps=465 apb=6 mps=991 mpb=24 lsp=0 avi=98.3 mni=95.2 fiu=251 frc=0
gci=10 rpp=33.8 tpp=0.9 cpt=1.0 tts=3584 tsu=3618
#Stats: aps=500 apb=6 mps=1744 mpb=37 lsp=0 avi=98.2 mni=87.5 fiu=256 frc=0
gci=10 rpp=36.6 tpp=1.0 cpt=1.0 tts=3584 tsu=3623


And here are some as we go past 32767:

#Stats: aps=405 apb=6 mps=885 mpb=14 lsp=0 avi=98.6 mni=96.0 fiu=197 frc=0
gci=10 rpp=28.9 tpp=0.9 cpt=1.1 tts=3584 tsu=32721
#Stats: aps=360 apb=5 mps=900 mpb=19 lsp=0 avi=98.7 mni=95.8 fiu=217 frc=0
gci=10 rpp=29.6 tpp=0.9 cpt=1.0 tts=3584 tsu=32740
#Stats: aps=372 apb=5 mps=922 mpb=17 lsp=0 avi=98.7 mni=95.6 fiu=233 frc=9
gci=10 rpp=30.0 tpp=0.9 cpt=1.0 tts=3584 tsu=32764
#Stats: aps=363 apb=5 mps=1329 mpb=26 lsp=0 avi=98.7 mni=70.1 fiu=198 frc=63
gci=10 rpp=30.8 tpp=0.9 cpt=1.1 tts=3584 tsu=4294934550
#Stats: aps=355 apb=6 mps=995 mpb=30 lsp=0 avi=98.8 mni=95.4 fiu=210 frc=0
gci=10 rpp=28.6 tpp=0.9 cpt=1.1 tts=3584 tsu=4294934560
#Stats: aps=305 apb=4 mps=848 mpb=14 lsp=0 avi=99.0 mni=96.8 fiu=227 frc=0
gci=10 rpp=28.5 tpp=0.9 cpt=1.0 tts=3584 tsu=4294934573


From netramet-owner  Tue Jul 18 21:08:23 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id UAA09954 for netramet-outgoing; Tue, 18 Jul 1995 20:08:02 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id TAA06837 for <[email protected]>; Tue, 18 Jul 1995 19:11:17 +1200
Received: from [39.11.22.239] (mac239.ietf33.nordu.net)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Tue,
18 Jul 1995 19:10:09 GMT+1300
Date: Tue, 18 Jul 1995 19:08:43 +1300
From: [email protected] (Nevil Brownlee)
Subject: Re: What are "tts" and "tsu"?
X-Sender: [email protected] (Unverified)
To: Andy Davenport <[email protected]>, [email protected]
Message-id: <v01510100ac30fe13e48b@[39.11.22.239]>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

Hello Andy:

I'm at the IETF meeting in Stockholm right now, and won't be home until around
10 Aug 95, so I won't be able to really fix your problem until then.

However I've had a brief look at it; tts is the number of slots available
in hash tables.  There is one has table for each count in your rule file,
so tts stays steady.  tsu is supposed to be the number of slots used, so of
course it shouldn't get bigger than tts - clearly there's a bug, which I'll
work on
over the next day or three.

Two further questions for you:  1) how often do you collect flows (I can't
see that from the statistics lines), and 2) Can you try running the NeTraMet
meter on a Unix system (to check that the bug isn't PC-specific)?

Cheers, Nevil

+-----------------------------------------------------------------------+
| Nevil Brownlee       [email protected]        Deputy Director |
|   FAX: 64 9 373 7425      Computer Centre, The University of Auckland |
| Phone: 64 9 373 7599 x8941   Private Bag 92019, Auckland, New Zealand |
+-----------------------------------------------------------------------M



From netramet-owner  Thu Jul 20 09:48:01 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id JAA09007 for netramet-outgoing; Thu, 20 Jul 1995 09:08:11 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id IAA07068 for <[email protected]>; Thu, 20 Jul 1995 08:38:42 +1200
Received: from Thuban.AC.HMC.Edu by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Thu,
20 Jul 1995 08:37:32 GMT+1300
Received: from THUBAN.AC.HMC.EDU by THUBAN.AC.HMC.EDU (PMDF V4.3-7 #9728)
id <[email protected]>; Wed, 19 Jul 1995 13:37:14 PDT
Date: Wed, 19 Jul 1995 13:37:14 -0700 (PDT)
From: Andy Davenport <[email protected]>
Subject: Another solid lead on a bug.
To: [email protected]
Message-id: <[email protected]>
X-VMS-To: IN%"[email protected]"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

> Two further questions for you:  1) how often do you collect flows (I can't
> see that from the statistics lines),

Every five minutes. I have not seen "fiu" get as high as 800, and I never
lose packets, so I assume the meter is able to handle the load.

> and 2) Can you try running the NeTraMet
> meter on a Unix system (to check that the bug isn't PC-specific)?

Unfortunately not very easily. I will put it on the list of things to
do. We did run it there once with v3.1, but we had lots of problems with
it colliding with the SNMP agent on that machine. I may be able to find
another machine to use.

I have another symptom, and this one is very solid. When we ran v3.1 we
found that an SNMP query of the ipForwarding attribute would kill the
PC meter dead. When I got 3.2 I tried this right away. I must not have
been paying attention because while 3.2 does keep it from falling over dead,
the same SNMP query still damages it. Perhaps the SNMP code still has a bug
but some other change in 3.2 handles it more gracefully.

One possible additional clue is that after sending the ipForwarding query,
the entire acctRuledata branch of the SNMP tree seems to disappear from
the meter. This is as queried by HP OpenView. I can send you a complete
SNMP dump both before and after if you want.

Note also that the ipForwarding query will kill it even if sent to the
just-booted meter running the default ruleset. It will still accept a
ruleset download, but nothing works again until the meter is reinvoked
from the DOS prompt.

Thanks again very much.

                                           Andy

From netramet-owner  Fri Jul 21 05:09:37 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id EAA20154 for netramet-outgoing; Fri, 21 Jul 1995 04:08:18 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id DAA19297 for <[email protected]>; Fri, 21 Jul 1995 03:45:20 +1200
Received: from [39.11.22.239] (mac239.ietf33.nordu.net)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
21 Jul 1995 03:44:51 GMT+1300
Date: Fri, 21 Jul 1995 03:43:30 +1300
From: [email protected] (Nevil Brownlee)
Subject: Re: Another solid lead on a bug.
X-Sender: [email protected]
To: Andy Davenport <[email protected]>, [email protected]
Message-id: <v01510100ac3412430e77@[39.11.22.239]>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

Hello again Andy:

>> 1) how often do you collect flows (I can't
>>              see that from the statistics lines),>
>
>Every five minutes. I have not seen "fiu" get as high as 800, and I never
>lose packets, so I assume the meter is able to handle the load.

That's nice to know.tht!  I've checked out why tsu increases indefinitely.
This is a bug.  the n_hash_ents variable (reported by tsu) is incremented
whenever a new hash chain is created, but I've forgotten todecrement it
when a hash chain is freed up during garbage collection.  Garbage
collection **is** done properly (otherwise the meter would crash much more
frequently), it's just the tsu= value which is incorrect.  I'll make a
patched version available shortly after I get home round 10 Aug 95.

>> and 2) Can you try running the NeTraMet
>> meter on a Unix system (to check that the bug isn't PC-specific)?
>
>Unfortunately not very easily. I will put it on the list of things to
>do. We did run it there once with v3.1, but we had lots of problems with
>it colliding with the SNMP agent on that machine. I may be able to find
>another machine to use.

OK, thanks.

>I have another symptom, and this one is very solid. When we ran v3.1 we
>found that an SNMP query of the ipForwarding attribute would kill the
>PC meter dead. When I got 3.2 I tried this right away. I must not have
>been paying attention because while 3.2 does keep it from falling over dead,
>the same SNMP query still damages it. Perhaps the SNMP code still has a bug
>but some other change in 3.2 handles it more gracefully.

Ah me, I thought I'd fixed this kind of problem!  I'velooked through the
source code, and can't see any obvious reason why this happens.  I'll have
to do some debugginh - thanks very much for the very detailed problem
description.

By the way, right now NeTraMet doesn't implement very many of the IP MIB
(such as IpForwarding) variables. Would users like to suggest which ones it
would be useful to implement?  This would make it easier to use NeTraMet
with Network Management systems other then NeMaC.

Cheers, Nevil

+-----------------------------------------------------------------------+
| Nevil Brownlee       [email protected]        Deputy Director |
|   FAX: 64 9 373 7425      Computer Centre, The University of Auckland |
| Phone: 64 9 373 7599 x8941   Private Bag 92019, Auckland, New Zealand |
+-----------------------------------------------------------------------M



From netramet-owner  Fri Jul 21 09:09:23 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id IAA28897 for netramet-outgoing; Fri, 21 Jul 1995 08:08:33 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id HAA27047 for <[email protected]>; Fri, 21 Jul 1995 07:31:17 +1200
Received: from Thuban.AC.HMC.Edu by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
21 Jul 1995 07:31:04 GMT+1300
Received: from THUBAN.AC.HMC.EDU by THUBAN.AC.HMC.EDU (PMDF V4.3-7 #9728)
id <[email protected]>; Thu, 20 Jul 1995 12:30:57 PDT
Date: Thu, 20 Jul 1995 12:30:57 -0700 (PDT)
From: Andy Davenport <[email protected]>
Subject: Desired MIB variables. Was: RE: Another solid lead on a bug.
To: [email protected]
Message-id: <[email protected]>
X-VMS-To: IN%"[email protected]"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

> By the way, right now NeTraMet doesn't implement very many of the IP MIB
> (such as IpForwarding) variables. Would users like to suggest which ones it
> would be useful to implement?  This would make it easier to use NeTraMet
> with Network Management systems other then NeMaC.

I don't need much, and I should point out that I don't need the ipForwarding
attribute at all. The only reason it comes up is that network management
packages seem to like to query it to see if that IP address represents a
router that they should know about. I only need the meter to reject them
gracefully. Beyond that, since NeMaC seems to "mother" the meter quite
effectively my only request would be for health-of-the-meter variable(s)
that I can watch independently via HP OpenView and from which I can generate
alarms if something is wrong. The acctActiveFlows, acctLostPackets, and
acctCurrentRuleSet go a long way in this regard. Since these variables
return reasonable values now even when the meter has been damaged by the
ipForwarding query, it does provoke thought on how we might construct a
more meaningful health indicator. Also, assuming we can devise bulletproof
health criteria, it would be of great value if the meter would make
herculean effort to send a last-gasp SNMP trap if/when it is dying.

Since we see NeTraMet as serving both accounting and network management
purposes, having MIB variables for any ethernet flotsam that are easily
cataloged (runts, bad checksums, etc) and are already being sensed by the
hardware/driver would be nice to have.

Thanks again.

                                                  Andy

From netramet-owner  Fri Jul 21 23:08:28 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id WAA25288 for netramet-outgoing; Fri, 21 Jul 1995 22:08:25 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id VAA24213 for <[email protected]>; Fri, 21 Jul 1995 21:40:51 +1200
Received: from [39.11.22.239] (mac239.ietf33.nordu.net)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
21 Jul 1995 21:40:44 GMT+1300
Date: Fri, 21 Jul 1995 21:39:22 +1300
From: [email protected] (Nevil Brownlee)
Subject: Re: What are "tts" and "tsu"?
X-Sender: [email protected]
To: Andy Davenport <[email protected]>, [email protected]
Message-id: <v01510100ac342268743b@[39.11.22.239]>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

At 01:32 7/17/95, Andy Davenport wrote:

>P.P.S. Nevil, Could we have a brief explanation of the MIB files found
>       in the /mib directory? Thanks.

The files in the mib/ direectory are:

43134 Feb 12 18:19 meter-mib-31.txt
43761 Jun 14 15:08 meter-mib-32.txt
                       The accounting meter mib for NeTraMet v3.1 and 3.2

2176 Nov 25  1994 mib.auckland
                       Auckland local variables for the meter.  These are
                       implementation-specific ones, used for NeTraMet's
                       'statistics' info

20150 May 25  1993 mib-1.txt
                       IP MIB-I, as set out in RFC 1156.  Part of the original
                       CMU SNMP distribution.

40472 Jun  2 09:00 mib.txt
                       The MIB which NeMaC expects to use.  Includes the 3.2
                       meter variables, all of mib.auckland, and a little of
                       mib-1

Cheers, Nevil

+-----------------------------------------------------------------------+
| Nevil Brownlee       [email protected]        Deputy Director |
|   FAX: 64 9 373 7425      Computer Centre, The University of Auckland |
| Phone: 64 9 373 7599 x8941   Private Bag 92019, Auckland, New Zealand |
+-----------------------------------------------------------------------M



From netramet-owner  Wed Jul 26 11:09:57 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id KAA07001 for netramet-outgoing; Wed, 26 Jul 1995 10:09:07 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id JAA04045 for <[email protected]>; Wed, 26 Jul 1995 09:32:21 +1200
Received: from Thuban.AC.HMC.Edu by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Wed,
26 Jul 1995 09:32:00 GMT+1300
Received: from THUBAN.AC.HMC.EDU by THUBAN.AC.HMC.EDU (PMDF V4.3-7 #9728)
id <[email protected]>; Tue, 25 Jul 1995 14:31:45 PDT
Date: Tue, 25 Jul 1995 14:31:45 -0700 (PDT)
From: Andy Davenport <[email protected]>
Subject: Packet direction swapping with RETRY
To: [email protected]
Message-id: <[email protected]>
X-VMS-To: IN%"[email protected]"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

I use the Retry action to force a preferred order for the addresses.
I am getting peculiar results--perhaps I don't understand exactly
what is/should be happening. Here are two lines representing two
different flows from the same flow file. AA-00-04-00-17-04 is the
ethernet address of IP address 134.173.239.111 which I force to be
in the destination position using retry. The question is: why do
the ethernet addresses not match up (source vs. destination) with
the IP addresses? Are the ethernet addresses also swapped when retry
is invoked? How about the other attributes and counts?

00-00-0C-05-50-B9   AA-00-04-00-17-04   127.0.0.1   134.173.239.111
AA-00-04-00-17-04   00-00-1D-01-80-3B   127.0.0.1   134.173.239.111

I should note that 134.173.239.111 is an assumed address to protect
the guilty. Also, the IP address 127.0.0.1 is not ever supposed to
appear on the wire. That is why these caught my attention. I assume
that represents a local network problem.

Thanks as always.

                                                Andy

From netramet-owner  Wed Jul 26 14:11:00 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id NAA21533 for netramet-outgoing; Wed, 26 Jul 1995 13:09:07 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id MAA17753 for <[email protected]>; Wed, 26 Jul 1995 12:25:42 +1200
Received: from cc-server9 (cc-server9.massey.ac.nz)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Wed,
26 Jul 1995 12:12:24 GMT+1300
Received: from cc-swdev1.massey.ac.nz (actually cc-swdev1)
by cc-server9 with SMTP(PP); Wed, 26 Jul 1995 12:08:10 +1200
Received: from massey.ac.nz by cc-swdev1.massey.ac.nz id
<[email protected]>; Wed, 26 Jul 1995 12:08:03 +1200
Date: Wed, 26 Jul 1995 12:08:03 +1200
From: Glen Eustace <[email protected]>
Subject: Modified Logging
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
X-Sun-Charset: US-ASCII
X-Signmail: 1.1. A Mailtool extension by Clay Luther.
Sender: [email protected]
Precedence: bulk

I am using netramet to provide as close to real time charging for traffic
as I can.  The meter is in a low volume subnet and seems at this stage to
be working well ( a DX4/100 with a PCI SMCPwr Combo card ).

The charging application needed to process the flow files as soon as
possible so the polling rate has been set to 60secs.  The difficulty was
that NeMaC holds the flow files open.  I have changed NeMaC so that it will
open, append and then close the flow files.  Now my charging application can
steal the flow files from underneath NeMaC.

Nevil,

Can this alternative form of logging be included in a latter version ?
It would be nice if it were another cmd line option so that it can be
applied on a meter by meter basis.


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Glen Eustace, Systems Manager                        | Phone: +64 6 350 5161
Computing Services, Massey University                | Fax:   +64 6 350 5607
Palmerston North, New Zealand.                       |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

From netramet-owner  Thu Jul 27 06:12:37 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id FAA16331 for netramet-outgoing; Thu, 27 Jul 1995 05:09:18 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id FAA16127 for <[email protected]>; Thu, 27 Jul 1995 05:05:23 +1200
Received: from Thuban.AC.HMC.Edu by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Thu,
27 Jul 1995 05:05:10 GMT+1300
Received: from THUBAN.AC.HMC.EDU by THUBAN.AC.HMC.EDU (PMDF V4.3-7 #9728)
id <[email protected]>; Wed, 26 Jul 1995 10:04:57 PDT
Date: Wed, 26 Jul 1995 10:04:57 -0700 (PDT)
From: Andy Davenport <[email protected]>
Subject: FWD: Modified Logging
To: [email protected]
Message-id: <[email protected]>
X-VMS-To: IN%"[email protected]"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

> I am using netramet to provide as close to real time charging for traffic
> as I can.  The meter is in a low volume subnet and seems at this stage to
> be working well ( a DX4/100 with a PCI SMCPwr Combo card ).
>
> The charging application needed to process the flow files as soon as
> possible so the polling rate has been set to 60secs.  The difficulty was
> that NeMaC holds the flow files open.  I have changed NeMaC so that it will
> open, append and then close the flow files.  Now my charging application can
> steal the flow files from underneath NeMaC.

On what platform are you running NeMaC? I have a similar requirement, but
I am having no trouble doing what you request on a Sun/Solaris using NeMaC
out of the box. In fact I use "tail -f" to follow updates as they are posted
to the flow file. I do note that fd_filter and fd_extract seem to buffer
their output hence there is a delay. This should be fixable with some kind
of buffer flushing after each output.

> Nevil,
>
> Can this alternative form of logging be included in a latter version ?
> It would be nice if it were another cmd line option so that it can be
> applied on a meter by meter basis.

> Glen Eustace, Systems Manager                        | Phone: +64 6 350 5161

                                              Andy Davenport

From netramet-owner  Thu Jul 27 09:07:44 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id IAA23476 for netramet-outgoing; Thu, 27 Jul 1995 08:09:12 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id HAA22539 for <[email protected]>; Thu, 27 Jul 1995 07:50:57 +1200
Received: from cc-server9 (cc-server9.massey.ac.nz)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Thu,
27 Jul 1995 07:50:52 GMT+1300
Received: from cc-swdev1.massey.ac.nz (actually cc-swdev1)
by cc-server9 with SMTP(PP); Thu, 27 Jul 1995 07:49:46 +1200
Received: from massey.ac.nz by cc-swdev1.massey.ac.nz id
<[email protected]>; Thu, 27 Jul 1995 07:49:39 +1200
Date: Thu, 27 Jul 1995 07:49:39 +1200
From: Glen Eustace <[email protected]>
Subject: Re: Modified Logging
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
X-Sun-Charset: US-ASCII
X-Signmail: 1.1. A Mailtool extension by Clay Luther.
Sender: [email protected]
Precedence: bulk

Several people have asked me what I did so I have extracted my changes.
They are available from

ftp://cc-swdev2.massey.ac.nz/pub/NeMaC.diffs

I am not using fd_filter but am analysing the flows directly in my accounting
application.

This raises another point, which I believe has already been discussed on this
list.  I am raising it again only because I wasn't part of the list then and
the ground may have shifted a bit.

I found analysing the flows for accounting purposes was more of a pain than
it might have been.  It would be nice if the flow data logged by NeMaC could
be a delta rather than an absolute.  i.e. if the counters in netramet for
each active flow were zeroed after being collected then each collection
would be autonomous.  As it is, one must keep a flow history to work out
real time volumes.  Could this be a cmd line option as well ?


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Glen Eustace, Systems Manager                        | Phone: +64 6 350 5161
Computing Services, Massey University                | Fax:   +64 6 350 5607
Palmerston North, New Zealand.                       |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

From netramet-owner  Thu Jul 27 10:41:06 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id KAA02037 for netramet-outgoing; Thu, 27 Jul 1995 10:09:44 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id JAA29550 for <[email protected]>; Thu, 27 Jul 1995 09:36:40 +1200
From: [email protected]
Received: from watson.ibm.com by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Thu,
27 Jul 1995 09:36:21 GMT+1300
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3)
with BSMTP id 9035; Wed, 26 Jul 95 17:35:44 EDT
Date: Wed, 26 Jul 1995 17:24:47 -0400 (EDT)
Subject: Re: Modified Logging
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

Reference:  Attached snippet from [email protected]

>
> This raises another point, which I believe has already been discussed on this
> list.  I am raising it again only because I wasn't part of the list then and
> the ground may have shifted a bit.
>
> I found analysing the flows for accounting purposes was more of a pain than
> it might have been.  It would be nice if the flow data logged by NeMaC could
> be a delta rather than an absolute.  i.e. if the counters in netramet for
> each active flow were zeroed after being collected then each collection
> would be autonomous.  As it is, one must keep a flow history to work out
> real time volumes.  Could this be a cmd line option as well ?
>

 This does sound nice, but there are at least two reasons against it...

1) What happens if the meter sends off its flow information and "erases" the
   old data and the packet with the data is subsequently lost?

2) I believe that the meter purposely does NOT zero the counters in order
   to support multiple collectors. Two or more collectors can poll the meter
   without stepping on each other. (Probably not too many people are using
   more than one collector right now, but if you really want to make sure
   that you don't lose anything - say due to a failure of the collecting
   machine, you might want to consider it.)


                                    Stephen Stibler


P.S. I am fairly new here, and think I missed that original discussion, but
     this is the way I see things right now.


From netramet-owner  Thu Jul 27 19:09:55 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id SAA15830 for netramet-outgoing; Thu, 27 Jul 1995 18:09:18 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id SAA15078 for <[email protected]>; Thu, 27 Jul 1995 18:00:40 +1200
Received: from decgat (tlrouter.motctl.gov.tw)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Thu,
27 Jul 1995 18:00:25 GMT+1300
Received: by decgat (5.57/Ultrix3.0-C) id AA00864; Thu, 27 Jul 95 14:07:59 +0800
Received: by jugar.tlnm (4.1/SMI-4.1) id AA01469; Wed, 26 Jul 95 11:33:00 CST
Date: Wed, 26 Jul 1995 11:33:00 -0600 (CST)
From: jason%[email protected] (Lin Jeng-Sen)
Subject: [Q}: Packets Counters and Rule Set Number
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

Hello, Nevil,

 I try to edit a new rules file, "rules.myown" and use the NeMaC to
collect the data. Here is the rules file:

***************************************************************************
#
SET 2
#
RULES
 SourcePeerType & 255 = IP:         Pushto, IP_pkt;
 Null & 0 = 0:                      Ignore, 0;
#
IP_pkt:
 SourcePeerAddress & 255.255.255.0 = 140.133.18.0:   PushPkttoAct,count_pkt;
#
count_pkt:
 Null & 0 = 0:  Count, 0;  # Source and Dest Peer Address pushed above
#
STATISTICS
#
FORMAT FlowRuleSet FlowIndex FirstTime "  "
  SourcePeerType SourcePeerAddress DestPeerAddress "  "
  ToPDUs FromPDUs "  " ToOctets FromOctets;
#
# end of file
****************************************************************************

 In this rules file, I wish to count the IP packets send from the
"140.133.18.0" subnet to somewhere else. And the result is :


##NeTraMet v3.2:   -c60 -r rules.myown  nm8301 le0  2600 flows  starting at 16:48:13 Tu e 25 Jul 95
#Format: flowruleset flowindex firsttime  sourcepeertype sourcepeeraddress destp
eeraddress  topdus frompdus  tooctets fromoctets
#Time: 16:48:13 Tue 25 Jul 95 nm8301 Flows from 1 to 112100
#Stats: aps=0 apb=0 mps=0 mpb=0 lsp=0 avi=0.0 mni=0.0 fiu=3 frc=0 gci=10 rpp=0.0
tpp=0.0 cpt=1.0 tts=0 tsu=0
1 2 200  2 0.0.0.0 0.0.0.0  8209 0  1312268 0
1 3 2400  12 00-00 00-00  197 0  11936 0
1 4 2800  6 0.0.0.0 0.0.0.0  152 0  15596 0
2 5 112100  2 140.133.18.0 0.0.0.0  9 0  616 0
#Time: 16:49:00 Tue 25 Jul 95 nm8301 Flows from 112099 to 116800
#Stats: aps=0 apb=0 mps=0 mpb=0 lsp=0 avi=0.0 mni=0.0 fiu=4 frc=0 gci=10 rpp=0.0
tpp=0.0 cpt=1.0 tts=512 tsu=1
1 2 200  2 0.0.0.0 0.0.0.0  8209 0  1312268 0
2 5 112100  2 140.133.18.0 0.0.0.0  216 3  19692 294

From netramet-owner  Thu Jul 27 21:09:36 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id UAA22171 for netramet-outgoing; Thu, 27 Jul 1995 20:09:38 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id TAA20961 for <[email protected]>; Thu, 27 Jul 1995 19:47:21 +1200
Received: from decgat (tlrouter.motctl.gov.tw)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Thu,
27 Jul 1995 19:47:15 GMT+1300
Received: by decgat (5.57/Ultrix3.0-C) id AA02039; Thu, 27 Jul 95 15:53:57 +0800
Received: by jugar.tlnm (4.1/SMI-4.1) id AA02126; Thu, 27 Jul 95 15:36:39 CST
Date: Thu, 27 Jul 1995 15:36:39 -0600 (CST)
From: jason%[email protected] (Lin Jeng-Sen)
Subject: Packet Collection and Rule Set Number
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk


Hello, Nevil,

 I try to edit a new rules file, "rules.myown" and use the NeMaC to
collect the data. Here is the rules file:

#
SET 2
#
RULES
 SourcePeerType & 255 = IP:         Pushto, IP_pkt;
 Null & 0 = 0:                      Ignore, 0;
#
IP_pkt:
 SourcePeerAddress & 255.255.255.0 = 140.133.18.0:     PushPkttoAct,count_pkt;
#
count_pkt:
 Null & 0 = 0:  Count, 0;  # Source and Dest Peer Address pushed above
#
STATISTICS
#
FORMAT FlowRuleSet FlowIndex FirstTime "  "
  SourcePeerType SourcePeerAddress DestPeerAddress "  "
  ToPDUs FromPDUs "  " ToOctets FromOctets;
#
# end of file

 In this rules file, I wish to count the IP packets send from the
"140.133.18.0" subnet to somewhere else. And the result is :

##NeTraMet v3.2:   -c60 -r rules.myown  nm8301 le0  2600 flows  starting at 16:48:13 Tu e 25 Jul 95
#Format: flowruleset flowindex firsttime  sourcepeertype sourcepeeraddress destp
eeraddress  topdus frompdus  tooctets fromoctets
#Time: 16:48:13 Tue 25 Jul 95 nm8301 Flows from 1 to 112100
#Stats: aps=0 apb=0 mps=0 mpb=0 lsp=0 avi=0.0 mni=0.0 fiu=3 frc=0 gci=10 rpp=0.0
tpp=0.0 cpt=1.0 tts=0 tsu=0
1 2 200  2 0.0.0.0 0.0.0.0  8209 0  1312268 0
1 3 2400  12 00-00 00-00  197 0  11936 0
1 4 2800  6 0.0.0.0 0.0.0.0  152 0  15596 0
2 5 112100  2 140.133.18.0 0.0.0.0  9 0  616 0
#Time: 16:49:00 Tue 25 Jul 95 nm8301 Flows from 112099 to 116800
#Stats: aps=0 apb=0 mps=0 mpb=0 lsp=0 avi=0.0 mni=0.0 fiu=4 frc=0 gci=10 rpp=0.0
tpp=0.0 cpt=1.0 tts=512 tsu=1
1 2 200  2 0.0.0.0 0.0.0.0  8209 0  1312268 0
2 5 112100  2 140.133.18.0 0.0.0.0  216 3  19692 294

From netramet-owner  Thu Jul 27 23:09:27 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id WAA27944 for netramet-outgoing; Thu, 27 Jul 1995 22:09:24 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id VAA25729 for <[email protected]>; Thu, 27 Jul 1995 21:24:26 +1200
Received: from Thuban.AC.HMC.Edu by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Thu,
27 Jul 1995 21:24:19 GMT+1300
Received: from THUBAN.AC.HMC.EDU by THUBAN.AC.HMC.EDU (PMDF V4.3-7 #9728)
id <[email protected]>; Thu, 27 Jul 1995 02:24:10 PDT
Date: Thu, 27 Jul 1995 02:24:10 -0700 (PDT)
From: Andy Davenport <[email protected]>
Subject: Re: [Q}: Packets Counters and Rule Set Number
To: [email protected]
Message-id: <[email protected]>
X-VMS-To: IN%"[email protected]"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

I think the output from NeMaC looks correct for the rule file given.
Remember that you will always get a few counts left over from ruleset 1
just after starting the meter because the meter begins counting with
ruleset 1 immediately. The fd_filter utility will ignore them.

The comments in the rule file suggest that perhaps you really meant to
also push the DestPeerAddress like this:

IP_pkt:
 SourcePeerAddress & 255.255.255.0 = 140.133.18.0:   PushPkttoAct, count_pkt;
 Null & 0 = 0:                                       Retry,        0;
#
count_pkt:
 DestPeerAddress   & 255.255.255.0 =            0:   CountPkt,     0;


This tests the SourcePeerAddress to see if it is equal to 140.133.18.0.
If it is, it goes to count_pkt and executes the CountPkt action _without_
testing DestPeerAddress against anything. It does not test DestPeerAddress
because of the "Act" added to the end of "PushPktto". The mask _is_ significant
however, and will determine how much of the DestPeerAddress is pushed by CountPkt.

If the SourcePeerAddress is not equal to 140.133.18.0, then it falls through
to the Retry action which will swap the source and destination, and then start
all over again. If the Retry is encountered a second time (meaning that neither
the SourcePeerAddress or DestPeerAddress was equal to 140.133.18.0) then the
Retry functions as an Ignore.

I hope this helps. If not, please be more specific about what you think the
output *should* look like.

                                                  Andy Davenport


[Original message follows]

Hello, Nevil,

 I try to edit a new rules file, "rules.myown" and use the NeMaC to
collect the data. Here is the rules file:

***************************************************************************
#
SET 2
#
RULES
 SourcePeerType & 255 = IP:         Pushto, IP_pkt;
 Null & 0 = 0:                      Ignore, 0;
#
IP_pkt:
 SourcePeerAddress & 255.255.255.0 = 140.133.18.0:   PushPkttoAct,count_pkt;
#
count_pkt:
 Null & 0 = 0:  Count, 0;  # Source and Dest Peer Address pushed above
#
STATISTICS
#
FORMAT FlowRuleSet FlowIndex FirstTime "  "
  SourcePeerType SourcePeerAddress DestPeerAddress "  "
  ToPDUs FromPDUs "  " ToOctets FromOctets;
#
# end of file
****************************************************************************

 In this rules file, I wish to count the IP packets send from the
"140.133.18.0" subnet to somewhere else. And the result is :


##NeTraMet v3.2:   -c60 -r rules.myown  nm8301 le0  2600 flows  starting at 16:48:13 Tu e 25
Jul 95
#Format: flowruleset flowindex firsttime  sourcepeertype sourcepeeraddress destp
eeraddress  topdus frompdus  tooctets fromoctets
#Time: 16:48:13 Tue 25 Jul 95 nm8301 Flows from 1 to 112100
#Stats: aps=0 apb=0 mps=0 mpb=0 lsp=0 avi=0.0 mni=0.0 fiu=3 frc=0 gci=10 rpp=0.0
tpp=0.0 cpt=1.0 tts=0 tsu=0
1 2 200  2 0.0.0.0 0.0.0.0  8209 0  1312268 0
1 3 2400  12 00-00 00-00  197 0  11936 0
1 4 2800  6 0.0.0.0 0.0.0.0  152 0  15596 0
2 5 112100  2 140.133.18.0 0.0.0.0  9 0  616 0
#Time: 16:49:00 Tue 25 Jul 95 nm8301 Flows from 112099 to 116800
#Stats: aps=0 apb=0 mps=0 mpb=0 lsp=0 avi=0.0 mni=0.0 fiu=4 frc=0 gci=10 rpp=0.0
tpp=0.0 cpt=1.0 tts=512 tsu=1
1 2 200  2 0.0.0.0 0.0.0.0  8209 0  1312268 0
2 5 112100  2 140.133.18.0 0.0.0.0  216 3  19692 294


From netramet-owner  Fri Jul 28 15:50:18 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id PAA26170 for netramet-outgoing; Fri, 28 Jul 1995 15:36:59 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id PAA24485 for <[email protected]>; Fri, 28 Jul 1995 15:17:13 +1200
Received: from decgat (tlrouter.motctl.gov.tw)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
28 Jul 1995 15:16:38 GMT+1300
Received: by decgat (5.57/Ultrix3.0-C) id AA07370; Fri, 28 Jul 95 11:24:24 +0800
Received: by jugar.tlnm (4.1/SMI-4.1) id AA00628; Fri, 28 Jul 95 11:07:05 CST
Date: Fri, 28 Jul 1995 11:07:05 -0600 (CST)
From: jason%[email protected] (Lin Jeng-Sen)
Subject: Re: [Q]: Packets Counters and Rule Set Number
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

Andy,

 Thanks for your answer. However, I failed to post my whole questions on
the last mail, so I post my entire questions again. Please read it and
give me some hints.


--(Original Mail)-----------------------------------------------------------

 I try to edit a new rules file, "rules.myown" and use the NeMaC to
collect the data. Here is the rules file:

#
SET 2
#
RULES
 SourcePeerType & 255 = IP:         Pushto, IP_pkt;
 Null & 0 = 0:                      Ignore, 0;
#
IP_pkt:
 SourcePeerAddress & 255.255.255.0 = 140.133.18.0:     PushPkttoAct,count_pkt;
#
count_pkt:
 Null & 0 = 0:  Count, 0;  # Source and Dest Peer Address pushed above
#
STATISTICS
#
FORMAT FlowRuleSet FlowIndex FirstTime "  "
  SourcePeerType SourcePeerAddress DestPeerAddress "  "
  ToPDUs FromPDUs "  " ToOctets FromOctets;
#
# end of file

 In this rules file, I wish to count the IP packets send from the
"140.133.18.0" subnet to somewhere else. And the result is :

##NeTraMet v3.2:   -c60 -r rules.myown  nm8301 le0  2600 flows  starting at 16:48:13 Tu e 25 Jul 95
#Format: flowruleset flowindex firsttime  sourcepeertype sourcepeeraddress destp
eeraddress  topdus frompdus  tooctets fromoctets
#Time: 16:48:13 Tue 25 Jul 95 nm8301 Flows from 1 to 112100
#Stats: aps=0 apb=0 mps=0 mpb=0 lsp=0 avi=0.0 mni=0.0 fiu=3 frc=0 gci=10 rpp=0.0
tpp=0.0 cpt=1.0 tts=0 tsu=0
1 2 200  2 0.0.0.0 0.0.0.0  8209 0  1312268 0
1 3 2400  12 00-00 00-00  197 0  11936 0
1 4 2800  6 0.0.0.0 0.0.0.0  152 0  15596 0
2 5 112100  2 140.133.18.0 0.0.0.0  9 0  616 0
#Time: 16:49:00 Tue 25 Jul 95 nm8301 Flows from 112099 to 116800
#Stats: aps=0 apb=0 mps=0 mpb=0 lsp=0 avi=0.0 mni=0.0 fiu=4 frc=0 gci=10 rpp=0.0
tpp=0.0 cpt=1.0 tts=512 tsu=1
1 2 200  2 0.0.0.0 0.0.0.0  8209 0  1312268 0
2 5 112100  2 140.133.18.0 0.0.0.0  216 3  19692 294

o
ooooooooooooo(skip)
o

#Time: 08:52:00 Wed 26 Jul 95 nm8301 Flows from 5888799 to 5894800
#Stats: aps=0 apb=0 mps=0 mpb=0 lsp=0 avi=0.0 mni=0.0 fiu=1 frc=0 gci=10 rpp=0.0
tpp=0.0 cpt=1.0 tts=512 tsu=1
2 5 112100  2 140.133.18.0 0.0.0.0  37206 9533  3952097 3156262
                                  ^^^^^^^^^^^^

 My first question is: I don't add any rule about the DestPeerAddress or the
"Retry" action. However, the collecter's result tell me that the "toPDUs" is
37206 and the "fromPDUs" is NOT zero, 9533. Why? I just count the packets
from "140.133.18.xx" to somewhere. Why is the "fromPDUs" not zero? Does it
mean that the NeTraMet will automatically count the "fromPDUs"? If it is true,
then why do we need the "Retry" action?

 In addition, I change the Rules Set Number from 2 to 21 (or any bigger
number) in "rules.myown" files. After I use NeMaC to collect the data
it appears the following error message:


NeMaC: NeTraMet Manager & Controller V3.2
Using MIB file: /home/users/jason/../nm/NeTraMet/mib/mib.txt
Community private doesn't have write access to meter nm8301!
  Collections won't trigger recovery of idle flows <<<
  Meter statistics won't be zeroed after collections <<<


 I use the same community name and just change the rules set's number as 21,
why can it not work?

 Please give me some hints and any kind answers will be greatly appriciated.

------------------------------------------------------------------------------
TTTTTTTTT LLLLL          Mr. Jeng-Sen Lin
T  TTT  T  LLL           jason%[email protected]
  TTT     LLL   L       Telecommunication Laboratories of Information
 TTTTT   LLLLLLLLL o    Technology Laboratory, Taiwan, R.O.C


*****************************************************************************
*****************************************************************************
>
>I think the output from NeMaC looks correct for the rule file given.
>Remember that you will always get a few counts left over from ruleset 1
>just after starting the meter because the meter begins counting with
>ruleset 1 immediately. The fd_filter utility will ignore them.
>
>The comments in the rule file suggest that perhaps you really meant to
>also push the DestPeerAddress like this:
>
>IP_pkt:
>  SourcePeerAddress & 255.255.255.0 = 140.133.18.0:   PushPkttoAct, count_pkt;
>  Null & 0 = 0:                                       Retry,        0;
>#
>count_pkt:
>  DestPeerAddress   & 255.255.255.0 =            0:   CountPkt,     0;
>
>
>This tests the SourcePeerAddress to see if it is equal to 140.133.18.0.
>If it is, it goes to count_pkt and executes the CountPkt action _without_
>testing DestPeerAddress against anything. It does not test DestPeerAddress
>because of the "Act" added to the end of "PushPktto". The mask _is_ significant
>however, and will determine how much of the DestPeerAddress is pushed by CountPkt.
>
>If the SourcePeerAddress is not equal to 140.133.18.0, then it falls through
>to the Retry action which will swap the source and destination, and then start
>all over again. If the Retry is encountered a second time (meaning that neither
>the SourcePeerAddress or DestPeerAddress was equal to 140.133.18.0) then the
>Retry functions as an Ignore.
>
>I hope this helps. If not, please be more specific about what you think the
>output *should* look like.
>
>                                                   Andy Davenport

From netramet-owner  Fri Jul 28 21:10:11 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id UAA17505 for netramet-outgoing; Fri, 28 Jul 1995 20:09:33 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id UAA16178 for <[email protected]>; Fri, 28 Jul 1995 20:00:05 +1200
Received: from Thuban.AC.HMC.Edu by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
28 Jul 1995 20:00:00 GMT+1300
Received: from THUBAN.AC.HMC.EDU by THUBAN.AC.HMC.EDU (PMDF V4.3-7 #9728)
id <[email protected]>; Fri, 28 Jul 1995 00:59:52 PDT
Date: Fri, 28 Jul 1995 00:59:52 -0700 (PDT)
From: Andy Davenport <[email protected]>
Subject: Re: [Q]: Packets Counters and Rule Set Number
To: [email protected]
Message-id: <[email protected]>
X-VMS-To: IN%"[email protected]"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

> IP_pkt:
>   SourcePeerAddress & 255.255.255.0 = 140.133.18.0: PushPkttoAct,count_pkt;
> #
> count_pkt:
>   Null & 0 = 0:  Count, 0;  # Source and Dest Peer Address pushed above
>
> #Time: 08:52:00 Wed 26 Jul 95 nm8301 Flows from 5888799 to 5894800
> #Stats: aps=0 apb=0 mps=0 mpb=0 lsp=0 avi=0.0 mni=0.0 fiu=1 frc=0 gci=10 rpp=0.0
> 2 5 112100  2 140.133.18.0 0.0.0.0  37206 9533  3952097 3156262
>                                   ^^^^^^^^^^^^
> My first question is: I don't add any rule about the DestPeerAddress or the
> "Retry" action. However, the collecter's result tell me that the "toPDUs" is
> 37206 and the "fromPDUs" is NOT zero, 9533. Why? I just count the packets
> from "140.133.18.xx" to somewhere. Why is the "fromPDUs" not zero? Does it
> mean that the NeTraMet will automatically count the "fromPDUs"? If it is true,
> then why do we need the "Retry" action?

Your program as written will fall through to the Count action even when the
previous line does not match. What happens in this case is not clear to me.
I think the manual still reflects the behavior of an earlier version of NeTraMet.
Look at the third paragraph of section 2.6 in the version 3.2 manual. This
seems to suggest that it will swap source and destination when it is looking
for a counter to increment. Since you are performing a Count action even on
packets that you do not mean to count, it may cause this behavior. Perhaps
a packet coming in the "opposite" direction gets counted by the spurious
count action. It is all somewhat mysterious to me too. Try this:

IP_pkt:
 SourcePeerAddress & 255.255.255.0 = 140.133.18.0: PushPkttoAct,count_pkt;
 Null & 0 = 0:  Ignore, 0; # Ignore if above rule fails to match.
#
count_pkt:
 Null & 0 = 0:  Count, 0;  # Source and Dest Peer Address pushed above


Also note that this should be equivalent:

IP_pkt:
 SourcePeerAddress & 255.255.255.0 = 140.133.18.0: CountPkt, 0;
 Null & 0 = 0:  Ignore, 0; # Ignore if above rule fails to match.

(On page 14 of the manual it says that CountPkt executes a PushPktto action
followed by a Count action.)


> In addition, I change the Rules Set Number from 2 to 21 (or any bigger
> number) in "rules.myown" files. After I use NeMaC to collect the data
> it appears the following error message:

There are some #defines in the source file flowhash.h. One of them is:

#define MXRTBLS     10  /* Max nbr of rule tables */

If you really need more rule tables, you should try increasing this number
and recompiling the source.

I hope this helps.

                                               Andy


From netramet-owner  Sat Jul 29 09:10:48 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id IAA17120 for netramet-outgoing; Sat, 29 Jul 1995 08:09:29 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id HAA15956 for <[email protected]>; Sat, 29 Jul 1995 07:33:29 +1200
Received: from merlion.singnet.com.sg by ccvcom.auckland.ac.nz
(PMDF V4.3-7 #2864) id <[email protected]>; Sat,
29 Jul 1995 07:33:23 GMT+1300
Received: (from gmlim@localhost) by merlion.singnet.com.sg (8.6.11/8.6.11)
id DAA05818; Sat, 29 Jul 1995 03:33:17 +0800
Date: Sat, 29 Jul 1995 03:33:16 +0800 (SST)
From: Lim Gek Meng <[email protected]>
Subject: netramet on FDDI
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

Hi,

has anyone tried using netramet(on a PC) and sticking it on a FDDI
backbone. Have heard that even on a SUN, we probably can't get more than
5000pps due to some kernel issues.

Hope I am talking sense here..

thanks

From netramet-owner  Mon Jul 31 20:32:55 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id UAA07617 for netramet-outgoing; Mon, 31 Jul 1995 20:17:47 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id UAA07563 for <[email protected]>; Mon, 31 Jul 1995 20:16:33 +1200
Received: from decgat (tlrouter.motctl.gov.tw)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Mon,
31 Jul 1995 20:16:22 GMT+1300
Received: by decgat (5.57/Ultrix3.0-C) id AA17256; Mon, 31 Jul 95 16:24:16 +0800
Received: by jugar.tlnm (4.1/SMI-4.1) id AA16338; Mon, 31 Jul 95 16:06:47 CST
Date: Mon, 31 Jul 1995 16:06:47 -0600 (CST)
From: jason%[email protected] (Lin Jeng-Sen)
Subject: Re: [Q]: Packets Counters
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk


Andy,

>Look at the third paragraph of section 2.6 in the version 3.2 manual. This
>seems to suggest that it will swap source and destination when it is looking
>for a counter to increment. Since you are performing a Count action even on
>packets that you do not mean to count, it may cause this behavior. Perhaps
>a packet coming in the "opposite" direction gets counted by the spurious
>count action. It is all somewhat mysterious to me too. Try this:
>
 In the second paragraph of section 2.6, it say:

"  If the match fails, the keys are "interchanged" and the packet is tested
against the rules again. If it fails this time it is discarded"

 Does it mean that NeTraMet will "automatically" interchange the source and
destination and re-test or will need to use "Retry" action to force this
behaviour?

 In the last 2 paragraphs of section 2.6, it says that we can use
symmetrical counts or enforce a particular "source-to-destination" order.
These statements confuse me........

 For example, if I want to count the packets send from every host in
my network, I use the following rule file:

#
SET 4
#
RULES
 SourcePeerType & 255 = IP:         PushtoAct, IP_pkt;
 Null & 0 = 0:                      Ignore, 0;
#
IP_pkt:
 SourcePeerAddress & 255.255.255.255 = 0:     PushPkttoAct, count_pkt;
 Null & 0 = 0:                      Ignore, 0;
#
count_pkt:
 Null & 0 = 0:  Count, 0;  # Source and Dest Peer Address pushed above
#
STATISTICS
#
FORMAT FlowRuleSet FlowIndex FirstTime LastTime "  "
  SourcePeerType SourcePeerAddress "  "
  ToPDUs FromPDUs "  " ToOctets FromOctets;
#
# end of file

 However, it can't work correctly. For example, if there is one flow count
the packets from source A, and no any flow count the packets from source B.
Now if B send one packet to A, we wish it will create one flow for B and
increase the "toPDU" in that flow. But the result is not what I want!!!
It just increase the "fromPDU" counter of the flow of source A.

 I wish to count all packets A to ...; B to .....; C to.....; and so on.
Just count the packets in the "toPDU" in every associate flow. Could you
tell me how to modify the rules file to achieve this goal?

 Thanks

                                                       Jason
--------------------------------------------------------------------------
TTTTTTTTT LLLLL          Mr. Jeng-Sen Lin
T  TTT  T  LLL           jason%[email protected]
  TTT     LLL   L       Telecommunication Laboratories of Information
 TTTTT   LLLLLLLLL o    Technology Laboratory, Taiwan, R.O.C

From netramet-owner  Mon Jul 31 21:17:53 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id VAA09721 for netramet-outgoing; Mon, 31 Jul 1995 21:02:43 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id VAA09562 for <[email protected]>; Mon, 31 Jul 1995 21:00:26 +1200
Received: from decgat (tlrouter.motctl.gov.tw)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Mon,
31 Jul 1995 21:00:25 GMT+1300
Received: by decgat (5.57/Ultrix3.0-C) id AA17596; Mon, 31 Jul 95 17:09:07 +0800
Received: by jugar.tlnm (4.1/SMI-4.1) id AA16537; Mon, 31 Jul 95 16:51:38 CST
Date: Mon, 31 Jul 1995 16:51:38 -0600 (CST)
From: jason%[email protected] (Lin Jeng-Sen)
Subject: [Q]: Count for specific host
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk


Hello,

 I wrote one rule file to count the packets send from a specific host,
"140.133.18.112" like following:
#
SET 6
#
RULES
 SourcePeerType & 255 = IP:         Pushto, IP_pkt;
 Null & 0 = 0:                      Ignore, 0;
#
IP_pkt:
 SourcePeerAddress & 255.255.255.255 = 140.133.18.112: GotoAct,count_pkt;
 Null & 0 = 0:                      Ignore, 0;
#
count_pkt:
 SourcePeerAddress & 255.255.255.255 = 0: PushPkttoAct,Next;
 DestPeerAddress & 255.255.255.255 = 0:        PushPkttoAct,Next;
 Null & 0 = 0:  Count, 0;  # Source and Dest Peer Address pushed above

#
STATISTICS
#
FORMAT FlowRuleSet FlowIndex FirstTime LastTime "  "
  SourcePeerType SourcePeerAddress DestPeerAddress "  "
  ToPDUs FromPDUs "  " ToOctets FromOctets;
#

 However, it always shows no flow by NeMaC. Why? Is there any error in my
rule file?

                                                       Jason
---------------------------------------------------------------------------
TTTTTTTTT LLLLL          Mr. Jeng-Sen Lin
T  TTT  T  LLL           jason%[email protected]
  TTT     LLL   L       Telecommunication Laboratories of Information
 TTTTT   LLLLLLLLL o    Technology Laboratory, Taiwan, R.O.C

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.