From netramet-owner Tue Jul 1 15:41:43 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id PAA10690 for netramet-outgoing; Tue, 1 Jul 1997 15:40:03 +1200 (NZST)
Received: from protoclown.nis.newscorp.com (protoclown.nis.newscorp.com [206.15.112.132]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id PAA10673 for <
[email protected]>; Tue, 1 Jul 1997 15:39:58 +1200 (NZST)
From:
[email protected]
Received: by protoclown.nis.newscorp.com; id AA03033; Mon, 30 Jun 1997 23:45:06 -0400
Message-Id: <
[email protected]>
To:
[email protected]
Subject: Not using the snmp ports
Date: Mon, 30 Jun 97 23:45:06 -0400
X-Mts: smtp
Sender:
[email protected]
Precedence: bulk
Hi,
I don't want to use the snmp ports for this, and I'm also working on
using the newer 4.1 netramet. I noticed that the SNMP_PORT defines
are not the same in 4.1 as they are in 3.2. So when I change au_snmp_port
to my new port in ausnmp.h, my meter listens to the right port, but my
manager still goes the the snmp port.
What have I missed?
Eric
From netramet-owner Tue Jul 1 22:40:32 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id WAA00640 for netramet-outgoing; Tue, 1 Jul 1997 22:37:55 +1200 (NZST)
Received: from iconz.co.nz (iconz.co.nz [202.14.100.2]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id WAA00635 for <
[email protected]>; Tue, 1 Jul 1997 22:37:52 +1200 (NZST)
Received: from localhost (ankh@localhost) by iconz.co.nz (8.6.12/8.6.10) with SMTP id LAA05287 for <
[email protected]>; Tue, 1 Jul 1997 11:20:52 +1200
Date: Tue, 1 Jul 1997 11:20:01 +1200 (NZST)
From: "J. Sean Connell" <
[email protected]>
To: "'
[email protected]'" <
[email protected]>
Subject: Re: International / National Traffic
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender:
[email protected]
Precedence: bulk
On Mon, 30 Jun 1997, Frieder Loeffler wrote:
> You are right, its certainly not possible just by using the IP adress.
> I think newer versions OC3MON offer this possibility nevertheless. This
> is implemented by determining the AS ("Autonomous System") identifier
> for the IP address.
>
> It should therefore, in theory, be possible to do this kind of analysis.
> I think the best way to implement this would be to trace the flows as
> usual and then use a C program that reads the output file from NeTraMet
> and determines the ASes for the IPs.
>
> Unfortunately I dont know anything about BGP and how the IP<->AS correlation
> can be done, but it should nevertheless be possible. It will surely require
> a not too small amount of CPU power though.
>
> Maybe someone who knows more about BGP can explain how ASes are constructed
> and how geographical information can be determined once you know the AS?
First: telnet to route-server.cerf.net. It's a Cisco router that runs a custom
IOS that shows AS numbers when you do a traceroute.
Second: using AS numbers as a way to determine national/international/etc.
would be lossy, as not everyone has an AS number.
Third: geographical information is not encoded in AS numbers as far as I am
aware; the correlation between AS numbers and geography would have to be done
by querying the AS database and examining it to find out where a particular
entity is.
--
J. S. Connell | Systems Adminstrator, ICONZ. Any opinions stated above
[email protected] | are not my employers', not my boyfriends', my God's, my
[email protected] | friends', and probably not even my own.
-------------------+---------------------------------------------------------
PGP key at
http://www.canuck.gen.nz/~ankh/pgpkey.html
From netramet-owner Wed Jul 2 00:32:41 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id AAA03336 for netramet-outgoing; Wed, 2 Jul 1997 00:29:11 +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 AAA03331 for <
[email protected]>; Wed, 2 Jul 1997 00:29:08 +1200 (NZST)
Received: from papaioea.manawatu.gen.nz (alan@localhost [127.0.0.1]) by papaioea.manawatu.gen.nz (8.6.12/8.6.12) with SMTP id AAA17502; Wed, 2 Jul 1997 00:15:50 +1200
Date: Wed, 2 Jul 1997 00:15:47 +1200 (NZST)
From: Alan Brown <
[email protected]>
To: Marc van Selm <
[email protected]>
cc: Andrew Frazer <
[email protected]>,
"'
[email protected]'" <
[email protected]>
Subject: Re: International / National Traffic
In-Reply-To: <
[email protected]>
Message-ID: <Pine.SUN.3.90.970702001148.11043H-100000@papaioea.manawatu.gen.nz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender:
[email protected]
Precedence: bulk
On Mon, 30 Jun 1997, Marc van Selm wrote:
> This is only possible if IP's are assigned in a geographical fashion. This
> is not the case. They are assigned to NIC's and they reassign.
It's not only possible, but often done.
Basically it requires a list of known local/national/whatever IP blocks
be parsed.
The program I use to do this uses nemac output to classify traffic type
based on the NZ netblock list held at ftphost.waikato.ac.nz:/pub/netinfo/nzgate/docs/nzip.latest
Our criterion for distance charging is fairly simple. If a netblock is
advertised as directly connected to NZgate then it's national traffic and
if not, it's int'l.
No, I cannot make it available. The package is called NePrEng (Netramet
processing engine)
Other software has been written by various universties in New Zealand
utilising the list to calculate charges on the wing and disable an
account should its credit run out.
AB
From netramet-owner Fri Jul 4 14:34:38 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id OAA28445 for netramet-outgoing; Fri, 4 Jul 1997 14:30:07 +1200 (NZST)
Received: from protoclown.nis.newscorp.com (protoclown.nis.newscorp.com [206.15.112.132]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id OAA28422 for <
[email protected]>; Fri, 4 Jul 1997 14:30:01 +1200 (NZST)
From:
[email protected]
Received: by protoclown.nis.newscorp.com; id AA09359; Thu, 3 Jul 1997 22:35:14 -0400
Message-Id: <
[email protected]>
To:
[email protected]
Subject: Newest beta's meter doesn't want to compile
Date: Thu, 03 Jul 97 22:35:14 -0400
X-Mts: smtp
Sender:
[email protected]
Precedence: bulk
I just pulled down the most recent beta, and she doesn't want
to compile on my digital unix 4.0 machine.
I get the following
gcc -g -I../../src/meter -I../../src/snmplib -I../../src/meter/tcpdump -DULTRIX -DCLNS -c ../../src/meter/flowhash.c
In file included from ../../src/meter/flowhash.c:55:
./../src/meter/pktsnap.h:80: field `arrival_time' has incomplete type
./../src/meter/pktsnap.h:133: warning: parameter has incomplete type
./../src/meter/pktsnap.h:134: warning: parameter has incomplete type
./../src/meter/flowhash.c: In function `create':
./../src/meter/flowhash.c:1457: type of formal parameter 1 is incomplete
./../src/meter/flowhash.c: In function `count':
./../src/meter/flowhash.c:1511: type of formal parameter 1 is incomplete
*** Exit 1
Stop.
Seems to be something wrong with these lines...
double centiseconds(struct timeval nt);
double microseconds(struct timeval nt);
Eric
From netramet-owner Mon Jul 28 17:22:26 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id RAA17298 for netramet-outgoing; Mon, 28 Jul 1997 17:14:09 +1200 (NZST)
Received: from ccu1.auckland.ac.nz (
[email protected] [130.216.3.1]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id RAA17285; Mon, 28 Jul 1997 17:14:02 +1200 (NZST)
Received: (from nevil@localhost)
by ccu1.auckland.ac.nz (8.8.5/8.8.5) id RAA11975;
Mon, 28 Jul 1997 17:13:58 +1200 (NZT)
From: Nevil Brownlee <
[email protected]>
Message-Id: <
[email protected]>
Subject: re: NeTraMet with high load
To:
[email protected]
Date: Mon, 28 Jul 1997 17:13:57 +1200 (NZT)
Cc:
[email protected]
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender:
[email protected]
Precedence: bulk
Hello Thomas:
> we are looking for a tool to measure on FDDI-WAN trunk the network load
> per net/subnet and also a top 20 list.
>
> As i understand i have do to this with netramet with a detailed flow ON
> host base. Since we see about 10000 internal hosts on this trunc, i
> expect a huge amount of data.
>
> We measured this with NNstat and limited the table sizes.
>
> - Is this possible with NeTraMet ?
>- How would it work with FDDI (with about 10-20% util)
I monitor an FDDI ring using a SPARC 20 running Solaris 2.5. This
ring is only about 5% loaded (peaking to maybe 10%), but NeTraMet takes
only a few % of the processor time. A 20% loaded FDDI ring should
not present problems.
As for doing the 'top 20,' ther's no way to do this directly within the
meter. You'd have to collect data for all the hosts, using some rules
about like this:
Assume your network is a Class B, say 123.123.0.0 ..
DestPeerAddress & 255.255.0.0 = 123.123.0.0: GotoAct, my_net;
Null & 0 = 0: NoMatch, 0;
#
my_net:
DestPeerAddress & 255.255.255.255 = 0: PushPkttoAct, Next;
Null & 0 = 0: Count, 0;
This should order the flows so that your hosts always appear as
destinations in the flow table. If there are 10000 or them, they won't
always be busy, so there shouldn't be too much data to retrieve.
Note that I haven't Pushed the Source address here - that would
create a LOT of flow table entries! Also, you may need to set a
big number of flows using the -f command line option. Version 4.1
allows this to be a 32-bit integer (50000 to 100000 seems to work well).
Cheers, Nevil
+-----------------------------------------------------------------------+
| Nevil Brownlee Director, Technology Development |
| Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland |
| FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand |
+-----------------------------------------------------------------------C
From netramet-owner Mon Jul 28 17:26:43 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id RAA18270 for netramet-outgoing; Mon, 28 Jul 1997 17:25:17 +1200 (NZST)
Received: from ccu1.auckland.ac.nz (
[email protected] [130.216.3.1]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id RAA18265; Mon, 28 Jul 1997 17:25:10 +1200 (NZST)
Received: (from nevil@localhost)
by ccu1.auckland.ac.nz (8.8.5/8.8.5) id RAA12888;
Mon, 28 Jul 1997 17:25:09 +1200 (NZT)
From: Nevil Brownlee <
[email protected]>
Message-Id: <
[email protected]>
Subject: re:
To:
[email protected]
Date: Mon, 28 Jul 1997 17:25:08 +1200 (NZT)
Cc:
[email protected]
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender:
[email protected]
Precedence: bulk
Hello Denys:
> I've just installed the NeTraMet 4.1 beta12 in a solaris environment.
>
> The meter and manager elements are all working well. However, when I run
> the command "NeTraMet" I receive the "segmentation fault" or "Bus Error"
> message. (This happened too in version 3.4!)
>
> The only way to avoid these errors is to run the meter with the command
> -n100 (Sampling Rate) wich means that only 1 out of 100 packets will be be
> processed.
>
> I've tried the option -p nnn (Size of buffer for incoming packet headers)
> but it wont recognize it. i.e: When I run "Netramet -p2048" the result is:
> "invalid option: -p". (this happens too in version 3.4!)
>
> My QUESTIONS are:
> 1.) Is the -p option available or not?
The -p option is only available on the PC meter, where it sets the
number of incoming packet buffers. In the Unix versions libpcap uses
whatever the kernel provides to do the input buffering, so there's
nothing further NeTraMet can do in this area.
> 2.) What does that "segmentation fault" and "Bus error" message mean?
One other test site has reported problems like this, but I haven't
been able to reproduce it - sigh. Can you run NeTraMet within gdb, so
as to give me some clue as to what it was doing when it got the fault,
please? Also, please try beta13; it fixes some problems which could
be related to this.
> 3.) How do I setup my env in order to improve the sampling rate of the
> meter? i.e: To process ALL packets!
As I said, I haven't been able to reproduce this. I hope your response
to 2) will give me some clues.
Cheers (and thanks for the feedback), Nevil
+-----------------------------------------------------------------------+
| Nevil Brownlee Director, Technology Development |
| Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland |
| FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand |
+-----------------------------------------------------------------------C
From netramet-owner Tue Jul 29 09:51:59 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id JAA04203 for netramet-outgoing; Tue, 29 Jul 1997 09:48:46 +1200 (NZST)
Received: from obelix.hrz.tu-chemnitz.de (
[email protected] [134.109.132.55]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id JAA04184 for <
[email protected]>; Tue, 29 Jul 1997 09:48:42 +1200 (NZST)
Received: from sunnyboy.informatik.tu-chemnitz.de by obelix.hrz.tu-chemnitz.de
with Local SMTP (PP); Mon, 28 Jul 1997 23:45:10 +0200
Received: from fred.csn.tu-chemnitz.de (fred.csn.tu-chemnitz.de [134.109.88.1])
by sunnyboy.informatik.tu-chemnitz.de (8.8.4/8.7.3) with SMTP
id XAA15030 for <
[email protected]>;
Mon, 28 Jul 1997 23:45:07 +0200 (MET DST)
Date: Mon, 28 Jul 1997 23:45:16 +0200 (MET DST)
From: Torsten Naumann <
[email protected]>
X-Sender:
[email protected]
To:
[email protected]
Subject: NeMaC-Flag (Timestamp confused)
Message-ID: <Pine.LNX.3.95L01at.970728234359.827E-100000@fred.csn.tu-chemnitz.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender:
[email protected]
Precedence: bulk
I don't know wether this messages was delivered to the list or not, so
I send it again:
Hi,
I'm using NeTraMet over a long time, but now I found a bug.
(I think this is a bug)
- starting netramet
NeMaC creating a flow-file (specified by the -F option) - that's
right.
- now "touch NeMaC.flag that NeMaC knows I want a new flowfile
NeMaC makes an new flowfile the starting time ist the time of
file creation but the "lasttime"-attribute holds the offset of the
meter first starting time. So when I calculate the absolut last
time of the flow only from the last flowfile then the result is
wrong.
--
bye Torsten
# Torsten Naumann *
[email protected] * +49-177-2382319
# Computer Science - TU Chemnitz - FRG *
http://www.tu-chemnitz.de/~tna
# PGP-public-key available via finger on email-address
#
# Das Schlimme an falschen Annahmen ist,
# da"s sie jedem Schwachkopf einleuchten. -- Leitzinger