High ram-usage with multiple /16 ipv4 networks

[Ruben Wisniewski]

Am Mon, 20 Apr 2015 18:48:12 +0200
schrieb Peter Rathlev <peter at rathlev.dk>:

> Hmm... I'm not sure I understand the configuration:
> 
> On Mon, 2015-04-20 at 17:14 +0200, Ruben Wisniewski wrote:
> > subnet 10.66.0.0 netmask 255.255.0.0 {
> >     range 10.66.11.1 10.66.20.255; #main
> >     pool {
> >         range 10.66.1.1 10.66.10.255;
> >         deny all clients;
> >     }
> >     pool {
> >         range 10.66.30.1 10.66.254.255;
> >         deny all clients;
> >     }
> 
> Wouldn't the "deny all clients" statements make those ranges a no-op?
> So each subnet has just 2558 available leases? But maybe this is just
> testing?
We need this deny all clients statement because of our routing-protocol.

The protocol is rerouting all dhcp traffic to the dhcpd-server which
have the best connection. So all other dhcp-servers does not get the
DHCPINFORM/DHCPREQUEST. So we need to activly deny the
other ranges, because no other dhcp-server will respond to the querys.

Example:

The client knows the network, 10.66.0.0/16 and had the 10.66.11.2 the
last time.

Our routing-protocol is routing the DHCPREQUEST to the server we
discuss about.

The dhcpd get an DHCPREQUEST for 10.66.11.2 which is out of his range
but in the subnet-definition and silently ignore the request, because
he thinks he is not responsible for this requests.

Since we know, no other dhcpd will get this client-packages, we need to
activly respond with DHCPNAK to change the client's status about his
ip-address.

Now the client ask for a new lease and the dhcpd respond with an
ip-address out of his range.

If we remove this "deny all clients" rule out of our configs, the
clients ask several times for the old ip-address, destroy any roaming
in the network. Any reconnect takes 12-15 seconds, depend on the
client's implementation of dhcpd. With this rule we got an ip in under
1 second.

> What part is it that you see constantly increasing in that graph? I
> see the swap doing something that looks like an asymptotic increase
> towards some number around 1 GBytes or thereabout. Similar for
> "committed", whatever that is in this context.
"committed" is not used but reserved memory and can be ignored.

I think the part which is constantly increasing is the nameserver's
cache.

> Is this a failover setup? The configuration doesn't say that, but in a
> failover setup the servers always create all leases from the
> beginning. The only thing that make the memory usage grow is whatever
> extra information is added to the leases, and there might even
> already be memory reserved for some of that in advance.
Well not in the dhcpd-meaning. Each dhcp-server has it's range and just
got requests for the clients he has to care about, which got be
determined by routing protocol.

 > I'd say it looks normal. Running a DHCP server for 1.5 million leases
> is no small feat. Running a server at all with just 512 MBytes of RAM
> sounds like asking for trouble anyway. (RAM inflation, I know, but RAM
> is cheap these days.)
Actually we just use the 2558 leases, not the 1.5 million ones. Since
the config says, that no client will ever use the other pool.




Best regards

Ruben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 303 bytes
Desc: Digitale Signatur von OpenPGP
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150421/fcb82b3e/attachment.bin>