dhcp fails with big dhcpd.leases

[dorian]

First of all I would like to inform that all the claims regarding the
dhcp problem with big dhcpd.leases file turned out to be completely false.
I was totally wrong stating that this is the problem subject.
I've just observed the same effect when the relatively small lease file.
So sorry for all the mess I've posted before.

The only what could excuse me is that until the most recent case the
problem appeared always when the lease file became "big".

Anyway a problem persists and I do not know the nature of it.

After some investigation I can describe it in that way.
I have a bridge br0 composed of interfaces eth1, eth2, eth3, ...
The dhcp server is listening on br0.

Sometimes the clients connected via eth2 cannot obtain IP address.
But in the same time the rest of the clients connected via eth1, eth3,
etc don't find any problem.

On the other hand it is not a matter of the connection via eth2 since I
am able to ssh to the hosts (some of them have static IP) connected via
this interface.
So it looks like for the dhcp protocol only this connection became
dysfunctional.

Till now I am investigating the problem since logically dchp protocol is
just one of the IP protocols so why it a problem with it only ?

Regarding the questions:
> Thinking some more about this, I'll add a few thoughts on things that
> have popped up.
>
> 1) Big bridged network.
> I'd personally doubt the sense in having one huge bridged network. If
> the number of active clients grows as big as dorian suggests, then I
> could see the amount of broadcast traffic getting quite significant.
> Unless all the links in the network are fairly high in capacity, I
> could see a situation where a big chunk of network capacity is taken
> up with broadcast traffic.
> It potentially makes any troubleshooting harder, since it won't be
> quick and easy to identify the location of a device causing problems -
> that would involve looking into the traffic and querying switches etc
> to find the device (although he may have put systems in place to
> automate this).
I need bridge since I need MAC addresses of the clients at the server.
>
> 2) Does anyone know if there are any problems running dhcpd on a
> bridge interface ?
Any help / experience exchange will be appreciated.
>
> 3) dorian also suggests they want to keep client IPs the same and this
> is important for management purposes. Two problems with this :
> Unless he uses fixed addresses or reserved leases, then a clients
> address is not guaranteed. All it takes is just one bad (or malicious)
> device, and some or all devices with expired leases could find their
> addresses change when they next connect.
> Secondly, any device can change it's address quite easily - just by
> changing client-id (trivial) or MAC address (almost trivial these days).
Well. Not quite true.
First of all the users who are using the network are not so educated in
IT to know what MAC is.
Secondly for mobile devices (a big user group) changing the MAC is very
difficult.
And lastly - the users _are interested_ to be identified correctly.
Previously I wrote it is a hot-spot network and it is true.
But the network used to serve personally dedicated content also.
>
> Relying on IP addresses not changing is likely to come back at some
> point and bite - badly. It also means that the evidence is unreliable
> should it be used for legal purposes. There has already been at least
> one well publicised case where an innocent victim was dragged into
> court on copyright theft charges because the ISP got their timezone
> wrong and gave the wrong customer details relating to the IP in question.
>
> If you need to keep track of who is using the network and when and
> what they are doing (such as billing for traffic) then some other
> mechanism needs to be in place - neither IP nor MAC address are
> adequate for this.
As I wrote above - I am registering MACs. Therefore I am using bridges
not routers.
The constancy of the IP only help me to make client identification faster.
> 3b) Giving customers the appearance of fixed addresses will raise
> expectations. Some customers will get accustomed to it, and will get
> upset if their IP does change. Having fewer IPs than customers (but
> enough to satisfy all concurrent needs) and forcing some churn will
> keep expectations realistic.
>
And it is fine. It is a essential for business to create users
expectations which could be satisfied and charged next.