request for advice / building dhcpd infraestructure

[Simon Hobson]

Leandro <ingrogger at gmail.com> wrote:

> Hello dhcpd users:
> Im planning to manage a /17 network using isc dhcpd. I would like to briefly describe my plan so I can get any comments/advices  from the list.
> My dhcp server will receive requests from approximately 20 relay agents from 3 different access technology.
> I dont know in advance behind wich relay will be most ip usage since I can not predict witch service will grown over the others.
> In order to be able to be flexible with ip pools management, Im thinking on:
> 
>    Create a class per each agent.circuit-id
>    Subneting the  /17 in /24 subnets
>    Create a pool declaration per each subnet.
>    Add / Delete "allow members of" statements within the pool declaration to bind a relay-agent with one or multiple pool

That's a horribly complicated way of screwing it all up ! I'm fairly certain it won't actually work.

To start with, go back to basics. Ignore DHCP and consider the IP routing.
Your routing must work, that means all networks must have unique and non-overlapping IP ranges/subnets. So each remote network will need it's own unique IP subnets.

Once you have that in place, your DHCP "just works". You define each subnet, you don't need any classes, the server just works out which network each relay agent is connected to (and hence where the client is) by the GI-Addr field the relay agent inserts into the DHCP packets.

To start out with the addressing, you have to guesstimate what the requirement will be for each network - and assign a subnet to suit. I would space them out so as to have the best opportunity to enlarge them later. You say you have 20 relay agents - so I'll assume for now that means 20 networks. A /17 gives you a.b.0.0 to a.b.127.255 (or a.b.128.0 to a.b.255.255), the third octet has 128 values. To get 20 networks out of that, you can afford to give each one a block of 4 in the third octet - ie a /22 - and that'll leave you about 1/3 of your space unused. If you have a feeling that some of them might grow, then you could leave the next block unused to grow into later (eg instead of allocating 0.0, and 4.0, and 8.0, and ..., you might skip 4.0 and leave that for the 0.0 block to grow into later).
If you do run out of space in one network, then you can add another subnet - and define a shared-network in DHCP.

If the extra subnet is larger (eg a /21), you can migrate existing users to the new subnet over time until the original /22 is empty - and then remove that smaller subnet which is then free to use elsewhere.