[K12OSN] network design

Sharon Betts sbetts at msad71.net
Sat Feb 5 22:20:29 UTC 2005

"Support list for opensource software in schools." <k12osn at redhat.com> on
Saturday, February 05, 2005 at 1:10 PM +0000 wrote:
Thanks for the input so far -- I will try to elaborate:
>>What specific services do you need to provide? (general computing,
>>profiles, roaming profiles across buildings, email, printing, web, shared
>>folders, library, database access, etc)
I need to provide general computing, roaming profiles within each LAN,
printing, web, etc.
These are all within LANS.  OTher services (SIS etc.) are via web.
>>What kind of connection do you have between sites?
>>Will these all be thin clients, or will this be a mixed mode install
>>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
>>web server, email server, web filter/proxy and central print server in
>>central office (or other suitable location), connected via WAN to the
>>locations.  You then have K12LTSP servers at each location to boot
>>and provide most applications.  You might want a number of application
>>servers for OO.o, Moz, programming, and what ever other high demand apps
>>have at each location, plus a Windows TS for what ever win apps you have
How easy is it to combine the Windows TS?
>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. 
This is something we have considered.But had the fears you wrote about

> 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.
Maybe this is a start to our solution.
>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.
We are nearing this level -- still have one school pretty "old".
>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.
This we knew.
This is great - thanks.  Any other suggestions?

More information about the K12OSN mailing list