I mostly agree with what Bob says about the plan making things way more complicated than it
needs to be.
I manage several DHCP servers. I've got over 48k public IP addresses and about 10 times as many
private addresses configured in my subnets. I too have multiple access methods coming into my
networks.
First, I don't understand how you could have a need for a /17 without knowing how many people
you have connected to each location or technology. You should be able to find that out. Not all
locations will be spread evenly around your relay agents.
I've got easily 100 to 200 different vlans defined and I don't care which of the dozens of relay
agents might be handling each vlan. What I do care about is that the relay agent refers the dhcp
requests to the server I've defined the vlan on. I often will use a private subnet as the
primary subnet for a vlan as it won't change very often and allows me to anchor the shared
network on it without worrying about the primary changing on me.
The public subnets are sized based upon what is needed in each location. I will add or remove or
change network sizes as customers come and go on that vlan. Some locations I might need a /22
plus a /24 or /23 or other subnets to handle the needs, where others are more rural locations
where a /26 or /27 or some combination is sufficient. It's a balancing act to have enough IPs
allocated to a vlan without wasting them with huge unused pools.
But Bob was absolutely right that you need to start with the routing and work back to the dhcp
from there. First thing I would do is have the IP folks setup a vlan from a nearby router to the
access equipment and from there you can define the shared network on a dhcp server and configure
the IP Helper to point at that dhcp server (or servers if you go for a shared master
configuration). Once that's done, lather, rinse and repeat with each other access technology and
it's next in line router.
BTW, setup rules on the pools so that the private network and public network get used for
different purposes. For example, a cable modem will use both a private address for the cable
modem as well as a public address for the user's data. Each of these will originate from a
different MAC address with different option 60 or option 82 settings. Simply setup rules to
allow or deny the right pools.
Dave
On 6/23/15 11:26, Simon Hobson wrote:
> Leandro <
[hidden email]> 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.
>
>
>
> _______________________________________________
> dhcp-users mailing list
>
[hidden email]
>
https://lists.isc.org/mailman/listinfo/dhcp-users>
--
Dave Calafrancesco
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Locked
