High ram-usage with multiple /16 ipv4 networks

[Ruben Wisniewski]

Dear list,


we use the isc-dhcp on virtual-servers, which are connected via tunnels
to open wifi-hotspots, which are spread all around in some citys.

We use a layer2 mesh-protocol, batman-adv, for routing from the servers
to the hotspots. So each city is one broadcast-domain and got a
ipv4 /16 subnet.

Shortened: We use the dhcp-server in a very dynamic enviroment, with
several thousand different clients per day. But since we got several
regional L2-Network, the clients usualy move around in the network
without asking the dhcpd for a new lease.

One of our smaller virtual servers got 512 MByte of ram, on this server
we got issues because of the ram-usage of the dhcp server:

[root@bragi ~]# /usr/bin/dhcpd --version
isc-dhcpd-4.3.2
[root@bragi ~]# pmap -x 3174
3174:   /usr/bin/dhcpd -4 -q -pf /run/dhcpd4.pid
Adresse            kByte     RSS   Dirty Modus Zuordnung
0000000000400000    2000     624       0 r-x-- dhcpd
00000000007f3000       4       4       0 r---- dhcpd
00000000007f4000      32      20      16 rw--- dhcpd
00000000007fc000     240      24      20 rw---   [ anon ]
0000000001709000   50980    2100     392 rw---   [ anon ]
00007f758d881000  472112  259264   15928 rw---   [ anon ]
00007f75aa58d000      44       0       0 r-x-- libnss_files-2.21.so
00007f75aa598000    2048       0       0 ----- libnss_files-2.21.so
00007f75aa798000       4       0       0 r---- libnss_files-2.21.so
00007f75aa799000       4       0       0 rw--- libnss_files-2.21.so
00007f75aa79a000    1636    1240       0 r-x-- libc-2.21.so
00007f75aa933000    2048       0       0 ----- libc-2.21.so
00007f75aab33000      16      12       0 r---- libc-2.21.so
00007f75aab37000       8       8       8 rw--- libc-2.21.so
00007f75aab39000      16      12      12 rw---   [ anon ]
00007f75aab3d000     136     124       0 r-x-- ld-2.21.so
00007f75aab67000    1964     252      64 rw---   [ anon ]
00007f75aad5d000       4       4       4 rw---   [ anon ]
00007f75aad5e000       4       4       0 r---- ld-2.21.so
00007f75aad5f000       4       4       4 rw--- ld-2.21.so
00007f75aad60000       4       4       0 rw---   [ anon ]
00007ffee1b13000     132      24      20 rw---   [ stack ]
00007ffee1bd4000       8       0       0 r----   [ anon ]
00007ffee1bd6000       8       4       0 r-x--   [ anon ]
ffffffffff600000       4       0       0 r-x--   [ anon ]
---------------- ------- ------- -------
kB gesamt         533460  263728   16468
[root@bragi ~]# du -h /var/lib/dhcp/dhcpd.leases
776K    /var/lib/dhcp/dhcpd.leases

Since the dhcpd uses this much ram, the system is swapping excessively,
and once an hour, when the dhcpd is writing it's leasefile to disk, the
dhcpd stuck for three minutes, without answering any request.

Our dhcp.conf looks like this, but with 25 subnets on different
interfaces:

ddns-update-style none;
ignore client-updates;
deny declines;
one-lease-per-client true;
ignore bootp;
default-lease-time 600;
max-lease-time 800;
min-lease-time 60;
ignore-client-uids true;
authoritative;
log-facility local7;

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;
    }
    option broadcast-address 10.66.255.255;
    option routers 10.66.11.0;
    option domain-name-servers 10.66.11.0;
    option ntp-servers 10.66.11.0;

    interface subnet-x;
}

[...]

The ram-consumption is the same when the daemon is starting with an
empty lease-file. And is constantly increasing on runtime:

http://i.imgur.com/60QgMe2.png


So my question is, it this much ram-consumtion expected or a bug?


Best regards

Ruben

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Peter Rathlev]

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?

Otherwise it seems to fit with what we see on our servers. I'm guessing
the ranges that deny all clients still create leases. That gives you
62714 leases per subnet (2558 + 2558 + 57598) and 1567850 leases for 25
of those.

Our dhcpd process currently uses around 360 MBytes on each of the two
servers in a failover configuration in total. We have about 750k leases:

  dump-complete-dhcpd-config \
  | sed -e 's/.*range //; t PRINT; d; :PRINT s/[[:space:]]*;.*//;' \
  | while read LINE ; do \
      set -- $LINE
      echo $(( 0x$( gethostip -x $2 ) - 0x$( gethostip -x $1 ) ))
  done \
  | awk '{ SUM += $1 } END { print "Total number of leases: "SUM; }'
 
  Total number of leases: 752066

> The ram-consumption is the same when the daemon is starting with an
> empty lease-file. And is constantly increasing on runtime:
>
> http://i.imgur.com/60QgMe2.png

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.

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.

I don't know if a non-failover configured server reserves memory for all
leases up front, I haven't run anything with a large pool of addresses
without failover.
 
> So my question is, it this much ram-consumtion expected or a bug?

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.)

--
Peter


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Peter Rathlev <[hidden email]> wrote:

> 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?

... [show rest of quote]

Correct.

> Otherwise it seems to fit with what we see on our servers. I'm guessing
> the ranges that deny all clients still create leases.

Yes, on startup, hash tables are created to hold every address configured - and I'd assume they won't have done a specific test for that "deny everything".
So even if you have few clients, the hash tables can be very large if you define large ranges - not it's the ranges, not the subnets, that need space.



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Ruben Wisniewski]

Am Mon, 20 Apr 2015 18:48:12 +0200
schrieb Peter Rathlev <[hidden email]>:

> 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?

... [show rest of quote]

We need this deny all clients statement because of our routing-protocol.

... [show rest of quote]

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


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Ruben Wisniewski]

When I delete the "deny all clients" rules, the ram-footage is reduced
to 35 MByte:

[root@bragi ~]# pmap -x 30521
30521:   /usr/bin/dhcpd -4 -q -pf /run/dhcpd4.pid
Adresse            kByte     RSS   Dirty Modus Zuordnung
0000000000400000    1996    1004       0 r-x-- dhcpd
00000000007f2000       4       4       4 r---- dhcpd
00000000007f3000      32      20      20 rw--- dhcpd
00000000007fb000     240      24      24 rw---   [ anon ]
0000000001eeb000    4712    4676    4676 rw---   [ anon ]
00007f9b9c8d7000   19532   19528   19528 rw---   [ anon ]
00007f9b9dbea000      44       0       0 r-x-- libnss_files-2.21.so
00007f9b9dbf5000    2048       0       0 ----- libnss_files-2.21.so
00007f9b9ddf5000       4       4       4 r---- libnss_files-2.21.so
00007f9b9ddf6000       4       4       4 rw--- libnss_files-2.21.so
00007f9b9ddf7000    1636    1380       0 r-x-- libc-2.21.so
00007f9b9df90000    2048       0       0 ----- libc-2.21.so
00007f9b9e190000      16      16      16 r---- libc-2.21.so
00007f9b9e194000       8       8       8 rw--- libc-2.21.so
00007f9b9e196000      16      16      16 rw---   [ anon ]
00007f9b9e19a000     136     112       0 r-x-- ld-2.21.so
00007f9b9e1c4000    1964    1956    1956 rw---   [ anon ]
00007f9b9e3ba000       4       4       4 rw---   [ anon ]
00007f9b9e3bb000       4       4       4 r---- ld-2.21.so
00007f9b9e3bc000       4       4       4 rw--- ld-2.21.so
00007f9b9e3bd000       4       4       4 rw---   [ anon ]
00007fffe680d000     132      20      20 rw---   [ stack ]
00007fffe689f000       8       0       0 r----   [ anon ]
00007fffe68a1000       8       4       0 r-x--   [ anon ]
ffffffffff600000       4       0       0 r-x--   [ anon ]
---------------- ------- ------- -------
kB gesamt          34608   28792   26292

So where can I file this bug?


Best regards

Ruben


Am Tue, 21 Apr 2015 13:07:36 +0200
schrieb Ruben Wisniewski <[hidden email]>:

> Am Mon, 20 Apr 2015 18:48:12 +0200
> schrieb Peter Rathlev <[hidden email]>:
>
> > 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
>

... [show rest of quote]

... [show rest of quote]

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Peter Rathlev]

On Tue, 2015-04-21 at 13:07 +0200, Ruben Wisniewski wrote:

> Am Mon, 20 Apr 2015 18:48:12 +0200
> schrieb Peter Rathlev <[hidden email]>:
> > 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.

Ah, okay. I had thought that "authoritative" would NAK those, but I can
see that it doesn't.

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

That's not really related to the dhcpd though, is it?

>  > 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.

No, you have configured 1.5 million leases. That you do not use them
does not mean that they do not exist.

So still: It sounds normal.

--
Peter

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Peter Rathlev]

On Tue, 2015-04-21 at 13:18 +0200, Ruben Wisniewski wrote:
> When I delete the "deny all clients" rules, the ram-footage is reduced
> to 35 MByte:
>
> [root@bragi ~]# pmap -x 30521
> 30521:   /usr/bin/dhcpd -4 -q -pf /run/dhcpd4.pid
...
> kB gesamt          34608   28792   26292
>
> So where can I file this bug?

Umm... what bug? :-)

With 1.5 million leases you use 533 Mbytes memory, with just 2558 leases
you use 35 Mbytes memory. That's not a bug.

What you want sounds like some way of actively denying clients with
specific addresses without creating leases for them. I can't from the
top of my head think of such a way with ISC DHCP, but I'll give it a
try.

--
Peter


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson-2]

Peter Rathlev <[hidden email]> wrote:

> With 1.5 million leases you use 533 Mbytes memory, with just 2558 leases
> you use 35 Mbytes memory. That's not a bug.
>
> What you want sounds like some way of actively denying clients with
> specific addresses without creating leases for them. I can't from the
> top of my head think of such a way with ISC DHCP, but I'll give it a
> try.

Sounds like a bit of a "sort of broken" setup - and I wonder if it wouldn't work with smaller subnets. The fact that the client is being forced to change address suggests that the network isn't as flat as stated.

But one way of "fudging" DHCP might be to lie to it about the subnets.

Looking back, the example given was an "active" range of 10.66.11.1 to 10.66.20.255. That fits in the 10.66.0.0/19 subnet which covers 10.66.0.0 to 10.66.31.255
Thus the ranges needing to be actively denied are much smaller - and by adjusting the ranges used, can be reduced a lot smaller still (or even eliminated). Eg, 10.66.16.1 to 10.66.23.255 fits within the 10.66.16.0/21 subnet (ie 1/4 the size again) but still offers over 2k leases.

Then (IIRC) you just need to specify the subnet mask option to override the default derived from the subnet declaration.

A request for an address outside of the server's declared subnet will get a NAK without creating a lease table entry - the server will just treat it as "not valid for this network".

As I say, it's something of a fudge, but worth trying.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Ruben Wisniewski]

Hi Simon,



Am Tue, 21 Apr 2015 14:42:46 +0100
schrieb Simon Hobson <[hidden email]>:

> Peter Rathlev <[hidden email]> wrote:
>
> > With 1.5 million leases you use 533 Mbytes memory, with just 2558
> > leases you use 35 Mbytes memory. That's not a bug.
> >
> > What you want sounds like some way of actively denying clients with
> > specific addresses without creating leases for them. I can't from
> > the top of my head think of such a way with ISC DHCP, but I'll give
> > it a try.
>
> Sounds like a bit of a "sort of broken" setup - and I wonder if it
> wouldn't work with smaller subnets. The fact that the client is being
> forced to change address suggests that the network isn't as flat as
> stated.

Well the problem is, that we need one big subnet, because the

... [show rest of quote]

routingprotocol is L2. Else all clients have to fit in one lease-range.
Since we use many gateways, this seem to be the only solution for this.

The routing-protocol does reroute the dhcp-requests because it have
more information about the quality of the links and the actual free
bandwitdth of each gateway. So turning off this feature will reduce the
overall network speed, because we have no loadbalancing based on free
bandwidth anymore.

> But one way of "fudging" DHCP might be to lie to it about the subnets.
>
> Looking back, the example given was an "active" range of 10.66.11.1
> to 10.66.20.255. That fits in the 10.66.0.0/19 subnet which covers
> 10.66.0.0 to 10.66.31.255 Thus the ranges needing to be actively
> denied are much smaller - and by adjusting the ranges used, can be
> reduced a lot smaller still (or even eliminated). Eg, 10.66.16.1 to
> 10.66.23.255 fits within the 10.66.16.0/21 subnet (ie 1/4 the size
> again) but still offers over 2k leases.
>
> Then (IIRC) you just need to specify the subnet mask option to
> override the default derived from the subnet declaration.
>
> A request for an address outside of the server's declared subnet will
> get a NAK without creating a lease table entry - the server will just
> treat it as "not valid for this network".
>
> As I say, it's something of a fudge, but worth trying.

... [show rest of quote]

Would this still give the right broadcast-address and subnetmask to

... [show rest of quote]

clients?


Best regards

Ruben

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Ruben Wisniewski <[hidden email]> wrote:

>> Sounds like a bit of a "sort of broken" setup - and I wonder if it
>> wouldn't work with smaller subnets. The fact that the client is being
>> forced to change address suggests that the network isn't as flat as
>> stated.
> Well the problem is, that we need one big subnet, because the
> routingprotocol is L2. Else all clients have to fit in one lease-range.
> Since we use many gateways, this seem to be the only solution for this.

I think what I was getting at is that you can run multiple subnets over one L2 network. Traditionally you'd need to configure a "shared-network" stanza for DHCP to cope with this - but in your case your L2 routing will do the necessary isolation.

Put another way, if a segment of the network is configured to use gateway A, then could you assign just a smaller subnet to those devices using gateway A. Similarly, another set of clients on a different bit of the network will use a different subnet and gateway B. The DHCP servers only need configuring for the set of clients they will serve.

When a client moves from zone A to sone B, it doesn't keep it's IP address - so moving to a different subnet (while on the same (segmented) L2 network doesn't matter.

>> But one way of "fudging" DHCP might be to lie to it about the subnets.
>>
>> Looking back, the example given was an "active" range of 10.66.11.1
>> to 10.66.20.255. That fits in the 10.66.0.0/19 subnet which covers
>> 10.66.0.0 to 10.66.31.255 Thus the ranges needing to be actively
>> denied are much smaller - and by adjusting the ranges used, can be
>> reduced a lot smaller still (or even eliminated). Eg, 10.66.16.1 to
>> 10.66.23.255 fits within the 10.66.16.0/21 subnet (ie 1/4 the size
>> again) but still offers over 2k leases.
>>
>> Then (IIRC) you just need to specify the subnet mask option to
>> override the default derived from the subnet declaration.
>>
>> A request for an address outside of the server's declared subnet will
>> get a NAK without creating a lease table entry - the server will just
>> treat it as "not valid for this network".
>>
>> As I say, it's something of a fudge, but worth trying.

... [show rest of quote]

> Would this still give the right broadcast-address and subnetmask to
> clients?

I think so as long as you set the option values within the subnet declaration rather than relying on the automatic calculation & assignment. You'll need to test it.



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Ruben Wisniewski]

Am Tue, 21 Apr 2015 14:33:21 +0200
schrieb Peter Rathlev <[hidden email]>:

> On Tue, 2015-04-21 at 13:18 +0200, Ruben Wisniewski wrote:
> > When I delete the "deny all clients" rules, the ram-footage is
> > reduced to 35 MByte:
> >
> > [root@bragi ~]# pmap -x 30521
> > 30521:   /usr/bin/dhcpd -4 -q -pf /run/dhcpd4.pid
> ...
> > kB gesamt          34608   28792   26292
> >
> > So where can I file this bug?
>
> Umm... what bug? :-)
>
> With 1.5 million leases you use 533 Mbytes memory, with just 2558
> leases you use 35 Mbytes memory. That's not a bug.
>
> What you want sounds like some way of actively denying clients with
> specific addresses without creating leases for them. I can't from the
> top of my head think of such a way with ISC DHCP, but I'll give it a
> try.
>

... [show rest of quote]

... [show rest of quote]

I think a pool which got "deny all clients" should be optimised for not
using the whole memory for nothing... since the leases will never been
used.

Else I wonder why an authorative server not answering all requests from
a subnet.

The man-page says this:

>If the server knows nothing about the address, it will remain silent,
>unless the address is incorrect for the network segment to which the
>client has been attached and the server is authoritative for that
>network segment, in which case the server will send a DHCPNAK even
>though it doesn't know about the address.

Network-segment seem to be the pool-definition here, not the subnet.
Wondering if this is correct or a bug.


Best regards

Ruben

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Ruben Wisniewski <[hidden email]> wrote:

> I think a pool which got "deny all clients" should be optimised for not
> using the whole memory for nothing... since the leases will never been
> used.

I guess that's a corner case not considered. TBH, it's the first time it's come up here that I can remember.
There are other things the parser doesn't catch/prevent - but that's down to the rapidly increasing complexity of a parser when you try and cater for more and more special cases (which one might reasonably expect a competent sysadmin to deal with).

What if the admin uses "deny unknown-clients" and there aren't any "known" clients, or all the known clients have fixed IP assignments ? Same situation.


> The man-page says this:
>
>> If the server knows nothing about the address, it will remain silent,
>> unless the address is incorrect for the network segment to which the
>> client has been attached and the server is authoritative for that
>> network segment, in which case the server will send a DHCPNAK even
>> though it doesn't know about the address.
>
> Network-segment seem to be the pool-definition here, not the subnet.

No, it is the subnet.

Consider this snippet :
subnet 192.168.1.0 subnet-mask 255.255.255.0 {
  range 192.168.1.100 192.168.1.200 ;
}

If a client requests (say) 192.168.2.57, then this is outside the subnet and hence "the address is incorrect for the network segment to which the client has been attached".

But if a client comes along and asks for 192.168.1.57 then the server will remain silent. The address is valid for the subnet, but the server "knows nothing about the address". It should **NOT** NACK it because it could be handled by another server on the network - it's not that uncommon to have different DHCP servers handling different DHCP clients.
One example is a customer network where their IP PBX runs a DCHP server which answers only their own IP phones. AFAIK the phones prefer an answer from the PBX (presumably because only those have the right information), and the PBX only responds to the phones - so the phones get to use one p[art of the subnet, while everything else uses another part running a different (Microsoft) DHCP server.

As you've surmised, if you need to NACK requests for addresses in the subnet but not in the allowed range then you need to tell the server to do that.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Ruben Wisniewski]

Hi Simon,


Am Mon, 27 Apr 2015 15:41:29 +0100
schrieb Simon Hobson <[hidden email]>:

> Ruben Wisniewski <[hidden email]> wrote:
>
> >> Sounds like a bit of a "sort of broken" setup - and I wonder if it
> >> wouldn't work with smaller subnets. The fact that the client is
> >> being forced to change address suggests that the network isn't as
> >> flat as stated.
> > Well the problem is, that we need one big subnet, because the
> > routingprotocol is L2. Else all clients have to fit in one
> > lease-range. Since we use many gateways, this seem to be the only
> > solution for this.
>
> I think what I was getting at is that you can run multiple subnets
> over one L2 network. Traditionally you'd need to configure a
> "shared-network" stanza for DHCP to cope with this - but in your case
> your L2 routing will do the necessary isolation.

... [show rest of quote]

This is not possible, since we got no straight Node A in the Network is

... [show rest of quote]

using Gateway A and Serving Gateway A's IP-Addresses, it more like:

Node A, Z, F is using Gateway A
Node C, X, R is using Gateway B

While Node G, H, I has just changed from Gateway A to B, while all
clients still useses Gateways A's IPs.

Isolation is supported by the routing-protocol but is not well tested
nor very performant, because traffic for neighbor-nodes has to be
submitted to the internet-gateways, which are behind a crappy
DSL-Upload...

> Put another way, if a segment of the network is configured to use
> gateway A, then could you assign just a smaller subnet to those
> devices using gateway A. Similarly, another set of clients on a
> different bit of the network will use a different subnet and gateway
> B. The DHCP servers only need configuring for the set of clients they
> will serve.
>
> When a client moves from zone A to sone B, it doesn't keep it's IP
> address - so moving to a different subnet (while on the same
> (segmented) L2 network doesn't matter.

Well this causes much martian traffic or need vlans or isolations ...

and split the network, this is something we don't want.

We still talking about an acl-issue in isc-dhcpd, so for this issue we
don't change our complete network infrastructure.

> > Would this still give the right broadcast-address and subnetmask to
> > clients?
>
> I think so as long as you set the option values within the subnet
> declaration rather than relying on the automatic calculation &
> assignment. You'll need to test it.
We gonna test this solution.


Best regards


Ruben

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Ruben Wisniewski]

Am Mon, 27 Apr 2015 15:59:35 +0100
schrieb Simon Hobson <[hidden email]>:

> As you've surmised, if you need to NACK requests for addresses in the
> subnet but not in the allowed range then you need to tell the server
> to do that.

Yes.

Is there any other way to achieve this?


Best Regards

Ruben

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Ruben Wisniewski <[hidden email]> wrote:

>> As you've surmised, if you need to NACK requests for addresses in the
>> subnet but not in the allowed range then you need to tell the server
>> to do that.

> Is there any other way to achieve this?

No, creating a pool with "deny booting" is the only way to do it.



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Ruben Wisniewski]

Am Tue, 28 Apr 2015 22:18:23 +0100
schrieb Simon Hobson <[hidden email]>:

> Ruben Wisniewski <[hidden email]> wrote:
>
> >> As you've surmised, if you need to NACK requests for addresses in
> >> the subnet but not in the allowed range then you need to tell the
> >> server to do that.
>
> > Is there any other way to achieve this?
>
> No, creating a pool with "deny booting" is the only way to do it.
Will this result in the same ram-usage?


Best regards

Ruben

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Ruben Wisniewski <[hidden email]> wrote:

>>>> As you've surmised, if you need to NACK requests for addresses in
>>>> the subnet but not in the allowed range then you need to tell the
>>>> server to do that.
>>
>>> Is there any other way to achieve this?
>>
>> No, creating a pool with "deny booting" is the only way to do it.
> Will this result in the same ram-usage?

Yes, it's the way you are already doing it.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users