[K12OSN] network design

Sat Feb 5 18:10:22 UTC 2005

Steven Santos wrote:

>>Hello everyone -- can I get a discussion going to help me sort out my
>>plans?
>>    
>>
>
>Always welcome!
>
>  
>
>>I would like some input on my network design.  I have 4 schools and a
>>business office; 3000 users; and over 1000 machines (growing by leaps and
>>bounds as we work toward one-to-one).   Presently I am using Active
>>Directory (Windows -- ugh) for authentication, DHCP etc.  Only have linux
>>servers in the background (proxy, web server, etc.).   I use mostly open
>>source software although there are occassions where MS stuff is necessary.
>>    
>>
>
>  
>
>>We just began using terminal services (linux terminals attaching to
>>Windows server) in a new building.   I want to redesign the rest of the
>>network to terminals. Of course the MS solution is cost prohibitive.
>>What is my best mode of attack?  We presently boot the terminals
>>individually from flash memory.
>>    
>>
>
>Lot of variables, so let me ask a few questions
>
>What specific services do you need to provide? (general computing, roaming
>profiles, roaming profiles across buildings, email, printing, web, shared
>folders, library, database access, etc)
>
>What kind of connection do you have between sites?
>
>Will these all be thin clients, or will this be a mixed mode install (thin,
>thick, windows, mac)
>
>What kind of policies are in place that may effect this?
>
>
>In an ideal world, with big fat pipes that never go down to each location, I
>would say that you would want an LDAP server, a home server, backup server,
>web server, email server, web filter/proxy and central print server in the
>central office (or other suitable location), connected via WAN to the other
>locations.  You then have K12LTSP servers at each location to boot clients,
>and provide most applications.  You might want a number of application
>servers for OO.o, Moz, programming, and what ever other high demand apps you
>have at each location, plus a Windows TS for what ever win apps you have to
>have.
>
>But the details of your situation will dictate what will and what will not
>work.
>
>  
>

I would add this:  at least one slave LDAP server at each physical 
location.  The reason for this is our own experience with the Windows 
Craptive Directory in our district.  We now have collapsed our domain 
structure so that everyone authenticates to our pair of domain 
controllers at one facility.  Therefore, folks are authenticating across 
the WAN, so when the WAN link goes down, nobody can authenticate.  
Cached credentials on the Windows workstations don't fix all the 
problems, either.  This was back in the Windows NT Server 4.0 days as 
well and applies to any centralized authentication scheme.  Sadly, WAN 
links do not respond well to, say, backhoes ripping the line to shreds, 
problems at your provider's end, your router either going Tango Uniform 
or getting misconfigured, etc.  They can and at times do go down, so 
this should, whenever possible, be accounted for.

LDAP authentication, being a centralized authentication scheme, operates 
the same way.  If you have a slave LDAP server at each physical site, 
then people can still log in and, for example, hit the file server, fire 
up certain network apps local to the school, etc.

On the LAN side, you'll want fiber runs between all of your wiring 
closets, and you'll want that fiber backbone to be running nothing less 
than Gigabit Ethernet.  All client drops should be 100Mbps, capable of 
autonegotiating to 100M/FullDuplex.  Pretty much everything made today 
and for at least the last five years is capable of this, so that won't 
be a issue.  There are some new switches coming out whose client drops 
do 10/100/1000, which, while not necessary for client drops, doesn't 
hurt anything to have if the pricing is close enough to 10/100.

I would also suggest switches that are capable of both 802.1q VLANs and 
GVRP.  GVRP is a very, very nice thing to have unless you're using Cisco 
gear, which uses a proprietary version that they call VTP.  We use VLANs 
for quite a few things in our district, and without something like GVRP 
or VTP, setting up all the VLAN info in all of our switches would simply 
be untenable.  Make sure, therefore, that you get *full* GVRP support.

You might consider going with TLS for your WAN links.  Essentially, this 
is Ethernet across the WAN.  We're using TLS in some parts of our 
network, and WAN bandwidth for TLS is about half to a third the price 
of, say, ATM links of the same speed.  You can go as high as Gigabit 
links with TLS.  Furthermore, if you go with TLS, you have a wider 
choice of router gear than just Cisco.  You can use, say, an inexpensive 
OpenBSD or GNU/Linux box with two Ethernet cards for your router 
(doesn't have to be x86, but of course it can be).  Either way, the 
boxes are cheap, and the Ethernet interfaces are cheap.  By contrast, if 
you go with ATM or Frame Relay, you're going to pay through the nose for 
your WAN interface cards.  We run ATM in my district, so I know.  I 
strongly urge you to at least look at TLS.

Speaking of WAN links and capacity, do *NOT* attempt to run LTSP itself 
across your WAN links!  You *will* be sorry.  What I mean here is, 
"don't fire up clients at one site trying to do X11 to a LTSP server at 
another site."  Keep all that inside the school's LAN.  Accessing file, 
print, or Web servers across WAN links?  Fine.  X11 across them?  Nope.

Hope this helps.

--TP
_____________________
Do you GNU!? <http://www.gnu.org>
Be virus- and spam-free with Free/Open Source Software (FOSS). Check it 
out! <http://www.mozilla.org/thunderbird>