Holt is a school district in the mid-Michigan area comprised of approximately 5,400 students ranging from pre-school to 12^th grade. We have a wide area network of 10 schools and an administrative office building. Within these scho ols, we have a total of about 900 workstations, some 600 Macintosh machines (LC3's and Centris 610's) 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 DS U/CSU units were controlled by Novell 4.x fileservers using Newport Systems LAN2LAN cards, and routed only IPX traffic. The Novell fileservers provide NetWare services to the Intel machines, and AppleTalk services to the Macintosh machines.

This is how the network was originally designed in 1993. Since then, the networking world has been turned upside down. In addition to the need for greater bandwidth for applications, getting Internet access to the classrooms has become a must. Public s chools have always been faced with tight financial budgets, and implementing major change in a school's network is usually quite costly. Because of these factors, our district was forced to examine alternative ways to upgrade our system. Through the use o f two key technologies: wireless WAN links and Linux, we have been able to provide everything our district wants at a minimum of cost. Both of these technologies, when combined, give us a system that is high in efficiency, and low in cost.

There were two major problems in upgrading our network. The first was that our WAN links were very slow, and very expensive. Using 56k DSU/CSUs, we were able to pass inter-district e-mail, do some management, and maintain our NDS database. At this spee d, copying files was bad, but Internet access 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 each direction 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 upon its point of origin. The bridge learns which network devices are on which network interface, and records the information into it's internal tables. When a packet reaches the bridge, it looks at the destination of the packet. If the packet is destined for the opposite side of the bridge, it forwards it. If the packet is destined for a network device on the same side of the bridge , it is ignored. In this way, the bridge only passes packets that need to be sent, and eliminates unnecessary traffic between segments. The wireless bridge product that we use performs this exact function, between an Ethernet segment and a Wireless "virtu al" network. This makes network configuration very simple and efficient. Consider the following examples.

Originally, we used a routed 56k solution such as you see to the right. 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 automatica lly 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 also not solve the bandwidth pro blem.

With the wireless links, we were able to set up a much more flexible network through the use of bridging. Because the wireless links we used can be set up as either point-to-point or multi-point links, it was possible to create a single virtual bridged radio network comprised of numerous locations. With the exception of a single remote school, we were able to connect every school into a single wireless network. We used a repeater to connect the auxiliary school to the larger network. In all, the physic al wireless network looks something like the picture below.

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 P-90s to P-150s. They have between 32 and 64 megabytes of parity ram, and IDE hard disks from 850mb to 2.1gigs. They each have two D-Link NE2000 compatible ethernet cards. The machines have a mini mal Slackware 3.2 distribution installed on them. The machines are configured as 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, and WAIS data on the server. Most of the other Linux software, such as login shells, FTP services, etc. has been disabled or restricted to a single management machine.

Between IP Masquerading and the Squid Object Cache, we are able to provide most of the services we need. With masquerading, we are able to provide access to our 900 or so clients with only a handful of IP addresses. In addition, we can configure the fi rewall to allow different types of access to different workstations. For example, restricting 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 worl d, thereby conferring a certain amount of security.

Controlling Internet access is a big deal for schools. As a public school district, we have 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. T his allows us to monitor what kinds of documents have been accessed, as well as to let us require a valid username 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 do cuments. Squid allows for the use of htpasswd style authentication, exactly like web server packages such as Apache. Using this, we can manage user access to the cache, and consequently to the World Wide Web. In addition, Squid allows us to configure acce ss 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 to the right. 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 routi ng 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 it's original settings, and configured a second ethernet card for the wireless LAN. Of course, I had to configure this second card with the network n umber 3141, so that I could call it the "Pi in the Sky." J .

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 the Squid Cache, all documents that pass through the proxy are cached, making subsequent requests 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, they simply view 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.

Overall, we have used Linux put together a greatly improved network. We have eliminated our ongoing leased line fees, which by themselves pay for all of the wireless hardware within four years. We have also provided controlled Internet access to all of our workstations with limited resources. We have increased our WAN bandwidth from a painful 56k to a respectable 4mb/s speed. With the help of the Squid Internet Object Cache, we have become responsible Internet citizens, and helped to reduce unne cessary net traffic. Now, we can even call all of our e-mail AirMail. None of this could 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 FUN.