From netramet-owner  Wed Sep  3 09:31:49 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id JAA27771 for netramet-outgoing; Wed, 3 Sep 1997 09:26:33 +1200 (NZST)
Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id JAA27760; Wed, 3 Sep 1997 09:26:29 +1200 (NZST)
From: Nevil Brownlee <[email protected]>
Reply-To: Nevil Brownlee <[email protected]>
To: [email protected], [email protected]
Subject: URLs for the Java-Nifty (39th IETF, RTFM WG) (fwd)
Message-ID: <[email protected]>
Date: Wed, 3 Sep 1997 09:19:42 +1200 (New Zealand Standard Time)
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.1 Build (3)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email protected]
Precedence: bulk

Hello all:

Herewith a note from Siegfried Loeffler, following up on his 'Nifty in
Java' presentation at the Munich IETF.  (Apologies to those who see
this on both the RTFM and NeTraMet lists).

Cheers, Nevil

Forwarded message:
> From floeff Mon Aug 25 21:21:10 1997
> Subject: URLs for the Java-Nifty (39th IETF, RTFM WG)
> To: [email protected]
> Date: Mon, 25 Aug 1997 21:21:10 +0200 (MSZ)
> Cc: [email protected]
> Bcc: [email protected], [email protected],
>       [email protected], [email protected],
>       [email protected], [email protected]
> X-Mailer: ELM [version 2.5 PL0b1]
> Content-Length: 3816
>
> Hi all,
>
> the Java version of "nifty" I presented on the 39th IETF in Munich is
> available for testing on-line under the following URL:
>
> http://ksoc3mon2.rus.uni-stuttgart.de/adventnet/frieder/fluid/fluid.html
>
> To test it, you need access to a NeTraMet meter that has a "nifty" like
> ruleset uploaded. I currently run a NeTraMet meter on our department
> ethernet that you can use for testing during the next few days.
> To see how the applet works, do the following:
>
> 1.) Open the above URL within a web browser (preferrably netscape) with
>     Java enabled.
>
> 2.) In the "Meter Host" field, you should see
>     "ksoc3mon2.rus.uni-stuttgart.de"
>     indicated.
>
>     In the "Community" field there should be "frieder".
>
>     The "Meter Version" and "Uptime" should be displayed within the
>     Applet as well.
>
>     If this is not the case, something is wrong. Check the Java Console
>     Output, this should help to resolve the case.
>
> 3.) Now enter the Name of the Ruleset you want to monitor. In the case
>     of the above machine (ksoc3mon2.rus.uni-stuttgart.de) I have uploaded
>     a ruleset called "2" to the meter. Therefore, you would enter
>     "2" in the ruleset field and press the return key. (On some strange
>     web browsers under M$ Windows it seems to be necessary to press
>     CTRL-N. Dont ask me why)
>
> 4.) Now you just have to wait a while. After a minute or so there should
>     be letters or symbols appearing in the lower half of the applet. These
>     indicate one flow each. By clicking with the mouse on those symbols
>     you can get more detailed information on those flows, like the amount
>     of data transferred etc. in a separate window that will pop up. Those
>     windows get updated each time that the applet gets new information
>     from the meter.
>
> To contact your own meter, just enter the hostname and community name
> of the meter you want to query. Upload the ruleset you usually use for
> "nifty" to your meter using NeMaC or nifty -- the applet does not include
> the manager functionality to do this.
>
> Thats it. I'd love to add more functionality, but unfortunately I ran
> out of time and I have now finished my diploma thesis on this subject.
> (Anyway, I was/am not paid for this - so I admit that I had a motivation
> for finishing the work ;-) )
>
> Whoever is interested in the thesis report - that is available online
> as well:
>
>      http://ksoc3mon2.rus.uni-stuttgart.de/diplom/
>            Contains a HTML Version (generated with LaTeX2html)
>
> and
>
>      http://ksoc3mon2.rus.uni-stuttgart.de/diplom/diplom.ps.gz
>            Contains a (hopefully printable) Postscript file with the
>            complete report I wrote. This covers an introduction into
>            web based network management, web based progamming techniques,
>            the NLANR OC3MON, and finally an introduction into the RTFM
>            architecture as well. In case somebody needs the TeX source
>            I can hand that out per e-mail as well.
>
> Everybody interested in the Java source code can get that as well:
>      http://ksoc3mon2.rus.uni-stuttgart.de/adventnet/frieder/fluid
>          contains all necessary source code files. I apologize for the mess. If
>          somebody really wants to use this code, I can help via e-mail.
>
> Finally, the IETF Slides are on the WWW at:
>      http://www.mathematik.uni-stuttgart.de/~floeff/diplom/ietfslides/index.htm
>
> As I said, since I will be doing a MBA like education at the "College des
> Ingenieurs" in Paris in the next ten months, I wont be able to continue
> my work on this in the next time.
>
> I would appreciate to get some comments on this work.
>
> Cheers,
> Siegfried
> --
>     Siegfried Loeffler, DG1SEK, Moehringer Str.. 96, 70199 Stuttgart, Germany
>       Phone: +49-711-6074762  Fax: +49-711-6074763  Mobile: +49-172-9021563
>                             http://home.pages.de/~dg1sek
>


--
   Siegfried Loeffler, DG1SEK, Moehringer Str. 96, 70199 Stuttgart, Germany
     Phone: +49-711-6074762  Fax: +49-711-6074763  Mobile: +49-172-9021563
                           http://home.pages.de/~dg1sek
--- End Forwarded Message ---


+---------------------------------------------------------------------+
| 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 |
+---------------------------------------------------------------------P




From netramet-owner  Fri Sep  5 05:49:58 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id FAA26574 for netramet-outgoing; Fri, 5 Sep 1997 05:46:58 +1200 (NZST)
Received: from chaos.ao.net ([email protected] [205.244.242.21]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id FAA26567 for <[email protected]>; Fri, 5 Sep 1997 05:46:54 +1200 (NZST)
Received: from chaos.ao.net (localhost [127.0.0.1])
       by chaos.ao.net (8.8.5/8.8.5) with ESMTP id NAA18207
       for <[email protected]>; Thu, 4 Sep 1997 13:47:44 -0400
Message-Id: <[email protected]>
To: [email protected]
Subject: NeMaC 4.1b13 on linux, totaly bogus flow results...
Date: Thu, 04 Sep 1997 13:47:43 -0400
From: Dan Merillat <[email protected]>
Sender: [email protected]
Precedence: bulk


#Time: 12:05:00 Thu  4 Sep 1997 chaos Flows from 1983846 to 2013808
#Stats: aps=501 apb=0 mps=724 mpb=0 lsp=0 avi=96.7 mni=91.0 fiu=46 frc=111 gci=1
0 rpp=5.1 tpp=0.6 cpt=1.0 tts=65536 tsu=308
195 10 97700 1 : 00-80-2D-00-5E-04 (0.0.0.0) 153550852 2364342275  1838875592 583796642
196 10 97706 1 : 00-80-2D-01-F4-B6 (0.0.0.0) 2315190276 3154247683  2991522230 3851094421

Running fd_filter on the file gives me:
##NeTraMet v4.1:  -c300 -r rules.monitor  chaos eth0  10000 flows  starting at 0
6:45:39 Thu  4 Sep 1997
#Format: flowindex flowruleset firsttime sourcepeertype : sourceadjacentaddress
#        (sourcepeeraddress) topdus frompdus  tooctets fromoctets
#Time: 06:45:39 Thu  4 Sep 1997 chaos Flows from 1 to 97729
#Ruleset: 10  7 rules.monitor  NeMaC
#Time: 06:50:00 Thu  4 Sep 1997 chaos Flows from 97728 to 123870
195 10 97700 1 : 00-80-2D-00-5E-04 () 10140417785857 256598526918656  8753144659968 0
196 10 97706 1 : 00-80-2D-01-F4-B6 () 27044872192 118674241486849  187909114691584 0

The important parts of the ruleset:  (acct is really used, to account
virtual IPs on one machine.)

RULES
 SourcePeerType & 255 = IP:         Pushto, IP_pkt;
 Null & 0 = 0:                      Ignore, 0;
#
IP_pkt:  # Align to egress router
       DestAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-00-0C-0B-FF-B5: Goto, test;
       Null & 0 = 0:   Retry, 0;

test:
       SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-80-2d-00-5e-04: GotoAct, acct2; # tserver1
       SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-80-2d-01-f4-b6: GotoAct, acct2; # tserver2
       SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-80-2d-00-b3-cd: GotoAct, acct2; # tserver3
       Null & 0 = 0: Ignore, 0;

acct:
       SourcePeerAddress  & 255.255.255.255 = 0: PushPktToAct, Next;
acct2:
       SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 0: PushPktToAct, Next;
       Null & 0 = 0: Count, 0;
#
STATISTICS
#
FORMAT FlowIndex FlowRuleSet FirstTime SourcePeerType " : "
  SourceAdjacentAddress " (" SourcePeerAddress ") "
  ToPDUs FromPDUs "  " ToOctets FromOctets;

Now, I thought it was a problem with my ruleset, but nm_rc works on it!
Gives me the top 10 flows and approximate what FTP to the machines shows
as a rate.

??  So, it looks like something is going wrong in NeMaC, not the meter
itself...

Some system information:
harik@chaos:~/nemac$ ldd `which nemac`
       libc.so.5 => /lib/libc.so.5.4.36

libpcap-0.3.1a2


linux 2.0.29 on intel, pointing at a SMC ultra ethernet card.

Those numbers are really huge, right?  It's not just my imagination?

Mac 00-80-2d-00-5e-04 is a terminal server, 64 modem ports, barely busy.

195 10 97700 1 : 00-80-2D-00-5E-04 (0.0.0.0) 153550852 2364342275  1838875592 583796642

Somehow I doubt this thing has pushed 153 billion packets over it's entire
lifetime, much less during the current sample period!

Any ideas where to look for conversion errors?

--Dan

From netramet-owner  Fri Sep  5 05:52:10 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id FAA26749 for netramet-outgoing; Fri, 5 Sep 1997 05:52:03 +1200 (NZST)
Received: from chaos.ao.net ([email protected] [205.244.242.21]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id FAA26739 for <[email protected]>; Fri, 5 Sep 1997 05:52:00 +1200 (NZST)
Received: from chaos.ao.net (localhost [127.0.0.1])
       by chaos.ao.net (8.8.5/8.8.5) with ESMTP id NAA18307
       for <[email protected]>; Thu, 4 Sep 1997 13:52:50 -0400
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: NeMaC 4.1b13 on linux, totaly bogus flow results...
Date: Thu, 04 Sep 1997 13:52:49 -0400
From: Dan Merillat <[email protected]>
Sender: [email protected]
Precedence: bulk


Looks like endian errors:

Dan Merillat writes:

> 195 10 97700 1 : 00-80-2D-00-5E-04 (0.0.0.0) 153550852 2364342275  1838875592
583796642
>
> Somehow I doubt this thing has pushed 153 billion packets over it's entire
> lifetime, much less during the current sample period!

harik@vulpine:~$ printf "0x%x\n" 153550852
0x09270004
harik@vulpine:~$ printf "%ld\n" 0x00040927
264487

264k packets is a lot more reasonable then 153 billion!  ;-)

I'll poke around the output parts and see what I can find... it may even
be a problem with libc printf, since nm_rc doing the math internaly,
and only outputting an integer works...

--Dan


From netramet-owner  Fri Sep  5 07:54:03 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id HAA01335 for netramet-outgoing; Fri, 5 Sep 1997 07:51:10 +1200 (NZST)
Received: from chaos.ao.net ([email protected] [205.244.242.21]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id HAA01326 for <[email protected]>; Fri, 5 Sep 1997 07:51:06 +1200 (NZST)
Received: from chaos.ao.net (localhost [127.0.0.1])
       by chaos.ao.net (8.8.5/8.8.5) with ESMTP id PAA20850
       for <[email protected]>; Thu, 4 Sep 1997 15:51:57 -0400
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: NeMaC 4.1b13 on linux, totaly bogus flow results...
Date: Thu, 04 Sep 1997 15:51:56 -0400
From: Dan Merillat <[email protected]>
Sender: [email protected]
Precedence: bulk


Dan Merillat writes:
>
> Looks like endian errors:

Yup, it is. ;-(


harik@vulpine:~$ printf "0x%x\n" 153550852
> 0x09270004
> harik@vulpine:~$ printf "%ld\n" 0x00040927
> 264487
>
> 264k packets is a lot more reasonable then 153 billion!  ;-)
>
> I'll poke around the output parts and see what I can find... it may even
> be a problem with libc printf, since nm_rc doing the math internaly,
> and only outputting an integer works...


Heh.  Ok, I don't get it.  the problem is in nmc_c64.[ch] in that there
don't seem to be any provisions for endianness...

So I wrote a test program, putc64.c that is really self evident. (2 strtol and
it printfs the results of putc64)

Here are the results:
harik@chaos:~$ putc64 0x0 0x1
65536
harik@chaos:~$ putc64 0x0 0x10000
1
harik@chaos:~$ putc64 0x1 0x0
281474976710656
harik@chaos:~$ putc64 0x10000 0x0
4294967296

which is exactly what I'm seeing happen when writing out the flowfiles...
gdb shows it enter putc64 with

putc64 (bp=0xbfffc358 "1", c=0xbffff340) at ../../src/manager/nmc_c64.c:62
62         nb[x = sizeof(nb)-1] = '\0';
(gdb) print *c
$36 = {high = 0, low = 8727}
and it comes back with: 571932672!

I may end up doing an endian swap on putc64 to demangle, but this really
makes no sense... unless b13 is only working properly on big-endian machines?

Am I crazy, or are other people seeing this to?

(it is probably just me. ;-)

--Dan

P.S.: putc64.c...

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>

#include "ausnmp.h"
#include "asn1.h"

#include "nmc.h"
#include "nmc_c64.h"

unsigned long c64arg;

main(int argc, char **argv) {
       struct counter64 counter;
       char buf[1024], *ptr;

       if (argc < 2) {
               printf("Usage: putc64 high low\n");
               exit(1);
       }
       counter.high=strtol(argv[1], (char **)NULL, 0);
       counter.low=strtol(argv[2], (char **)NULL, 0);
       ptr=(char *)&buf;
       putc64(ptr, &counter);
       puts(buf);
}

From netramet-owner  Tue Sep  9 13:06:34 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id NAA18587 for netramet-outgoing; Tue, 9 Sep 1997 13:02:41 +1200 (NZST)
Received: from mail.telstra.com.au (mail.telstra.com.au [192.148.160.15]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id NAA18571 for <[email protected]>; Tue, 9 Sep 1997 13:02:33 +1200 (NZST)
Received: (from uucp@localhost) by mail.telstra.com.au (8.8.2/8.6.9) id LAA14706 for <[email protected]>; Tue, 9 Sep 1997 11:01:56 +1000 (EST)
Received: from mail-gw.fwall.telstra.com.au(192.148.147.15) by mail via smap (V1.3)
       id sma009188; Tue Sep  9 10:41:15 1997
Received: (from uucp@localhost) by mail-gw.fwall.telstra.com.au (8.8.2/8.6.9) id KAA11365 for <[email protected]>; Tue, 9 Sep 1997 10:41:05 +1000 (EST)
Received: from cdn-mail.dn.itg.telecom.com.au(144.135.109.134) by mail-gw via smap (V1.3)
       id sma011210; Tue Sep  9 10:40:31 1997
Received: from cygnus.dn.itg.telecom.com.au (cygnus.dn.itg.telecom.com.au [144.136.188.138]) by cdn-mail.telecom.com.au (8.8.2/8.6.9) with ESMTP id KAA18339 for <[email protected]>; Tue, 9 Sep 1997 10:40:29 +1000 (EST)
Received: from cygnus (localhost [127.0.0.1]) by cygnus.dn.itg.telecom.com.au (8.8.2/8.6.9) with SMTP id KAA26882 for <[email protected]>; Tue, 9 Sep 1997 10:45:24 +1000 (EST)
Message-ID: <[email protected]>
Date: Tue, 09 Sep 1997 10:45:24 +1000
From: Brian Miller <[email protected]>
Organization: Telstra
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: [email protected]
Subject: NeTraMet dropping packets, but not showing up in the #Stats line
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

I have just started testing NeTraMet at our site, and am having a little
trouble.

Sorry in advance for the long post, but too much information is better
than too little.

First thing I guess is a bit of a background and what we're doing.

We have a PentiunII/266 box running Linux (2.0.30), a DEC FDDI card, and
a 3Com 3C509 Ethernet card for the meter (running NeTraMet).  This will
be monitoring an FDDI ring.  The FDDI interface has a bogus IP address
on it (1.2.3.4), and the Ethernet interface is used for IP access to
the host.  This box is called 'snafu'.

I am running NeMaC (and nm_rc) on a Sun Sparc5.

The Version of NeTraMet we are running is 4.1b13.

Currently I am running all this in a test environment so I can see
exactly
what is happening.

I have an FDDI concentrator that I have connected the Linux host to
and also a Sniffer.  The Sniffer is injecting previously captured FDDI
ring data onto the test ring at a rate of 75,000 to 80,000
packets/second
(about 60% utilisation).  This is a very consistant flow of traffic that
is replayed in a never ending loop.

I set up NeTraMet/NeMaC to monitor the FDDI ring with a very simple
rule file; just to see how things go.  Here is a copy of the rule file
called 'rules.mac':

  # A little rule file
  SET 3
  RULES
     Null & 0 = 0 : Count, 0;
  #
  FORMAT
     ToPDUs
  ;
  #
  STATISTICS;
  #

Pretty simple.  :-)

I start NeTraMet on the Linux host with the following command in
/etc/rc.d.rc.local:

  /usr/local/NeTraMet/NeTraMet -s -k -rread1 -wwrite1 -ifddi0 &

As soon as NeTraMet is started, it uses all available CPU.  'top'
has the following output:

   11:30am  up 4 days, 40 min,  5 users,  load average: 0.96, 0.94,
0.89
 32 processes: 28 sleeping, 4 running, 0 zombie, 0 stopped
  CPU states:  7.3% user, 92.5% system, 95.9% nice,  0.3% idle
  Mem:  63340K av, 61836K used,  1504K free,  7576K shrd, 47668K buff
  Swap: 130748K av,   264K used, 130484K free                3376K
cached

    PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME
COMMAND
   4001 root      12   0   824  824   284 R       0 94.2  1.3  62:31
NeTraMet
    108 root       0   0   416  416   300 S       0  3.6  0.6 118:15
top


In the Sun Sparc5, I run NeMaC as follows:

  NeMaC -c60 -r rules.mac snafu write1 &

When I look at the snafu.flows.00n file to see how things were going,
I think I have a problem...  I have included the last two observations
from the file:

  #Time: 18:09:00 Mon  8 Sep 1997 snafu Flows from 507854 to 513893
  #Stats: aps=6214 apb=0 mps=12828 mpb=0 lsp=0 avi=3.7 mni=0.0 fiu=4
    frc=0 gci=10 rpp=0.0 tpp=1.0 cpt=1.0 tts=16384 tsu=1
  31594872
  #Time: 18:10:00 Mon  8 Sep 1997 snafu Flows from 513892 to 519833
  #Stats: aps=6267 apb=0 mps=9599 mpb=0 lsp=0 avi=3.2 mni=0.0 fiu=4
    frc=0 gci=10 rpp=0.0 tpp=1.0 cpt=1.0 tts=16384 tsu=1
  31963246

I wasn't expecting the Linux host to be able to keep up with a 60%
utilised FDDI ring, but the problem is that the #Stats line says that
the FDDI ring is running at around 6,200 packets/second, and there are
_NO_ lost packets (lsp) or _NO_ backlog (apb & mpb).

I have been looking at the FDDI interface on the Linux host, and by
doing
a "netstat -i ; sleep 60 ; netstat -i" I have the following output:

Iface   MTU Met  RX-OK RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP TX-OVR
Flags
fddi0  4470   0 872175983 222812      0      2      3      0      0
0 BMRU
Iface   MTU Met  RX-OK RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP TX-OVR
Flags
fddi0  4470   0 876893630 222812      0      2      3      0      0
0 BMRU

This gives a packet rate on the FDDI of 78627 packets/second over the 60
second interval.

An 'ifconfig fddi0' gives the following output:


  fddi0     Link encap:UNSPEC  HWaddr
00-00-F8-9C-B7-2D-00-00-00-00-00-00-00-00-00-00
            inet addr:1.2.3.4  Bcast:1.255.255.255  Mask:255.0.0.0
            UP BROADCAST RUNNING PROMISC MULTICAST  MTU:4470  Metric:1
            RX packets:894624953 errors:222812 dropped:0 overruns:2
            TX packets:3 errors:0 dropped:0 overruns:0

There have been a few errors, but I think I captured a single sick
packet
on my initial sniffer capture as it goes up at a consistant rate.

Does any one know why NeTraMet is saying that the FDDI utilisation is
only around 6,200 packets/second (without any lost packets), and all
other tools I can get my hands on say that the utilisation is around
75,000 to 80,000 packets/second?

I don't mind losing packets; but I just want to know how many.  If
I know how many I am losing, I will happily run with a '-n nnn' option
to look at only every nth packet without losing any.

Many thanks in advance.

Brian
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Brian Miller                                 Telstra
CDN Product Group                            30/242 Exhibition Street
ITG Communication Network Platforms          Melbourne, VIC 3000
[email protected]                       Australia
Tel: +61-3-9632-3883                         FAX: +61-3-9632-3884
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

From netramet-owner  Tue Sep  9 17:22:08 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id RAA17627 for netramet-outgoing; Tue, 9 Sep 1997 17:21:10 +1200 (NZST)
Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id RAA17615 for <netramet@auckland>; Tue, 9 Sep 1997 17:21:06 +1200 (NZST)
From: Nevil Brownlee <[email protected]>
Reply-To: Nevil Brownlee <[email protected]>
To: [email protected]
Subject: 'Endia' bug fixed in NeTraMet 4.1b13
Message-ID: <[email protected]>
Date: Tue, 9 Sep 1997 17:16:16 +1200 (New Zealand Standard Time)
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.1 Build (3)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email protected]
Precedence: bulk

Hello all:

Several people posted notes to the list recently reporting that NeMaC
had little-endian problems, giving incorrect (very high) counts when
run on linux systems.

This has been fixed in beta14, available now from the ftp site.

Thanks very much for the bug reports and feedback in general - please
keep it coming!

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 |
+---------------------------------------------------------------------P




From netramet-owner  Tue Sep 16 21:56:59 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id VAA07313 for netramet-outgoing; Tue, 16 Sep 1997 21:56:07 +1200 (NZST)
Received: from oscar.broadcom.ie (oscar.broadcom.ie [192.107.110.20]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id VAA07304; Tue, 16 Sep 1997 21:56:00 +1200 (NZST)
Received: from dell93 (pc93.broadcom.ie [192.107.110.193])
       by oscar.broadcom.ie (8.8.7/8.8.6) with SMTP id KAA28679;
       Tue, 16 Sep 1997 10:50:32 +0100 (BST)
Message-Id: <[email protected]>
From: "Denys Miranda" <[email protected]>
To: <[email protected]>
Cc: "Nevil Brownlee" <[email protected]>
Subject: Reading individual IP flows through a proxy server
Date: Tue, 16 Sep 1997 10:55:20 +0100
MIME-Version: 1.0
Content-Type: text/plain;
       charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1008.3
X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.1008.3
Sender: [email protected]
Precedence: bulk



Hi everybody!.

I've been using NeTraMet for a while now and I have designed rules in
order to monitor the external IP traffic of our network and it works
very well.

The configuration of our network is very simple


--------------         --------------          ----------         ----------
OUR NET | -- | proxy server | -- | Router | -- | Internet |
--------------        ----------------        -----------       -----------

The rulesets can meter the flows between proxy server and the internet
cloud.
Now, do you know of a way to monitor the IP flows from each individual
machine to the internet.?.

Thanks for your help!.

Regards,

Denys Miranda.

PS: Nevil, I'm running the PC version of the meter and it works fine.
But I'm still looking forward to get the segmentation fault problem
fixed in the Solaris version.
Thanks again for your time!



From netramet-owner  Tue Sep 16 21:56:59 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id VAA07178 for netramet-outgoing; Tue, 16 Sep 1997 21:52:26 +1200 (NZST)
Received: from oscar.broadcom.ie (oscar.broadcom.ie [192.107.110.20]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id VAA07165; Tue, 16 Sep 1997 21:52:13 +1200 (NZST)
Received: from dell93 (pc93.broadcom.ie [192.107.110.193])
       by oscar.broadcom.ie (8.8.7/8.8.6) with SMTP id KAA28610;
       Tue, 16 Sep 1997 10:46:34 +0100 (BST)
Message-Id: <[email protected]>
From: "Denys Miranda" <[email protected]>
To: <[email protected]>
Cc: "Nevil Brownlee" <[email protected]>
Subject: Reading individual IP flows through a proxy server
Date: Tue, 16 Sep 1997 10:51:22 +0100
MIME-Version: 1.0
Content-Type: text/plain;
       charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1008.3
X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.1008.3
Sender: [email protected]
Precedence: bulk

Hi everybody!.

I've been using NeTraMet for a while now and I have designed rules in
order to monitor the external IP traffic of our network and it works
very well.

The configuration of our network is very simple

----------------     -------------------           -----------
------------
OUR NET | -- | proxy server | ------- | Router | ----- | Internet |
----------------     -------------------           -----------
------------

The rulesets can meter the flows between proxy server and the internet
cloud.
Now, do you know of a way to monitor the IP flows from each individual
machine to the internet.?.

Thanks for your help!.

Regards,

Denys Miranda.

PS: Nevil, I'm running the PC version of the meter and it works fine.
But I'm still looking forward to get the segmentation fault problem
fixed in the Solaris version.
Thanks again for your time!




From netramet-owner  Wed Sep 17 03:06:47 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id DAA17789 for netramet-outgoing; Wed, 17 Sep 1997 03:06:00 +1200 (NZST)
Received: from oscar.broadcom.ie (oscar.broadcom.ie [192.107.110.20]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id DAA17781; Wed, 17 Sep 1997 03:05:54 +1200 (NZST)
Received: from dell93 (pc93.broadcom.ie [192.107.110.193])
       by oscar.broadcom.ie (8.8.7/8.8.6) with SMTP id PAA04534;
       Tue, 16 Sep 1997 15:59:34 +0100 (BST)
Message-Id: <[email protected]>
From: "Denys Miranda" <[email protected]>
To: "Andrzej Bialecki" <[email protected]>
Cc: <[email protected]>, "Nevil Brownlee" <[email protected]>
Subject: Re: Reading individual IP flows through a proxy server
Date: Sat, 16 Aug 1997 16:04:23 +0100
MIME-Version: 1.0
Content-Type: text/plain;
       charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1008.3
X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.1008.3
Sender: [email protected]
Precedence: bulk

Hi Andrzej,

Thanks for your help but I think I wasn't clear enough.

I can see each client by IP address....BUT,  the flows that I actually see are
flows between the client machine and the proxy server...and not the real
destination server IP address.....

--------
Say:
A = my client address
P = proxy server address
D = distant server address

           segment#1                segment#2
| A | <------------------> | P | < --------------> | S |

* If I run the meter in the segment # 1  the meter will read flows with:
SourceAddress = A
DestAddress = P

* If I run the meter in the segment # 2 the meter will read flows with:
SourceAddress = P
DestAddress = S
-----------

I am interested in flows with:
SourceAddress = A
DestAddresss = D

and because of the proxy server , the meter won't see the REAL Source and Dest
Addresses!!!!

Perhaps I'm missing something here and that's why I'm asking for help!

Regards,

Denys Miranda.
----Original Message-----
From: Andrzej Bialecki <[email protected]>
To: Denys Miranda <[email protected]>
Cc: [email protected] <[email protected]>; Nevil Brownlee
<[email protected]>
Date: Tuesday, September 16, 1997 12:19 PM
Subject: Re: Reading individual IP flows through a proxy server



>On Tue, 16 Sep 1997, Denys Miranda wrote:
>
>> Now, do you know of a way to monitor the IP flows from each individual
>> machine to the internet.?.
>
>Simply: change the netmask to 255.255.255.255, and the meter will create
>flows for every IP address separately, instead of collecting them as a one
>C-class flow (like in rules.ip)
>
>Andrzej Bialecki
>
>---------------------+---------------------------------------------------------
>[email protected]  | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") }
>Research & Academic  | "Be open-minded, but don't let your brains to fall out."
>Network in Poland    | All of the above (and more) is just my personal opinion.
>---------------------+---------------------------------------------------------
>


From netramet-owner  Wed Sep 17 03:19:21 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id DAA18256 for netramet-outgoing; Wed, 17 Sep 1997 03:18:57 +1200 (NZST)
Received: from oscar.broadcom.ie (oscar.broadcom.ie [192.107.110.20]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id DAA18248; Wed, 17 Sep 1997 03:18:51 +1200 (NZST)
Received: from dell93 (pc93.broadcom.ie [192.107.110.193])
       by oscar.broadcom.ie (8.8.7/8.8.6) with SMTP id QAA04690;
       Tue, 16 Sep 1997 16:12:35 +0100 (BST)
Message-Id: <[email protected]>
From: "Denys Miranda" <[email protected]>
To: "Andrzej Bialecki" <[email protected]>
Cc: <[email protected]>, "Nevil Brownlee" <[email protected]>
Subject: Re: Reading individual IP flows through a proxy server
Date: Sat, 16 Aug 1997 16:17:24 +0100
MIME-Version: 1.0
Content-Type: text/plain;
       charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1008.3
X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.1008.3
Sender: [email protected]
Precedence: bulk

 Hi Andrzej,

Thanks for your help but I think I wasn't clear enough.

I can see each client by IP address....BUT,  the flows that I actually see are
flows between the client machine and the proxy server...and not the real
destination server IP address.....


Let's say:

A = my client address
P = proxy server address
D = distant server address

           segment#1                segment#2
| A | <------------------> | P | < --------------> | S |

* If I run the meter in the segment # 1  the meter will read flows with:
SourceAddress = A
DestAddress = P

* If I run the meter in the segment # 2 the meter will read flows with:
SourceAddress = P
DestAddress = S
-----------

I am interested in flows with:
SourceAddress = A
DestAddresss = D

and because of the proxy server , the meter won't give the the REAL Source and
Dest Addresses!!!!

Perhaps I'm missing something here and that's why I'm asking for help!

Regards,

Denys Miranda.

-----Original Message-----
From: Andrzej Bialecki <[email protected]>
To: Denys Miranda <[email protected]>
Cc: [email protected] <[email protected]>; Nevil Brownlee
<[email protected]>
Date: Tuesday, September 16, 1997 12:19 PM
Subject: Re: Reading individual IP flows through a proxy server



>On Tue, 16 Sep 1997, Denys Miranda wrote:
>
>> I've been using NeTraMet for a while now and I have designed rules in
>> order to monitor the external IP traffic of our network and it works
>> very well.
>
>[snip]
>
>> Now, do you know of a way to monitor the IP flows from each individual
>> machine to the internet.?.
>
>Simply: change the netmask to 255.255.255.255, and the meter will create
>flows for every IP address separately, instead of collecting them as a one
>C-class flow (like in rules.ip)
>
>Andrzej Bialecki
>
>---------------------+---------------------------------------------------------
>[email protected]  | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") }
>Research & Academic  | "Be open-minded, but don't let your brains to fall out."
>Network in Poland    | All of the above (and more) is just my personal opinion.
>---------------------+---------------------------------------------------------
>


From netramet-owner  Wed Sep 17 05:36:42 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id FAA23194 for netramet-outgoing; Wed, 17 Sep 1997 05:36:00 +1200 (NZST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id FAA23187 for <[email protected]>; Wed, 17 Sep 1997 05:35:56 +1200 (NZST)
From: [email protected]
Received: from mailhub2.watson.ibm.com (mailhub2.watson.ibm.com [9.2.250.15]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id NAA13054; Tue, 16 Sep 1997 13:27:55 -0400
Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub2.watson.ibm.com (8.8.2/07-14-97) with SMTP id NAA21934; Tue, 16 Sep 1997 13:35:42 -0400
Message-Id: <[email protected]>
Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R4)
  with BSMTP id 6629; Tue, 16 Sep 97 13:35:38 EDT
Date: Tue, 16 Sep 97 13:14:01 EDT
To: [email protected]
cc: [email protected]
Subject:  Re: Reading individual IP flows through a proxy server
Sender: [email protected]
Precedence: bulk

Reference:  Your note of Sat, 16 Aug 1997 16:17:24 +0100

 Hi Denys,

 The problem is not that NeTraMet is withholding information from you.
The problem is that NeTraMet does not have the info you want. It
extracts the addresses from the packets on the wire. The proxy
server is the thing that is "changing" this address as the packets
pass through. Unfortunately, I don't think that NeTraMet has the
ability to match the "true" source and destination addresses.

 The only way this might be done would be to incorporate the metering
code into the proxy server, perhaps at the point where the address
translation is taking place? (I don't know enough about proxy servers
to make any real suggestions here.)

 Sorry for the bad news.


    Stephen Stibler


*************** Referenced Note ***************

       Tue, 16 Sep 1997 16:12:35 +0100 (BST)
From: "Denys Miranda" <[email protected]>
To: "Andrzej Bialecki" <[email protected]>
Cc: <[email protected]>, "Nevil Brownlee" <[email protected]>
Subject: Re: Reading individual IP flows through a proxy server
Date: Sat, 16 Aug 1997 16:17:24 +0100
MIME-Version: 1.0
Content-Type: text/plain;
       charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1008.3
X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.1008.3
Sender: [email protected]
Precedence: bulk

 Hi Andrzej,

Thanks for your help but I think I wasn't clear enough.

I can see each client by IP address....BUT,  the flows that I actually see are
flows between the client machine and the proxy server...and not the real
destination server IP address.....


Let's say:

A = my client address
P = proxy server address
D = distant server address

           segment#1                segment#2
| A | <------------------> | P | < --------------> | S |

* If I run the meter in the segment # 1  the meter will read flows with:
SourceAddress = A
DestAddress = P

* If I run the meter in the segment # 2 the meter will read flows with:
SourceAddress = P
DestAddress = S
-----------

I am interested in flows with:
SourceAddress = A
DestAddresss = D

and because of the proxy server , the meter won't give the the REAL Source and
Dest Addresses!!!!

Perhaps I'm missing something here and that's why I'm asking for help!

Regards,

Denys Miranda.

-----Original Message-----
From: Andrzej Bialecki <[email protected]>
To: Denys Miranda <[email protected]>
Cc: [email protected] <[email protected]>; Nevil Brownlee
<[email protected]>
Date: Tuesday, September 16, 1997 12:19 PM
Subject: Re: Reading individual IP flows through a proxy server



>On Tue, 16 Sep 1997, Denys Miranda wrote:
>
>> I've been using NeTraMet for a while now and I have designed rules in
>> order to monitor the external IP traffic of our network and it works
>> very well.
>
>[snip]
>
>> Now, do you know of a way to monitor the IP flows from each individual
>> machine to the internet.?.
>
>Simply: change the netmask to 255.255.255.255, and the meter will create
>flows for every IP address separately, instead of collecting them as a one
>C-class flow (like in rules.ip)
>
>Andrzej Bialecki
>
>---------------------+---------------------------------------------------------
>[email protected]  | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") }
>Research & Academic  | "Be open-minded, but don't let your brains to fall out."
>Network in Poland    | All of the above (and more) is just my personal opinion.
>---------------------+---------------------------------------------------------
>


From netramet-owner  Wed Sep 17 07:10:30 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id HAA26644 for netramet-outgoing; Wed, 17 Sep 1997 07:09:56 +1200 (NZST)
Received: from papaioea.manawatu.gen.nz ([email protected] [202.36.148.67]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id HAA26631; Wed, 17 Sep 1997 07:09:49 +1200 (NZST)
Received: from fnord.manawatu.gen.nz ([email protected] [202.36.148.66]) by papaioea.manawatu.gen.nz (8.6.12/8.6.12) with SMTP id GAA26902; Wed, 17 Sep 1997 06:55:47 +1200
Message-Id: <[email protected]>
X-Sender: [email protected]
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Wed, 17 Sep 1997 06:24:25 +1200
To: "Denys Miranda" <[email protected]>
From: Alan Brown <[email protected]>
Subject: Re: Reading individual IP flows through a proxy server
Cc: "Andrzej Bialecki" <[email protected]>, <[email protected]>,
       "Nevil Brownlee" <[email protected]>
In-Reply-To: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email protected]
Precedence: bulk

At 16:17 16/08/97 +0100, Denys Miranda wrote:

>I can see each client by IP address....BUT,  the flows that I actually see are
>flows between the client machine and the proxy server...and not the real
>destination server IP address.....

Use the server logs and munge them into a pseudo flow file for your accounting software, or just process the logs separately and merge into your accounting database at the end of the month

Alternatively, charge proxy traffic at a fixed rate higher than other local traffic, but lower than direct access.

Both these schemes are being used in NZ.

AB

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.