The N.E.L. Intranet

  Introduction  | The First Connection |
The Intranet Comes Alive  | Hooking up to THE Internet  |
The Final, Completed Product


INTRODUCTION

    It's very simple.  In order to carry out some of my reasearch this summer, I have had to build a "miniature Internet" -- that's what I call this endeavour to people who aren't familiar with the term "Intranet," anyway.  As I anticipate this Intranet of mine growing over time, and as its construction has taught me so much, I decided to document its evolution over the summer.  Again, the main emphasis of my research is supposed to be on protocols, but I can't pretend to NOT be interested in the practicality of learning how to set up a wide area network.
    The page is geared toward the Computer Science type person who knows plenty about networks on a theoretical level, but is interested in, say, the actual command that one enters into a Cisco Router to do all of this stuff.  I know that was my battle cry before this summer!  Now that I possess some of this knowledge, I'd like to "share the wealth."



THE FIRST CONNECTION

    When I first walked into the lab, I wanted to assure myself that I could even hook up one computer, much less a whole Intranet.  But plugging into an empty hub as the only solitary connection on an empty Ethernet segment doesn't give you much confidence -- there's no one to ping but yourself!  So, with the help of the guy showing me the lab, I pretended I was a faculty member at UT...

    In the far corner of the room (off in the shadows), there is an Ethernet port which provides access to "UTNet" -- the University's Intranet.  This is the same situation that a new professor faces when he/she enters their new office.  So, what do you need to know to plug your computer into one of these jacks?  Will your computer configure itself "magically?"

    Well, if this connection supported DHCP (Dynamic Host Configuration Protocol), that wouldn't be far from the truth.  It turns out, however, that my lab tour guide had to provide me with the essential info, since there was no DHCP server on that link.  I needed:


Figure 1

    All of this plugs right into the TCP/IP setup area in Windows 95, the OS of choice for this first test.  In fact, it worked so well after a quick reboot and plug into the wall, that I decided to tackle my next task.

    For those of you of the Linux frame of mind, I also discovered the essential commands to set up a Linux box on an Ethernet segment.
    Assuming that you have a network card (aka a NIC) that has been recognized by the Linux kernel, you have two main commands you have to use.  First, you use the ifconfig command (as the root user, of course):

% ifconfig eth0 xxx.xxx.xxx.xxx netmask yyy.yyy.yyy.yyy broadcast zzz.zzz.zzz.zzz
where xxx is your IP address, yyy is your subnet mask,  and zzz is your broadcast address (typically the last address in your subnet)
    Then comes the route command, where you get to add entries to Linux's forwarding table:
% route add -net xxx.xxx.xxx.xxx netmask yyy.yyy.yyy.yyy
where xxx is your network number -- not the IP address of your machine.  In other words, this is just the network and subnet parts of an IP address that is divided into network, subnet, and host parts. (are you familiar with CIDR?)
where yyy is the subnet mask -- the series of ones followed by all zeros that lets the OS know how many bits are dedicated to network and subnet.
% route add default gw xxx.xxx.xxx.xxx
where xxx is the address of the "router" the OS should send all packets to that are not in your same network and subnet.  If you neglect to enter this command, you will be able to reach all hosts on your local subnet, but will receive a "network unreachable" ICMP error for all other addresses.
    If you want the changes to take effect permanently (even after a reboot), there are two files that need to be edited:  /etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth0.  All of the values that belong in here are fairly obvious, and are approximately the same as the values above.



THE INTRANET COMES ALIVE

    "It's not as hard as it sounds."  Sure, whatever.  Hooking up routers, hubs, and point-to-point links takes some careful thought!

Schematic Diagram of my Private Intranet

Legend:     This was version one of my Intranet.  Here are the step-by-step ways that this came about.




HOOKING UP TO THE INTERNET

    I wanted to be able to access the public Internet from the lab.  In order to do this, I had to hook one of my router's interfaces up to the central router in the lab.  Then, I'd have to somehow tell this router about my network.

    The gray areas in the picture are the parts I added in.  Also, let's say that I had leased this connection from another company.  I would not be responsible for management of the gray areas -- only the color areas.

    An interesting problem arose at this point.  For my intranet, I was running the RIP routing update protocol, while the network to which the NEL-ATM-ROUTER belonged to was running the IGRP routing protocol.  Would I have to run IGRP to connect to this network?  Theoretically, I knew that I wouldn't have to -- that's the whole idea of "autonomous systems."  The NEL-ATM-ROUTER has no business knowing the internal structure of my intranet -- it should only need to know the address of my "gateway" router.

    Well, after SEVERAL weeks, the solution just "came to me" one day.  This was the line in the NEL-ATM-ROUTER that I needed:

ip address 206.77.43.106 255.255.255.192
    It seems simple enough, but note that the subnet mask here is DIFFERENT from the one I used for the subnets in my intranet (I used 255.255.255.248).  Basiaclly, this "larger" mask above covers the entire address space I used on my Intranet.  After I used this command, all datagrams routed perfectly to me!  Any datagram with an address from 206.77.43.64 to 206.77.43.127 would go out on the interface on NEL-ATM-ROUTER that I programmed this command into.  Then, my router at the other end would receive the datagrams destined for my network and route them appropriately.

    So how did NEl-ATM-ROUTER know whether, say, 206.77.43.89 is a host on the ethernet directly attached to it, or if it needs to forward a datagram for this host my gateway router?  Well, NEL-ATm-ROUTER doesn't care!  Recall, the ARP rpotocol is used to determine the actual data-link layer address of a destination.  When NEL-ATM-ROUTER does an ARP request on this interface, my gateway router will respond with ITS data-link layer address.  As far as NEL-ATM-ROUTER is concerned, it HAS found the destination host.



THE FINAL, COMPLETED PRODUCT

    Once I realized that all of my crazy, eccentric work would eventually be used by future students, I had to buckle down and make this intranet of mine MAKE SENSE!  So, after a few weeks of happy complacency under the topology described in the previous section, I completely redesigned my intranet (though hints of the old one are still evident).  Here's what I came up with:

    Please don't be intimidated.  This intranet is conceptually the same at everything else I've talked about on this web page.  Each interface of a router is connected to a subnet (once again, 29 bits were used for the network portion, and 3 bits were used for the host portion of the address -- a subnet mask of 255.255.255.248).  Just study this diagram for a few minutes, and it will hopefully be apparent that there's really nothing mystical or uncomprehendable.  This IS an intranet, a wide area network -- the exact same thing that companies worldwide set up for themselves!

    There are a few important things to note here.  First, note that subnetting is being used -- that is, the network segments in this diagram are neither Class A, Class B, nor Class C.  Since this is the case, more or less every address has to have a subnet mask associated with it.  Using the subnet mask, IP can determine if two addresses are on the same subnet or on different networks.  Recall that a subnet is the "finest grained" unit of measurement under IP -- an intranet (or WAN) is simply a bunch of interconnected subnets.

    For simplicity, the same subnet mask is used for all of the subnets in this WAN.  That means that each subnet will have the same number of maximum hosts, which, if you'll notice, is not very many for the mask we are using.  There are only three bits for the "host" portion!  But that will work fine for this setup -- it would be pretty useless if we were really interconnecting real offices between cities (you couldn't have more than a handful of workstations in each office!)

    Also, notice that all of the small subnets (such as .80, .88, .96, etc.) can be grouped into a supernet of 206.77.43.64.  This supernet has a subnet mask that allocates 26 bits and 6 bits to the network and host portion, respectively.  This is the beauty of hierarchial addressing -- my entire intranet, with its 7 subnets and four routers, can be completely represented to the outside world as this one network address -- the rest of the world doesn't need to know how I chose to subnet my intranet!
 
    So, that's it!  My intranet, over the entire summer, slowly became the sophistocated, fancy picture that you see above.  If you're interested in what this final product will be used for, check this out.



Questions? Comments? Observations? Bored???
bgarner@cs.utexas.edu
Last updated: 8-9-1999
This page is Y2K compliant; a charismatic millenialist cult leader has been chosen.