Linux at Holt Public Schools

How a public school system in Michigan has used WAN links and Linux proxy servers to upgrade its computer network.

Holt Public Schools is located in the
mid-Michigan area and is comprised of approximately 5,400 students,
ranging from pre-school to 12th grade. We have a wide area network
of 10 schools and an administrative office building. Within these
schools are a total of about 900 workstations: some 600 Macintosh
machines (LC3s and Centris 610s) and around 300 Intel machines. The
network, as installed, was comprised of a number of 10MB/s Ethernet
LAN segments connected by 56K leased lines. The DSU/CSU units were
controlled by Novell 4.x file servers using Newport Systems LAN2LAN
cards and routed only IPX traffic. The Novell file servers provided
NetWare services to the Intel machines and AppleTalk services to
the Macintosh machines.

Since 1993, the computer networking world has been turned
upside down, and we recognized the need to update our system. In
addition to the need for greater bandwidth for applications,
getting Internet access to the classrooms has become a must. Public
schools have always been faced with tight financial budgets and
implementing a major change in a network is usually quite costly.
Because of these factors, our district was forced to examine
alternative ways to upgrade our system. Through the combination of
two key technologies, spread spectrum wireless WAN links and Linux
proxy servers, we were able to provide what our district wanted: a
system that is highly functional and low in cost. In fact, based on
our financial calculations, the entire system (including the Linux
machine hardware) should pay for itself within 5 years, based
solely on the recurring costs of six leased lines.

There were two major problems in upgrading our network. The
first was that our WAN links were slow and very expensive. Using
56K DSU/CSUs, we were able to pass GroupWise e-mail, do some
management and replicate our Novell directory services. At this
speed, copying files was slow, and Internet access for the entire
district was unthinkable. To provide for more bandwidth, we
replaced our 56K lines with a wireless 4MB/s bridge unit from
Pinnacle Communications of Dayton, Ohio. The wireless links can
transmit data at a rate of 2MB/s on each channel simultaneously and
function as an Ethernet bridge.

An Ethernet bridge, in its simplest form, is a device that
will selectively forward or drop a packet based on its destination.
The bridge learns which network devices (based on its unique MAC
address) are on which network interface and records the information
into its internal tables. When a packet reaches the bridge, the
bridge looks at its destination. If the packet is destined for the
opposite side of the bridge, it is forwarded. If the packet is
destined for a network device on the same side of the bridge, it is
ignored. In this way, the bridge passes only packets that need to
be sent and eliminates unnecessary traffic between segments. The
wireless bridge product we use performs this exact function between
an Ethernet segment and a wireless “virtual” network. This makes
network configuration very simple and efficient.

Originally, we used a routed 56K solution such as that shown
in Figure 1. This worked relatively well for our Novell network.
However, it required that all of the traffic be routed. This is
fine for NetWare, which uses protocols such as RIP to automatically
configure routes. However, in order to pass TCP/IP data, it would
be necessary to break our class C range of IP addresses into a
number of smaller subnets. This would result in a net loss of
available IP addresses and add to the bandwidth problem.

With the wireless links, we were able to set up a much more
flexible network. Since the links can be configured as either
point-to-point or multi-point, it was possible to create a single,
virtual-bridged radio network comprised of numerous locations. At
the education center, we have OMNI-directional antennas which are
configured as repeaters. Because the remote locations use
directional links and point directly at the education center, they
cannot communicate directly with one another. To alleviate this
problem, the education-center bridge is configured to forward all
traffic not intended for its own Ethernet LAN segment back out to
the wireless network. Thus, while one elementary school cannot
communicate with another elementary school directly, they can
communicate by making an extra hop through the OMNI. This happens
transparently in the hardware and is unseen by the network devices.
With the exception of a single remote school (Dimondale), we were
able to connect every location into a single wireless network. We
used a repeater at the west campus area to connect this auxiliary
school to the larger network. At this location, there are
essentially two different wireless links plugged into the same hub.
Although the link to Dimondale is actually a totally different
wireless network, it appears, logically, to be part of the larger
wireless network. The complete physical wireless network looks
something like the picture in Figure 2.

With the bridging topology, we were able to maintain our
Novell communications while expanding our TCP/IP functionality. For
our TCP/IP services, we deployed a number of Linux proxy servers.
These Linux servers are Pentium computers, ranging from Pentium 90s
to Pentium 150s. They have between 32 and 64MB of parity RAM and
IDE hard disks from 850MB to 2.1GB. They each have two D-Link
NE2000 compatible Ethernet cards. The machines have a minimal
Slackware 3.2 distribution installed, are configured as IP
Masquerading firewalls and act as Internet gateways for our remote
LAN segments. Also running on the servers is the Squid Internet
Object Cache software, which allows us to cache HTTP, FTP, GOPHER
and WAIS data on the server. Most of the other Linux software, such
as login shells, FTP services, etc. have been disabled or
restricted to a single management machine.

Between IP Masquerading and the Squid Object Cache, we were
able to provide the necessary Internet services. With masquerading,
we gave access to our 900 or so clients with only 7 true IP
addresses. In addition, we can configure the firewall to allow
different types of access to different workstations. For example,
we might wish to configure the firewall in such a way as to
restrict a computer lab while allowing a teacher station access.
Also, because of the nature of the firewall, our clients are more
or less unreachable by the outside world, thereby conferring a
certain amount of security. Using the standard
ipfwadm program, there are a
number of possible configuration options.

Overall, the speed of the wireless links has been quite good.
When the network first went up, we began gathering information
about the speed and reliability of the links. To do this, a script
was set up which runs a program called
tcpspray to transfer 100KB of data
to each location and measure the amount of time it takes to get
there. The script runs constantly on a management station and tests
each of the links every 15 minutes. Below is the actual output of
one of our wireless links—in this case, between the education
center and the senior high school:

Admittedly, that PPP link should be running a little bit faster. I
had expected to see throughput more along the lines of 3K, or
possibly 4KB/s. Lastly, to compare it to another popular networking
option, take a look at the throughput attained by a 10MB/s LanCity
cable modem which I have connected to my personal Internet host:

Bear in mind that these figures don't give you the whole picture.
For example, the speed of the throughput varies from moment to
moment by as much as 50%. All it takes is a split-second delay in
the network to give a very poor reading. The readings I have
provided represent an average throughput. Also, the speed of the
computers sending and receiving the information makes quite a
difference. All the machines used for the above testing are running
Linux, but if they were not, the speed of the TCP/IP stack would
also be a factor. In addition, it's important to note that certain
services have more data overhead than others. Thus, performance
might vary depending upon the service you are using. FTP, for
example, runs at roughly the same speed as a
tcpspray test.

In addition to speed, controlling Internet access is
important. As a public school district, we need to have a certain
amount of accountability as to what our students do and see on the
Internet. To this end, we have made the use of the Squid Cache
mandatory, allowing us to monitor the kinds of documents accessed,
as well as require a valid user name and password to access the
cache. By filtering all traffic for port 80 at the firewall, client
workstations must use the cache to get WWW documents. Squid allows
for the use of htpasswd style authentication,
exactly like web server packages such as Apache. Using this
authentication method, we can manage user access to the cache and
to the World Wide Web. In addition, Squid allows us to configure
access control lists, which will disallow certain “known naughty”
sites that might endanger the innocence of our students.

At each of the individual LAN segments, we have a
configuration similar to the picture in Figure 3. The wireless link
is plugged into a small hub, which is also connected to the NetWare
server and Linux box. The NetWare server is responsible for routing
the IPX/SPX traffic and the Linux box is responsible for the TCP/IP
traffic. All of the client workstations are configured for the
10.0.0.0 network and have their Linux box set as the default
gateway. When a client sends TCP/IP traffic, it goes through the
Linux box, out through the wireless link, to the education center
and eventually out to the Internet.

On the Novell side, configuration is quite simple. We simply
left the original Ethernet card at its original settings and
configured a second Ethernet card for the wireless LAN. Naturally,
I had to configure this second card with the network number 3141,
so I could call it the “Pi in the Sky”. We must all seek humor
where we can.

The proxy servers have been working quite well. Our first
Linux proxy server, which was based on kernel version 2.0.18, has
run for months and never crashed. Even with the ever-demanding (and
ever-popular) PointCast traffic, it has performed wonderfully. With
Squid, all documents that pass through the proxy are cached,
allowing subsequent requests to come from the proxy server at
near-Ethernet speeds. This reduces traffic across our Internet
connection, as well as across the Internet in general. In a school
situation, this works very well. For example, when a teacher wants
to visit a certain web site with the whole computer lab, he simply
views the pages the night before. When the class comes in the next
day, the documents are served very quickly, making it possible for
a whole class to browse the site at Ethernet speed. With the
combination of helpful utilities such as
wget, teachers can recursively
cache a whole site with a simple shell command.

Using Linux has allowed us to put together a greatly improved
network and provide Internet access to all our workstations using
limited resources. We have increased our WAN bandwidth from a
painfully slow 56K to a respectable 4MB/s. With the help of the
Squid Internet Object Cache, we have become responsible Internet
citizens and reduced unnecessary net traffic. Now, we can even call
all of our e-mail airmail. None of this would have been possible
without the effort of the hundreds of people who contribute to
Linux every day. In education, in particular, Linux fits
perfectly—it's cheap, it' s flexible and it's powerful.

Mark Lachniet
is a Network Systems Specialist for
Holt Public Schools. Mark's hobbies include disc golfing,
“nerdin” and home brewing beer. Mark can be contacted at
lachniet@pilot.msu.edu. Mark maintains a small home page which
includes a tutorial on IP Masquerading, a HOWTO-in-progress on
creating a proxy server like the ones described above and other
miscellaneous stuff. His home page is accessible at
http://scnc.holt.k12.mi.us/~lachniet/.

Are you using the Linux program at your school? The reason I am asking is because I am doing a research paper on the Linux program for my Masters program. I am interested in sending a survey for your students to fill out comparing the Linux program to the Microsoft program. If so and I have permission to do this, would you be willing to submit the survey and send the results back to me? I do not need names on the survey for confidentiality purposes.

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.