[rrd-users] FW: [Jkflow-users] Question

Sat Jul 3 18:41:17 MEST 2004

Hello Jaime,

This single IP graphing was already asked some time ago.

Programming this is not hard, but I have more concerns about how to keep
this data in RRDtool databases. If I have to create a new
direction/directory with RRDTool databases for every IP-address, the amount
of needed disk space will increase a lot. Much of this space will actually
not be needed because nobody will surf, email, chat, ftp, kazaa, ssh, X11,
etc... and all at the same time. A lot of RRDTool databases will be filled
up with zero's, and to avoid the bottleneck speed of IO input of RRDTool
updating, I would have to create a way to create/delete directions dynamical
or I should create top-IP hash tables inside each hash counter to keep the
largest users, but I don't know how I would have to keep this data in the
RRDTool databases. Let's say that I can create a system where 5 largest
users of http, ftp, etc... are kept in RRDTool. How could I retrieve this
data from RRDTool in function of a certain IP-address? This would mean that
I need to enter this data in some sort of attributes in RRDTool datasets.
Actually this is getting to a point where RRDTool is getting to it's limit,
and a SQL database would be a better solution, but this would mean that I
have to create the graphing capabilities, or a data handling layer to update
RRDTool files from the database myself. RRDTool with it circular fixed
amount of datapoints is not good for this scenario, and maybe this should be
splitted into a data and a graphing part. I send this to the RRDtool
mailinglist too, maybe they have good ideas

For your case It all depends on how much distinct IP's you need to handle,
if it is a few (10-30 IP addresses), then much of what is mentioned here
above doesn't apply to you: go program it, you just have to create a new
countDirections() function for distinct IP adresses.

Hmm, Packeteer, I have seen it already, costed a lot, but that was no
problem because I was scheduled to leave my previous job anyway. I'm curious
how they keep their data within proportions.

A little related to this: I used Autofocus this week to analyse a week long
low volume traffic, this package is capable to correlate
IP/protocols/services to each other. Other than doing it's work perfectly,
it was painfully slow in relation with the very low volume traffic I
captured. I guess this would be normal with the magic it does, but I don't
expect this will is usable for analysing high volume data.

Jurgen

-----Original Message-----
From: jkflow-users-admin at lists.sourceforge.net
[mailto:jkflow-users-admin at lists.sourceforge.net]On Behalf Of Jaime Nebrera
Sent: donderdag 1 juli 2004 18:38
To: jkflow-users at lists.sourceforge.net
Subject: [Jkflow-users] Question and paid support

  Hi all,

  I have one question and a might be offer if a quote to a client is
accepted.

  First the question.

  The client has around 15 branches all connecting to a central "server"
zone and the Internet (over a central common router).

  I see from the documentation its easy to get information about the
whole net (all branches going through the central router) and each
branch or subnet. I could aggregate traffic based on application or
IP/Subnet

  But the client wants to go further and also have the same information
but aggregating at a a single IP level (that is a subnet (single
machine) of a subnet).

  The idea is have a general picture (total bandwith by subnet and
application), a detailed view for a particular branch (total bandwidth
by IP and application) and at the end a view by single IP.

  Network <= Subnet <= IP   Total traffic by IP/Subnet and application

  I dont know if this is possible.

  Secondly, if the client (a big local government) accepts our quote, we
will gladly pay to get some support in setting this one right fast as is
a very important project for us. If the above is possible, we would pay
just to get it right and fast, and if not, pay to develop it (if not too
expensive).

  We have to beat an offer from packeteer :) We have the traffic control
side solved, but want to get the traffic viewing too.

  Very thankful for your help. You will hear from us if this is
accepted.

--
Jaime Nebrera - jnebrera at eneotecnologia.com
Consultor TI - ENEO Tecnologia SL
Telf.- 95 455 40 62 - 619 04 55 18

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Jkflow-users mailing list
Jkflow-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jkflow-users

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Jkflow-users mailing list
Jkflow-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jkflow-users

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi