Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Child Fund

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents
Up to --> Networking

· IP Addressing
· Pseudo Terminals
· Network Services
· Network Standards
· Subnet Masks
· Routing and IP Gateways
· The Domain Name System

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages
Recommend Us

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 200 guest(s) and 2 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

Linux Tutorial - Networking - TCP-IP - Routing and IP Gateways
  Subnet Masks ---- The Domain Name System  

Routing and IP Gateways

I mentioned previously that IP is an unreliable, connection-less protocol. That is, it contains no provision to ensure that the packet arrives correctly at the destination, nor is there anything that guarantees that when packets do arrive they arrive in the correct order. Although IP is responsible to ensure that the packets get to the right machine, it has essentially no understanding of the physical connection between the two machines. IP will happily run on machines that are connected with something as simple as a telephone wire, to something as complex as satellites. IP depends on some other means to "physically" carry it across the network.

What this means is that the system administrator (or network administrator) is responsible for laying the "map" that is used to define which network address go with what sets of machine and what IP addresses are assigned to individual machines.

One important job that IP does is routing. That is, getting the packet to the right machine. If the source and destination machines are directly connected, that is on the same network, then routing is easy. Essentially there isn't any. IP sees this fact and simply hands the packets off to the data link layer. Otherwise, IP has to figure out how and where to send it.

Usually the 'how' is over a router. A router is some piece of hardware that acts like an air traffic controller send one packet off one way and others off a different way. Often routers are separate pieces of equipment that can be configured in very detailed ways. The disadvantage to this is that with power comes price. The ability to configure a router in many different ways usually means a high price tag. Fortunately, many operating systems, including Linux allow IP to serve as router-software. Thereby avoiding the cost of router hardware.

In comparison to the router is the concept of a gateway. Like a router, a gateway has knowledge of other networks and how to reach them. In general, we can think of a router as a special piece of hardware that does the work for us. In fact, there are companies that sell equipment called routers. A gateway is more of a concept, in that is the means by which you go from one network to another. Today, the distinction between a router and a gateway is blurred. Originally, a gateway was a machine that converted from one protocol to another. However, in common usage today, routers can server as gateways, gateways can serve as routers.

The path the packet takes from one machine to the next is called a route. Although each machine can maintain static routes for specific destinations, the default gateway is usually used to find remote destinations. (The default gateway is needed only for computers that are part of an internetwork.) If you have a gateway connected to several other networks, there will (probably) be route definitions for each of those other networks.

Let's look at this process as if we were sending a letter, as we did a little while ago. Each letter we send has an envelope which contains a message. On the envelope we write the source and destination addresses. When we mail the letter it gets to the post office and the person sorting the mail checks the destination zip code. If it's the same as the local zip code, the envelope is sent to one of the carriers for delivery. If the zip code is different, then it is sent to some other location. Perhaps all non-local mail is sent to the same place.

If you live across the country from me, the letter probably doesn't go directly from my local post office to yours. (assuming I don't live in San Francisco and you don't live in New York) The same applies to IP packets. My letter first goes to my local post office, if it is destined for a local address it is processed there. If not, it is sent along to a larger post office. If I sent a letter from Santa Cruz, California destined for Annsville, Pennsylvania, it will probably go first to San Francisco and then to New York (or Philadelphia) before it gets sent to Annsville.

Again, the same applies to IP packets. If I were communicating with a network on the other side of the country, my machine needs to know how to get to the other one. This is the concept of a "gateway". A gateway is the first step in the path, or "route" to the remote machine. Just as there are a couple of post offices between Santa Cruz and Annsville, there can be multiple gateways between computers.

Since San Francisco is the closest "major" city to Santa Cruz, it is possible that all mail bound for points beyond must first go through there. What if I lived in Fresno, which is about halfway between San Francisco and Los Angeles? If I sent a letter to Annsville, it could go through Los Angeles or it could go through San Francisco. To make things easy, it might always get sent through San Francisco it not destined for a local address.

What if the letter is bound for Los Angeles? It seems silly to go through San Francisco first when it is bound for LA. At the post office in Fresno, they might have a special procedure that says all remote mail goes through San Francisco, except for those with a zip code in a special range.

Here, too, the same applies to IP addresses. One machine may be defined as the "default" gateway, but if an IP packet was bound for a particular network it could be told to use a completely different gateway. Which gateway to use to get to a particular machine or network is the concept of "routes." If I want all remotely-bound packets to use a particular route, I add that route as a default to my machine. If packets bound for a particular network are to go via a different route, I can add that route as well.

Image - Network gateway (interactive)

When IP prepares to send a "message", it inserts the local (source) and destination IP addresses in the IP header. It then checks whether the network ID of the destination and source match (the zip codes). If so, the packet is sent directly to the destination, since it is on the local network. If the network IDs don't match, the routing table is examined for static routes. If none are found, the packet is forwarded to the default gateway.

The default gateway is a computer connected to the local subnet and other networks that has knowledge of the IDs for other networks and how to reach them. Because the default gateway knows how to reach the other networks, it can forward the packet, either to other gateways or directly to that machine if the gateway is on the same network as the destination. This process is known as routing.

If you only have a single network, there is no reason to have a gateway, as each machine is directly connected to every other. It's possible that you only want certain machines within your network to go beyond the local net to the outside. In this case, these machine can have a default (or static) route default, while the others have none. However, users can add routes themselves, using the route command.

As we talked about earlier, TCP connections are not the only ones that are managed by inetd. Basically all network connections are. This can be understood if we go back to the telephone operator analogy. If the operator (inetd) is also the receptionist, we can then think of TCP connections as incoming telephone calls and UDP packets as incoming letters. Like incoming phones calls, the receptionist is responsible to route the incoming mail to the right person. (This is a valid analogy, because like regular mail, there is nothing to guarantee the delivery of the message in the letter, although with TCP connections you can ask your partner to resend the message.) Like TCP connections, UDP daemons are "listening" on specific ports. Also like TCP connections, these well-known ports are listed in /etc/services.

One common UDP connection is the routing daemon: routed. Routed supplies (as you might have guessed) routing information in the form of routing packets. If your system is serving as a router, then routed periodically sends copies of its routing tables to other machines.

One key difference is that routed is not actually started by inetd. Instead, it is normally started through one of the scripts under /etc/rc.d as the system is booting. This actually calls the script /etc/sysconfig/network-scripts/ifcfg-routes.

When it starts, routed makes the assumption that it will forward packets between all interfaces on the system. This only includes those that are "up" and does not include the loopback driver. (The loopback driver is a special TCP/IP interface that simply loops the packets back to the local machine. Hence the name.) Routed then transmits a REQUEST packet on each of these interfaces and waits for a RESPONSE packet for any other hosts. Potentially there are other machines on the network that are also sending REQUESTS packets, so routed can also respond to them.

The response routed gives is based on information it has in it's routing tables. This contains information about known routes, including how far away the destination machine is in turns of hops or intermediary machines. When routed receives a RESPONSE packet, it uses the information contained in that packet to update it's own routing tables. Look at the routed man-page for more information.

Routes are added to and removed from the system using the route command. The general syntax is:

route <option> command destination gateway metric

The two commands used are add and delete. The destination is the IP address of the machine or network you want to reach. You can also use tokens for the network name by including entries in the /etc/networks file. This is an ASCII file containing two columns. The first is the name of the network and the second column is the network address. You can then use that name in the route command.

The gateway is the IP address of the interface to which the packets need to be addressed. Keep in mind that the system must already know how to get to the gateway for this to work.

The metric is a value that normally indicates the number of intermediate machines (hops). The system uses this value in determining the shortest route to a particular machine.

For example, let's assume we have an entry in /etc/networks like this:

siemau 132.147

Let's also assume that the machine I need to use to access this route has an IP address of I could then run the route command like this:

This says that any packet destined for the siemau network (as defined in /etc/networks) should go to the IP address with a metric of 0. Normally, 0 is used when the IP address you specify is directly connected to your machine.

If you have a single machine that serves as your gateway to the rest of the world, you can specify default instead of a specific address or network as your destination. In the example above, if we wanted to use the same machine for all networks instead of just siemau, the command would look like this:

As you move about the network, dynamic entries are created by the routing protocol that you use. (Most commonly routed) The routing protocol communicates with it's counterpart on other machines and adds entries to the routing tables automatically.

When it starts, routed looks for the file /etc/gateways, which contains a list of gateways. (What else?) The general format for this file is:

<net|host> name gateway metric type

The first field specifies whether the gateway is to a specific machine or network. The name field is the name of the destination host or network. This can either be an IP address or a token. If using a token, then the hostname must be located in /etc/hosts or can be determined through DNS. If through DNS, routed must be started after named. If a network, the name must be in /etc/networks.

The gateway field is the name or address of the gateway that is to be used. The metric is the same as for routes and indicates the number of hops. The type can be either passive, active or external. A passive gateway is one that is not expected to exchange routing information. Active gateways will exchange information and usually have routed running on them. External gateways are ones that are managed by another system, but alternate routes should not be installed.

 Previous Page
Subnet Masks
  Back to Top
Table of Contents
Next Page 
The Domain Name System


Test Your Knowledge

User Comments:

You can only add comments if you are logged in.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
The Linux Tutorial can use your help.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 2.49 Seconds