On Wed December 29 2010 18:12:21 Daniel Bareiro wrote:
> Sorry. I forgot to comment that they are all static IPs for better
> control of workstations accessing the network.

Hi Daniel,

You may be doing a lot of work that is not providing any security.

If someone connects an unauthorized workstation, and configures it
with an unused IP from the DHCP pool, are they blocked from accessing
the network?

On the very rare occasions when I've done MAC filtering it's been
in a switch, not a DHCP server.

--Mike Bird


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201012291838.51366.mgb-debian@yosemite.net">http://lists.debian.org/201012291838.51366.mgb-debian@yosemite.net

On Wednesday, 29 December 2010 18:38:51 -0800,
Mike Bird wrote:

> > Sorry. I forgot to comment that they are all static IPs for better
> > control of workstations accessing the network.

> Hi Daniel,

Hi, Mike.

> You may be doing a lot of work that is not providing any security.
>
> If someone connects an unauthorized workstation, and configures it
> with an unused IP from the DHCP pool, are they blocked from accessing
> the network?

Still we do not have something contemplates this situation. It's
something I have on my 'to do' list, so if you know some free software I
can use for this purpose, I would appreciate.

> On the very rare occasions when I've done MAC filtering it's been in a
> switch, not a DHCP server.

The idea of having static IP was that they were easily identifiable if
they were conducting suspicious activity (for example an indiscriminate
use of bandwidth). Simplifying the configuration of DHCP server, what
other tools can make the fine adjustment when detecting a problem with
workstations?

Thanks for your reply.

Regards,
Daniel
--
Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598

On Wed December 29 2010 19:42:35 Daniel Bareiro wrote:
> The idea of having static IP was that they were easily identifiable if
> they were conducting suspicious activity (for example an indiscriminate
> use of bandwidth). Simplifying the configuration of DHCP server, what
> other tools can make the fine adjustment when detecting a problem with
> workstations?

FWIW, we simply use the MAC tables on the switches when we need to
track down somebody abusing a network.

Sorry I can't help you with your large static DHCP file. Maybe a
PERL or sed script to generate it from text file of MAC/IP pairs?

--Mike Bird


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201012292007.35739.mgb-debian@yosemite.net">http://lists.debian.org/201012292007.35739.mgb-debian@yosemite.net

On 12/30/2010 09:05 AM, Daniel Bareiro wrote:


Hi all!

I have a network of over a hundred machines in which we are using a DHCP
server on Debian GNU/Linux Lenny. But the dhcpd.conf file is monolithic
and unwieldy.

Thanks in advance for your replies.


I've been thinking about a similar problem & what I'd like to do would
possibly require the DHCP server use a database back-end instead of a
flat file. What I would like is for it to automatically give each new
client an IP address and then enter that address as a static entry,
every time a known client requests an IP address it would update a "last
seen" field so that if it runs out of address space it would overwrite
the MAC address of the entry with the oldest "last seen" field.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4D1C3B5D.7090405@homeurl.co.uk">http://lists.debian.org/4D1C3B5D.7090405@homeurl.co.uk

Bob wrote:
> I've been thinking about a similar problem & what I'd like to do
> would possibly require the DHCP server use a database back-end
> instead of a flat file.

I am sure you mean a relational database. The ISC dhcpd already has a
database on the back end. It just isn't a relational database. The
flat-file you are referring to is simply a text dump of the in memory
database. It provides persistent data for the database across
restarts.

I am not sure using a full relational database would improve things.
Does it really need that heavy of a back end? There have been patches
available in the past to add a relational database to it however.

> What I would like is for it to automatically give each new client an
> IP address and then enter that address as a static entry, every time
> a known client requests an IP address it would update a "last seen"
> field so that if it runs out of address space it would overwrite the
> MAC address of the entry with the oldest "last seen" field.

You have pretty closely described how the ISC DHCP daemon is currently
implemented. It already keeps track of the state of each ethernet
address seen and the times for the lease. It will keep the same
assignment for the same address unless it needs to reclaim it for a
different device.

Please be careful when using words like "static" in your description.
Because strictly speaking your description didn't describe a static
entry. And that word already has the meaning of an address that can't
be changed or overwritten as you say.

Bob

On 12/30/2010 05:05 PM, Bob Proulx wrote:

Bob wrote:

I've been thinking about a similar problem& what I'd like to do
would possibly require the DHCP server use a database back-end
instead of a flat file.


I am sure you mean a relational database. The ISC dhcpd already has a
database on the back end. It just isn't a relational database. The
flat-file you are referring to is simply a text dump of the in memory
database. It provides persistent data for the database across
restarts.

I am not sure using a full relational database would improve things.
Does it really need that heavy of a back end? There have been patches
available in the past to add a relational database to it however.


What I would like is for it to automatically give each new client an
IP address and then enter that address as a static entry, every time
a known client requests an IP address it would update a "last seen"
field so that if it runs out of address space it would overwrite the
MAC address of the entry with the oldest "last seen" field.


You have pretty closely described how the ISC DHCP daemon is currently
implemented. It already keeps track of the state of each ethernet
address seen and the times for the lease. It will keep the same
assignment for the same address unless it needs to reclaim it for a
different device.

Please be careful when using words like "static" in your description.
Because strictly speaking your description didn't describe a static
entry. And that word already has the meaning of an address that can't
be changed or overwritten as you say.


Ah yes I know what you mean, pfSence refers to it as a static mapping
when a DHCP daemon gives a device the same address all the time but it's
not the same as a device having a statically assigned address within
it's own settings, D stands for dynamic.


It was just a question of how fast the damon could identify the client
that hasn't connected for the longest to over write, obviously for me
with 245 address in my subnet this would never be a real problem but I
could imagine a hotel, cafe, office building or municipal WiFi project
might find it useful to have devices repeatedly & persistently assigned
the same address, while playing with a 24 bit address block.


A flat file for 16 million users would be a little unwieldy whereas an
RDBMS wouldn't have a problem.


Does ISC DHCP remember it's self assigned "static mapping" between reboots?

Thank you for your help, I've been wondering about this for a while.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4D1C5D74.4080004@homeurl.co.uk">http://lists.debian.org/4D1C5D74.4080004@homeurl.co.uk

2010/12/30 Bob <spam@homeurl.co.uk>:

> A flat file for 16 million users would be a little unwieldy whereas an RDBMS
> wouldn't have a problem.

Do you really want to use only one dhcpd for 16 millions users ? You
might run into big big problems, when it crashes


--
Eero


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTikh8rkFBAeyd4rMdQcgKVAo1To5e3KzCG5zvaDA@mail .gmail.com">http://lists.debian.org/AANLkTikh8rkFBAeyd4rMdQcgKVAo1To5e3KzCG5zvaDA@mail .gmail.com

On Thursday, 30 December 2010 17:42:31 +0300,
Eero Volotinen wrote:

> > A flat file for 16 million users would be a little unwieldy whereas
> > an RDBMS wouldn't have a problem.

> Do you really want to use only one dhcpd for 16 millions users ? You
> might run into big big problems, when it crashes

Their telephone and pager will set fire of the amount of calls that he
will receive if it gets to fail X-D

While my case is not as extreme as this, the amount of workstation is
interesting. So I was wondering if there any better way to manage this
situation with the ISC DHCPd; Maybe simplifying the configuration work
in the dhcpd.conf and concentrating on other tools to keep track of
any specific IP address.


Regards,
Daniel
--
Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598

Bob wrote:
> Does ISC DHCP remember it's self assigned "static mapping" between reboots?

Yes. The daemon writes information into the dhcpd.leases file with
information about every lease assigned before it assigns it. This
guarentees that the file has enough information to restart. It
ensures that even in the case of a system crash that a lease won't be
forgotten. On startup it reads that same file to populate its
internal database. This allows it to have the lease information
persistent across restarts.

When a new lease is requested the client may ask to continue a
previous lease that it already had assigned to it. In that case the
dhcpd program looks to see if this is possible. (The client may have
requested an IP not valid on this network, if it was a mobile device
and just came from a different network.) If that IP is available then
it will be assigned because the client requested that address. Or the
client may just ask for an IP assignment. In that case the dhcpd
program will look to see if that client had previously any IP address
in the database. If so and if that IP address is also currently
available for assignment then it will assign that address. In a
typical case with a large pool of addresses this means that a client
device will get the same address all of the time and it will never
change.

On a pool that is small relatively to the number in use the requested
address may not be available. It may have already been taken for use
by another device because it was the only available address when some
other device requested an address. In which case a different address
must be assigned. If this is happening and not wanted then a larger
size of the pool of addresses is needed. If the pool is large enough
then the server will assign the same address. (Unless the client has
requested a different address and that different address is available.
Happens when a mobile device moves between two compatible subnets and
requests a continuation of an IP that it really got on the other subnet.)

A typical problem I see is when the lease times are configured to be
quite long but the turnover of devices is fast. A local airport FBO
had lease times configured for one full day and only 128 addresses for
the pool. At 8am in the morning everything would be okay. But then
by the afternoon there had already been 128 people connected for a
short time as they passed through the airport and then moved on. They
were gone but the full day of lease time kept that IP allocated until
it expired. At that time no new device could get an IP address and
"things never work in the afternoon" was the complaint. The pool was
too small, where small was the product of number times timeout. In
that type of environment setting a much shorter lease time to one hour
allowed leases to expire sooner so only active leases were kept in the
pool. Also the address pool size was increased. That combination
solved the problem. The point here is that it isn't just the number
of currently active devices but any device that aquired and still
holds an active lease even if it has moved on. With laptops, smart
phones and tablets this means more addresses are needed.

Bob