[K12OSN] LTSP Lab Slow to Boot
Terrell Prude' Jr.
microman at cmosnetworks.com
Sun Sep 14 06:16:37 UTC 2008
See inline. :-)
Todd O'Bryan wrote:
> To help answer this, I'll need a little more info. If I
> understand you
> correctly, the "192.168..." NICs on both of your LTSP servers (you
> specify this, so I'm by necessity making an assumption here) are
> your "eth0"
> interfaces for talking to your thin clients.
> You're correct. They're not actually eth0 (we were having driver
> issues with the onboard eth0 NIC, so they're eth2, I think), but
> they're the interface that talks to all the thin clients.
Interesting...what kind of onboard NICs are these? And what kind of
server motherboard nowadays includes non-Linux-friendly NIC's? I'd like
to know, so I can avoid them like the plague.
> Furthermore, both of these eth0 interfaces are now on the 8-port
> Gig-E switch.
> Additionally, you have this newly acquired, SCSI-disk-equipped
> file server
> that is on this same Gig-E switch, and all of this constitutes a
> broadcast domain which houses only the 192.168.x.x subnet.
> BTW, which specific 192.168.x.x subnet are you using--is it
> 192.168.251.0 <http://192.168.251.0>,
> 192.168.33.160 <http://192.168.33.160>, 192.168.2.128
> <http://192.168.2.128>, etc? I don't see that specified. And what is
> the subnet mask?
> I'm in room 202, so my local network is
> 192.168.202.1 <http://192.168.202.1> = server1 (application server)
> 192.168.202.2 <http://192.168.202.2> = server2 (application server)
> 192.168.202.3 <http://192.168.202.3> = server3 (file server with /home
> which is NFS mounted to server1 and server2)
> 192.168.202.101 <http://192.168.202.101> - 130 = the thirty thin
> clients (assigned by MAC address so I know the IP of each client)
> I'm not sure what the subnet mask is set to (and I actually don't know
> what it's used for, so guidance would be appreciated if there a
> particular setting that would be useful). I think it's 255.255.255.0
> <http://255.255.255.0>, but I'd have to check to be sure.
> server1 and server2 also have separate NICs that plug into the school
> network, get an IP using DHCP and are what we use to access the wider
So, all this means that you have both LTSP servers with their
thin-client-facing interfaces (eth2, in this case) on the same broadcast
domain. I guess that's why you're doing DHCP reservations (assigning by
MAC address), so you can manually load-balance the clients across the
two LTSP servers. If that's what you're doing, then it's
higher-maintenance than another method involving VLANs, but it certainly
I take it that you don't want "server3", the file server, accessible
from the main school LAN. If so, then you did it right.
Most people use 255.255.255.0 (or "/24" in CIDR notation). In your
case, since you don't need to handle gobs of nodes on this subnet,
that's certainly sufficient. For the anally retentive, yes, a smaller
one (a /25, or 255.255.255.128) would also work here, but unless you
know why you need to do that, you *don't* need to do that.
> Finally, you have this 8-port Gig-E switch uplinked to a Gig-E
> port on the two
> switches in the lab (another, separate room).
> Is all of this correct, or am I misunderstanding something here.
> Correct. Actually, servers 1, 2, and 3 are in a storage closet in my
> room so they can be behind a locked door and the thin clients are in
> the room proper. The 8-port gig switch is in the closet with the
> servers and the 2 24-port switches with 2 gig ports each are in the room.
I don't predict that you should have any problems related to network
design. Since all the servers's Gig-E ports are on the same Gig-E
switch, the backplane will make traffic between them quite fast,
assuming that your 8-port switch has a decent backplane (all quality
ones do). Fifteen thin clients will be coming into the 8-port switch
via one Gig-E interface (the downlink to one 24-port classroom switch),
and the other fifteen will be coming in via another Gig-E interface.
The backplane of the 8-port "core" switch will most certainly be big
enough to bridge such traffic to the correct switch port (the ones for
server1 and server2, that is).
So, it sounds like you have a good setup here.
More information about the K12OSN