Recently I stumbled across two details of DHCP which in theory are no-brainers but in pracitce can take a moment to figure. Which is why I pinned them down here for future revisiting.

Rolling out multiple routes using DHCP

Sometimes it's desirable to push not only a default route to clients but all kinds of routes. You may want to publish not only a default route into the internet but also the route to the IT department's local pornhub mirror1 which is hosted on a different subnet than the accounting web application. Alternate ways to solve that problem would be to have the default gateway make that decision for you. However, there's no sane reason to do so2 and have the default router deal with all that traffic if local clients could have all knowledge necessary. And this is why the DHCP standard allows for the rollout of classless routes. As there's no predefined way to specify those in your dhcpd.conf (for ISC DHCPD), you have to define the option before you can use it.
What you do is essentially defining the header option identifier and then tell the ISC dhcpd that this identifier announces an array of unsigned byte values.

option classless-route     code 121 = array of unsigned integer 8;
option classless-route-win code 249 = array of unsigned integer 8;
To use this configuration, we can take a look at an example subnet definition:
subnet 172.16.9.0 netmask 255.255.255.0 {
	range 172.16.9.11 172.16.9.55;
	option classless-route     32,    192, 168, 5, 3,    172, 16, 9, 4;
	option classless-route-win 32,    192, 168, 5, 3,    172, 16, 9, 4;

	option classless-route     16,    10, 9,    172, 16, 9, 3;
	option classless-route-win 16,    10, 9,    172, 16, 9, 3;

	option classless-route     0, 172, 16, 9, 1;
	option classless-route-win 0, 172, 16, 9, 1;
}
The first line within the subnet definition is not really related to this article; it essentially lets the DHCPD know that it can hand out some leases. Whatevs. The following lines however demonstrate how this configuration barely scratches some millimeters above the level of specifying voltages on the fucking cable. Thus it's not really a surprise to learn that the format is as follows:
option classless-route <prefixlen in bits>, [<prefix byte msb> , ... , <prefix byte lsb>,] <router ip byte msb>, ... , <route ip lsb>;
After specification of the prefix len for the subnet we want to learn the router for, we add the prefix byte by byte (or not, in case of a default route, see example above). This is followed by the router, also specified byte-wise. Also as you see in my example above, whitespace can really help you keeping things organized and readable.

Roaming

So you divided your network in several subnets. In this case "roaming" referrs to a DHCP server's ability to serve leases which allow a client node to move from one subnet to another. Depending on the seperation technique, this can have different implications. There are essentially two ways of this seperation, each of them featuring a slightly different set of isolation powers:


Pure Layer-3-Seperation
All clients are sharing one LAN and this is the very same your DHCPD is attached to. It then can "see" all clients and so can they. They all share one giant broadcast domain. This has its advantages -- e.g., one gateway can serve all those clients at once, one client can be in multiple subnets by having multiple IPs bound to its one interface and also simplicity. In a network in which each and every client is considered trusted and in which subnets' sole purpose is organizational seperation but not security, a pure layer-3-seperation might be considered; especially since it can be realized without any specialized network equipment in terms of switches capable of VLAN technology. In fact, switches used in this scenario can be dumb as fuck. In terms of roaming, there's nothing to do. One client will always be assigned "its" IP and will always be given the according routes. In case each of the subnets has its own default gateway (load balancing), this will not affect a travelling salesclient. It will stick to its home default route. Which can be a trade off to live with or not, always depending on how many travelling salesclients your network has. A configuration for an ISC DHCPD might look as follows:
option server-identifier 192.168.4.3;
option domain-name-servers 192.168.4.1

shared-network foo {
 subnet 192.168.4.0 netmask 255.255.255.0 {
   option classless-route     16,    10, 0,    192, 168, 4, 2;
   option classless-route-win 16,    10, 0,    192, 168, 4, 2;

   option classless-route     0, 192, 168, 4, 1;
   option classless-route-win 0, 192, 168, 4, 1;
 }
 subnet 10.0.0.0 netmask 255.0.0.0 {
   option classless-route     24,    192, 168, 4,    10, 0, 0, 2;
   option classless-route-win 24,    192, 168, 4,    10, 0, 0, 2;

   option classless-route     0, 10, 0, 0, 1;
   option classless-route-win 0, 10, 0, 0, 1; 
 }
}

host alpha { hardware ethernet 00:11:22:33:44:55:66; fixed-address 192.168.4.3; }
host bravo { hardware ethernet 01:11:22:33:44:55:66; fixed-address 192.168.4.2; }
host charl { hardware ethernet 02:11:22:33:44:55:66; fixed-address 192.168.4.9; }
host delta { hardware ethernet 03:11:22:33:44:55:66; fixed-address 10.0.1.7; }
host echo_ { hardware ethernet 04:11:22:33:44:55:66; fixed-address 10.0.1.4; }
host foxtr { hardware ethernet 05:11:22:33:44:55:66; fixed-address 10.0.1.27; }
Note that the network definitions do not allow for any freely available ranges of leases to be handed out. Instead, each client is provided its very own host entry, pinning it down to one specific IP that will be given each host depending on its hardware address.

Layer 2+Layer 3 Seperation
In case a VLAN-seperation of subnets is desirable, things get a bit more complicated as this also splits broadcast domains -- and thus will not relay DHCP requests from one VLAN to another. On the plus side, this technique features a seperation in which the client by itself cannot access other networks without help -- since clients cannot change the subnet their respective switch port is assigned to. To overcome the implications of a split broadcast domain, the switch (or a computer connected to the seperated VLAN and the VLAN with the DHCPD in it) needs to become a dhcp-helper. Which is just a fuckin-fancy word for "proxy". So what happens is that the dhcp-helper listens for any DHCP-broadcasts and then forwards them as directed packages to the (known) DHCP server. Which then -- in return -- hands the lease back to the client which broadcasted for a lease in the first place. It's important to understand that the dhcphelper in this case acts like a real proxy, that is, to the client the dhcphelper is the DHCP server which just handed it a lease. As for roaming -- in this setup, client nodes need to be assigned different and new addresses whenever they switch VLAN; otherwise they'd not be able to communicate to their gateway. This needs the DHCPD to know when to hand out which lease, but that's something ISC DHCPD is ready for. As soon as it's poked with a relayed request, it will see from which subnet it came and pull up the according address (if available). Thus a configuration snipplet could look like this (note the missing shared-networkdefinition):
option server-identifier 192.168.4.3;
option domain-name-servers 192.168.4.1
subnet 192.168.4.0 netmask 255.255.255.0 {
  option classless-route     16,    10, 0,    192, 168, 4, 2;
  option classless-route-win 16,    10, 0,    192, 168, 4, 2;

  option classless-route     0, 192, 168, 4, 1;
  option classless-route-win 0, 192, 168, 4, 1;
}
subnet 10.0.0.0 netmask 255.0.0.0 {
  option classless-route     24,    192, 168, 4,    10, 0, 0, 2;
  option classless-route-win 24,    192, 168, 4,    10, 0, 0, 2;

  option classless-route     0, 10, 0, 0, 1;
  option classless-route-win 0, 10, 0, 0, 1; 
}


host alpha { hardware ethernet 00:11:22:33:44:55:66; fixed-address 192.168.4.3; 10.0.1.9}
host bravo { hardware ethernet 01:11:22:33:44:55:66; fixed-address 192.168.4.2; }
host charl { hardware ethernet 02:11:22:33:44:55:66; fixed-address 192.168.4.9; }
host delta { hardware ethernet 03:11:22:33:44:55:66; fixed-address 10.0.1.7; }
host echo_ { hardware ethernet 04:11:22:33:44:55:66; fixed-address 10.0.1.4; 192.168.4.10}
host foxtr { hardware ethernet 05:11:22:33:44:55:66; fixed-address 10.0.1.27; }
This configuration would allow hosts alpha and echo_ to roam between both VLANS, the other clients would not be served a lease and the DHCPD would log this as "no leases left" into its respective logging target.


1 I am more than thrilled to see what the usage of the term "pornhub" will do to my site's reputation. Oh, and I apologize to all those dudes who got here by accident after googling for "build your local pornhub mirror". Sorry for wasting your ... excitement.
2 Not counting the wish to see all traffic and be able to filter, prioritize or manipulate it.

Stichworte:


Impressum