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.

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.

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:

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:

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.

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.

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:

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:

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:

Add the desired route statements to a startup file.

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:

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.

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.

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].

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".

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.

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").

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”.

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.

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].

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.

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.

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.

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.

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” 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.

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”.

[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.

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:

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:

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.

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:

FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
in our efforts to advance understanding of environmental, political,
human rights, economic, democracy, scientific, and social justice
issues, etc. We believe this constitutes a 'fair use' of any such
copyrighted material as provided for in section 107 of the US Copyright
Law. In accordance with Title 17 U.S.C. Section 107, the material on
this site is distributed without profit exclusivly for research and educational purposes. If you wish to use
copyrighted material from this site for purposes of your own that go
beyond 'fair use', you must obtain permission from the copyright owner.

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no
less then 90 days. Multiple types of probes increase this period.

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.

Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development
of this site and speed up access. In case softpanorama.org is down currently there are
two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.

Disclaimer:

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 author present and former employers, SDNP or any other organization the author may be associated with.We do not warrant the correctness
of the information provided or its fitness for any purpose.