Technical:Subnetting

From K12LTSP Wiki

Supporting multiple subnets on one server

Originally from the K12LTSP mailing list (2007-1-11): Some clean-up and a few additions for the Wiki also added:

This is how I used to do x86, PPC, and UltraSPARC clients off of one server. It's certainly doable, but there are several things that you get to modify:

/etc/dhcpd.conf

/etc/hosts

Some stuff under /opt/ltsp/

For /etc/dhcpd.conf, just copy 'n' paste your existing 192.168.0.0/24 scope, thus creating two scopes. Wherever you see 192.168.0, replace it with 192.168.1. dhcpd is smart enough to know to hand out 192.168.1.0/24 addresses only on the interface in that subnet (I'm assuming you'll use 192.168.1.254 for your server's new NIC). Also, make sure that you have a "next-server" setting in each of your DHCP scopes that points to the appropriate NIC (192.168.0.254 for the original scope, and 192.168.1.254 for the second, new scope). That's how your clients will know where to TFTP-boot from.

For /etc/hosts, you get to essentially replicate everything in there, in a way that you avoid name/address resolution conflicts. You know all those entries that look like this?

 192.168.0.9     ws009.ltsp      ws009

Well, you'll need to make 254 more entries to account for the clients on the new (192.168.1.x) NIC. But you can't have two "ws009.ltsp" entries pointing to different addresses! What to do?

My solution was to tweak the names so that my /etc/hosts has entries like this:

 192.168.0.009     ws0009.ltsp      ws0009
 192.168.1.009     ws1009.ltsp      ws1009
 192.168.2.009     ws2009.ltsp      ws2009

In my case, I simply added a digit to the hostname, specifically, the third octet of the IP address. A simple little script will generate this for you:

 rm mynewetchosts.txt
 for octet3 in `seq 0 2`
 do
   for octet4 in `seq -w 1 254`
   do
     echo '192.168.'$octet3.$octet4'   ws'$octet3$octet4'.ltsp   ws'$octet3$octet4 >> mynewetchosts.txt
   done
 done

Then, after backing up your original /etc/hosts (/etc/hosts.bak, perhaps?), just copy this mynewetchosts.txt over to /etc/hosts.

Finally, we deal with /opt/ltsp/. In my case, since my clients are different CPU architectures, I needed /opt/ltsp/i386 (comes with K12LTSP), /opt/ltsp/ppc, and /opt/ltsp/sparc. Each of these subdirectories served a different subnet. Well, if all of your clients are x86, then you get to have more than one "i386" directory tree. Why? Yes, the binaries are the same, but you need to tell your clients which IP address to talk to, and you do that in /opt/ltsp/<dirname>/lts.conf. Just copy your entire /opt/ltsp/i386 directory over to, say, /opt/ltsp/i386-1. Head on into this new /opt/ltsp/i386-1, and tweak lts.conf such that wherever you see "192.168.0", you replace it with "192.168.1". There should be only a couple of spots, and, IIRC, the critical one is the "SERVER" variable.

Note that, in your second DHCP scope in /etc/dhcpd.conf, you will need to tweak "option root-path" to point to /opt/ltsp/i386-1. In my /etc/dhcpd, I've got three scopes, one pointing to /opt/ltsp/i386, one pointing to /opt/ltsp/ppc, and one pointing to /opt/ltsp/sparc. The reason you have to do that is because this is the directory that your LTSP clients use to do the pivot-root. In your case, each of your /opt/ltsp/i386 and /opt/ltsp/i386-1 will be pointing to a different IP address (NIC) on your LTSP server.

A note about "option root-path" that a lot of people miss: there is a global one in /etc/dhcpd.conf, before the "shared-network" declarations (these are your DHCP scopes). Do not simply change that one to read /opt/ltsp/i386-1 and think that things will work! You *must* put a separate "option root-path" under *each* "shared-network" stanza. Obviously, since we are declaring more than one DHCP scope, this also therefore applies to the other following options:

option subnet-mask option broadcast-address

If you want to stick thick clients on these LTSP segments, of course you will also need to add "option routers" to each specific DHCP scope on which you want to be able to do this. Don't forget to turn on IP Forwarding and NAT as well. If you're not putting thick clients on these LTSP client segments, then you don't have to worry about this.

Once you're done, you should be able to turn up your second NIC, bounce dhcpd, and have clients netbooting on your other subnet.

Someone pointed out, after this was originally written, that this method is also an effective way to deal with bandwidth bottlenecks at the server NIC. I hadn't, at the time, considered that application--it was more of a side effect of what I originally needed to do (different thin-client CPU architectures to the same server)--but it certainly does help out with the bandwidth problem. The other way to do that is link aggregation, which works very well, but it takes a bit more networking knowledge to pull that off, as well as a switch capable of supporting it.