That's a basic flaw of dhcp, nothing related to ntop.
The dhcp server thinks it owns a range, and it offers up addresses in that
range. If people don't respect that ownership, there's not much the server
can do. See ftp://ftp.isi.edu/in-notes/rfc2131.txt
Also,
distributed address allocation schemes depend on a polling/defense
mechanism for discovery of addresses that are already in use. IP
hosts may not always be able to defend their network addresses, so
that such a distributed address allocation scheme cannot be
guaranteed to avoid allocation of duplicate network addresses.
and this:
In some environments it will be necessary to reassign network
addresses due to exhaustion of available addresses. In such
environments, the allocation mechanism will reuse addresses whose
lease has expired. The server should use whatever information is
available in the configuration information repository to choose an
address to reuse. For example, the server may choose the least
recently assigned address. As a consistency check, the allocating
server SHOULD probe the reused address before allocating the address,
e.g., with an ICMP echo request, and the client SHOULD probe the
newly received address, e.g., with ARP.
However, it's a SHOULD not a MUST. So it's possible for a lazy server to
hand out an address that's in use and a lazy client to accept and use it.
It's actually up to the client to defend their IP addresses ... there's an
interesting piece on "IP Address Defense" here -
http://www.rtaautomation.com/documents/EIPAddressIssuesPaper.pdf.
It's also possible for the ARP requests not to be seen due to networks being
partitioned by switches - ARP and DHCP broadcasts are normally limited to a
single collision domain - so the software could be innocent. So it's really
up to you, Mr. SysAdmin, to keep the DHCP configuration files updated with
any static assignments. And that's about the best you can hope for...
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ben
Zampatti
Sent: Thursday, September 04, 2003 5:41 PM
To: [EMAIL PROTECTED]
Subject: RE: [Ntop] Bandwidth logging per IP... ntop the way to go?
Hey, thanks for replying to this. At least i know that you know what I'm
talking about, how that IP logging is unreliable if two people use the
same IP
from a different machine at different times. I understand that MAC
address
logging would be better in my situation, but anyway, I have worked out
how to
use the latest NTOP for our system, I have compiled it all and just need
to
work out how to use it with rrdtool to see if that fits the job.
The problem is, everyone should be on dhcp, yes, but lets just say
someone
decides to put a static IP on their machine, which would cause
confustion with
NTOP. I want to make it as fool proof as possible, and thats why that
logging
by MAC address would be the way to go. I'm up to the stage though that I
dont
really care if someone else uses the same IP as someone else, as long as
it
logs it FOR that IP, and not just start the stats for that IP from the
beginning (ie, 0 bytes). I haven't used RRDtool at all, but am about to
look at
it seeing that NTOP is now compiled. Hopefully things work out, will let
you
know.
> ----- Original Message -----
> From: "Burton M. Strauss III" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 27, 2003 16:23 PM
> Subject: RE: [Ntop] Bandwidth logging per IP... ntop the way to go?
>
>
> > Nope. I'm right and you're wrong. Naaaaa Naaaaa.... :-)
> >
>
> I'll permit you to escape, but only this one time....:-)
>
> > Actually, it depends on your network.
> >
> > If the network is stable, that is machines don't come and go
frequently,
> > then an IP address is a stable identifier and is substantially equal
to a
> > machine (PC) and thus to a user.
> >
> > From his question, I was expecting a network with a limited pool of
DHCP
> > addresses, where a large population of individuals come in, join the
> network
> > and receive an address, do stuff for a period of minutes, hours,
days and
> > then leave. Some number of days later (depends on the lease time),
> another
> > user touches down and gets assigned the same IP.
> >
>
> I read his question as simpler, ie. CAN one easily track bwidth
> by IP w/ the *current* NTOP, even *if* one uses DHCP.
>
> > So 192.168.1.12 is You on Monday/Tuesday and Me on Friday.
> >
> > Because ntop uses ip for the rrd's it will commingle our workload.
> >
> > In this situation, the MAC address is a better stable identifier.
> >
> > It would certainly be feasible to re-write rrdPlugin.c to use the
MAC
> > address not the IP address for local hosts (or maybe do both), but
it
> > doesn't do that today.
> >
>
> Actually, I was only chiming in to say that, in fact this could be
> done and I'd done it (w/ the latest NTOP.) Yeah, tracking via MACs
mite be
>
> better from one perspective, but one can track traffic via IPs rite
now.
> Moreover, in spite of the possibility of DHCP lease-related conflicts,
the
> inclusion of RRD to NTOP, has made bwidth-by-IP more reliable.
>
> > As a work-around, extending the DCHP lease time means that there
would be
> > much less reuse - maybe you want a time that is at least 110% of the
> > interarrival time of your frequent users. That way, the people who
show
> up
> > periodically get the same address each time, while the transients
and
> > one-timers use the rest. It wouldn't be perfect, but it would
work...
> >
>
> Agreed. Later....Jet
>
> =============== From the desk of Jethro Wright, III ================
> + Nothing causes self-delusion quite so readily as power. =
> === [EMAIL PROTECTED] ========================= Liu Binyan ===
>
> _______________________________________________
> Ntop mailing list
> [EMAIL PROTECTED]
> http://listgateway.unipi.it/mailman/listinfo/ntop
>
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
