Chapter 10
SuSE's scheme of network configuration
|
|
|
| |
|
 |
| In this chapter: |
| |
|
| |
 |
Understanding SuSE's method for configuring networks
|
|
Setting up regular and virtual interfaces
|
|
Learning about the dummy device
|
|
Setting up static routing
|
|
Understanding ICMP redirects
|
|
| |
|
|
| |
Now that we've reviewed how TCP/IP works in general, we can move on to
give you an understanding of how to set it up in SuSE Linux. Although
YaST has forms to define arbitrary numbers of network interfaces,
routing must be set up manually by editing the file
/etc/route.conf. The SuSE manual covers how YaST performs
setting up network interfaces, so we review
/etc/rc.config, which is where YaST stores the setup, and
show you how to can modify these settings manually.
|
| 10.1 | Interface configuration |
| |
A network interface is any device that connects a machine to
network. The most popular interfaces are ethernet cards and
modems. Linux supports networking over many devices, including
parallel lines (PLIP -- Parallel Line IP), serial lines (PPP, SLIP),
Arcnet, token ring, and ATM (Asynchronous Transfer Mode). Most of
these devices are configured in the same way. However, a distinction
is made between point-to-point connections and regular networks.
Point-to-point connections are used to connect two machines -- no
more, no less. Examples of point-to-point connections are PPP, PLIP,
and SLIP (Serial Line IP). PPP is now the most common form of
point-to-point. Point-to-point is unique because there is only one
host to send packages on the wire. You don't need broadcasting, and
some of the IP headers are useless in this case.
SuSE stores the configuration of all network interfaces in
/etc/rc.config. It doesn't make any difference whether
these settings are created by YaST or added manually. YaST can
accept manual changes and YaST settings can be changed by editing
this file.
The first important variable in /etc/rc.config is
NETCONFIG. It contains a list of suffixes. All other
network settings are per device variables, where all settings
referencing one device have the same suffix. Only device variables
with suffixes listed in NETCONFIG will be set up by the
rc-scripts. This allows it to switch interfaces on and off very
easily, without losing their configuration, even when they are not
active. The suffixes normally have the format
_number, where number
represents an arbitrary number. YaST starts with zero and counts
upward. You may also can start with 100 and count backwards, or use
letters. It doesn't make a difference.
The most important thing is that all settings for each interface have
the same suffix. Each interface has to have an IP address. This
address is stored in IPADDR_suffix. Then
you need a device name in
NETDEV_suffix. This can be
eth0 for an ethernet card, plip0 for a PLIP
connection or any other kind of network device recognized by the
kernel. The last interface specific setting is the parameter line for
ifconfig. This is specified in
IFCONFIG_suffix. The listing that
follows shows the settings that would probably be found on Router A/B
in Figure 9-2:
|
| | #
# networking
#
# number of network cards: "_0" for one, "_0 _1 _2 _3" for four cards
#
NETCONFIG="_0 _1"
#
# IP Adresses
#
IPADDR_0="192.168.0.0"
IPADDR_1="192.168.0.130"
#
# network device names (e.g. "eth0")
#
NETDEV_0="eth0"
NETDEV_1="eth1"
#
# parameters for ifconfig, if you put "bootp" into it, bootp will
# be used to configure it
# sample entry for ethernet:
# IFCONFIG_0="192.168.81.38 broadcast 192.168.81.63 netmask 255.255.255.224"
#
IFCONFIG_0="192.168.0.0 broadcast 192.168.0.127 netmask 255.255.255.128"
IFCONFIG_1="192.168.0.130 broadcast 192.168.0.255 netmask 255.255.255.128"
|
| |
You see that two suffixes are listed in NETCONFIG, and
these suffixes are used to specify the IP address, interface and
ifconfig settings. The suffix scheme is very useful to
temporarily disable or change settings. Just remove the suffix for the
interface you want to disable from the list, and the rc scripts will
ignore these settings. In YaST, this is done by toggling the active
flag for an interface. Although the workings of the IP address and the
interface are fairly obvious, the ifconfig parameters
require some explanation.
The command ifconfig is used to configure a network
interface. In its simplest form, it uses the device name, the IP
address, network mask, and broadcast address as parameters. You can
use it with fewer parameters, but you may find that the used default
values result in an incorrect configuration.
Taking the preceding example, the resulting ifconfig call
for the _0 device would be as follows:
|
| | # /bin/ifconfig eth0 192.168.0.0 broadcast 192.168.0.127 netmask80 255.255.255.12881
|
| |
Point-to-point connections don't require a netmask or a broadcast
address, only the address of the point-to-point partner. To set up
this kind of connection, you would use something like this:
|
| | # /sbin/ifconfig plip1 192.168.14.3 pointopoint 192.168.34.9
|
| |
This will set up a PLIP connection, using the device
plip1 (usually the first parallel port) from your
machine with the IP address 192.168.14.3 to another machine with IP
address 192.168.34.9.
Other settings you may want to specify include the Maximum Transfer
Unit (MTU) of the interface, its metric or hardware values of the
network card to use. Refer to ifconfig(8) to get the88 exact syntax
for those values and any additional settings that can be made using
ifconfig.
|
| 10.2 | Virtual interfaces |
| |
So far, we've talked only about real (meaning actual or physical)
network interfaces. Linux provides support for virtual interfaces as
well. The fact is, most people don't need virtual interfaces. But if
you are running a server that acts as host for Web or ftp sites, and
you want to host more than one server for a single service (for
example, a multi-homes server), you may want to think about using
virtual interfaces.
A virtual interface involves assigning more than one IP address to a
real interface. This concept is also known as aliasing interfaces. You
simply take one existing interface (which has to be real) and let it
"listen" to additional IP addresses. This way, you can configure your
Web server and/or ftp server to distinguish between traffic directed
to these different IPs and point the request to separate document
trees, depending on the IP address the request went to.
In Linux, virtual interfaces are specified by adding a colon
(:) and an increasing number to the device name of the
real interface. For example, if you have the device eth0
and you'd like to add more addresses to this device, you would use
eth0:1 for the second address, eth0:2 for
the third, and so on. Nothing else is needed. You can use these
devices just as you'd use any real device. Of course, the primary
concern is that you must set up the real device (in this case, eth0)
before setting up the virtual interfaces.
We use the example from the previous section again, but with a twist:
this time, the second interface (which used to be eth1)
is a virtual interface and the device name changes.
|
| | #
# network device names (e.g. "eth0")
#
NETDEV_0="eth0"
NETDEV_1="eth0:1"
|
| |
Virtual interfaces are also useful if your network is set up in such a
way that different subnets114 share one network segment, and you like
to have your host be part of both (or all) subnets. The conventional
method requires that you have a separate ethernet card for each subnet
you want to participate, even if they run on the same wire. With the
virtual interface option, you can configure one card to listen to each
subnet by assigning it one address for each subnet. It's even possible
to set this up for routing, or to masquerade from one subnet to the
other so that hosts that don't support virtual interfaces can
communicate to the host of another subnet through the Linux
machine.
|
| 10.3 | The dummy interface |
| |
The dummy device is a feature particular to SuSE Linux. This network
device is not an actual, physical device, nor is it a virtual device
in the sense we defined a moment ago. It is virtual, but is not
related to any physical device. Yet it has all the properties of a
physical device, and for an application, there is no difference
between the dummy device and a real device. The intention of the
dummy device is to work around problems that can happen when the
machine doesn't have a network device.
Traditionally, the loopback ( lo) device works to prevent these errors
and acts as a local device on which everyone can rely. Some
applications seem to have problems using the lo device and don't work
without the presence of a real network device. The dummy device works
perfectly for these applications, which is why it is set up by default
on SuSE Linux installations.
If you have a real, permanent network connection (as opposed to
temporary connections, such as a PPP dial up) you don't need the dummy
device and you don't need to activate it. Whether the dummy device
will be set up or not depends on the value of
SETUPDUMMYDEV in the file /etc/rc.config. If
this variable is set to yes, the dummy device dummy0 will
be created. The IP address listed in IPADDR_0 will be
used for the dummy device. Remember to enter an IP address here if
you need the dummy device.
|
| 10.4 | Setting up static routing |
| |
We've discussed network configurations and what routing is used
for. Now you're ready for setting up routing in SuSE Linux. YaST
allows you to specify a default router in the format that you used to
configure an interface. This is fine for a leaf node in a simple
network. However, if the network has more than one router, or you
actually want to set up a router, you'll need more than this. You
need to specify a routing table. Even if YaST doesn't provide a way to
set up a routing table, the SuSE Linux distribution has a fairly
easy way to do this.
The file /etc/route.conf contains a routing table, which
will be set up by the script /sbin/init.d/route whenever a
networking runlevel (by default runlevels two and three) is reached.
Following is a very simple routing table such as is found in
/etc/route.conf.
|
| | #
# /etc/route.conf for hosts in 'Network A'
#
# In this file you can configure your static routing...
#
# This file is read by /sbin/init.d/route.
#
#
# Destination Dummy/Gateway Netmask Device
#
192.168.0.0 0.0.0.0 255.255.255.128 eth0
default 192.168.0.1
|
| |
This routing table is typical for a simple network host. It could be
any host in Network A from Figure 9-2. As you can see,
comment lines start with a hash sign (#) in the first
column. Comment lines and empty lines are ignored when the route
script sets up the kernel routing table.
The other lines represent routing table entries. The format is very
close to the output of the route command, as we demonstrate in
Chapter 9.
The first column specifies a destination. This can be either a network
address, a host address, or the string default for the default
gateway. Whether the given address is a host or a network is
determined by the netmask given in the third column. The network mask
for a host is always 255.255.255.255. Everything else specifies a
network route. Network route means a route to a network, whereas a
host route is a route to a single host. The second column gives either
the IP address of the router, which should be used to reach the
destination given in the first column, or the special value 0.0.0.0,
which means that all traffic headed to the destination will be given
to1 the device specified in the last column. If a gateway address is
given, the device specification is optional.
To clearly illustrate this, we refer back to Figure 9-2
and have a look at the entries of the routing tables of the hosts
and routers in this network.
|
| 10.4.1 | Hosts in Network A |
| |
These hosts use the table shown above. They can reach the subnet
192.168.0.0/25 directly over their ethernet card, and send
everything else to Router A/B at 192.168.0.1.
|
| 10.4.2 | Hosts in Network B |
| |
Here we have two routers, Router A/B for traffic to Network A, and
Router B/C for everything else:
|
| | #
# /etc/route.conf for hosts in 'Network B'
#
# Destination Dummy/Gateway Netmask Device
#
# route to local subnet 'Network B'
192.168.0.128 0.0.0.0 255.255.255.128 eth0
# route to 'Network A'
192.168.0.0 192.168.0.130 255.255.255.128
# default gateway is 'Router B/C'
default 192.168.0.129
|
| |
This example illustrates a very important point. All router addresses
must be within a network that can be reached directly through an
interface of this machine. This seems to be pretty obvious, because
how should a host send packages to a router if it is not in the same
network segment? And yet, this is a common mistake that is made when
one is setting up routing tables. The address used for Router A/B
must be 192.168.0.130 and not 192.168.0.1, because the latter one
is not part of this subnet.
|
| 10.4.3 | Hosts in Network C |
| |
Same situation as in Network A. One router gets all the traffic not
destined to the local subnet:
|
| | #
# /etc/route.conf for hosts in 'Network C'
#
# Destination Dummy/Gateway Netmask Device
#
# route to local subnet 'Network C'
192.168.1.0 0.0.0.0 255.255.255.0 eth0
# default router is 'Router B/C'
default 192.168.1.1
|
| |
|
| 10.4.4 | Router A/B |
| |
This machine is directly connected to two subnets and forwards all
traffic destined to Router B/C:
|
| | #
# /etc/route.conf for 'Router A/B'
#
# Destination Dummy/Gateway Netmask Device
#
# route to 'Network A' (local)
192.168.0.0 0.0.0.0 255.255.255.128 eth0
# route to 'Network B' (local)
192.168.0.128 0.0.0.0 255.255.255.128 eth1
# default gateway is 'Router B/C'
default 192.168.0.129
|
| |
|
| 10.4.5 | Router B/C |
| |
This machine is your connection to the Internet. We assume that it
uses an ISDN link (which also is a point-to-point connection) to some
router located at the ISP. As we stated previously, this router has
the IP address 204.179.13.1. So besides setting up the routes for the
local environment, you need to set up a route to this machine and then
you can use this machine as the default gateway:
|
| | #
# /etc/route.conf for 'Router B/C'
#
# Destination Dummy/Gateway Netmask Device
#
# route to 'Network C' (local)
192.168.1.0 0.0.0.0 255.255.255.0 eth1
# route to 'Network B' (local)
192.168.0.128 0.0.0.0 255.255.255.128 eth0
# route to 'Network A' (via 'Router A/B')
192.168.0.0 192.168.0.130 255.255.255.128
# route to ISP router
204.179.13.1 0.0.0.0 255.255.255.255 isdn0
# default router is ISP's machine
default 204.179.13.1
|
| |
Again you can see that you first need a route to the default gateway
before you can use it as a hop to other hosts. Because the ISDN
connection is point-to-point, this route is a host route. The netmask
for a route to a single host is 255.255.255.255, which means that all
bits of the netmask are set. There are no bits left to distinguish
between different hosts in this address because it points to only
one machine.
The basic principle of routing is to forward packages not destined to
a local subnet to another router which knows how handle them. The
example shown doesn't reflect this strategy, that is, the hosts in
Network B could send all packages that don't go to machines in the
same subnet to Router B/C. This router knows that traffic for Network
A has to go to Router A/B. So why do you need the extra entry in the
routing table for Network A? Well, you don't really need it; the setup
would work without it. As soon as a host from Network B sends packages
for a host in Network A to Router B/C (you still know what's going
on?), it would get an ICMP redirect from Router B/C that tells it
to send those traffic directly to Router A/B.
|
| 10.5 | ICMP redirects |
| |
ICMP redirect messages represent one of the lowest level routing
protocols for simple redirects. Routers send them to hosts to inform
them about more efficient ways to reach a host rather than route them
over themselves. A host will allow this message and will store this
"hint" in a temporary table. It will send the next package directly to
the host given by the ICMP redirect. One can argue whether you should
use this intentionally in network setups like this. We say "no". When
you have the chance to set the routing tables up correctly, which
means including all the knowledge you have about the network in the
routing table, then you should do it. It avoids redirect messages and
minimizes the overhead on the wire. But on the other hand, nobody will
fire you for trying to keep the routing tables of regular hosts as
simple as possible. For this educational example, it makes sense to
show several kinds of constellations to discuss the referring
routing issues. If you are in the situation you, will have to decide
for yourself whether you want to use ICMP redirects or not.
However, the Linux kernel doesn't listen to ICMP redirects when it is
configured as router and not as host. So, be careful setting up
routing tables for routers. They have to be complete. No hints from
other hosts will be accepted and only the local routing table decides
where packages go.
|
|
| Summary: |
| |
SuSE stores its network configuration in two files. The interfaces are
set up in the global configuration file /etc/rc.config;
the routing table is stored in /etc/route.conf. The SuSE
scheme allows it to configure an arbitrary number of interfaces and
set them active or inactive as needed.
Static routing is set up by entering the routing table entries in
/etc/route.conf. The interface and routing information is
used by the rc-scripts responsible for the network setup each time
a network runlevel is entered or left.
|
|
