2. Overview of Our Network We consider the following points before installing and constructing our LAN: Size(How large it should or would be, how many users are going to use it) Cost(How much it would cost us) Maintenance(The easiest way of maintaining it) Extension(Is there enough option to extend our LAN?) We have to consider different points related to the servers too: Server(What kind of server) Server LAN OS(What kind of OS to install for the LAN OS server) Applications(What kind of Applications would be required most) Considering all these options we conclude to construct a star shaped Ethernet in our research laboratory. As it is a small network, it is comfortably easy to manage a single centered HUB with options of attaching other HUBs parallelly in case of future extension. We choose FreeBSD as our LAN server OS (Operating System). FreeBSD is based on 4.4BSD which has built in networking facility and provides one of the most solid and fast TCP/IP stacks available thus making it one of the favorite server OS around the world. Moreover, it supports a variety of network protocols, such as TCP/IP(that's standard though, Transmission Control Protocol/Internet Protocol), IPX/SP(Internetwork Packet Exchange/Sequenced Packet Exchange: used by Novell Netware), NetBEUI(Used by Microsoft Family), AppleTalk(Used by Macintosh), just what we are considering. So, finally the network turns out to be like Fig 1.1. As you may have already noticed that we use a Class C Network Address to construct our Ethernet LAN. It uses 24 bits among 32 bits as Network Address bits and remaining 8 bits as Host Address bits, thus giving us opportunity of connecting 256 hosts, theoretically. The hosts belong to the domain ant.yatsushiro-nct.ac.jp, a personally derived domain name by Prof. Hashimoto. stands for antenna, his field of study. Maple(192.168.0.3) has two Network Interface Cards, one connected to the outside network address(202.251.39.12), the other one to the local network address(192.168.0.3). It works as gateway for our Ethernet LAN. Most of the servers are run by maple. While it is desirable to run them on different hosts, we run them on maple only, partly due to power savings and partly it is convenient for different hosts, both local and remote, to access it. 2.1 Hardware Setting HUB The HUB is one the most important element of our LAN. As it is obvious from our LAN, that it is the central connection point for the whole network, all hosts are required to connect to this central point. Our hub has 8 ports to which client hosts are connected. When an Ethernet packet is transmitted to the hub by any clients it is copied and repeated over all the ports that clients are connected to, thus making all the clients see the packet. Only the client that has the designated address in the packet, really decode it. The access method used by the clients is CSMA/CD, the famous Carrier Sense Multiple Access with Collision Detection. In this method collisions are regarded as normal events and when there is collision due to simultaneous access by different clients the normal activity is quickly restored forcing the clients to wait for a random amount of time. Cables 10BaseT Ethernet requires at least UTP (Unshielded Twisted Pair) cables of Level 3. Here in our LAN we use UTP cables of Level 5. Cables are graded according to the quantity of data they can carry starting from Level 1 as the lowest to Level 5. There is also limitation on the length of cables specification requires that clients should connect to the central hub with an UTP cable not more than 100m in length. Network Cards NE2000 compatible cards are used. As this type of cards are supported from the very beginning of FreeBSD, our LAN OS server, it was very comfortable to use. Another type of card is used as the NIC of momo(192.168.0.12), Ethernet PCCT corega. However, for this special kind of card a special driver is required and it is done by installing PAO. 2.2 Software Setting We consider the following things before trying over with different kind of servers: Local users have to contact remote users using our server, thus requiring a mail server Local users might require to post their own homepages required to their research thesis, thus requiring a WWW server. Local users need to have accesses outside for their research purposes, thus requiring the ftp server (also needed for installing systems over the network), proxy server, etc. Since we are building a network of our own we need to have an authoritative name server for better performance. NFS server is also tested considering a need of sharing all the disk space available, it's a nice experience. 2.2.1 Mail Server Our mail server is designed to use our school mail server for remote delivery while local mails are directly delivered. For delivering purpose we use Sendmail. Since we are not permitted to receive our remote mails directly for our clients we have to use fetchmail to fetch the necessary mails in our local server. We also have to consider running a pop server so that our clients can pop their mails to their own places. So, the complete mail server turns out to be like figure 2.1. Local hosts can send mails between themselves. However, while sending mails to remote hosts they cannot send it directly. They send it to sendmail on maple and sendmail on maple does the rest of the work. It changes the from header and forwards it to the outer mail server. It is a rather complicated way of sending mails but we cannot overcome it due to the position of our network. Since our local hosts cannot receive mails, maple fetches their mails from a remote mailbox and runs a qpopper enabling them (local hosts) to pop them up. We will see, later in this chapter, that natd makes all this complex way of sending mail obsolete. Please refer to the Appendix 1, Appendix 2 and Appendix 3 for detail setting. 2.2.2 WWW Server In the process of building our server it becomes quite necessary to set up our own WWW server. The WWW server not only gives us opportunity to publish our research interest publicly but also to the school. It is a nice way of communicating in different interest. Apache-1.2.6's httpd server version is used for this purpose. It is working as illustrated in Fig. 2.2. It listens on port 80, the default port for http requests. Please refer to Appendix 4 for detail setting. 2.2.3 Ftp Server While ftp server is installed by default we change it to wu-ftpd-2.4.2b18 since it gives better controls over the ftp accesses made by users. It is equipped with anonymous access thus enabling us to run an anonymous ftp server. The user ftp's home directory is also used for installing purpose untarring (we mean tar) all the installation files there serving as a FreeBSD ftp server. While it takes from 30 to 45 minutes to install FreeBSD from a remote server depending on the network traffic, it requires less than 15 minutes to install from a local ftp server. Please refer to Appendix 5 for detail setting. 2.2.4 DNS DNS(Domain Name System) is a distributed database which provides necessary information to map between hostnames and IP addresses on the internet or your small network. Theoretically every host needs to be in the DNS database but in practical you won't find every host there. In fact, if you are running a small server like us you won't necessarily require a Name Server. Most probably you will get away with /etc/hosts file and by pointing your resolver to an upstream Domain Name Server editing /etc/resolv.conf. But we insist on using a name server no matter how small your network can be. In the long run it will give you better benefit. Here we are using our name server for the following purposes: Hierarchical Namespace(maple owns our namespace) Host table(required for accessing outside) Sendmail(MX utility for better routing of e-mail) Library routines(gethostbyname(3), gethostbyaddr(3) should use it) Let's try to find out how our name server works. We will illustrate how maple finds out funny.com. We assume that there is no cached stuff anywhere in our upstream name servers and maple, our name server, doesn't know anything about funny.com beforehand. It works in the following way: maple, our name server, forwards a request for any cached data to an upstream name server gaia.as.yatsushiro-nct.ac.jp (202.251.33.1). Since we assumed that there's no cached data stored anywhere, it fails to get a cached reply. Queries a known server for domain com. Since com is managed by non-recursive servers, they direct to other name servers rather than producing an address. It directs to funny.com. Funny.com seems like a recursive server thus producing an address. Finally that produced answer is returned back to maple. Please refer to Appendix 6 for detail setting. 2.2.5 Proxy Server As you can see we are running a local network using a single IP address so it is necessary to give our clients access for a lot of reason, say ftp, WWW access, telnet - just to name a few. But it is not possible directly from the client hosts to access outside networks, thus appearing the necessity of setting a proxy server on 'maple', which will serve our clients with necessary services. There is a lot of Proxy server available but we decided to use Delegate for the following features available on the tool: Ftp Proxy Telnet Proxy Http Proxy(forwarding) Pop Proxy etc. It is available at http://wall.etl.go.jp/delegate/ or from the ftp site. Delegate is capable of using caches, forwarding requests, translating protocols between clients and servers, aliasing and filtering, thus giving us a perfect solution for the local clients. Here is an illustration of how our delegate is working on maple in Fig. 2.5. The figure will surely prompt you with a question "Don't the proxy servers slow things down?". Though the answer is "yes", they make life much easier, especially for local networks like one we are describing. For example, local hosts on our network without having global addresses can access vast resources of WWW pages through the proxy server on maple. Please refer to Appendix 7 for detail setting. 2.2.6 Natd Nat stands for Network Address Translation. Referring to the RFC 1613 you can find out that it is proposed as a short term solution for IP address depletion problem while a long term solution is in progress. Let's see how our natd is working on maple: A packet originating from 192.168.0.16 destined to 202.251.34.161 will pass through maple. As it passes through natd on maple natd substitues the packet header with it's own global address and makes necessary checksums on the packet. The packet is then sent to the outside host 202.251.34.161 as if it is originated from maple (202.251.39.12). When a reply arrives at natd on maple from 202.251.34.161 the local address is substituted thus sending the reply packet to 192.168.0.12. In this way a conversation is possible from the local hosts to the remote hosts with respect to our local network. We would like to give another reason of using natd over proxy servers like Delegated. Proxy servers are not practical in places with a lot of users since every connection made to the proxy makes a process on the server and eventually there is a high probability of the server getting overloaded. In case of cache proxy server it becomes more painful, because each and every process must perform a disk I/O causing a bottleneck server. A place like our network will work quite nicely with the proxy servers but natd will give better services. Please refer to Appendix 8 for detail setting. 2.2.7 NFS NFS is a client-server application. Server exports file systems to other machines (clients) and other machines can import these file systems and users on those (other) machines can access these file systems as any other local file system. At least that is the way it works on FreeBSD. Using such kind of sharing filye system even diskless hosts can do pretty nice works over the network. Please refer to Appendix 9 for detail setting.

this page is maintained by:
jchakma@yahoo.com