shared-network with single subnet vs multiple subnets

Glenn Satchell glenn.satchell at uniq.com.au
Wed Feb 3 04:17:49 UTC 2010


A single subnet with a shared-network around it works just like a single 
subnet, so there should be no harm in doing what you proposed. If you 
had hundreds of shared-networks then there might be some noticeable 
increase in memory or cpu usage, but that's likely to be insignificant 
in your case.

The idea of using a central dhcp server as one of the failover peers is 
a good one. I have done something similar in the past and it worked ok. 
Make sure that you have relay agents set up to forward requests to the 
central server. You will see some increase in your WAN traffic due to 
the relaying of requests to the central server.

-- 
regards,
-glenn
--
Glenn Satchell                            |  Miss 9: What do you
Uniq Advances Pty Ltd, Sydney Australia   |  do at work Dad?
mailto:glenn.satchell at uniq.com.au         |  Miss 6: He just
http://www.uniq.com.au tel:0409-458-580   |  types random stuff.

Andrew M Stemen wrote:
> I'm working on a project that entails the migration from a mixture of
> Windows, Cisco, and Linksys devices offering DHCP in many buildings to a
> bunch of servers running ISC DHCPD. We're going to have many (tens)
> servers at remote sites, serving few (hundreds) clients at each site,
> most of which will have a failover peer of a single (larger) server in a
> central facility. For example, branches A, B, and C will have dhcp
> servers, and office Z will have one dhcp server having the appropriate
> configuration and failover peer statements for each of those branches.
> While this is definitely overkill for most needs, we plan to do this in
> case of WAN failure or local dhcp server failure.
> 
> In order to make the management of these servers much faster and
> automated than having to manually alter config files when small details
> change (such as fixed host addresses), I am creating a small database /
> IPAM solution, from which config files will be generated and pushed out
> to the servers.
> 
> After studying the man pages (and searching the internet, and reading
> nearly all of the dhcp-users archive), I'm still left wondering about
> shared-network and subnets. I understand that shared-network contains
> subnet declarations and pools that are to be issued to clients where any
> address in that shared-network will be issued to any client on that
> network segment (wire/VLAN). Is there any reason why a shared-network
> cannot contain only one subnet and associated pool(s)? Is there any
> technical disadvantage to doing so?  While I understand that
> shared-network is designed for use by multiple subnets, I'm hoping that
> I can impose the restriction within this home-brew IPAM solution that
> all subnets and pools must be within a shared-network, simply for
> uniformity and ease of design. 
> 
> Example 1 is my configuration without shared-network statements, Example
> 2 is my configuration with shared-network statements. The examples
> aren't yet ready to be put into production (no failover peers, etc), but
> they're complete enough for these purposes. Is there any reason that
> these wouldn't work, in theory?
> 
> ########## EXAMPLE 1 ##########
> authoritative;
> server-identifier       10.0.16.5;
> ddns-update-style none;
> option option-242 code 242 = string;
> option time-offset     -18000; # Eastern Time
> option ntp-servers 10.0.1.1;
> 
> # SODB SCOPE DATA
> subnet 10.0.16.0      netmask 255.255.255.0
> {
> 	option routers 10.0.16.1;
> 	option option-242 "L2QVLAN=216";
> 	option subnet-mask     255.255.255.0;
> 	option domain-name-servers     10.0.1.10;
> 	option domain-name     "data.mydomain.tld";
> 	default-lease-time 14400;
> 	max-lease-time 28800;
> 	pool {
> 		range   10.0.16.100 10.0.16.254;
> 		#failover statement, etc
> 	}
> }
> 
> # SODB SCOPE VOICE
> subnet 10.2.16.0      netmask 255.255.255.0
> {
> 	option routers 10.2.16.1;
> 	option option-242 "blahblahblah";
> 	option subnet-mask     255.255.255.0;
> 	option domain-name-servers     10.0.1.10;
> 	option domain-name     "voice.mydomain.tld";
> 	default-lease-time 86400;
> 	max-lease-time 172800;
> 	pool {
> 		range   10.2.16.100 10.2.16.254;
> 		#failover statement, etc
> 	}
> }
> ########## END EXAMPLE 1 ##########
> ########## EXAMPLE 2 ##########
> 
> authoritative;
> server-identifier       10.0.16.5;
> ddns-update-style none;
> option option-242 code 242 = string;
> option time-offset     -18000; # Eastern Time
> option ntp-servers 10.0.1.1;
> 
> shared-network sodbdata {
> 	
> 	default-lease-time 14400;
> 	max-lease-time 28800;
> 
> 	subnet 10.0.16.0      netmask 255.255.255.0
> 	{
> 		option routers 10.0.16.1;
> 		option option-242 "L2QVLAN=216";
> 		option subnet-mask     255.255.255.0;
> 		option domain-name-servers     10.0.1.10;
> 		option domain-name     "data.mydomain.tld";
> 	}
> 	
> 	pool {
> 		range   10.0.16.100 10.0.16.254;
> 		#failover statement, etc
> 	}
> 	
> }
> 
> shared-network sodbvoice {
> 	
> 	default-lease-time 86400;
> 	max-lease-time 172800;
> 	
> 	subnet 10.2.16.0      netmask 255.255.255.0
> 	{
> 		option routers 10.2.16.1;
> 		option option-242 "blahblahblah";
> 		option subnet-mask     255.255.255.0;
> 		option domain-name-servers     10.0.1.10;
> 		option domain-name     "voice.mydomain.tld";
> 	}
> 	
> 	pool {
> 		range   10.2.16.100 10.2.16.254;
> 		#failover statement, etc
> 	}
> 	
> }
> 
> ########## END EXAMPLE 2 ##########
> 
> I found the following statement in a changelog (Changes since 4.1.0a1):
> 
> "When configuring a "subnet {}" or "subnet6 {}" without an explicit
> shared-network enclosing it, the DHCP software would synthesize a
> shared-network to contain the subnet. However, all configuration
> parameters within the subnet more intuitively belong "to any client on
> that interface", or rather the synthesized shared-network. So, when a
> shared-network is synthesized, it is used to contain the configuration
> present inside the subnet {} clause. This means that the configuration
> will be valid for all clients on that network, not just those addressed
> out of the stated subnet. If you intended the opposite, the workaround
> is to explicitly configure an empty shared-network."
> 
> This statement leads me to believe that what I intend to do will work
> properly, since it is advising users to explicitly configure a shared
> network with a single subnet. Or am I misinterpreting that?
> 
> Thanks, and apologies for my verbosity. 
> 
> ---
> Andrew Michael Stemen
> andrew at andrewmstemen.net
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users



More information about the dhcp-users mailing list