Static Routing

Static routing is the most simple and the most common way of configuring path selection of routers in computer networks. In this case topology of the network (routes) is encoded manually in so called routing table. The opposite of static routing is dynamic routing, sometimes also referred to as adaptive routing.

Static routing is the best in simple configurations, for example when only one router is assessable from a workstations as well as when dynamic routing would be a security risk. It should be on the same network.

For example, if your local network has three subnets that need to share data, a static route could be created between each router and the other two routers in the network. The number of specific routes required to allow data to flow seamlessly between networks is directly proportional to the square of the number of routers on the network. Every time a change is made to the network topology, these routes will have to be modified manually. If that sounds like too much hard work, consider the situation where it might be desirable: a secure database server that can be accessible only by knowing the route to the host and is not publicly announced. Instead of permitting route discovery, a static route is an appropriate technique here. This could be implemented by creating a point-to-point routing table.

In these case, routes through a data network are described by fixed paths (statically). An entire network can be configured using static routes, but this type of configuration is not fault tolerant. When there is a change in the network or a failure occurs between two statically defined nodes, traffic will not be rerouted. This means that anything that wishes to take an affected path will either have to wait for the failure to be repaired or the static route to be updated by the administrator before restarting its journey. Most requests will time out (ultimately failing) until repairs are made. There are, however, cases when static routes can improve the performance of a network, for example the concept of the default route and related concept of the default router.

Static routes does not change or time-out. You define them using route utility and view the resulting routing table with  netstat -r or   netstat -rn

The localhost entry in the local routing table is a loopback route to the local host that is created when the lo0 pseudo interface is configured.

Configuring Static Routes Using route Utility

The Solaris route command enables manual manipulation of the route table The syntax of the command is pretty convoluted but it consist of two parts target route(or host) and gateway used. Linux version of route uses keyword gw before gateway specification. 

[Solaris] route [-fn] add|delete [net|host|default] destination gateway

[Linux] route [-fn] add|delete [net|host|default] destination  gw gateway

With keywords add and delete the default for optional [net|host|default] troika is host.

For example, to add a direct static route between the  systems alpha and beta, perform a command similar to the following:

# route add beta alpha
add host beta: gateway alpha

This is equivalent to:

# route add host beta alpha

To delete the route between beta and alpha, perform a command similar to the following:

# route delete beta alpha
delete host beta: gateway alpha

To define a default route using the system sigma , perform a command similar to the following:

# route add default sigma
add net default: gateway sigma

The route utility can also to retrieve information about a specific route. For example, to retrieve information about the default route:

# route get default
   route to: default
destination: default
       mask: default
    gateway: 10.201.12.1
  interface: bge0
      flags: 
 recvpipe  sendpipe  ssthresh    rtt,ms rttvar,ms  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0
	

To change the route table, use the change option with the route utility. For example, to change the default route from sigma to gamma, perform a command similar to the following:

# route change default gamma
change net default: gateway gamma

To continuously report any changes to the route table, route lookup misses, or suspected network partitionings, use the monitor option: 

# route monitor
got message of size 124
RTM_DELETE: Delete Route: len 124, pid: 633, seq 1, errno 0,
flags:<UP,GATEWAY,DONE,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>

192.168.3.0 alphaext 255.255.255.0

To flush (remove) the route table of all gateway entries, use the flush option (only indirect routing table entries would be removed):

# route flush

192.168.9 beta done
two beta done
two alphaext done
default 172.20.4.248 done

you can also flush the route table before any command with -f option:

# route -f add net 192.168.4.0 alphaext
add net 192.168.4.0: gateway alphaext

In case you accidentally deleted mulcast entry you can restore it manually (you can consult the command syntax in the /etc/rc2.d/S72inetsvc startup file).  For example to add a route to the multicast address range of 224 through 239, perform the command:

# route add 224.0/4 ‘uname -n‘

To define a route that uses a specific netmask, use the netmask option with the route utility. For example, to add a route to the 192.168.3.0 network that uses a netmask of 255.255.255.224, perform the command:

# route add net 192.168.3.0 deltaext -netmask 255.255.255.224
add net 192.168.3.0: gateway deltaext

More concise way of doing the same would be to specify 192.168.3.0/27 :

# route add net 192.168.3.0/27 deltaext
add net 192.168.3.0/27: gateway deltaext

Note:  The in.routed process does not automatically detect route table changes. Therefore, do not perform changes while the in.routed process is running. Instead, shut down the in.routed process, make the required changes, and then restart the in.routed process. This ensures that the in.routed process use the latest version of the routing table.

You can use the route utility to define a static routes. A static route is a route that is not automatically removed by the in.routed process if a more efficient route is identified.

Here is a relevant quote from Building a Static Routing Table (TCP-IP Network Administration, 3rd Edition)

As we have seen, the minimal routing table works to reach hosts only on the directly connected physical networks. To reach remote hosts, routes through external gateways must be added to the routing table. One way to do this is by constructing a static routing table with route commands.

Use the Unix route command to add or delete entries manually in the routing table. For example, to add the route 207.25.98.0 to a Solaris system's routing table, enter:

# route add 207.25.98.0 172.16.12.1 1
add net 207.25.98.0: gateway crab

The first argument after the route command in this sample is the keyword add. The first keyword on a route command line is either add or delete, telling route either to add a new route or delete an existing one. There is no default; if neither keyword is used, route displays the routing table.

The next value is the destination address, which is the address reached via this route. The destination address can be specified as an IP address, a network name from the /etc/networks file, a hostname from the /etc/hosts file, or the keyword default. Because most routes are added early in the startup process, numeric IP addresses are used more than names. This is done so that the routing configuration is not dependent on the state of the name server software. Always use the complete numeric address (all four bytes).

route expands the address if it contains fewer than four bytes, and the expanded address may not be what you intended (Some implementations of route expand "26" to 0.0.0.26, even though "26" could mean Milnet (26.0.0.0).)

If the keyword default is used for the destination address, route creates a default route.[70] The default route is used whenever there is no specific route to a destination, and it is often the only route you need. If your network has only one gateway, use a default route to direct all traffic bound for remote networks through that gateway.

[70]The network address associated with the default route is 0.0.0.0.

Next on the route command line is the gateway address.[71] This is the IP address of the external gateway through which data is sent to the destination address. The address must be the address of a gateway on a directly connected network. TCP/IP routes specify the next hop in the path to a remote destination. That next hop must be directly accessible to the local host; therefore, it must be on a directly connected network.

[71]Linux precedes the values on the route command line with keywords; e.g., route add -net 207.25.98.0 netmask 255.255.255.0 gw 172.16.12.1. Check your system's documentation for the details.

The last argument on the command line is the routing metric. The metric argument is not used when routes are deleted, but some older systems require it when a route is added; for Solaris 8, the metric is optional. Systems that require a metric value for the route command use it only to decide if this is a route through a directly attached interface or a route through an external gateway. If the metric is 0, the route is installed as a route through a local interface, and the G flag, which we saw in the netstat -i display, is not set. If the metric value is greater than 0, the route is installed with the G flag set, and the gateway address is assumed to be the address of an external gateway. Static routing makes no real use of the metric. Dynamic routing is required to make real use of varying metric values.

7.3.1. Adding Static Routes

As an example, let's configure static routing on the imaginary workstation rodent. Figure 7-1 shows the subnet 172.16.12.0. There are two gateways on this subnet, crab and horseshoe. crab is the gateway to thousands of networks on the Internet; horseshoe provides access to the other subnets on books-net. We'll use crab as our default gateway because it is used by thousands of routes. The smaller number of routes through horseshoe can easily be entered individually. The number of routes through a gateway, not the amount of traffic it handles, decides which gateway to select as the default. Even if most of rodent's network traffic goes through horseshoe to other hosts on books-net, the default gateway should be crab.

To install the default route on rodent, we enter:

# route add default gw 172.16.12.1

The destination is default, and the gateway address (172.16.12.1) is crab's address. Now crab is rodent's default gateway. Notice that the command syntax is slightly different from the Solaris route example shown earlier. rodent is a Linux system. Most values on the Linux route command line are preceded by keywords. In this case, the gateway address is preceded by the keyword gw.

After installing the default route, examine the routing table to make sure the route has been added:[72]

[72]Solaris always uses netstat to examine the routing table. Linux can use either netstat or route, but route is more common.

# route -n
Kernel IP routing table
Destination   Gateway       Genmask         Flags Metric Ref Use Iface
172.16.12.0   0.0.0.0       255.255.255.0   U     0      0     0 eth0
127.0.0.0     0.0.0.0       255.0.0.0       U     0      0     0 lo
0.0.0.0       172.16.12.1   0.0.0.0         UG    0      0     0 eth0

Try ping again to see whether rodent can now communicate with remote hosts. If we're lucky,[73] the remote host responds and we see:

[73]It is possible that the remote host is down. If it is, ping receives no answer. Don't give up; try another host.

% ping 207.25.98.2 
PING 207.25.98.2: 56 data bytes 
64 bytes from ruby.ora.com (207.25.98.2): icmp_seq=0. time=110. ms 
64 bytes from ruby.ora.com (207.25.98.2): icmp_seq=1. time=100. ms 
^C 
----207.25.98.2 PING Statistics---- 
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 100/105/110

This display indicates successful communication with the remote host, which means that we now have a good route to hosts on the Internet.

However, we still haven't installed routes to the rest of books-net. If we ping a host on another subnet, something interesting happens:

% ping 172.16.1.2 
PING 172.16.1.2: 56 data bytes 
ICMP Host redirect from gateway crab.wrotethebook.com (172.16.12.1) 
 to horseshoe.wrotethebook.com (172.16.12.3) for ora.wrotethebook.com (172.16.1.2) 
64 bytes from ora.wrotethebook.com (172.16.1.2): icmp_seq=1. time=30. ms 
^C 
----172.16.1.2 PING Statistics---- 
1 packets transmitted, 1 packets received, 0% packet loss round-trip (ms)  min/avg/max = 30/30/30

rodent believes that all destinations are reachable through its default route. Therefore, even data destined for the other subnets is sent to crab. If rodent sends data to crab that should go through horseshoe, crab sends an ICMP Redirect to rodent telling it to use horseshoe. (See Chapter 1, " Overview of TCP/IP" for a description of the ICMP Redirect Message.) ping shows the ICMP Redirect in action. The redirect has a direct effect on the routing table:

# route -n
Kernel IP routing table
Destination   Gateway       Genmask         Flags Metric Ref Use Iface
172.16.12.0   0.0.0.0       255.255.255.0   U     0      0     0 eth0
127.0.0.0     0.0.0.0       255.0.0.0       U     0      0     0 lo
0.0.0.0       172.16.12.1   0.0.0.0         UG    0      0     0 eth0 
172.16.1.2    172.16.12.3   255.255.255.0   UGHD  0      0   514 eth0 

The route with the D flag set was installed by the ICMP Redirect.

Some network managers take advantage of ICMP Redirects when designing a network. All hosts are configured with a default route, even those on networks with more than one gateway. The gateways exchange routing information through routing protocols and redirect hosts to the best gateway for a specific route. This type of routing, which is dependent on ICMP Redirects, became popular because of personal computers (PCs). Many PCs cannot run a routing protocol; some early models did not have a route command and were limited to a single default route. ICMP Redirects were one way to support these clients. Also, this type of routing is simple to configure and well suited for implementation through a configuration server, as the same default route is used on every host. For these reasons, some network managers encourage repeated ICMP Redirects.

Other network administrators prefer to avoid ICMP Redirects and to maintain direct control over the contents of the routing table. To avoid redirects, specific routes can be installed for each subnet using individual route statements:

# route add -net 172.16.1.0 netmask 255.255.255.0 gw 172.16.12.3 
# route add -net 172.16.6.0 netmask 255.255.255.0 gw 172.16.12.3
# route add -net 172.16.3.0 netmask 255.255.255.0 gw 172.16.12.3
# route add -net 172.16.9.0 netmask 255.255.255.0 gw 172.16.12.3

rodent is directly connected only to 172.16.12.0, so all gateways in its routing table have addresses that begin with 172.16.12. The finished routing table is shown below:

# route -n
Kernel IP routing table
Destination   Gateway       Genmask         Flags Metric Ref Use Iface
172.16.6.0    172.16.12.3   255.255.255.0   UG    0      0     0 eth0
172.16.3.0    172.16.12.3   255.255.255.0   UG    0      0     0 eth0
172.16.12.0   0.0.0.0       255.255.255.0   U     0      0     0 eth0
172.16.1.0    172.16.12.3   255.255.255.0   UG    0      0     0 eth0
172.16.9.0    172.16.12.3   255.255.255.0   UG    0      0     0 eth0
127.0.0.0     0.0.0.0       255.0.0.0       U     0      0     0 lo
0.0.0.0       172.16.12.1   0.0.0.0         UG    0      0     0 eth0 
172.16.1.2    172.16.12.3   255.255.255.0   UGHD  0      0   514 eth0

The routing table we have constructed uses the default route (through crab) to reach external networks, and specific routes (through horseshoe) to reach other subnets within books-net. Rerunning the ping tests produces consistently successful results. However, if any subnets are added to the network, the routes to these new subnets must be manually added to the routing table. Additionally, if the system is rebooted, all static routing table entries are lost. Therefore, to use static routing, you must ensure that the routes are re-installed each time your system boots.

7.3.1.1. Installing static routes at startup

If you decide to use static routing, you need to make two modifications to your startup files:

1. Add the desired route statements to a startup file.
2. Remove any statements from the startup file that run a routing protocol.

To add static routing to a startup script, you must first select an appropriate script. On BSD and Linux systems, the script rc.local is set aside for local modifications to the boot process. rc.local runs at the end of the boot process so it is a good place to put in changes that will modify the default boot process. On our sample Red Hat Linux system, the full path of the rc.local file is /etc/rc.d/rc.local. On a Solaris system, edit /etc/init.d/inetinit to add the route statements:

route -n add default 172.16.12.1 > /dev/console 
route -n add 172.16.1.0 172.16.12.3 > /dev/console 
route -n add 172.16.6.0 172.16.12.3 > /dev/console 
route -n add 172.16.3.0 172.16.12.3 > /dev/console
route -n add 172.16.9.0 172.16.12.3 > /dev/console

The -n option tells route to display numeric addresses in its informational messages. When you add route commands to a Solaris startup file, use the -n option to prevent route from wasting time querying name server software that may not be running. The -n option is not required on a Linux system because Linux does not display informational messages when installing a route.

After adding the route commands, check whether the script starts a routing protocol. If it does, comment out the lines that start it. You don't want a routing protocol running when you are using static routing. On our Solaris sample system, the routing software is started only if the system has more than one network interface (i.e., is a router) or the /etc/gateways file has been created. (More on this file later.) Neither of these things is true; therefore, the routing daemon won't be run by the startup process and we don't have to do anything except add the route statements.

Before making changes to your real system, check your system's documentation. You may need to modify a different boot script, and the execution path of the routing daemon may be different. Only the documentation can provide the exact details you need.

Although the startup filename may be different on your system, the procedure should be basically the same. These simple steps are all you need to set up static routing. The problem with static routing is not setting it up, but maintaining it if you have a changeable networking environment. Routing protocols are flexible enough to handle simple and complex routing environments. That is why some startup procedures run routing protocols by default. However, most Unix systems need only a static default route. Routing protocols are usually needed only by routers.

NEWS CONTENTS

• 200102 : Guide to IP Layer Network Administration with Linux ( Guide to IP Layer Network Administration with Linux, )
• 200102 : 14.4. Configuring Static Routes ( 14.4. Configuring Static Routes, )
• 200102 : 14.5. Routing in SUSE LINUX ( 14.5. Routing in SUSE LINUX, )

Old News ;-)

Guide to IP Layer Network Administration with Linux

IP Networking Control Files

Different linux distribution vendors put their networking configuration files in different places in the filesystem. Here is a brief summary of the locations of the IP networking configuration information under a few common linux distributions along with links to further documentation.

Location of networking configuration files

• RedHat (and Mandrake)
  • Interface definitions /etc/sysconfig/network-scripts/ifcfg-*
  • Hostname and default gateway definition /etc/sysconfig/network
  • Definition of static routes /etc/sysconfig/static-routes
• SuSe (version >= 8.0)
  • Interface definitions /etc/sysconfig/network/ifcfg-*
  • Static route definition /etc/sysconfig/network/routes
  • Interface specific static route definition /etc/sysconfig/network/ifroute-*

... ...

For the remainder of this document, many examples refer to machines in a hypothetical network. Refer to the example network description for the network map and addressing scheme.

1.2. Reading Routes and IP Information

Assuming an already configured machine named tristan, let's look at the IP addressing and routing table. Next we'll examine how the machine communicates with computers (hosts) on the locally reachable network. We'll then send packets through our default gateway to other networks. After learning what a default route is, we'll look at a static route.

One of the first things to learn about a machine attached to an IP network is its IP address. We'll begin by looking at a machine named tristan on the main desktop network (192.168.99.0/24).

The machine tristan is alive on IP 192.168.99.35 and has been properly configured by the system administrator. By examining the route and ifconfig output we can learn a good deal about the network to which tristan is connected ^[1].

Example 1.1. Sample ifconfig output

[root@tristan]# ifconfig eth0 Link encap:Ethernet HWaddr 00:80:C8:F8:4A:51 inet addr:192.168.99.35 Bcast:192.168.99.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:27849718 errors:1 dropped:0 overruns:0 frame:0 TX packets:29968044 errors:5 dropped:0 overruns:2 carrier:3 collisions:0 txqueuelen:100 RX bytes:943447653 (899.7 Mb) TX bytes:2599122310 (2478.7 Mb) Interrupt:9 Base address:0x1000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:7028982 errors:0 dropped:0 overruns:0 frame:0 TX packets:7028982 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1206918001 (1151.0 Mb) TX bytes:1206918001 (1151.0 Mb) [root@tristan]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.99.254 0.0.0.0 UG 0 0 0 eth0

For the moment, ignore the loopback interface (lo) and concentrate on the Ethernet interface. Examine the output of the ifconfig command. We can learn a great deal about the IP network to which we are connected simply by reading the ifconfig output. For a thorough discussion of ifconfig, see Section C.1, "ifconfig".

The IP address active on tristan is 192.168.99.35. This means that any IP packets created by tristan will have a source address of 192.168.99.35. Similarly any packet received by tristan will have the destination address of 192.168.99.35. When creating an outbound packet tristan will set the destination address to the server's IP. This gives the remote host and the networking devices in between these hosts enough information to carry packets between the two devices.

Because tristan will advertise that it accepts packets with a destination address of 192.168.99.35, any frames (packets) appearing on the Ethernet bound for 192.168.99.35 will reach tristan. The process of communicating the ownership of an IP address is called ARP. Read Section 2.1.1, "Overview of Address Resolution Protocol" for a complete discussion of this process.

This is fundamental to IP networking. It is fundamental that a host be able to generate and receive packets on an IP address assigned to it. This IP address is a unique identifier for the machine on the network to which it is connected.

Common traffic to and from machines today is unicast IP traffic. Unicast traffic is essentially a conversation between two hosts. Though there may be routers between them, the two hosts are carrying on a private conversation. Examples of common unicast traffic are protocols such as HTTP (web), SMTP (sending mail), POP3 (fetching mail), IRC (chat), SSH (secure shell), and LDAP (directory access). To participate in any of these kinds of traffic, tristan will send and receive packets on 192.168.99.35.

In contrast to unicast traffic, there is another common IP networking technique called broadcasting. Broadcast traffic is a way of addressing all hosts in a given network range with a single destination IP address. To continue the analogy of the unicast conversation, a broadcast is more like shouting in a room. Occasionally, network administrators will refer to broadcast techniques and broadcasting as "chatty network traffic".

Broadcast techniques are used at the Ethernet layer and the IP layer, so the cautious person talks about Ethernet broadcasts or IP broadcast. Refer to Section 2.1.1, "Overview of Address Resolution Protocol", for more information on a common use of broadcast Ethernet frames.

IP Broadcast techniques can be used to share information with all partners on a network or to discover characteristics of other members of a network. SMB (Server Message Block) as implemented by Microsoft products and the samba package makes extensive use of broadcasting techniques for discovery and information sharing. Dynamic Host Configuration Protocol (DHCP) also makes use of broadcasting techniques to manage IP addressing.

The IP broadcast address is, usually, correctly derived from the IP address and network mask although it can be easily be set explicitly to a different address. Because the broadcast address is used for autodiscovery (e.g, SMB under some protocols, an incorrect broadcast address can inhibit a machine's ability to participate in networked communication ^[2].

The netmask on the interface should match the netmask in the routing table for the locally connected network. Typically, the route and the IP interface definition are calculated from the same configuration data so they should match perfectly.

If you are at all confused about how to address a network or how to read either the traditional notation or the CIDR notation for network addressing, see one of the CIDR/netmask references in Section I.1.3, "General IP Networking Resources".

1.2.1. Sending Packets to the Local Network

We can see from the output above that the IP address 192.168.99.35 falls inside the address space 192.168.99.0/24. We also note that the machine tristan will route packets bound for 192.168.99.0/24 directly onto the Ethernet attached to eth0. This line in the routing table identifies a network available on the Ethernet attached to eth0 ("Iface") by its network address ("Destination") and size ("Genmask").

Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

Every host on the 192.168.99.0/24 network should share the network address and netmask specified above. No two hosts should share the same IP address.

Currently, there are two hosts connected to the example desktop network. Both tristan and masq-gw are connected to 192.168.99.0/24. Thus, 192.168.99.254 (masq-gw) should be reachable from tristan. Success of this test provides evidence that tristan is configured properly. N.B., Assume that the network administrator has properly configured masq-gw. Since the default gateway in any network is an important host, testing reachability of the default gateway also has a value in determining the proper operation of the local network.

The ping tool, designed to take advantage of Internet Control Message Protocol (ICMP), can be used to test reachability of IP addresses. For a command summary and examples of the use of ping, see Section G.1, "ping".

Example 1.2. Testing reachability of a locally connected host with ping

[root@tristan]# ping -c 1 -n 192.168.99.254 PING 192.168.99.254 (192.168.99.254) from 192.168.99.35 : 56(84) bytes of data. --- 192.168.99.254 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss PING 192.168.99.254 (192.168.99.254) from 192.168.99.35 : 56(84) bytes of data. 64 bytes from 192.168.99.254: icmp_seq=0 ttl=255 time=238 usec --- 192.168.99.254 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.238/0.238/0.238/0.000 ms

1.2.2. Sending Packets to Unknown Networks Through the Default Gateway

In Section 1.2.1, "Sending Packets to the Local Network", we verified that hosts connected to the same local network can reach each other and, importantly, the default gateway. Now, let's see what happens to packets which have a destination address outside the locally connected network.

Assuming that the network administrator allows ping packets from the desktop network into the public network, ping can be invoked with the record route option to show the path the packet travels from tristan to wan-gw and back.

Example 1.3. Testing reachability of non-local hosts

[root@tristan]# ping -R -c 1 -n 205.254.211.254 PING 205.254.211.254 (205.254.211.254) from 192.168.99.35 : 56(84) bytes of data. --- 205.254.211.254 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss PING 205.254.211.254 (205.254.211.254) from 192.168.99.35 : 56(84) bytes of data. 64 bytes from 205.254.211.254: icmp_seq=0 ttl=255 time=238 usec RR: 192.168.99.35 (1) 205.254.211.179 (2) 205.254.211.254 (3) 205.254.211.254 192.168.99.254 (4) 192.168.99.35 (5) --- 192.168.99.254 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.238/0.238/0.238/0.000 ms

1	As the packet passes through the IP stack on tristan, before hitting the Ethernet, tristan adds its IP to the list of IPs in the option field in the header.
2	This is masq-gw's public IP address.
3	Our intended destination! (Anybody know why there are two entries in the record route output?)
4	This is masq-gw's private IP address.
5	And finally, tristan will add its IP to the option field in the header of the IP packet just before the packet reaches the calling ping program.

By testing reachability of the local network 192.168.99.0/24 and an IP address outside our local network, we have verified the basic elements of IP connectivity.

To summarize this section, we have:

• identified the IP address, network address and netmask in use on tristan using the tools ifconfig and route
• verified that tristan can reach its default gateway
• tested that packets bound for destinations outside our local network reach the intended destination and return

1.2.3. Static Routes to Networks

Static routes instruct the kernel to route packets for a known destination host or network to a router or gateway different from the default gateway. In the example network, the desktop machine tristan would need a static route to reach hosts in the 192.168.98.0/24 network. Note that the branch office network is reachable over an ISDN line. The ISDN router's IP in tristan's network is 192.168.99.1. This means that there are two gateways in the example desktop network, one connected to a small branch office network, and the other connected to the Internet.

Without a static route to the branch office network, tristan would use masq-gw as the gateway, which is not the most efficient path for packets bound for morgan. Let's examine why a static route would be better here.

If tristan generates a packet bound for morgan and sends the packet to the default gateway, masq-gw will forward the packet to isdn-router as well as generate an ICMP redirect message to tristan. This ICMP redirect message tells tristan to send future packets with a destination address of 192.168.98.82 (morgan) directly to isdn-router. For a fuller discussion of ICMP redirect, see Section 4.10.2, "ICMP Redirects and Routing".

The absence of a static route has caused two extra packets to be generated on the Ethernet for no benefit. Not only that, but tristan will eventually expire the temporary route entry ^[3] for 192.168.98.82, which means that subsequent packets bound for morgan will repeat this process ^[4].

To solve this problem, add a static route to tristan's routing table. Below is a modified routing table (see Section 1.3, "Changing IP Addresses and Routes" to learn how to change the routing table).

Example 1.4. Sample routing table with a static route

[root@tristan]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.98.0 192.168.99.1 255.255.255.0 UG 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.99.254 0.0.0.0 UG 0 0 0 eth0

According to this routing table, any packets with a destination address in the 192.168.98.0/24 network will be routed to the gateway 192.168.99.1 instead of the default gateway. This will prevent unnecessary ICMP redirect messages.

These are the basic tools for inspecting the IP address and the routes on a linux machine. Understanding the output of these tools will help you understand how machines fit into simple networks, and will be a base on which you can build an understanding of more complex networks.

---

^[1] For BSD and UNIX users, the idiom netstat -rn may be more familiar than the common route -n on a linux machine. Both of these commands provide the same basic information although the formatting is a bit different. For a fuller discussion of these, see either Section G.4, "netstat" or Section D.1, "route". For access to all of the routing features of the linux kernel, use ip route instead.

^[2] An incorrect broadcast address often highlights a mismatch of the configured IP address and netmask on an interface. If in doubt, be sure to use an IP calculator to set the correct netmask and broadcast addresses.

^[3] If the machine is a linux machine, then the temporary route entry is stored in the routing cache. Consult Section 4.7, "Routing Cache" for more information on the routing cache.

^[4] It is quite reasonable to ignore ICMP redirect messages from unknown hosts on the Internet, but ICMP redirect messages on a LAN indicate that a host has mismatched netmasks or missing static routes.

1.3. Changing IP Addresses and Routes

This section introduces changing the IP address on an interface, changing the default gateway, and adding and removing a static route. With the knowledge of ifconfig and route output it's a small step to learn how to change IP configuration with these same tools.

1.3.1. Changing the IP on a machine

For a practical example, let's say that the branch office server, morgan, needs to visit the main office for some hardware maintenance. Since the services on the machine are not in use, it's a convenient time to fetch some software updates, after configuring the machine to join the LAN.

Once the machine is booted and connected to the Ethernet, it's ready for IP reconfiguration. In order to join an IP network, the following information is required. Refer to the network map and appendix to gather the required information below.

• An unused IP address (Use 192.168.99.14.)
• netmask (What's your guess?)
• IP address of the default gateway (What's your guess?)
• network address ^[5] (What's your guess?)
• The IP address of a name resolver. (Use the IP of the default gateway here ^[6]. )

Example 1.5. ifconfig and route output before the change

[root@morgan]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:80:C8:F8:4A:53 inet addr:192.168.98.82 Bcast:192.168.98.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:9 Base address:0x5000 [root@morgan]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.98.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.98.254 0.0.0.0 UG 0 0 0 eth0

The process of readdressing for the new network involves three steps. It is clear in Example 1.5, "ifconfig and route output before the change", that morgan is configured for a different network than the main office desktop network. First, the active interface must be brought down, then a new address must be configured on the interface and brought up, and finally a new default route must be added. If the networking configuration is correct and the process is successful, the machine should be able to connect to local and non-local destinations.

Example 1.6. Bringing down a network interface with ifconfig

[root@morgan]# ifconfig eth0 down

This is a fast way to stop networking on a single-homed machine such as a server or workstation. On multi-homed hosts, other interfaces on the machine would be unaffected by this command. This method of bringing down an interface has some serious side effects, which should be understood. Here is a summary of the side effects of bringing down an interface.

Side effects of bringing down an interface with ifconfig

• all IP addresses on the specified interface are deactivated and removed
• any connections established to or from IPs on the specified interface are broken ^[7]
• all routes to any destinations through the specified interface are removed from the routing tables
• the link layer device is deactivated

The next step, bringing up the interface, requires the new networking configuration information. It's a good habit to check the interface after configuration to verify settings.

Example 1.7. Bringing up an Ethernet interface with ifconfig

[root@morgan]# ifconfig eth0 192.168.99.14 netmask 255.255.255.0 up [root@morgan]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:80:C8:F8:4A:53 inet addr:192.168.99.14 Bcast:192.168.99.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:9 Base address:0x5000

The second call to ifconfig allows verification of the IP addressing information. The currently configured IP address on eth0 is 192.168.99.14. Bringing up an interface also has a small set of side effects.

Side effects of bringing up an interface

• the link layer device is activated
• the requested IP address is assigned to the specified interface
• all local, network, and broadcast routes implied by the IP configuration are added to the routing tables

Use ping to verify the reachability of other locally connected hosts or skip directly to setting the default gateway.

1.3.2. Setting the Default Route

It should come as no surprise to a close reader (hint), that the default route was removed at the execution of ifconfig eth0 down. The crucial final step is configuring the default route.

Example 1.8. Adding a default route with route

[root@morgan]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo [root@morgan]# route add default gw 192.168.99.254 [root@morgan]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.99.254 0.0.0.0 UG 0 0 0 eth0

The routing table on morgan should look exactly like the initial routing table on tristan. Compare the routing tables in Example 1.1, "Sample ifconfig output" and Example 1.8, "Adding a default route with route".

These changes to the routing table on morgan will stay in effect until they are manually changed, the network is restarted, or the machine reboots. With knowledge of the addressing scheme of a network, and the use of ifconfig and route it's simple to readdress a machine on just about any Ethernet you can attach to. The benefits of familiarity with these commands extend to non-Ethernet IP networks as well, because these commands operate on the IP layer, independent of the link layer.

1.3.3. Adding and removing a static route

Now that morgan has joined the LAN at the main office and can reach the Internet, a static route to the branch office would be convenient for accessing resources on that network.

A static route is any route entered into a routing table which specifies at least a destination address and a gateway or device. Static routes are special instructions regarding the path a packet should take to reach a destination and are usually used to specify reachability of a destination through a router other than the default gateway.

As we saw above, in Section 1.2.3, "Static Routes to Networks", a static route provides a specific route to a known destination. There are several pieces of information we need to know in order to be able to add a static route.

• the address of the destination (192.168.98.0)
• the netmask of the destination (255.255.255.0)
  • EITHER the IP address of the router through which the destination (192.168.99.1) is reachable
  • OR the name of the link layer device to which the destination is directly connected

Example 1.9. Adding a static route with route

[root@morgan]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.99.254 0.0.0.0 UG 0 0 0 eth0 [root@morgan]# route add -net 192.168.98.0 netmask 255.255.255.0 gw 192.168.99.1 [root@morgan]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.98.0 192.168.99.1 255.255.255.0 UG 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.99.254 0.0.0.0 UG 0 0 0 eth0

Example 1.9, "Adding a static route with route" shows how to add a static route to the 192.168.98.0/24 network. In order to test the reachability of the remote network, ping any machine on the 192.168.98.0/24 network. Routers are usually a good choice, since they rarely have packet filters and are usually alive.

Because a more specific route is always chosen over a less specific route, it is even possible to support host routes. These are routes for destinations which are single IP addresses. This can be accomplished with a manually added static route as below.

Example 1.10. Removing a static network route and adding a static host route

[root@morgan]# route del -net 192.168.98.0 netmask 255.255.255.0 gw 192.168.99.1 [root@morgan]# route add -net 192.168.98.42 netmask 255.255.255.255 gw 192.168.99.1 [root@morgan]# route add -host 192.168.98.42 gw 192.168.99.1 SIOCADDRT: File exists [root@morgan]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.98.42 192.168.99.1 255.255.255.255 UGH 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.99.254 0.0.0.0 UG 0 0 0 eth0

This should serve as an illustration that there is no difference to the kernel in selecting a route between a host route and a network route with a host netmask. If this is a surprise or is at all confusing, review the use of netmasks in IP networking. Some collected links on general IP networking are available in Section I.1.3, "General IP Networking Resources".

---

^[5] The network address can be calculated from the IP address and netmask. Refer to Section H.1, "ipcalc and other IP addressing calculators". Especially handy is the variable length subnet mask RFC, RFC 1878.

^[6] Many networks are configured with the name resolution services on a publicly connected host. See Section 12.6, "DNS Troubleshooting".

^[7] It is possible for a linux box which meets the following three criteria to maintain connections and provide services without having the service IP configured on an interface. It must be functioning as a router, be configured to support non-local binding and be in the route path of the client machine. This is an uncommon need, frequently accomplished by the use of transparent proxying software.

14.4. Configuring Static Routes

Routing will be configured on routing devices, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients. However, if static routes are required they can be configured for each interface. This can be useful if you have multiple interfaces in different subnets. Use the route command to display the IP routing table.

Static route configuration is stored in a /etc/sysconfig/network-scripts/route-interface file. For example, static routes for the eth0 interface would be stored in the /etc/sysconfig/network-scripts/route-eth0 file. The route-interface file has two formats: IP command arguments and network/netmask directives.

IP Command Arguments Format

Define a default gateway on the first line. This is only required if the default gateway is not set via DHCP:

default X.X.X.X dev interface

X.X.X.X is the IP address of the default gateway. The interface is the interface that is connected to, or can reach, the default gateway.

Define a static route. Each line is parsed as an individual route:

X.X.X.X/X via X.X.X.X dev interface

X.X.X.X/X is the network number and netmask for the static route. X.X.X.X and interface are the IP address and interface for the default gateway respectively. The X.X.X.X address does not have to be the default gateway IP address. In most cases, X.X.X.X will be an IP address in a different subnet, and interface will be the interface that is connected to, or can reach, that subnet. Add as many static routes as required.

The following is a sample route-eth0 file using the IP command arguments format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks:

default 192.168.0.1 dev eth0
10.10.10.0/24 via 192.168.0.1 dev eth0
172.16.1.0/24 via 192.168.0.1 dev eth0

Static routes should only be configured for other subnets. The above example is not necessary, since packets going to the 10.10.10.0/24 and 172.16.1.0/24 networks will use the default gateway anyway. Below is an example of setting static routes to a different subnet, on a machine in a 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:

10.10.10.0/24 via 10.10.10.1 dev eth1

Duplicate Default Gateways

If the default gateway is already assigned from DHCP, the IP command arguments format can cause one of two errors during start-up, or when bringing up an interface from the down state using the ifup command: "RTNETLINK answers: File exists" or 'Error: either "to" is a duplicate, or "X.X.X.X" is a garbage.', where X.X.X.X is the gateway, or a different IP address. These errors can also occur if you have another route to another network using the default gateway. Both of these errors are safe to ignore.

Network/Netmask Directives Format

You can also use the network/netmask directives format for route-interface files. The following is a template for the network/netmask format, with instructions following afterwards:

ADDRESS0=X.X.X.X
NETMASK0=X.X.X.X
GATEWAY0=X.X.X.X

• ADDRESS0=X.X.X.X is the network number for the static route.
• NETMASK0=X.X.X.X is the netmask for the network number defined with ADDRESS0=X.X.X.X.
• GATEWAY0=X.X.X.X is the default gateway, or an IP address that can be used to reach ADDRESS0=X.X.X.X

The following is a sample route-eth0 file using the network/netmask directives format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks. However, as mentioned before, this example is not necessary as the 10.10.10.0/24 and 172.16.1.0/24 networks would use the default gateway anyway:

ADDRESS0=10.10.10.0
NETMASK0=255.255.255.0
GATEWAY0=192.168.0.1
ADDRESS1=172.16.1.0
NETMASK1=255.255.255.0
GATEWAY1=192.168.0.1

Subsequent static routes must be numbered sequentially, and must not skip any values. For example, ADDRESS0, ADDRESS1, ADDRESS2, and so on.

Below is an example of setting static routes to a different subnet, on a machine in the 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:

ADDRESS0=10.10.10.0
NETMASK0=255.255.255.0
GATEWAY0=10.10.10.1

DHCP should assign these settings automatically, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients.

14.5. Routing in SUSE LINUX

The routing table is set up in SUSE LINUX via the configuration files /etc/sysconfig/network/routes and /etc/sysconfig/network/ifroute-*. All the static routes required by the various system tasks can be entered in the /etc/sysconfig/network/routes file: routes to a host, routes to a host via a gateway, and routes to a network. For each interface that needs individual routing, define an additional configuration file: /etc/sysconfig/network/ifroute-*. Replace * with the name of the interface. The entries in the routing configuration files look like this:

DESTINATION           GATEWAY NETMASK   INTERFACE [ TYPE ] [ OPTIONS ]
DESTINATION           GATEWAY PREFIXLEN INTERFACE [ TYPE ] [ OPTIONS ]
DESTINATION/PREFIXLEN GATEWAY -         INTERFACE [ TYPE ] [ OPTIONS ]

To omit GATEWAY, NETMASK, PREFIXLEN, or INTERFACE, write - instead. The entries TYPE and OPTIONS may just be omitted.

• The route's destination is in the first column. This column may contain the IP address of a network or host or, in the case of reachable name servers, the fully qualified network or host name.
• The second column contains the default gateway or a gateway through which a host or a network can be accessed.
• The third column contains the netmask for networks or hosts behind a gateway. The mask is 255.255.255.255, for example, for a host behind a gateway.
• The last column is only relevant for networks connected to the local host such as loopback, ethernet, ISDN, PPP, and dummy device. The device name must be entered here.

The following scripts in the directory /etc/sysconfig/network/scripts/ assist with the handling of routes:

ifup-route

for setting up a route

ifdown-route

for disabling a route

ifstatus-route

for checking the status of the routes

Recommended Links

Softpanorama Recommended

Top articles

Sites

I good and reasonable up-to-date description of Linux routing can be found at Guide to IP Layer Network Administration with Linux by Martin A. Brown. This probably the best Internet available guide I have found

• Guide to IP Layer Network Administration with Linux
• Understanding routing tables
• Gateways and Routes FreeBSD Handbook
• Static routing - Wikipedia, the free encyclopedia
  • Routing
  • Packet forwarding
• Null route - Wikipedia, the free encyclopedia Typically used for preventing routing loops. See also Use a Static Route to the Null0 Interface for Loop Prevention [IP Routed Protocols] - Cisco Systems
• [Chapter 7] 7.3 Building a Static Routing Table
• Internetworking Technology Handbook - Routing Basics - Cisco Systems
• Static Routes in the Cisco IOS
• Configure Static Routes In Debian or Red Hat Enterprise Linux
• Configuring a Gateway of Last Resort Using IP Commands - Cisco Systems
• RFC 1397 - Default Route Advertisement In BGP2 and BGP3 Version of ...

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019