The Routing Process

Now that I've talked a little bit about what a router is and what it does, I want to talk about the routing process. In order to understand how routing works, you have to understand a little bit about how the TCP/IP protocol works.

Every device connected to a TCP/IP network has a unique IP address bound to its network interface. The IP address consists of a series of four numbers separated by periods. For example, a typical IP address looks something like this: 192.168.0.1

The best analogy I can think of to describe an IP address is to compare it to a street address. A street address consists of a number and a street name. The number identifies the specific building on the street. An IP address works kind of the same way. The address is broken into the network number and a device number. If you were to compare an IP address to a Street address, then think of the network number as being like a street name, and at the device number as being like a house number. The network number identifies which network the device is on, and the device number gives the device an identity on that network.

So how do you know where the network number ends and the device number begins? This is the job of the subnet mask. A subnet mask tells the computer where the network number portion of an IP address stops, and where the device number starts. Subnetting can be complicated, and I will cover in detail in a separate article. For now, let's keep it simple and look at a very basic subnet mask.

A subnet mask looks a lot like an IP address in that it follows the format of having four numbers separated by periods. A typical subnet mask looks like this: 255.255.255.0

In this particular example, the first three numbers (called octets) are each 255, and the last number 0. The number 255 indicates that all of the bits in the corresponding position in the IP address are a part of the network number. The number zero indicates that none of the bits in the corresponding position in the IP address are a part of the network number, and therefore they all belong to the device number.

I know this probably sounds a little bit confusing, so consider this example. Imagine that you had a PC with an IP address of 192.168.1.1 and a subnet mask of 255.255.255.0. In this particular case, the first three octets of the subnet mask are all 255. This means that the first three octets of the IP address all belong to the network number. Therefore, the network number portion of this IP address is 192.168.1.x.

The reason why this is important to know is because a router’s job is to move packets of data from one network to another. All of the devices on a network (or on a network segment to be more precise) share a common network number. For example, if 192.168.1.x was the network number associated with computers attached to the router shown in Figure B, then the IP addresses for four individual computers might be:

·         192.168.1.1

·         192.168.1.2

·         192.168.1.3

·         192.168.1.4

As you can see, each computer on the local network shares the same network number, but has a different device number. As you may know, whenever a computer needs to communicate with another computer on a network, it does so by referring to the other computer’s IP address. For example, in this particular case the computer with the address of 192.168.1.1 could easily send a packet of data to the computer with the address of 192.168.1.3, because both computers are a part of the same physical network.

Things work a bit differently if a computer needs to access a computer on another network. Since I am focusing this particular discussion on small broadband routers that are designed to provide Internet connectivity, let’s pretend that one of the users on the local network wanted to visit the www.brienposey.com Web site. A Web site is hosted by a server. Like any other computer, a Web server has a unique IP address. The IP address for this particular Web site is 24.235.10.4.

You can easily look at this IP address and tell that it does not belong to the 192.168.1.x network. That being the case, the computer that’s trying to reach the Web site can’t just send the packet out along the local network, because the Web server isn’t a part of the local network. Instead, the computer that needs to send the packet looks at its default gateway address.

The default gateway is a part of a computer’s TCP/IP configuration. It is basically a way of telling a computer that if it does not know where to send a packet, then send it to the specified default gateway address. The default gateway’s address would be the router’s IP address. In this case, the router’s IP address would probably be 192.168.1.0.

Notice that the router’s IP address shares the same network number as the other computers on the local network. It has to so that it can be accessible to those computers. Actually, a router has at least two IP addresses. One of those addresses uses the same network number as your local network. The router’s other IP address is assigned by your ISP. This IP address uses the same network number as the ISPs network. The router’s job is therefore to move packets from your local network onto the ISPs network. Your ISP has routers of its own that work in exactly the same way, but that route packets to other parts of the Internet.

Last month I received an e-mail message from a reader who wanted to know why most of the articles in this series have focused on Windows. It was not so much that the person who sent me the message hated Microsoft, or preferred Linux, or anything like that, but wondered why Windows was necessary. As he correctly pointed out, networking has been around since long before Windows. To make a long story short, I thought that the message made a good point, so I wanted to take the opportunity to talk about the role that Windows plays in networking.

Before I Begin

Before I get started, there are a couple of things that I need to say up front. First, I am going to be spending some time talking about the early days of Windows. There are a lot of rumors alleging that Microsoft “borrowed” parts of the Windows Operating System from companies like IBM and Apple. Personally, I do not know if these rumors are true or not, and to be perfectly frank, I do not really care. I just wanted to acknowledge the point up front in an effort to reduce the number of e-mail messages that I receive in response to this article.

The other thing that I want to clarify up front is that today, every operating system implements networking in roughly the same way. Although one operating system might be more efficient than another, the end result is basically the same. After all, it is no coincidence that Windows, Macintosh, Linux, and UNIX can all communicate across the same Internet, using the same protocols.

By writing about Windows, I am not trying to start an operating system war, as I seem to have inadvertently done so many times in the past. I just choose to write about Windows because it is the most commonly used operating system, and articles about Windows would therefore theoretically benefit the largest number of people, and this is primarily a Windows focused website.

What Windows Did for the World

Now that I have hopefully appeased most of the haters, let us get down to business. The reason why Windows became such a dominant operating system was because it solved two major problems that plagued the IT industry.

The first of these problems is that prior to the creation of Windows, PCs were relatively difficult to use (at least for the lay person anyway). Prior to Windows 3.x, most PCs ran a Microsoft operating system known as MS-DOS. DOS was an acronym that stood for Disk Operating System.

The DOS operating system actually worked pretty well, but it did have some serious shortcomings. For starters, the operating system was text based. This meant that if you wanted to launch an application, you could not just point and click on an icon, you had to know the command or commands needed to launch that application. If you wanted to know how much free disk space you had, you could not just right click on a disk icon, you had to use the CHKDSK or DIR command.

The average person was intimidated by DOS. After all, using DOS even for the basics required learning quite a few commands. Many of those commands could do significant damage to your data if you accidentally used them incorrectly, so that added to the problem.

There is no denying that PC use was already becoming widespread before Microsoft introduced the graphical operating system, but Windows helped to make PCs much easier to use.

The second thing that Windows accomplished was far more important. Windows provided a level of abstraction that allowed device drivers to be separated from applications.

In the days of DOS, it was an application developer’s responsibility to include device drivers as a part of an application. For example, when I was in high school, the best word processor on the market was a now defunct product known as PFS Write. One of the things that made PFS Write such a good product was that it supported numerous printers. Even so, I recall purchasing a copy and installing it onto my computer, only to find out that it did not include a driver for my printer. As a result, I had to buy a new printer, just to be able to use a word processor.

Keep in mind that my previous printer was not junk. The problem was that most applications at the time shipped on floppy disks, which had an extremely limited capacity. As a result, application developers would typically only include drivers for the most commonly available hardware. At the time, it was not at all uncommon to find that some applications (especially video games) did not support particular video cards, sound cards, etc.

The way that drivers were tied to applications was bad for both application developers and for consumers. It was bad for application developers, because they had to spend time writing a zillion device drivers, which increased development cost and increased the amount of time that it took to get their product to market. Because an application could only support a limited set of hardware, the developer inevitably alienated some would be customers by not supporting their hardware.

Having device drivers tied to applications was bad for consumers as well. Typically, older hardware was not supported, often forcing consumers to purchase new hardware along with their new application. At the same time though, cutting edge hardware was not usually supported either. Application developers needed to create drivers that would work for the largest number of people possible, so it was rare for an application to contain drivers for the latest hardware. Often the new hardware was backward compatible with device drivers for older hardware, but it might take years for the cutting edge hardware’s full potential to be widely utilized by applications.

When Microsoft created Windows, they created an environment in which any application can interact with any hardware. Sure, applications still have minimum hardware requirements, but hardware brands and models do not really matter anymore. For example, if I wanted to print this document, it would not really matter what kind of printer I have, as long as I have a printer driver installed.

Windows is built in layers. Every Windows application generates print jobs in exactly the same way, regardless of what the application is, or what type of printer the job is being sent to. The Windows operating system then uses the specified print driver to translate the job into something that the printer can understand. The actual process is a little bit more complicated than this, but I wanted to convey the basic idea rather than going into a lot of boring architectural details.

The point is that abstracting applications from device drivers helps everyone. Application developers no longer suffer the burden of writing device drivers, and consumers are now free to use any hardware they want (so long as it meets minimum standards) without having to worry about whether or not it will work with a particular application.

                                                                               In last month’s article, I talked about the way that Windows (and other network operating systems) use a process called abstraction to allow applications to be developed without the vendor having to worry about creating drivers for specific hardware components. Although this concept is widely used throughout the Windows operating system, it is especially important when it comes to networking.

To see why this is the case think about what I talked about in the previous article in regard to hardware abstraction. Suppose that an application needs to be able to communicate across the network. The application developer does not build network drivers into the application, they merely write the application in a way that allows it to make certain calls to the Windows operating system. The manufacturer of the machine’s network adapter provides a driver that also links to Windows, and Windows performs the necessary match ups that allow the application to communicate with the network adapter.

Of course that is just the quick and dirty version. Things are actually quite a bit more complex than that. After all, the network adapter is just a device that is designed to send and receive packets of data. The card itself knows nothing of Windows, the application, or even of the protocols that are being used.

The example that I provided a moment ago implies that there are three layers at work; the application, the operating system, and the physical hardware. While these layers do exist (but not necessarily by those names), they can be subdivided into several more layers.

Before I explain what these layers are and what they do, I want to point out that the concepts that I am about to teach you are not abstract. In fact, if you open the Local Area Connection properties sheet, shown in Figure A, you can see that a network connection is made up of several different components, such as the network client, the network adapter driver, and the protocol. Each of these components corresponds to one or more individual layers.

Figure A: The Local Area Connection properties sheet offers a glimpse at the way that the various network layers are implemented in Windows

The network model that Windows, and most other network operating systems use is called the OSI Model. The term OSI Model is short for Open System Interconnection Basic Reference Model. The OSI Model consists of seven different layers. Each layer of the model is designed so that it can perform a specific task, and facilitate communications between the layer

 above it and the layer below it. You can see what the OSI Model looks like in Figure B.

Figure B: The OSI Model