Part Workbook 6. Network Configuration

Part Workbook 6.
Network Configuration
Table of Contents
1. Managing Network Interfaces ........................................................................................... 4
Discussion ................................................................................................................ 4
Network Manager .............................................................................................. 4
Red Hat Enterprise Linux as a Networking Machine ................................................ 5
Network Interface Cards (NICs) ........................................................................... 6
Network Interfaces ............................................................................................ 6
Examining Interfaces with ip addr ........................................................................ 6
Configuring Network Interfaces with ip ................................................................. 7
Interface Configuration Files: ifcfg-eth0 ................................................................ 8
Controlling Interfaces with ifup and ifdown ........................................................... 9
Configuring Interfaces as a DHCP Client ............................................................. 10
IP aliases ....................................................................................................... 11
Summary ........................................................................................................ 12
Examples ............................................................................................................... 13
Example 1. Configuring an Interface with ip addr ................................................... 13
Example 2. Configuring an Interface Configuration File ........................................... 14
Example 3. Configuring an Interface to use DHCP .................................................. 15
Online Exercises ...................................................................................................... 15
Specification ................................................................................................... 15
Deliverables .................................................................................................... 17
Cleaning up .................................................................................................... 17
Questions ............................................................................................................... 17
2. Basic IP Routing and Gateways ....................................................................................... 20
Discussion .............................................................................................................. 20
IP Networks ................................................................................................... 20
On the Horizon: Internet Protocol version 6 ("IPv6") .............................................. 21
Ethernet Hardware Addresses ............................................................................. 21
Communicating with Machines on the Local Network ............................................ 22
The ARP Cache ...................................................................................... 22
Communicating with Machines on Remote Networks ............................................. 23
The Routing Table ........................................................................................... 24
Using ip to Edit the Routing Table ..................................................................... 25
Defining a Default Gateway .............................................................................. 26
Examples ............................................................................................................... 26
Example 1. Adding a Default Gateway with the route Command ............................... 26
Example 2. Adding a Default Gateway to the Interface Configuration File ................... 27
Specification ................................................................................................... 27
Deliverables .................................................................................................... 28
Questions ............................................................................................................... 28
3. Configuring DNS Clients ................................................................................................ 31
Discussion .............................................................................................................. 31
Domain Name Service (DNS) ............................................................................ 31
The resolv Library ........................................................................................... 31
Static Lookups: /etc/hosts .................................................................................. 31
What should be included in an /etc/hosts file? ............................................... 32
What should not be included in an /etc/hosts file? .......................................... 32
Dynamic Lookups: /etc/resolv.conf ...................................................................... 33
Proxy Servers ................................................................................................. 34
Examples ............................................................................................................... 34
Example 1. Specifying a Nameserver ................................................................... 34
rha130-6.1-1
Copyright 2011, Red Hat Inc.
Network Configuration

Specification ................................................................................................... 35
Deliverables .................................................................................................... 35
Clean Up ....................................................................................................... 35
Questions ............................................................................................................... 36
4. Miscellaneous Network Settings ...................................................................................... 39
Discussion .............................................................................................................. 39
Miscellaneous Network Configuration ................................................................. 39
Assigning Hostnames ....................................................................................... 39
The hostname Command ........................................................................... 39
The /etc/sysconfig/network File .................................................................. 40
Linux Computers Don't Have Hostnames; IP Addresses do .............................. 41
Treating Network Configuration as a service ......................................................... 42
Enabling IP Forwarding in /etc/sysctl.conf ............................................................ 42
More about DHCP ........................................................................................... 43
Network Configuration with system-config-network-tui .......................................... 44
Now you Tell Us! ............................................................................................ 45
Examples ............................................................................................................... 45
Example 1. Setting a Machine's Hostname with hostname ........................................ 45
Example 2. Configuring a Machine's Hostname in /etc/sysconfig/network .................... 46
Example 3. Using system-config-network-tui to Configure a Machine to use DHCP....... 46
Example 4. Enabling IP Forwarding on a Router .................................................... 48
Specification ................................................................................................... 48
Deliverables .................................................................................................... 49
Cleaning Up ................................................................................................... 49
Questions ............................................................................................................... 49
5. Network Diagnostic Utilities ........................................................................................... 52
Discussion .............................................................................................................. 52
Getting Reacquainted with ping, host, and traceroute .............................................. 52
The ping command .................................................................................. 52
The host Command .................................................................................. 53
The traceroute Command .......................................................................... 53
Diagnosing Network Configuration Problems ........................................................ 54
Examining Network Activity with tcpdump .......................................................... 54
tcpdump Command Line Switches .............................................................. 55
tcpdump Filters ....................................................................................... 56
Examining Network Activity with wireshark ......................................................... 57
Capturing Network Traffic ........................................................................ 57
Browsing captured Packets ........................................................................ 58
Assembling a TCP stream ......................................................................... 58
Examples ............................................................................................................... 59
Example 1. Diagnosing Network Problems 1: No Interface ....................................... 59
Example 2. Diagnosing Network Problems 2: Bad Gateway ...................................... 60
Example 3. Diagnosing Network Problems 3: No DNS ............................................ 61
Specification ................................................................................................... 62
Deliverables .................................................................................................... 63
Questions ............................................................................................................... 64
rha130-6.1-1
Chapter 1. Managing Network

Interfaces
Key Concepts
Network devices are accessed using network interfaces.
Network interfaces can be configured directly using the ip command.
Red Hat Enterprise Linux provides the ifup and ifdown convenience scripts for managing interfaces.
The ifup and ifdown scripts rely on interface configuration files named /etc/sysconfig/
network-scripts/ifcfg-eth0, where eth0 might be replaced with another relevant interface
name.
The primary task behind configuring an interface is generating an appropriate interface configuration
file.
Discussion
Network Manager
While interfaces can be configured directly with the ip command, any such changes are dynamic, or stored
directly within the kernel. In order to preserve the configuration between reboots, the relevant information
(i.e., the IP address and its associated network mask) must be stored within the filesystem.
Beginning in Red Hat Enterprise Linux 6, the default method for storing, configuring, starting, and stopping
network interfaces is Network Manager. This program is also available in earlier versions and is the
ideal method for mobile clients such as laptops since it also scans for available wireless devices and can
automatically change networks as the user travels. It does have some limitations, however, in a server
environment which we will discuss later in this lesson.
To view the available networks and connect and disconnect to networks, (left) click the Network Manager
icon on the desktop panel. Sitting at a laptop in busy town center you may see many wireless networks
available. In the example below, only the "System eth0" network is visible and this system does not appear
to have a wireless adapter installed.
Figure 1.1. Enabling and Disabling Interfaces with Network Manager
To view the connection information or to edit connections and add new connections, right click on the
applet and select options from the menu. Below, our administrator selected Edit Connections... then choose
to edit the existing eth0 interface.
rha130-6.1-1
Managing Network Interfaces
Figure 1.2. Configuring Network Settings with Network Manager
This configuration utility should look familiar as we saw it during the installation lesson. Recall that we
modified the configuration to "Connect automatically". By default Network Manager does not configure
the network interface until the user logs into the system. This is not an acceptable solution for a server
which should be available to clients even if no users are logged in locally. The "Connect automatically"
option can also be thought of as the start "on boot". Looking at the bottom of the configuration screen,
there is an option "Available to all users". As the description implies, if the system is used by several
people, each can see the interface in the list of available networks. This action will also create an ifcfg
file which will be discussed below.
While most common settings can be configured with Network Manager, there are a number of advanced
network settings which require that we use other methods of configuring the interfaces. For example,
bonding, which is the process of using two adapters connected to the same network for failover or load
balancing, cannot be configured within Network Manager.
For the remainder of the this workbook, we will disable Network Manager and use more traditional Red
Hat Enterprise Linux configuration files. To disable Network Manager use the service and chkconfig
commands to turn off the NetworkManager service and turn on the network service.
[root@station root]# chkconfig NetworkManager off
[root@station root]# service NetworkManager stop
Red Hat Enterprise Linux as a Networking Machine

Linux has always had a reputation as a networking machine. Linux's support for networking includes a
robust collection of networking applications (both servers and clients), a flexible and stable networking
infrastructure, and an active development community.
Although networking is a large and complicated topic, the goal of this Workbook is fairly modest:
configure a Red Hat Enterprise Linux operating system to participate in an already existing network
infrastructure. At the simplest, this involves the following tasks.
Assign each network interface an appropriate IP address and network mask (netmask).
Configure a default gateway.
rha130-6.1-1
Configure one or more DNS nameservers.

We discuss these three steps in this Workbook's first three Lessons.
Network Interface Cards (NICs)

Networking is generally implemented through Network Interface Cards (commonly referred to as a NIC,
pronounced as a single word that rhymes with "thick"), which often connect to machines as PCI devices.
The Linux kernel should detect all connected NICs, and the lspci command can be used to determine
if a given PCI NIC has been detected by the kernel. In the following excerpt, two individual NICs are
recognized.
[root@station root]# lspci
...
00:1f.5 Multimedia audio controller: Intel Corp. 82801EB AC'97 Audio (rev 02)
01:00.0 VGA compatible controller: nVidia NV18 [GeForce4 MX 440 AGP 8x] (rev a2)
02:08.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
02:0c.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet (rev 02)
Network Interfaces
Unlike other devices, the Linux kernel does not allow users to access NICs "as a file". In other words,
there is no device node in the /dev directory which corresponds directly to a NIC, as there are entries
which correspond to harddrives or sound cards.
Instead, Linux (and Unix) accesses NICs through network interfaces. For every recognized NIC, the kernel
creates a network interface, with a name such as eth0 or tr1, where the letters refer to the type of underlying
data link technology, and the number is used to distinguish between multiple cards that might be detected.
For example, the two Ethernet NICs illustrated in the previous section would be represented with network
interfaces named eth0 and eth1, respectively.
The following table lists some of the common interface names Linux associates with various Data Link
technologies.
Table 1.1. Common Linux Interface Names

Name
Type
eth0
Ethernet
lo
The (virtual) loopback device
ppp0
Serial Line (usually a Modem), using the PPP protocol
tr0
Token Ring
fddi0
Fiber Optic
Examining Interfaces with ip addr

The ip addr command can be used to examine information about all currently recognized network
interfaces, as in the following example.
[root@station root]# ip addr
1:
lo: >LOOPBACK,UP,LOWER_UP< mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2:
eth0: >BROADCAST,MULTICAST,UP,LOWER_UP< mtu 1500 qdisc pfifo_fast state UP qlen 1000
rha130-6.1-1
link/ether 00:00:86:4d:f0:0c brd ff:ff:ff:ff:ff:ff

inet 192.168.0.3/24 brd 192.168.0.255 scope global eth0
inet6 fe80::ae00:86ff:fe4d:f00c/64 scope link
3:
eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 3c:4a:92:c8:c3:2d brd ff:ff:ff:ff:ff:ff
The interface lo, referred to as the loopback interface (or sometimes, less correctly, as the loopback
device), is a special virtual interface implemented by the Linux kernel. The loopback interface has
no associated hardware. Instead, network packets "transmitted" using the loopback interface are
instantly "received" using the same interface, without the packets ever reaching an actual network.
The loopback interface allows networking clients to connect to networking services which are
running on the same machine.
The interface eth0 is currently active, and has been configured with an IP address of 192.168.0.3
(more on this next).
The interface eth1, which has no associated IP address (and packet counts of zero for everything)
is currently inactive.
To view only a specific interface, use the show argument:
[root@station root]# ip addr show eth0
2: eth0: >BROADCAST,MULTICAST,UP,LOWER_UP< mtu 1500 qdisc pfifo_fast state UP qlen 1000
Configuring Network Interfaces with ip

System administrators are responsible for configuring interfaces with an appropriate networking identity,
such as an IP address and network mask. In Linux, this can be accomplished using the ip command. The
ip command uses the following general syntax.
ip [options] objects {command | help }
Objects include, among others, addr, link, and route. For the moment, we are only concerned with the
link and addr objects. The following tables contain some of the more common commands used with the
ip link set command.
Table 1.2. Common ip link set commands

Object Command
Use
up
Activate the interface.
down
Deactivate the interface.
mtu limit
Set the MTU (maximum transfer unit) for the interface to

limit.
vf mac addr
Set the hardware (i.e., MAC) address for the device to addr.
A number of commands and options are used to assign an IP address and optionally, a slash and decimal
number representing the network netmask or prefix.
ip addr add local address[/prefix] dev name
Do not be too concerned with all the options. Some will be discussed in the next lesson, some are provided
only to establish context for students with some networking experience. Instead, focus on the fact the the
ip command can be used to activate, deactivate, or assign an IP address to a given network interface.
rha130-6.1-1
Continuing the example from above, the following command would activate the currently inactive
interface eth1 and assign an IP address of 10.1.1.8 with a netmask of 255.0.0.0. Next, the ip addr show
eth1 command is used to examine the configuration of the interface eth1.
[root@station root]# ip addr add dev eth1 local 10.1.1.8/24 up
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 3c:4a:92:c8:c3:2d brd ff:ff:ff:ff:ff:ff
inet 10.1.1.8/24 scope global eth0
The machine is now configured to respond to the IP address 10.1.1.8 on interface eth1 (as well as
192.168.0.3 on interface eth0, and 127.0.0.1 on the loopback interface lo). A machine which is listening
to multiple (external) IP addresses is often referred to as a multihomed host.
The interface can be again deactivated with the down keyword.
[root@station root]# ip link dev eth1 set down
Interface Configuration Files: ifcfg-eth0

In many versions of Unix, the ip command (including any appropriate IP address) is hard coded into an
appropriate startup script (such as /etc/rc.d/rc.sysinit). Red Hat Enterprise Linux takes a more
general approach to configuring network interfaces which relies on configuration files found in the /etc/
sysconfig/network-scripts/ directory, with a name of the form ifcfg-interface.
Interface configuration files ("ifcfg" files for short) store all of the relevant information for configuring
an interface, using a shell variable assignment syntax. An ifcfg configuration file can be as simple as
the following, which assigns the IP address 10.1.1.3 with a netmask of 255.0.0.0 to the interface eth1.
[root@station root]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
IPADDR=10.1.1.3
NETMASK=255.0.0.0
In practice, they are usually a little more complicated, taking advantage of features related to the following
variables.
Table 1.3. Variables Relevant to Interface Configuration Files

Variable
Sample Values
Use
DEVICE
eth0
A required entry, which defines the interface for which this

file contains configuration information. Although required,
the entry is redundant, because the device name must also
be included in the filename of the file.
HWADDR
hardware
address
MAC If there are multiple adapters in the system, this entry will
be used to map the adapter to the specific logical interface
name. Without this entry, it is possible that the eth0 and eth1
interfaces will switch with each boot.
BOOTPROTOnone|static|dhcp
How the interface should receive its configuration

information. "static", which is the same as "none", and is
also the default, indicates that the configuration information
will be supplied by the local file. "dhcp" implies that
information will be supplied by a DHCP server whenever
the interface is activated. (More on this later).
IPADDR
The IP address to associate with the interface.
rha130-6.1-1
192.168.0.1
Variable
Sample Values
Use
NETMASK
255.255.255.0
The network mask to associate with the specified IP

address. The role of the network mask will be discussed in
more detail in the next lesson. In many situations, the line
is unnecessary, as the network mask can be automatically
generated from the IP address. When required, the
network mask would have to be supplied from a network
administrator along with the IP address. If this is the case,
the supplied network mask is configured with the NETMASK
variable.
ONBOOT
yes|no
Should the interface be started automatically as part of the

bootup process? If the answer is no, the interface would
need to be started manually by an administrator before it
can be used. The default is yes.
USERCTL
yes|no
Can normal users control the interface? By default, only the

root user may raise, lower, or otherwise configure network
interfaces. The default is no.
GATEWAY 192.168.0.254
Gateway to use for routing packets out of the local network.

See next lesson. The default is none.
NM_CONTROLLED
yes|no
Indicates if the Network Manager service should control

(yes) or ingnore (no) this interface.
A more complicated configuration file, which takes advantage of some of these additional parameters, is
seen below. Note that the order of the entries is irrelevant.
IPADDR="192.168.1.254"
NETMASK="255.255.255.0"
HWADDR="52:54:00:D9:D3:4C"
ONBOOT="no"
DEVICE="eth0"
USERCTL="no"
NM_CONTROLLED="no"
Unfortunately, full documentation for ifcfg files cannot be found in traditional man pages or info
pages. However, the text file /usr/share/doc/initscripts-*/sysconfig.txt contains
documentation on most files which can be found within the /etc/sysconfig directory, including these
files. (It's a big file. Try searching for the text ifcfg.)
Controlling Interfaces with ifup and ifdown

Once the relevant configuration files have been created, network interfaces can be easily managed with
two front-end commands, ifup and ifdown. Each of these commands expects a single interface name as an
argument. When ifup eth0 is executed, the ifup command searches for the relevant interface configuration
file (i.e., /etc/sysconfig/network-scripts/ifcfg-eth0), and then calls the ip command
with the appropriate information to configure the interface. Similarly, the ifdown eth0 command would
call the ip command to disable the same.
After creating an interface configuration file, management of the interface is as simple as ifup eth0 and
ifdown eth0, as illustrated in the following sequence of commands.
1: lo: >LOOPBACK,UP,LOWER_UP< mtu 16436 qdisc noqueue state UNKNOWN
rha130-6.1-1

2: eth0: >BROADCAST,MULTICAST,UP,LOWER_UP< mtu 1500 qdisc pfifo_fast
[root@station root]# ifdown eth0
[root@station root]# ifdown lo
[root@station root]# ifup lo
[root@station root]# ifup eth0
[root@station root]# ls /etc/sysconfig/network-scripts/ifcfg-*
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-lo
state UP qlen 1000
state UP qlen 1000
state UP qlen 1000
state UP qlen 1000
To begin with, both the interfaces eth0 and lo are configured and active.
After calling ifdown eth0, the eth0 interface is no longer active.
After calling ifdown lo, no interfaces are active.
After calling ifup lo and ifup eth1, the interfaces are again active, with configuration information
supplied from the relevant interface configuration files.
Configuring Interfaces as a DHCP Client

With DHCP (Dynamic Host Configuration Protocol), system administrators may coordinate the IP
configuration information for large number of machines from a central server. Machines which obtain
their configuration information from a DHCP server are referred to as DHCP clients. The IP configuration
information which DHCP clients receive may include the IP address (and its associated network mask)
which we have discussed, and other information (such as a gateway and nameserver) which we have not
yet addressed.
Machines which obtain their information using DHCP do not have a fixed IP address. Instead, they obtain
one dynamically every time the interface is raised (with ifup), and release it every time the interface is
lowered (with ifdown). While the mechanics of how a DHCP client communicates with a DHCP server
over the network before it has an IP address are interesting (the answer is with broadcast packets), one
need not understand the details to understand how to configure a machine to be a DHCP client.
In order to act as a DHCP client, the BOOTPROTO variable in an interface configuration file should be
set to dhcp, as in the following example.
rha130-6.1-1
10
[root@station130 root]# cat /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
Note that, in this case, the IPADDR and NETMASK variables should not be defined. (If they are, they will be
ignored). The following transcript demonstrates the activation of the interface which is being configured
by DHCP, and whose interface configuration file is shown above.
ip_tables: (C) 2000-2002 Netfilter core team
Determining IP information for eth0...
done.

Before the interface is raised, only the loopback device is active.

Unlike raising a statically defined interface (which happens without any output), the ifup command
displays a banner. The banner displays up until the ... when the DHCP query is broadcast ...
... and completes with the word done when the response is received from the DHCP server.
Failure to display the word "done" implies that your machine is having trouble contacting the DHCP
server. The problem is often as simple as the machine not being physically connected to the network.
After successful completion, the interface eth0 is configured with the IP address obtained from the
DHCP server.
IP aliases
The Linux kernel allows multiple IP addresses to be assigned to a single interface, using a concept called
IP aliasing. IP aliasing is conceptually easy. Every interface, in addition to its primary configuration, may
support up to 255 additional aliased configurations. The aliased interfaces are referred to by appending a
:number to the interface name, such as eth0:1, or eth0:218.
Aliased interfaces may be configured directly with the ip command. In the following example, the interface
eth0, with an IP address of 192.168.0.130, will be assigned two aliased address, 192.168.0.201, and
192.168.100.1.
rha130-6.1-1
11

[root@station root]# ip addr add dev eth0 label eth0:1 local 192.168.0.201/24 broadcast 192.168.0.255
[root@station root]# ip addr add dev eth0 label eth0:1 local 192.168.100.1/24 broadcast 192.168.100.255
What happens when the machine is rebooted (or if the interface eth0 is lowered)? The aliased interfaces
disappear. If an administrator wants IP aliases to be established as part of the normal startup process
(or every time the base interface is raised), interface configuration files can be created for the aliased
interfaces. The files have the same format as interface configuration files for normal configurations, with
the exception that the device (and the file name) refer to the aliased interface, as in the following example.
[root@station root]# ls /etc/sysconfig/network-scripts/ifcfg-*
/etc/sysconfig/network-scripts/ifcfg-eth0:1
/etc/sysconfig/network-scripts/ifcfg-eth0:2
[root@station root]# head /etc/sysconfig/network-scripts/ifcfg-eth0*
==> /etc/sysconfig/network-scripts/ifcfg-eth0 <==
# Intel Corp.|82540EM Gigabit Ethernet Controller (LOM)
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0D:60:2F:F5:9C
ONBOOT=yes
TYPE=Ethernet
==> /etc/sysconfig/network-scripts/ifcfg-eth0:1 <==
DEVICE=eth0:1
IPADDR=192.168.0.201
ONBOOT=yes
==> /etc/sysconfig/network-scripts/ifcfg-eth0:2 <==
DEVICE=eth0:2
IPADDR=192.168.100.1
ONBOOT=yes
Summary
In summary, we have learned the following about configuring network interfaces.
A summary of the configuration of all active interfaces can be obtained with the ip addr command.
The primary task in configuring a network interface is to generate an appropriately configured interface
configuration file, called /etc/sysconfig/network-scripts/ifcfg-name, where name is
replaced with the name of the interface.
A minimal interface configuration file for a statically defined interface could be as simple as the
following.
DEVICE=eth0
rha130-6.1-1
12
IPADDR=192.168.0.5
NETMASK=255.255.255.0
A minimal interface configuration file for an interface obtaining its configuration from a DHCP server
could be as simple as the following.
DEVICE=eth0
BOOTPROTO=dhcp
Once the appropriate configuration file has been created, the interface can be activated or deactivated
trivially with the ifup and ifdown commands, respectively.
A single network interface card can be assigned multiple IP addresses, using the concept of IP aliases.
Examples
Configuring an Interface with ip addr
An administrator has received the following network configuration information from the local network
administrator for a Red Hat Enterprise Linux machine whose network configuration was not performed
during a recent installation.
IP Address/Mask: 172.16.48.18/255.255.0.0
Gateway: 172.16.0.1
Name Server: 10.11.119.1
Hostname: nimbus.example.com
In order to test the configuration information, the administrator decides to first "try out" the IP address,
and see if the machine can ping the gateway. He first insures that the machine has an Ethernet card, by
listing all PCI devices.
[root@station root]# lspci
...
02:00.0 CardBus bridge: Texas Instruments: Unknown device ac46 (rev 01)
02:00.1 CardBus bridge: Texas Instruments: Unknown device ac46 (rev 01)
02:01.0 Ethernet controller: Intel Corp.: Unknown device 101e (rev 03)
In the output of the lspci command, he observes a single Ethernet device.

Next, the administrator checks to see if the network interface associated with the device has been
configured, by using ip addr show eth0 to list the configuration of the interface eth0 directly.
The administrator does not see an assigned IP address. Next, he assigns the IP address directly with the ip
command, observers the configuration, and attempts to ping the gateway.
[root@station root]# ip addr add dev eth0 local 172.16.48.18/24
inet 172.16.48.18/24 scope global eth0
[root@station root]# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=0 ttl=64 time=0.532 ms
CTRL+C
--- 172.16.0.1 ping statistics ---
rha130-6.1-1
13
2 packets transmitted, 2 received, 0% packet loss, time 1007ms

rtt min/avg/max/mdev = 0.132/0.332/0.532/0.200 ms, pipe 2
The administrator is now convinced that the IP address does not conflict with another machine's IP address,
and can contact the local gateway. He finishes by lowering the interface.
[root@station root]# ip addr del dev eth0 local 172.16.48.18/24
Configuring an Interface Configuration File

Convinced that the networking configuration information that he received is legitimate, the same
administrator from the previous exercise would now like to configure the interface eth0 with the same
information automatically upon bootup. He uses a simple text editor to create the following ifcfg-eth0
interface configuration file.
DEVICE=eth0
IPADDR=172.16.48.18
NETMASK=255.255.0.0
ONBOOT=yes
NM_CONTROLLED=no
Once completed, the administrator wants to verify the configuration file by raising and lowering the
interface with the ifup and ifdown network scripts. He first ensures the interface is not already active
with ip addr.
Seeing only the loopback interface with address, he proceeds.

The interface has been activated, and received the appropriate IP address.
The interface has now been lowered. The administrator now feels confident that, upon reboots, the network
interface will be appropriately configured and activated.
rha130-6.1-1
14
Configuring an Interface to use DHCP

A system administrator asks the local network administrator for the appropriate network configuration
information for a newly install Red Hat Enterprise Linux machine. "Oh, just use DHCP.", the network
administrator replies.
The system administrator creates the appropriate interface configuration files using a simple text editor.
[root@station root]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
She then confirms that the interface is not active, and raises the interface with the ifup command.
Determining IP information for eth0... done.
The administrator observers that the machine acquired an IP address of 192.168.0.52 and a network mask
of 255.255.255.0 from the DHCP server. She then takes a moment to thank the local network administrator
for having the foresight to set up DHCP.
Online Exercises
Lab Exercise
Objective: Configure an aliased interface with an IP address and Network Mask.
Estimated Time: 15 mins.
Specification
Note
This exercise uses IP aliasing to teach interface configuration skills while preserving your
station's current IP configuration, which is required for network access. All of your configuration
should occur on the aliased interfaces eth0:101 and eth0:102. The interface eth0 should remain
untouched.
rha130-6.1-1
15
When applying these skills in the "real world", seldom would you be operating on an aliased
interface, such as eth0:101, but the techniques map directly to a "real" interface, such as eth0.
The IP addresses 10.217.y.z and 10.218.y.z are arbitrarily chosen, and hopefully will not conflict with
your local network configuration. If a conflict does occur, the IP addresses may be changed in the grading
script found on the classroom server, and your students can be informed accordingly. Request help from
academy-docs@redhat.com for more information.
1. As a precaution, make a backup copy of the file /etc/sysconfig/network-scripts/ifcfgeth0, and store it in your home directory.
If, for some reason, your networking configuration is mangled as a result of this lab, you should
be able to restore the network settings by removing all files which begin ifcfg-eth0 from the /
etc/sysconfig/networking-scripts directory, restoring your backup file, and running the
following commands.
2. Using the ip addr command, observe your current IP address for the interface eth0. This lab will refer
to the IP address as w.x.y.z. As an example, the IP address 192.168.0.52 would have w=192, x=168,
y=0, and z=52.
3. To use IP aliasing we first need to turn off Network Manager. Use the chkconfig to disable the
NetworkManager service and the service to stop the service.
Next, to be sure everything else is configured correctly, stop then start your eth0 interface and check that
you still have the same IP addess. If you do not have the same address, ask your instructor for assistance.
4. Using the ip command, assign the interface eth0:101 an IP address 10.217.y.z and netmask of 255.0.0.0,
where y and z are determined from your base IP address. Leave the interface active. Do not create an
interface configuration file for this interface.
5. Generate an appropriate interface configuration file for the interface eth0:102, named /etc/sysconfig/
network-scripts/ifcfg-eth0:102, which assigns an IP address of 10.218.y.z to the interface, with a
network mask of 255.0.0.0. Use the following two commands, along with ip, to ensure that the interface
is configured properly. When you are finished, deactivate the interface with ifdown.
[root@station root]# ifup eth0:102
[root@station root]# ifdown eth0:102
If you have performed the lab correctly, you should be able to reproduce commands similar to the
following.
[root@station network-scripts]# ifup eth0:102
[root@station network-scripts]# ip addr
inet 10.217.0.52/8 brd 10.255.255.255 scope global eth0:101
inet 10.218.0.52/8 brd 10.255.255.255 scope global eth0:102
rha130-6.1-1
16

[root@station network-scripts]# ifdown eth0:101
usage: ifdown <device name>
[root@station network-scripts]# ifdown eth0:102
Deliverables
1.
1. Network Manager is no longer running on the system.
2. An active eth0:101 interface, with an IP address of 10.217.y.z and a netmask of 255.0.0.0,
where y and z are determined from the IP address of the interface eth0.
3. An interface configuration file for the interface eth0:102, which assigns an IP address of
10.218.y.z and a network mask of 255.0.0.0, where y and z are the same as above. The interface
should not be active when the lab is graded.
Cleaning up
After your lab has been graded, use the ip command to lower the interface eth0:101, the ifdown command
to lower the interface eth0:102, and remove the ifcfg-eth0:102 configuration file.
Questions
1.
Which of the following could be a Linux Ethernet network interface?

a.
lo
b.
eth2
c.
net0
d.
tr1
e.
neta
2.
What command is used to list all currently active network interfaces?

a.
ip addr
b.
lsnet
c.
shownet
d.
netview
e.
None of the above
3.
rha130-6.1-1
Which of the following is the device node for the first Ethernet interface?
a.
/dev/net0
b.
/dev/eth0
c.
/dev/net/eth0
d.
/dev/netdevice0
17
e.
4.
The question is misguided, because network interfaces do not have associated device nodes.
What IP address and network mask are conventionally assigned to the loopback interface?
a.
127.0.0.0/24
b.
127.0.0.1/16
c.
127.0.0.1/8
d.
127.0.0.0/16
e.
None of the above
5.
Within an interface configuration file, which of the following lines specify that the interface should
be configured using DHCP?
a.
DHCP=yes
b.
IPADDR=DHCP
c.
ONBOOT=DHCP
d.
DHCP=IPADDR
e.
BOOTPROTO=DHCP
6.
Which of the following command lines would configure the interface eth0 with an IP address of
192.168.0.5 and a network mask of 255.255.255.0?
a.
netcfg eth0 192.168.0.5/24
b.
ip addr add dev eth0 local 192.168.0.5/24
c.
ip addr dev eth0 addr 192.168.0.5 mask 255.255.255.0
d.
netcfg eth0 192.168.0.5 mask 255.255.255.0
e.
None of the above
Use the following contents of an interface configuration file to answer the next question.
DEVICE=eth0
ADDR=192.168.10.18
NETMASK=255.255.255.0
ONBOOT=yes
7.
What configuration error does the network interface file contain?

a.
The parameter ADDR should instead be IPADDR.
b.
The file does not contain the BOOTPROTO parameter.
c.
It should not contain the DEVICE line (the device is specified as part of the filename).
d.
The parameters and values should be separated by a space, not an equals sign.
e.
The file is properly configured.
When raising an interface with the ifup command, you received the following error.
rha130-6.1-1
18
[root@localhost root]# ifup eth0

Usage: ifup <device name>
8.
What is the most likely cause of the problem?

a.
The argument eth0 should have been wrapped in brackets.
b.
The user does not have permissions to raise the interface.
c.
The kernel does not detect an attached Ethernet card.
d.
The interface configuration file for the interface eth0 does not exist.
e.
The PATH environment variable is misconfigured.
9.
Where should the interface configuration file for the interface eth0 be located?
a.
/etc/network/eth0.cfg
b.
/etc/sysconfig/ifcfg-eth0
c.
/etc/netcfg/ifcfg-eth0
d.
/dev/eth0.cfg
e.
None of the above
10.
rha130-6.1-1
What command is used to raise a properly configured network interface?

a.
up
b.
netup
c.
ifup
d.
netstart
e.
None of the above
19
Chapter 2. Basic IP Routing and

Gateways
Key Concepts
A network mask is used to distinguish the network and host portions of an IP address.
Every Ethernet card has a built in MAC address, which is used to communicate between hosts on the
same IP network.
In order to communicate with hosts on external IP networks, a host must forward packets to a machine
acting as a router, also called a gateway.
The currently defined gateway can be examined, defined, or deleted with the ip route command.
Gateway definitions can be incorporated in the bootup process by adding the line GATEWAY=ipaddr
to either /etc/sysconfig/network or the relevant network interface configuration file.
Discussion
IP Networks
The IP protocol is based on individual networks of machines which are connected together using routers.
All of the machines connected to a single IP network have similar IP addresses, and are often connected
using the same network switch or hub.
Every IP address consists of two portions, a network portion, and a host portion. For any given address, a
network mask (often more simply called a netmask) must be used to distinguish the two. Every host on an
IP network shares the same network address (and therefore the same network mask).
Using the network mask to determine the network portion of an IP address can be complicated (unless
you know how to write numbers in binary, in which case it's easy). Fortunately, many IP networks are
defined using one of the three network masks which are the easiest to apply. These network masks are so
commonly used, networks which use them are referred to as "Class A", "Class B", and "Class C" networks.
The following table summarizes characteristics of these three classes of networks.
Table 2.1. Standard IP Networks

Class
Network Mask (/CIDR) Sample IP Address
Resulting
Sample
Network Address
Class A
255.0.0.0 (/8)
118.43.96.2
118.0.0.0/8
Class B
255.255.0.0 (/16)
155.34.95.101
155.34.0.0/16
Class C
255.255.255.0 (/24)
192.118.12.66
192.118.12.0/24
Subnetting
255.255.192.0 (/18)
172.56.174.40
172.56.128.0/18
As the table implies, when calculating the network address for Class A, B, and C networks, the network
mask serves to "zero out" latter portions of the IP address, with the network address consisting of the
leading portions which remain. For a class A network, with a network mask of 255.0.0.0, the network
address consists of only the first IP segment, followed by three 0's. For a class B network, with a mask of
rha130-6.1-1
20
Basic IP Routing and Gateways
255.255.0.0, the first two segments (followed by two zeros) are used, and for a class C network, the first
three segments (followed by one zero) are used.
The last entry of the table is provided as an example of a network mask that is more difficult to apply. Were
we to write all of the numbers in binary format, the very same principle would apply: the network mask
serves to "zero out" portions of the IP address which are not relevant to the network address. Unfortunately,
if we stick to decimal ("normal") numbers, the process is not trivial. IP networks which use use this type
of network mask are often referred to as subnets. For our purposes, we will only deal with Class A, Class
B, and Class C networks.
In all cases, if the network mask were to be written in binary, it would consist of a series of ones followed by
a series of zeros. As we saw with the ip, the notation of 255.255.255.0 did not appear in the output. Instead
the IP address was followed by a slash number, in this case /24. That number refers to the number of ones
in the network mask. The notation is called Classless Inter-Domain Routing (CIDR) and is pronounced
like the beverage "cider".
On the Horizon: Internet Protocol version 6 ("IPv6")

There currently exists two versions of the IP protocol. Version 4, commonly called IPv4, is the standard IP
protocol which has been in use for 20 years. When this workbook refers to the "IP protocol", it is referring
to IPv4. Linux also supports version 6, commonly called IPv6 or inet6.
An IPv6 address is a 128-bit number, expressed as eight colon-separated groups of four hexadecimal digits
(ranging from 0000 to ffff). The address is divided into a network part and a host part, but instead of a
network mask, they use the term prefix. The prefix ia always assumes to be /64; therefore the network part
is the first four groups and the host part is the last four groups. An organization might be assigned a "/48"
network, giving it the ability to have up to 65535 subnets, for example.
Because IPv6 address can be long, there are a couple of rules that can be used to condense them in use:
In any group, leading zeros can be suppressed: :0db8: can be written :db8: and :0000: can be written :0:
Only once in an address, one run of consecutive zeros can be replaced with ::. For example,
2001:db8:0:0:0:0:0:1 is better written as 2001:db8::1 and 0:0:0:0:0:0:0:1 is better written as ::1
IPv6 does not have a broadcast address, but many machines normally have a number of special multicast
addresses that are used only to talk to hosts on the local link. The special unicase address ::1 is the IPv6
version of the 127.0.01 "localhost" address.
Although you will see references to IPv6 in the output of many Linux networking commands, IPv6 is not
yet often used when networking general purpose machines, and will not be relevant to this workbook.
Ethernet Hardware Addresses

We will now focus our discussion to the most common data link layer technology, Ethernet. As the output
of the ip command implies, every Ethernet interface has not one, but two addresses: an IP address, and
a hardware (or "MAC") address.
1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:00:86:4D:F0:0C brd ff:ff:ff:ff:ff:ff
inet6 fe80::200:86ff:fe4d:f00c/64 scope link
The interface has a hardware address ("MAC address") of 00:00:86:4D:F0:0C.

The interface has an IP address of 192.168.0.51.
The automatically assigned IP version 6 address for the interface.
rha130-6.1-1
21
While IP addresses must be assigned by an administrator, the MAC address is part of the identity of the
NIC (Network Interface Card) itself. Every Ethernet card comes with a unique hardware address "burned
into" its on board firmware (thus the name "hardware address"), which uniquely identifies the card. In
the following sections, we will find that the IP address is used to route communications between any two
hosts (be they on the same or other networks), while the MAC address is used to communicate with hosts
on the same IP network.
Communicating with Machines on the Local Network

In order to discuss how machines on the same network communicate, consider the machine 192.168.10.51,
which would like to deliver information to 192.168.10.8. The process is similar to the following.
Figure 2.1. Communication between Hosts on a Local Network
1. First, the source machine (192.168.10.51) must determine if the destination machine is on the same
network. It does this by applying its own network mask (in this case, 255.255.255.0) to the destination
address (192.168.10.8), resulting in 192.168.10.0.
2. Determining that the source machine and the destination machine share the same network address, the
source machine must now determine the hardware address of the destination machine. It does this using
the low level ARP (Address Resolution Protocol) protocol, which only works on local networks. The
source machine sends out a broadcast packet to the local network which effectively says "who has
192.168.10.8? tell 192.168.10.51." This is known as an ARP Request.
Every host on the local network hears the request, but only the host that has the IP address 192.168.10.8
replies, providing the requesting host (192.168.10.51) it's MAC address: 00:10:A4:9B:A3:E7. Naturally
enough, this is known as an ARP Reply.
3. Now that the the sending host has both the IP address and MAC address of the destination machine, it
formulates a packet whose destination IP address is 192.168.10.8, and whose destination MAC address
is 00:10:A4:9B:A3:E7, and sends it on its way.
The ARP Cache

Notice that the protocol outlined above required the sending host 192.168.10.51 to "discover" the MAC
address of the receiving host, 192.168.10.8, using the ARP protocol. This is true of communication between
any two hosts on an Ethernet network.
In order to reduce time and effort, machines maintain a cache of IP address and MAC address pairings for
machines that they have discovered, known as the ARP Cache. A machine's ARP cache can be examined
with the command arp -a.
rha130-6.1-1
22
[root@station root]# arp -a

apu.example.com (192.168.10.8) at 00:10:A4:9B:A3:E7 [ether] on eth0
wiggum.example.com (192.168.10.75) at 00:80:AD:B0:52:05 [ether] on eth0
? (192.168.10.1) at 00:E0:1E:5D:9C:BB [ether] on eth0
selma.example.com (192.168.10.78) at 00:80:AD:B0:52:05 [ether] on eth0
ned.example.com (192.168.10.61) at 00:0A:27:B3:FC:54 [ether] on eth0
moe.example.com (192.168.10.58) at 00:A0:CC:65:53:45 [ether] on eth0
barney.example.com (192.168.10.202) at 00:03:93:26:49:15 [ether] on eth0
otto.example.com (192.168.10.202) at 00:03:93:26:49:15 [ether] on eth0
The arp command can also be used to manipulate the ARP cache (by adding or removing entries), but this
is seldom (if ever) necessary. Generally, ARP cache entries are stored for only a matter of minutes.
Communicating with Machines on Remote Networks

We now examine the case when our same source machine wants to communicate with www.redhat.com,
at an IP address of 66.187.232.50. As we trace the steps, we will discover that the sending machine must
enlist the services of a default gateway, or router. The first step, however, is identical to the previous case.
Figure 2.2. Communication between Hosts on Different Networks
1. The source machine (192.168.10.51) must first determine if the destination machine is on the same
network. By applying its own network mask (255.255.255.0) to the destination address (66.187.232.50),
the source machine determines that the resulting network address (66.187.232.0) differs from the local
network address (192.168.10.0).
2. Because the destination machine is not on the same network as the source machine, the two will not be
able to communicate directly. Instead, the source machine enlists the help of its default gateway. As part
of its networking configuration, the sending machine knows that its default gateway is 192.168.10.1.
If it has not done so already, it performs an ARP request to determine the gateway's MAC address.
(Otherwise, it just looks up the MAC address in its local ARP cache).
rha130-6.1-1
23
3. The source machine now formulates a packet, whose destination IP address is www.redhat.com
(66.187.232.50), but whose destination MAC address is the MAC address of the local gateway:
00:E0:1E:5D:9C:BB, and delivers it to the network.
4. Specified as the recipient by the the packet's destination MAC address, the local gateway examines
the packet, where it discovers some other machine's (namely, www.redhat.com's) IP address as the
IP destination address. Most machines in this case would discard the packet as a malformed packet.
Because it is acting as a router, however, the gateway machine implements a feature called IP
Forwarding, and repackages the packet, replacing the destination MAC address with that of the
"upstream" router. It then throws the packet to the upstream network.
5. The packet continues toward its final destination in a similar fashion, passing through a series of
IP networks interconnected by routers. In turn, each router along the route receives the packet, and
determines the appropriate "next hop" (i.e., the next router to which the packet should be forwarded).
As the packet precedes from IP network to IP network, it's destination MAC address will vary (always
referring to the next router), while the destination IP address remain unchanged, defining the final
destination for the packet. 1
Figure 2.3. Basic IP Routing
The Routing Table

Every Linux kernel maintains an internal table known as the routing table. The routing table is used to
determine which of the above approaches the kernel should follow for a given outgoing packet. The routing
table defines which network interfaces are associated with which local networks, and the identity of any
machine on the local network which should be used as a gateway to external networks.
Just as the IP address and netmask, the routing table can be examing with the ip.
[root@station root]# ip route
192.168.0.0/24 dev eth0 proto kernel scope link
default via 192.168.0.254 dev eth0 proto static
src 192.168.0.51
metric 2
Here the "dev eth0" portion of the first line indicates the local interface for traffic on the 192.168.0.0
network which does not need to be routed. All packets destined for another location are sent to the default
router of 192.168.0.254, again through the device eth0.
To better understand the routing table, we can also examine it using the traditional UNIX route command,
as illustrated in the following.
[root@station root]# route
Kernel IP routing table
Destination
Gateway
192.168.0.0
*
Genmask
255.255.255.0
Flags Metric Ref

U
0
0
Use Iface
0 eth0
The routing discussion simplifies matters by assuming that every intermediate network is an Ethernet network, which in general is not the case.
The packet often must be repackaged to match the appropriate data link technology (such as frame relay or FDDI). Throughout any repackaging,
however, the packet's IP configuration (including the destination IP address) and payload will be preserved.
rha130-6.1-1
24
169.254.0.0
127.0.0.0
default
*
255.255.0.0
*
255.0.0.0
server1.example 0.0.0.0
U
U
UG
0
0
0
0
0
0
0 lo
0 lo
0 eth0
The first line specifies that any packet destined for the network address 192.168.0.0/255.255.255.0
should be delivered to the local network accessed through the interface eth0. This information is used
for communicating with hosts on the local network.
The second line refers to a virtual network used by an application specific protocol, and can be safely
ignored in the current discussion.
The third line specifies that any packet destined for the network address 127.0.0.0/255.0.0.0 should
be delivered to the loopback interface lo. Accordingly, the loopback interface acts like any other
locally connected network.
Any packet destined for a location not spanned by the preceding entries will be forwarded to the
specified gateway, in this case the machine "server1.example..." (in order to preserve the table's
formatting, the remainder of the host's name has been truncated). This information is used when
communicating with hosts on remote networks. Note that the G flag has been included, indicating
that this routing table entry specifies a gateway instead of a network.
Often, the routing table is more easily understood when it lists gateways by IP address rather than hostname,
as specified by the -n command line switch.
[root@station root]# route -n
Kernel IP routing table
Destination
Gateway
192.168.0.0
0.0.0.0
169.254.0.0
0.0.0.0
127.0.0.0
0.0.0.0
0.0.0.0
192.168.0.254
Genmask
255.255.255.0
255.255.0.0
255.0.0.0
0.0.0.0
Flags
U
U
U
UG
Metric
0
0
0
0
Ref
0
0
0
0
Use
0
0
0
0
Iface
eth0
eth0
lo
eth0
Using ip to Edit the Routing Table

The same ip route command which is used to examine the routing table can also be used to manipulate
the routing table dynamically. The ip route command supports an elaborate syntax for adding, removing,
and editing entries, as reflected in the ip(8) man page.
In practice, administrators seldom edit the routing table directly. The Linux kernel automatically adds and
removes the appropriate entries to define local networks when an interface is raised or lowered with the
ip command (or any of the front end commands which use it, such as ifup and ifdown), so these lines are
not a concern for the administrator.
The default gateway used to communicate with external networks, however, cannot be determined from
an interface's configuration directly, and must be supplied by an administrator. The default gateway can
be removed from the routing table using the command ip route del default, and a new gateway can be
specified using ip route add default via IPADDR, where IPADDR should be replaced with the gateway's
IP address.
The following transcript demonstrates an administrator examining the local routing table, then removing
the default gateway, reexamining, restoring the gateway, and reexamining.
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.51
default via 192.168.0.254 dev eth0
[root@station root]# ip route del default
[root@station root]# ip route add default via 192.168.0.254
rha130-6.1-1
25
metric 2
metric 2
metric 2
Notice in the second invocation of the ip route command, the routing table no longer contains the entry
for the default gateway.
Defining a Default Gateway

In this lesson, we have illustrated the role of a gateway, and seen how the ip route command can be
used to observe, add, or remove a gateway from the kernel's routing table. The kernel's routing table is
maintained dynamically, however, and any edits made using the ip route command will be lost upon any
subsequent reboots.
In order to incorporate a gateway's definition into the bootup process, the gateway's identity can be added
to the configuration file of the appropriate interface using the shell variable GATEWAY. For example, on
a machine with a single Ethernet card, the following line can be added to the file /etc/sysconfig/
network-scripts/ifcfg-eth0:
GATEWAY=192.168.0.254
With this addition, whenever the interface is raised with the command ifup eth0, or whenever the interface
is raised automatically on bootup, the gateway 192.168.0.254 will be added to the routing table. Whenever
the interface is lowered with ifdown eth0, the gateway will be removed from the table.
Examples
Adding a Default Gateway with the route Command
Our administrator from the previous Lesson is continuing to configure a Red Hat Enterprise Linux machine
using the information provided by the local Network Administrator:
IP Address/Mask: 172.16.48.18/255.255.0.0
Gateway: 172.16.0.1
Having already configured and activated the network interface, he turns his attention to the routing table,
which he examines with the ip route command.
[root@localhost network-scripts]# ip route
src 172.16.48.18 metric 2
While the local network definitions look appropriate, the administrator notices that no gateway is defined.
He attempts to contact an IP address of a machine he knows is available on the Internet, namely
www.yahoo.com, with an IP address of 216.109.118.79.
[root@localhost network-scripts]# ping 216.109.118.79
connect: Network is unreachable
Not surprisingly, the ping command is not able to contact 216.109.118.79, because the kernel does not
have a direct entry for any network which begins 216, nor a default gateway to use for destination networks
which are not locally connected.
The administrator now uses the ip route command to add the gateway specified by the network
administrator, and again lists the routing table.
[root@localhost root]# ip route add default via 172.16.0.1
[root@localhost root]# ip route
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.48.18 metric 2
rha130-6.1-1
26
Having added the gateway, he again tries to ping www.yahoo.com by IP address.

[root@localhost root]# ping 216.109.118.79
CTRL+C
--- 216.109.118.79 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2015ms
This time, as expected, the gateway routes his packets out of his local network toward the appropriate
Internet destination.
Adding a Default Gateway to the Interface Configuration

File
Our same administrator from the previous example would now like the gateway to be defined
automatically whenever the appropriate interface is raised. Using a simple text editor, he adds the line
GATEWAY=172.16.0.1 to the interface configuration file ifcfg-eth0.
[root@localhost root]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
IPADDR=172.16.48.18
NETMASK=255.255.0.0
ONBOOT=yes
GATEWAY=172.16.0.1
He then confirms correct operation by dropping the interface eth0, examining the routing table, then raising
eth0, and examining the routing table again.
[root@localhost root]#
172.16.0.0/24 dev eth0
172.16.0.0/24 dev eth0
default via 197.16.0.1
ifdown eth0
ip route
proto kernel
ifup eth0
ip route
proto kernel
dev eth0
scope link
src 172.16.48.18 metric 2
scope link
src 172.16.48.18 metric 2
The administrator is satisfied that the gateway is automatically added to the routing table whenever the
interface eth0 is raised with the ifup network script.
Online Exercises
Lab Exercise
Objective: Observe your local gateway definition.
Specification
1. Use the ip route command to display your kernel's routing table, and observe the IP address of your
default gateway.
rha130-6.1-1
27
2. In your home directory, create the file gateway, which contains the IP address of your default gateway
as its only word. (Some classrooms, particularly those using a proxy server to access the Internet, may
not have a default gateway. In this case, just put the word "none" in the file.)
Deliverables
1.
1. The file ~/gateway, which contains the IP address of your default gateway (or the word
"none") as its only word.
Questions
1.
What network mask is associated with a Class B IP Network?

a.
255.255.255.255
b.
255.255.255.0
c.
255.255.0.0
d.
255.0.0.0
e.
None of the above
2.
What network protocol is used to associate an Ethernet MAC address with an IP address?
a.
IP
b.
TCP
c.
ARP
d.
DNS
e.
None of the above
Use the following transcript to answer the next 3 questions.

[root@station root]$ ip addr
link/ether 00:0d:60:2f:f5:9c brd ff:ff:ff:ff:ff:ff
inet6 fe80::ae00:60ff:fe2f:f59c/64 scope link
3.
rha130-6.1-1
What is the MAC address of the interface eth0?

a.
192.168.0.52
b.
192.168.0.255
c.
00:0d:60:2f:f5:9c
d.
255.255.255.0
28
e.
4.
1500
What is the MAC address of the loopback interface?
a.
127.0.0.1
b.
255.0.0.0
c.
00:0d:60:2f:f5:9c
d.
192.168.0.52
e.
The loopback interface does not have a MAC address.
5.
What is the network mask of the interface eth0?

a.
255.0.0.0
b.
192.168.0.255
c.
255.255.255.0
d.
1500
e.
Not enough information is provided.
Use the following transcript to answer the next 3 questions.

[root@station root]$ ip route
6.
What is the IP address of the default gateway?

a.
10.0.0.0
b.
0.0.0.0
c.
127.0.0.0
d.
192.168.0.254
e.
There is no default gateway.
7.
What is the IP address of the interface eth0?

a.
10.1.1.1
b.
127.0.0.1
c.
255.0.0.0
d.
192.168.0.254
e.
Not enough information is provided.
8.
What network configuration problem is implied by the above routing table?

a.
rha130-6.1-1
src 10.1.1.1 metric 2
The gateway 192.168.0.254 cannot be reached using any of the local networks.
29
b.
The interface eth0 is not active.
c.
The network mask for the gateway is misconfigured.
d.
The default gateway should always be accessed through the lo interface.
e.
Only one gateway is listed.
9.
On a system whose only external network interface is the interface eth0, in what file could the
default gateway be specified?
a.
/etc/sysconfig/gateways
b.
/etc/services
c.
/etc/ip.conf
d.
/etc/sysconfig/route
e.
10.
rha130-6.1-1
In the appropriate configuration file, what parameter is used to specify a default gateway?
a.
GATE
b.
GATEWAY
c.
ROUTE
d.
DEFAULTGW
e.
None of the above
30
Chapter 3. Configuring DNS Clients

Key Concepts
Domain Name Service (or DNS) uses nameservers to interface with a distributed database which maps
hostnames to IP addresses.
Unlike network interface and gateway configuration, Domain Name Service configuration can be
considered optional (though it is seldom left unconfigured).
The /etc/hosts defines hostname to IP address mappings local to a particular machine.
The file /etc/resolv.conf specifies nameservers (by IP address) and default DNS search domains.
Often, networks which use proxy servers to access the Internet do no implement DNS directly, but rely
on the proxy server to perform DNS lookups.
Discussion
Domain Name Service (DNS)
The previous two Lessons have discussed networking configuration which is essential to communicating
using the IP protocol. In order to communicate between any two hosts, a station must be assigned an IP
address. In order to communicate with hosts outside of the local network, a station must be configured
with a default gateway.
In this Lesson, we address Domain Name Service (DNS) configuration. In theory, DNS configuration is
optional. If you were to address every computer you accessed on the Internet by IP address, there would
be no need for domain name service. (For example, try referring a web browser to http://209.132.177.50.)
In practice, people prefer to refer to computers by names instead of numbers, so DNS is seldom left
unimplemented.
Domain Name Service (DNS) maps hostnames to IP addresses. When using the telephone network, people
consult a telephone book to convert a name into a telephone number. Analogously, when using an IP
network, the computer consults a DNS server to convert a hostname (such as www.redhat.com) into an
IP address (such as 209.132.177.50).
The resolv Library

Most Linux (and Unix) applications use a common infrastructure to resolve hostnames, technically known
as the resolv library. When resolving a hostname, the resolv library first attempts to perform a "static"
lookup (using a simple database defined in the /etc/hosts file). Next, the library will attempt a
"dynamic" lookup, consulting nameservers listed in the /etc/resolv.conf configuration file. The
configuration of each of these files is covered in the next sections.
Static Lookups: /etc/hosts

The /etc/hosts file implements a simple database which maps hostnames to IP addresses. The file
lists one entry per line, where the first token is an IP address, the second token is the "true" hostname for
the IP address, and subsequent tokens are alias hostnames which should resolve to the address as well.
Empty lines and lines beginning with the traditional Unix comment character ("#") are ignored.
rha130-6.1-1
31
Configuring DNS Clients
[root@station root]# cat /etc/hosts

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
192.168.0.5 station5.example.com station5
The file may be edited with any text editor, and changes take effect immediately. For example, if people
in an office where sharing information served by a webserver running at 192.168.0.111, and commonly
downloading files from a FTP server at 10.8.93.3, an administrator might add the following lines to the
/etc/hosts file.
192.168.0.111 info
10.8.93.3 downloads
Now a browser can be referred to simply http://info or ftp://downloads.

In the (very) early days of the Internet, the /etc/hosts file was the only resource for resolving
hostnames. Obviously, the mechanism does not scale well. You cannot expect every Linux (and Unix)
machine to maintain a text database that lists the millions of domains and IP addresses found on the Internet.
Now, the functionality of the /etc/hosts files has been almost completely superseded by DNS servers
(to be discussed next). However, there are a few cases where the /etc/hosts file is still relevant, namely
while the system is booting, and for machines that are always or occasionally isolated from the network
(such as laptops).
What should be included in an /etc/hosts file?

The following entries should be found in a modern Linux /etc/hosts file.
Localhost: The /etc/hosts file should contain an entry which defines the hostnames
localhost.localdomain and localhost, mapping each to the IP address 127.0.0.1.
127.0.0.1
localhost.localdomain localhost
Statically Allocated IP Addresses: If your machine has a statically allocated IP address (i.e., it is
guaranteed to assign an interface the same IP address every time the interface is raised), a reference to
the hostname associated with the IP address may be placed in the /etc/hosts file. This way, network
services may resolve their own hostname even when the network interface is disabled.
Convenience Addresses: If an administrator wants to create local hostnames (such as the info and
downloads example above), or if the administrator does not have direct control over a DNS server,
convenience entries may be added to the /etc/hosts file.
10.8.93.3 downloads.example.com downloads d
What should not be included in an /etc/hosts file?

The following entry may cause problems if found in a /etc/hosts file.
Misleading Localhost Definitions: Sometimes, administrators are tempted to assign a computer a
hostname, such as station5.example.com, even though the machine is receiving a dynamically allocated
IP address from a DHCP server. When the machine is not attached to the network, many services will
complain upon startup that they cannot resolve the assigned hostname. In an effort to avoid complaints,
the administrator will map the hostname to the an address the file /etc/hosts. Because the interface
is configured by DHCP, however, the IP address may not be available, and the administrator is tempted
to map the hostname to the loopback IP address, as in the following.
# in the /etc/hosts file, this is usually a sign of trouble....
127.0.0.1 localhost.localdomain localhost station5.example.com
rha130-6.1-1
32
While the problem is solved while the machine is not attached to the network, this configuration can
cause subtle problems when the machine is attached to the network. Usually, the hostname should
be associated with a legitimate (external) IP address, but this configuration will override any such
assignment, and assign the hostname to the loopback address instead. In general, such configurations
should be avoided.
(The crux of the problem in this scenario is the desire to assign a hostname to a machine while it does
not (yet) have an external IP address. More on this in a moment).
Dynamic Lookups: /etc/resolv.conf

These days, almost all hostnames are resolved using a large, distributed database, accessed through DNS
servers. The database must be large and flexible, as it covers every Internet hostname and IP address. The
database does not exist on a single machine or in a single location. Instead, corporations or organizations
may apply for a domain (such as redhat.com or mit.edu), and are then responsible for implementing the
portion of the database relevant to that domain. The local portion of the database must also be registered
with "upstream" database servers, so that other DNS servers may find the local server to query for its local
information.
The design of the DNS database, and the configuration of DNS servers which implement it, is an interesting
but complicated topic. Fortunately, we do not need to understand the details of how to implement a DNS
server in order to use it. We merely need to know its IP address.
The /etc/resolv.conf file is used by the resolv library to define nameservers. The line based
configuration file expects lines to begin with one of several keywords, as listed below. We focus our
discussion on the nameserver, search, and domain keywords.
[root@localhost root]# cat /etc/resolv.conf
search isp.net example.com
nameserver 172.16.32.18
nameserver
Lines beginning nameserver follow with a single IP address of a host running

the DNS service. Multiple nameserver lines may be used, in which case the first
nameserver listed is referred to as the primary nameserver, the second as the
secondary nameserver, and so on. When performing a DNS lookup, the primary
nameserver will be consulted first. If for some reason the primary nameserver is
unavailable, the second will be consulted, and so on.
search
Every hostname has a long, fully specified form referred to as a Fully Qualified
Domain Name (or often just FQDN), such as station5.example.com. Often, when
using many hostnames which all share a common trailing domain, the trailing
domain is conveniently omitted, such as just station5. In order to perform this
shortcut, a list of possibly omitted trailing domains should be listed in the /etc/
resolv.conf file on a line beginning with the keyword search. Unlike the
case when listing multiple nameservers, multiple domains are appended to a
single search line.
As an example using the resolv.conf configuration file listed above, when
attempting to resolve the host server1, the resolv library would first query
the nameserver for the host server1 directly. If the nameserver did not have
an entry for a literal server1 (which would probably be the case), the resolv
library would begin appending domain names found in the search field, first
trying server1.isp.net, then server1.example.com, until the nameserver returned
a successful response (or the list of domains was exhausted).
rha130-6.1-1
33
domain
Similar in spirit to the search keyword, the domain keyword defines a domain
name which should be appended to shortened hostnames. Unlike the search
field, a domain line only takes a single domain, which is intended to be the
machine's local domain. When looking up the hostname server1, the resolv
library would first append the domain name, then try a bare server1, and then
append domains found in any search line. In practice, administrators often
simplify, and omit the domain field, making sure to include the local domain
name towards the beginning of the search line.
The /etc/resolv.conf file may be edited with a simple text editor, and changes take effect
immediately.
Proxy Servers
This lesson assumes that stations have a direct Internet connection, or at least a direct connection to a DNS
nameserver. In some situations, stations are only allowed to connect to the Internet through applications
called proxy servers. Applications which can use proxy servers, such as web browsers or FTP clients, must
generally be configured with the IP address of the proxy server directly. When using a proxy server, the
local station rarely tries to resolve DNS lookups directly, but instead forwards the hostname to the proxy
server, which does the hard work.
Networks which rely on proxy servers may opt to not implement Domain Name Service directly. In these
situations, DNS may not even be implemented on the local machine, and the /etc/resolv.conf file
may be left unconfigured. While this approach may simplify some aspects of network configuration, the
downside is that only selected applications, using selected protocols, may resolve hostnames or access
the Internet.
Examples
Specifying a Nameserver
Our administrator form the previous two lessons is continuing to configure a Red Hat Enterprise Linux
machine using the following network configuration information, which was provided by the local network
administrator:
IP Address/Mask: 172.16.48.18/255.255.0.0
Gateway: 172.16.0.1
The administrator first examines the local DNS definitions in the /etc/hosts file.
[root@localhost root]# cat /etc/hosts
127.0.0.1
Noting nothing out of the ordinary, the administrator next attempts to ping the host www.yahoo.com by
hostname.
[root@localhost root]# ping www.yahoo.com
ping: unknown host www.yahoo.com
As should be expected from a machine which does not have access to a nameserver, the system cannot
resolve the hostname.
rha130-6.1-1
34
Using a simple text editor, the administrator now adds the supplied nameserver to the /etc/
resolv.conf configuration file, using the nameserver keyword. Because he expects that users on
this machine will often be contacting other machines in the example.com domain, he adds the domain to
the file using the search keyword.
[root@localhost root]# cat /etc/resolv.conf
search example.com
In order to confirm nameservice, he again attempts to ping the host www.yahoo.com.

[root@localhost root]# ping www.yahoo.com
PING www.yahoo.akadns.net (216.109.118.67) 56(84) bytes of data.
64 bytes from p4.www.dcn.yahoo.com (216.109.118.67): icmp_seq=0 ttl=51 time=30.7 ms
CTRL+C
--- www.yahoo.akadns.net ping statistics --2 packets transmitted, 2 received, 0% packet loss, time 1004ms
This time, the system uses the specified nameserver to resolve the hostname to the IP address
216.109.118.67.
Online Exercises
Lab Exercise
Objective: Configure nameservers and static hostname definitions.
Specification
1. Using a simple text editor (or shell redirection), append a line to the /etc/hosts configuration file
which maps the hostname rha to the IP address 127.0.0.5. Once completed, you should now be able
to ping the host rha.
2. Add the domain isp.net to any already existing search domains in the /etc/resolv.conf
configuration file. (If no search line exists, create one).
3. Append to the bottom of the /etc/resolv.conf configuration file a nameserver line defining
the nameserver 192.168.99.118. Do not modify any other nameserver lines.
Deliverables
1.
1. The statically defined host rha, which should resolve to the IP address 127.0.0.5.
2. The domain isp.net included in your station's list of DNS search domains.
3. The nameserver 192.168.99.118 included in your station's list of nameservers, with a lower
precedence than any other defined nameserver.
Clean Up
After your lab has been graded, remove the domain isp.net and the nameserver 192.168.99.118 from your
/etc/resolv.conf file, and the entry rha from your /etc/hosts file.
rha130-6.1-1
35
Questions
1.
Which file defines local hostname to IP address translations?

a.
/etc/ip.conf
b.
/etc/resolv.conf
c.
/etc/hosts
d.
/etc/sysconfig/dns
e.
None of the above
2.
What daemon process on a standard Red Hat Enterprise Linux system is responsible for resolving
a hostname into an IP address?
a.
dnsd
b.
hostd
c.
resolvd
d.
resolvd
e.
The question is misguided, as local hostname resolution is not implemented as a daemon.
3.
What network protocol is used to resolve hostnames into IP addresses?

a.
IP
b.
DNS
c.
ARP
d.
TCP
e.
None of the above
Use the following text to answer the next question.

[root@station root]# cat /etc/hosts
127.0.0.1
downloads
10.1.1.8
4.
rha130-6.1-1
What configuration error is found in the above file?

a.
The IP address should be the first token on the line.
b.
The downloads entry is not a fully qualified domain name.
c.
The IP address for the localhost entry is not the conventionally assigned address.
d.
The wrong character is used to comment out the first two lines.
e.
None of the above
36
5.
What keyword is used to assign nameservers in the /etc/resolv.conf file?

a.
nameserver
b.
ns
c.
search
d.
domain
e.
None of the above
6.
What keyword is used to define domains to possibly append to non-fully-qualified hostnames?

a.
nameserver
b.
ns
c.
dots
d.
search
e.
None of the above
7.
After editing the /etc/resolv.conf configuration file, what command must be run before
the edits take effect?
a.
service dns restart
b.
killall -1 resolvd
c.
make
d.
dnsupdate
e.
None, as the changes take effect immediately.
8.
After editing the /etc/hosts configuration file, what command must be run before the edits
take effect?
a.
service dns restart
b.
killall -1 hostd
c.
make
d.
dnsupdate
e.
None, as the changes take effect immediately.
Use the following text to answer the next question.

[root@station root]# cat /etc/resolv.conf
search example.com isp.net
nameserver 192.168.0.254 10.1.1.8
9.
What configuration error does the file contain?

a.
rha130-6.1-1
Nameservers should be defined using the keyword ns.
37
b.
Multiple nameservers should be defined with multiple nameserver entries, with one
nameserver per line.
c.
Multiple search domains should be defined with multiple search entries, with one domain
per line.
d.
Nameservers can only be accessed on the local IP network, and the two listed nameservers
have different network addresses.
e.
Both B and C
10.
rha130-6.1-1
No /etc/hosts or /etc/resolv.conf file can be found on a Red Hat Enterprise Linux

machine, and yet the web browser is able to access websites by hostname. Which of the following
is the most likely explanation?
a.
The files were removed after the dnsd daemon was started.
b.
The web browser is using a remote DNS nameserver to resolve the hostnames.
c.
The web browser is accessing the Internet through a remote proxy server.
d.
The web browser is implementing nameservice internally.
38
Chapter 4. Miscellaneous Network

Settings
Key Concepts
Although hostnames are in reality assigned to IP addresses, not machines, the Linux kernel maintains a
single hostname which is thought of as the hostname for the machine.
The kernel's hostname can be examined or set directly with the hostname command, or incorporated
into the bootup process by adding HOSTNAME=station.example.com to the file /etc/
sysconfig/network.
Administrators should avoid the temptation to assign the kernel hostname arbitrarily, but instead
coordinate with any existing DNS entries for an expected IP address. If the IP address is being obtained
dynamically, the hostname should be set to localhost.localdomain, or remain unset.
Red Hat Enterprise Linux machines can act as routers if IP forwarding is enabled in the /etc/
sysctl.conf configuration file.
When obtaining an IP address from a DHCP server, the default gateway and DNS configuration
information may be obtained as well. If provided, the information will be automatically implemented.
The netconfig and NetworkManager utilities can simplify the process of network configuration.
Discussion
Miscellaneous Network Configuration
The previous three lessons have outlined what can be considered the minimum requirements for
configuring a station to participate in an IP network, namely (1) assigning interfaces an IP address and
network mask, (2) assigning a default gateway, and (3) defining one or more nameservers.
This lesson considers some aspects of network configuration that extend or provide an alternate
implementation of these core concepts.
Assigning Hostnames
The hostname Command
The Linux kernel maintains a machine's hostname dynamically in the kernel memory. A machine's
hostname may be examined using the hostname command, which simply returns the current hostname,
as follows.
[root@station root]# hostname
station.example.com
The root user may also use the hostname command to dynamically assign a hostname, merely by adding
an argument which will be interpreted as the new hostname. In the following sequence, the root user will
observe a machine's hostname, set it to a nonsense value, and then reset it to the appropriate value.
[root@station root]# hostname
station.example.com
rha130-6.1-1
39
Miscellaneous Network Settings
[root@station root]#
foo
station.example.com
hostname foo
hostname
hostname station.example.com
hostname
Note
Notice that the shell's prompt did not change to reflect the changed hostname. Newly started
shells, however, would reflect the change.
Note
The X windowing system is sensitive to network configuration. If you change your hostname
from within the Linux graphical environment, you will probably not be able to open any new
windows. The problem may be fixed by simply logging out and logging back into to the system.
The /etc/sysconfig/network File

The hostname command can be used to define a machine's hostname, but the effect is dynamic. As soon as
the machine reboots, the change is lost. The information must somehow be incorporated into the machine's
startup process.
In a previous Lesson, we saw that interface configuration files, such as /etc/sysconfig/networkscripts/ifcfg-eth0, record interface configuration information. Analogously, the file /etc/
sysconfig/network records global networking configuration information. Like the interface
configuration files, the file is used to define shell variables (using bash shell syntax) which are incorporated
into the bootup process, as seen in the following transcript.
[root@station root]# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=yes
HOSTNAME=station.example.com
NISDOMAIN=RHA130
Obviously, a machine's hostname is one of the parameters that may be specified in the file. Some of
the more common parameters used within the /etc/sysconfig/network file are outlined in the
following table.
Table 4.1. Variables Relevant to /etc/sysconfig/network

Variable
Sample Values
Use
NETWORKING
yes|no
By setting NETWORKING=no, all network related

configuration is omitted from the bootup process.
NETWORKING_IPV6
yes|no
By setting NETWORKING_IPV6=no, all IPv6

related configuration is disabled.
HOSTNAME
station.example.com
Upon startup, the kernel's hostname is set using
the value specified by the HOSTNAME command.
If not specified, the hostname will be set to
localhost.localdomain.
NISDOMAIN
RHA130
Upon startup, the value of the NISDOMAIN

parameter is used to establish a NIS domains, if any.
GATEWAY
192.168.0.254
If specified, the IP address will be added to the

network routing table as the default gateway upon
rha130-6.1-1
40
Variable
Sample Values
Use
startup. (Note that the GATEWAY can also be
specified in an interface configuration file, which
has precedence).
GATEWAYDEV
eth1
If specified, the IP address specified by the DHCP

configuration for the relevant interface will be used
as the default gateway.
The role of the NETWORKING parameter should be obvious (it is rarely set to anything other than "yes").
The use of the NISDOMAIN and GATEWAY parameters were discussed in previous lessons. As is the
case with interface configuration files (and most every file found in the /etc/sysconfig directory),
complete documentation may be found in the file /usr/share/doc/initscripts-version/
sysconfig.txt.
Linux Computers Don't Have Hostnames; IP Addresses do

We have discussed how to set and examine the kernel's concept of a machine's hostname directly (with the
hostname command), and how to incorporate the definition into the bootup process (with the HOSTNAME
entry in the /etc/sysconfig/network file). Now that we know how its done, we will discuss why
an administrator should usually avoid the temptation to set a machine's hostname at all.
We have learned that, in order to convert a hostname into an IP address, the computer performs a DNS
lookup. The DNS database is also able to reverse the process. If given an IP address, a properly configured
DNS server should be able to return the hostname that refers to the address, by performing what is called
a reverse lookup. This leads us to an subtle but important point about Linux (and Unix) IP networking:
computers do not have hostnames; IP addresses do. When we refer to a machine's hostname, there is an
implicit assumption that the machine has only one (external) IP address, and the computer's hostname is
the hostname associated with it.
When an interface is activated, if the kernel's concept of the machine's hostname has not been set (or,
equivalently, if it has been set to the special value localhost.localdomain), the networking startup scripts
will perform a reverse lookup on the interface's assigned IP address, and set the kernel's hostname
accordingly. Therefore, assuming that the relevant DNS server can properly perform the reverse lookup,
any "hardwired" hostname definition will be redundant at best, and can cause networking problems at
worst.
An observant student might complain, "but if computers don't have hostnames, what am I setting with the
hostname command?" The Linux kernel does maintain a hostname, but the hostname should not be set
arbitrarily. Administrators should only set the hostname directly if the machine is known to consistently
use the same IP address, and then it should only be set to the hostname associated with that IP address. If
DNS is properly configured to perform reverse lookups, this will happen automatically. If multiple network
cards are supported, any one of the associated hostnames may be chosen. If a computer is set to acquire its
IP address from a DHCP server, the hostname should remain unset. Until the machine has been assigned
an IP address, it does not have a hostname, and should use the default value localhost.localdomain.
In summary, here are some points to remember about hostnames.
Administrators do not assign hostname by whim. Host names are assigned to particular IP addresses
in DNS databases.
If a computer must be assigned a hostname, make sure it is consistent with the IP address that it will use.
If a computer does not have a consistently assigned IP address, it should not have a fixed hostname. The
hostname of the computer will vary, depending on the IP address it uses at any given moment.
rha130-6.1-1
41
If in doubt, do nothing (and remove any HOSTNAME definition from the /etc/sysconfig/
network file). The default Red Hat Enterprise Linux startup scripts will configure networking
appropriately.
Treating Network Configuration as a service

We have introduced the ifup and ifdown scripts as the primary way of raising and lowering interfaces. For
example, after editing the ifcfg-eth0 configuration file, running ifdown eth0 followed by ifup
eth0 would apply any changes.
As an alternative, network configuration is also implemented as a service, implying that network
configuration can be managed by the service command: service network stop disables networking
(effectively calling ifdown on every defined interface), service network start starts networking
(effectively calling ifup on every defined interface), and service network restart can be used
to apply both, so that new configurations will take effect.
In addition to raising and lowering interfaces, the network service script performs other networking
configuration, such as adjusting the hostname, if necessary, and applying any "networking parameters",
such as IP Forwarding (to be described next).
The upshot? If you change a networking related configuration file, the change can usually by applied with
service network restart
When using the Network Manager graphical configuration to edit network configurations, you will also
need to restart the interface after making changes. You can use the Network Manager applet to "disable"
then "enable" the interface or you can restart the NetworkManager service.
Enabling IP Forwarding in /etc/sysctl.conf

In a previous lesson, we introduced the role of a router. A router is a machine which has more than one
network interface, on at least two IP networks. A router serves as a gateway, routing network packets out
of the local network.
In the detailed explanation of routing, we mentioned that a router, unlike other hosts, will accept packets
whose destination IP address does not coincide with its own, and attempt to forward the packet to another
IP network closer to its destination, a concept referred to as IP Forwarding.
Every Red Hat Enterprise Linux kernel is capable of IP Forwarding, although IP Forwarding is disabled by
default. If (and only if) a machine is going to act as a router, IP Forwarding must be enabled. IP Forwarding
is enabled in the /etc/sysctl.conf configuration file, where the following line should be added (or
edited).
net.ipv4.ip_forward = 1
In the default /etc/sysctl.conf file which ships with Red Hat Enterprise Linux, the appropriate
parameter is listed, disabled, with comments on how to enable it.
[root@station root]# cat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Enterprise Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
...
rha130-6.1-1
42
IP forwarding may be enabled by merely editing the 0 to a 1 (using a simple text editor), and applying
the change with the command sysctl -p, or simpler to remember, service network restart.
(The exact role of the /etc/sysctl.conf configuration file and the sysctl command was discussed
in an earlier Workbook).
Under the Hood

The /etc/sysctl.conf configuration file, and the associated sysctl command, are really
an interface to the underlying /proc/sys/net/ipv4/ip_forwarding file. The contents
of the file reflects the current state of IP Forwarding, and the current state can be modified by
directly writing to the file, as follows.
[root@station ~]# cat /proc/sys/net/ipv4/ip_forward
0
[root@station ~]# echo 1 > /proc/sys/net/ipv4/ip_forward
[root@station ~]# cat /proc/sys/net/ipv4/ip_forward
1
Realize that the /proc filesystem is a virtual filesystem, however, so this change will not persist
across a system reboot. That is why the above mentioned /etc/sysctl.conf configuration
file is preferred.
More about DHCP

In a previous lesson, we introduced the Dynamic Host Configuration Protocol (DHCP) as a method for
managing IP address assignment from a central DHCP server running on the same IP network. We will
now look at the DHCP protocol in more detail, and discover that more than IP addresses may be configured
using DHCP.
When an interface is configured using DHCP, a dhclient daemon is automatically started to manage
the DHCP negotiation. When the dhclient daemon receives an appropriate IP address from a DHCP
server, it may also receive other networking configuration information, such as the IP address of a default
gateway, nameserver, default search domains, and even NIS domains. Any such information received by
the dhclient daemon is immediately applied. Default gateways are added to the routing table, nameservers
are written to the /etc/resolv.conf file, and NIS domains are automatically set.
As a result, administration of a DHCP client is particularly easy. Usually, the only required step is to
add the line BOOTPROTO=dhcp to the appropriate interface configuration file. The other configuration
mentioned in the previous two lessons (adding a default gateway and assigning nameservers) will be
performed automatically.
Any information received by the dhclient daemon is stored as text in the automatically created file /
var/lib/dhclient/dhclient-name.leases, where name is replaced with the interface name,
as illustrated in the following example.
[root@station root]# cat /var/lib/dhclient/dhclient-eth0.leases
lease {
interface "eth0";
fixed-address 192.168.0.5;
option subnet-mask 255.255.255.0;
option routers 192.168.0.254;
option dhcp-lease-time 21600;
option dhcp-message-type 5;
option domain-name-servers 192.168.0.254;
option dhcp-server-identifier 192.168.0.254;
option domain-name "example.com";
renew 1 2003/2/9 21:48:22;
rebind 2 2003/2/10 00:14:46;
expire 2 2003/2/10 00:59:46;
rha130-6.1-1
43
The name of the interface for which the DHCP lease is appropriate.
The assigned IP address for the interface
The network mask associated with the IP address.
The IP address to be used as the default gateway, 192.168.0.254
The IP address to be used as the primary nameserver, again 192.168.0.254.
The IP address of the machine on which the DHCP server is running (yet again, 192.168.0.254).
Domain names to be included on the search line of the /etc/resolv.conf configuration file.
In this example, the server with an IP address of 192.168.0.254 is apparently performing triple duty, not
only acting as a DHCP server, but also as a router and a DNS nameserver. The remaining information
pertains to the management of the DHCP lease, which is beyond the scope of our current discussion.
The behavior of the dhclient daemon is configurable. More information may be found in the dhclient(8)
and dhclient.conf(5) man pages.
Network Configuration with system-config-network-tui

How do I remember all those variables and files and settings? For many situations, Network Manager
and its graphical configuration interface will suffice. But even with our network service and only a text
environment, there is an alternative. The system-config-network-tui command will bring up an interactive
configuration similar to the following:
+----------| Select Action |---------+
|
|
|
Device configuration
|
|
DNS configuration
|
|
|
|
|
|
+-----------+
+-------+
|
|
| Save&Quit |
| Quit |
|
|
+-----------+
+-------+
|
|
|
|
|
+------------------------------------+
Although apparently presented with only the unproductive choices of saving and quiting or just quiting,
just hitting RETURN on a selected action will allow you to choose a device.
+--------| Select A Device |---------+
|
|
| eth0 (eth0)
|
| <New Device>
|
|
|
|
|
|
+------+
+--------+
|
|
| Save |
| Cancel |
|
|
+------+
+--------+
|
|
|
|
|
+------------------------------------+
Similarly, hitting RETURN on a selected action will open the following configuration panle.
+-------| Ethernet Configuration |--------+
|
|
|
|
| Name
eth0______________ |
rha130-6.1-1
44
| Device
eth0______________ |
| Use DHCP
[*]
|
| Static IP
__________________ |
| Netmask
__________________ |
| Default gateway IP
__________________ |
| Primary DNS server
__________________ |
| Secondary DNS server __________________ |
|
|
|
+----+
+--------+
|
|
| Ok |
| Cancel |
|
|
+----+
+--------+
|
|
|
|
|
+-----------------------------------------+
From within this panel, all of the information for basic IPv4 configuration can be specified, and upon
exiting, will be committed to the appropriate underlying files. Just as with editing the files, after the changes
are committed, the interface still needs to restarted. Use the ifdown and ifup commands or run service
network restart for the changes to be implemented.
Now you Tell Us!

After laboring through the previous lessons, students might be delighted to know that configuration utilities
exist, and wonder why they are not emphasized, or even introduced first. The following list summarizes
the reasons why knowledge of the underlying configuration files is essential.
Linux (and Unix) systems are primarily configured using configuration files. If a text or graphical utility
exists, it usually servers only as a front end to an underlying configuration file.
With knowledge of the underlying configuration files, the behavior of most graphical configuration
utilities is transparent. The converse is not true.
Often, text configuration files support a richer set of capabilities than can be conveniently expressed
in a graphical utility. Graphical utilities also have a habit of removing explanatory comments from
configuration files, which makes the service more difficult to configure by hand when necessary.
When administering a large number of machines, distributing and maintaining appropriately configured
text files is easier than operating graphical utilities on individual machines.
Remember that Linux is, at its heart, a command-line operating system. The graphical environment is
an add-on and may not be available on all systems. An administrator who only knows how to configure
a system using the graphical tools will be crippled when configuring a system that does not have a
graphical environment installed or where the graphical environment is malfunctioning.
Graphical configuration utilities have their place. When an administrator is new to an application, graphical
configuration utilities provide an easy way to learn some of the various features the system supports.
In Linux (and Unix) system administration, however, systems and applications are almost invariably
configured more directly by text based configuration files. When viewing a graphical configuration utility,
the administrator should have in mind which files the utility is configuring.
Examples
Setting a Machine's Hostname with hostname
Our administrator from the previous three Lessons is setting his machine's hostname, as specified in the
following information which he received from the local network administrator.
rha130-6.1-1
45
IP Address/Mask: 172.16.48.18/255.255.0.0
Gateway: 172.16.0.1
The administrator first uses the hostname command to observer the machine's current hostname.
[root@localhost root]# hostname
localhost.localdomain
The hostname command returns the default hostname for machines which have not yet had their hostname
set.
Next, the administrator used the same hostname command to set the specified hostname, and again to
observe the new value.
[root@localhost root]# hostname nimbus.example.com
[root@localhost root]# hostname
nimbus.example.com
The administrator than starts a new bash subshell, to confirm that the change has taken effect.
[root@localhost root]# bash
[root@nimbus root]#
Observing the new hostname in the subshell's prompt, the administrator is convinced that the new hostname
has taken effect.
Configuring a Machine's Hostname in /etc/sysconfig/

network
Our same administrator from the previous example would now like to configure the machine so that the
hostname is set automatically at bootup. Because the machine has a statically defined IP address, the
administrator feels confident that the same hostname will always apply.
Using a simple text editor, the administrator edits the /etc/sysconfig/network file to resemble
the following.
[root@nimbus root]# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=nimbus.example.com
As an additional precaution, the administrator would like network services to be able to resolve the
hostname, even when the network interface is not active. Again using a simple text editor, He adds the
following last line to the /etc/hosts configuration file.
[root@nimbus root]# cat /etc/hosts
127.0.0.1
172.16.48.18
nimbus.example.com
Using system-config-network-tui to Configure a Machine

to use DHCP
A system administrator has recently installed a Red Hat Enterprise Linux machine. During the installation,
she wasn't sure how to configure the network settings, so she made up an IP address of 1.2.3.4, and a
rha130-6.1-1
46
hostname of sylvester, and left the nameserver and gateway blank. Upon rebooting her machine, of course,
she found she could not use the network. She did some snooping, and observed the following.
[root@sylvester root]# ip addr
inet 1.2.3.4/8 brd 1.255.255.255. scope global eth0
[root@sylvester root]# ip route
1.2.3.0/8 dev eth0 proto kernel
scope link
src 1.2.3.4 metric 2
[root@sylvester root]# cat /etc/resolv.conf

cat: /etc/resolv.conf: No such file or directory
She consulted her network administrator, who told her "just use system-config-network-tui to set the
machine to use DHCP". Returning, she opened a terminal and ran system-config-network-tui. She selects
the action of device configuration and the interface eth0, and using the space bar, arrow keys, TAB, and
RETURN, she selects "Use DHCP".
+-------| Ethernet Configuration |--------+
|
|
|
|
| Name
eth0______________ |
| Device
eth0______________ |
| Use DHCP
[*]
|
| Static IP
__________________ |
| Netmask
__________________ |
| Default gateway IP
__________________ |
| Primary DNS server
__________________ |
| Secondary DNS server __________________ |
|
|
|
+----+
+--------+
|
|
| Ok |
| Cancel |
|
|
+----+
+--------+
|
|
|
|
|
+-----------------------------------------+
After choosing OK, she returns to the bash prompt, and restarts the network service to apply her new
configuration.
[root@sylvester root]# service network restart
Shutting down interface eth0:
Shutting down loopback interface:
Bringing up loopback interface:
Bringing up interface eth0:
[
[
[
OK
OK
OK
]
]
]
OK
She reexamines her network configuration.

[root@sylvester root]# ip addr
inet 192.168.0.192/24 brd 192.168.0.255. scope global eth0
[root@sylvester root]# ip route
192.168.0.0/24 dev eth0 proto kernel
rha130-6.1-1
scope link
47
src 192.168.0.192 metric 2

[root@sylvester root]# cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search widgets.com
The DHCP server assigned an IP address of 192.168.0.192, with the appropriate network mask.
The DHCP server assigned the gateway 192.168.0.1.
The DHCP server assigned the nameserver 192.168.0.254, with a default search domain of
widgets.com. The network startup scripts created this resolv.conf file automatically.
The computer is still using the hostname sylvester, however, which the administrator suspects is
inappropriate. Because the computer is using DHCP to receive its IP address, there is no guarantee which
IP address it will receive, and therefore no guarantee which hostname is appropriate. She decides to remove
the HOSTNAME line from the /etc/sysconfig/network file entirely, leaving just the following.
[root@sylvester root]# cat /etc/sysconfig/network
NETWORKING=yes
Enabling IP Forwarding on a Router

A system administrator has decided to use a Red Hat Enterprise Linux machine as a router, with one
network interface on each of two separate IP networks. After generating an interface configuration file
for each of the interfaces eth0 and eth1, he realizes he must enable IP Forwarding. He edits the /etc/
sysctl.conf configuration file with a text editor, and includes the following line.
net.ipv4.ip_forwarding = 1
He then applies the change by restarting the network service.
[root@station root]# service network restart
Shutting down loopback interface:
Bringing up loopback interface:
[
[
[
[
[
[
OK
OK
OK
OK
OK
OK
]
]
]
]
]
]
Online Exercises
Lab Exercise
Objective: Configure network related settings using the system-config-network-tui utility, and
enable IP forwarding.
Note
This exercise assumes you are accessing the network using the interface eth0. If you are using
another interface, you should adjust the references to eth0 accordingly.
Specification
1. Using a text editor, enable IP Forwarding in the /etc/sysctl.conf configuration file. Apply your
changes using the sysctl command.
rha130-6.1-1
48
2. Make a copy of each of the following files in your home directory. Do not edit the files in any way,
as you will use these to restore your current configuration when you have finished the exercise. You
should preserve filenames, as well.
/etc/resolv.conf
/etc/sysctl.conf
3. Using the ip addr and ip route commands, and examining the file /etc/resolv.conf, determine
the following network parameters for your machine, and record them for later reference.
IP Address and Network Mask (for eth0)
Gateway
Primary Nameserver
(If you are using a proxy server to access the Internet, your configuration may not include a nameserver
or gateway.)
4. Use the system-config-network-tui command to reconfigure your machine's network configuration.
Do not use DHCP, but enter values identical to the information you recorded in the previous step. If
you are not using a gateway or nameserver, leave these fields blank.
5. Apply your changes from the previous step, by running service network restart.
Deliverables
1.
1. A machine with recent, statically configured, and correct IP network configuration.
2. A machine with IP Forwarding enabled.
Cleaning Up
After your exercise has been graded, restore your previous network configuration by restoring the
original /etc/sysctl.conf, /etc/sysconfig/network-scripts/ifcfg-eth0, and /
etc/resolv.conf configuration files from the copies made in your home directory, and running
service network restart.
Questions
1.
What command is used to directly examine the Linux kernel's currently defined hostname?
a.
ip name
b.
host
c.
ip addr
d.
hostname
e.
None of the above
2.
Which of the following command would set the Linux kernel's hostname to station1.example.com?
a.
rha130-6.1-1
hostname station1.example.com
49
b.
hostname -s station1.example.com
c.
ip name -h station1.example.com
d.
ip name station1.example.com
e.
None of the above
3.
In which of the following files can the Linux kernel's hostname be defined explicitly, so that the
name is set automatically upon bootup?
a.
/etc/sysctl.conf
b.
c.
/etc/resolv.conf
d.
/etc/hosts
e.
/etc/sysconfig/network
4.
Which file can be edited in order to enable a Red Hat Enterprise Linux machine to act as a router?
a.
/etc/sysctl.conf
b.
c.
/etc/resolv.conf
d.
e.
/etc/hosts
5.
Within the appropriate file, what is the name of the parameter which must be enabled in order to
enable routing?
a.
kernel.sysrq
b.
net.ipv4.conf.default.rp_filter
c.
net.ipv4.ip_forward
d.
net.ipv4.route
e.
net.kernel.route
6.
7.
rha130-6.1-1
In what directory can information about a machine's current DHCP lease be found?
a.
/etc/dhcp/
b.
/var/lib/dhclient/
c.
/etc/sysconfig/dhcp/
d.
/var/spool/dhclient/
e.
/usr/lib/dhcp/
Which utility helps an administrator simply configure a network interface from a terminal?
50
a.
ifup
b.
system-config-network-tui
c.
host
d.
ip
e.
None of the above
8.
Which of the following parameters can not be configured directly with system-config-networktui?
a.
IP address
b.
Default DNS search domain
c.
Primary nameserver
d.
Default gateway
e.
Network mask
9.
Which sophisticated utility allows an administrator to configure multiple interfaces and DNS using
an X graphical environment?
a.
system-config-interfaces
b.
system-config-network
c.
ip
d.
The Network Manager applet
e.
There is no graphical network configuration tool.
10.
rha130-6.1-1
Which of the following utilities can be used to configure a network interface to receive its
configuration information via DHCP?
a.
system-config-network-tui
b.
ip
c.
system-config-netmanager
d.
system-config-interfaces
51
Chapter 5. Network Diagnostic Utilities

Key Concepts
The ping utility confirms low level IP connectivity between two machines.
The host utility performs direct DNS lookups, and is often used when debugging DNS issues.
The traceroute utility reports a packet's path through intermediate routers from source to destination.
The tcpdump utility can be used to observe network traffic in realtime, or capture network transactions
for later analysis.
The wireshark graphical application performs the same operations as tcpdump, but displays the
captured information using a sophisticated graphical interface.
Discussion
Getting Reacquainted with ping, host, and traceroute
In the RHA030 course, three utilities were introduced as tools for helping to diagnose network
configuration issues. We here reintroduce the tools, and mention some new features available to each.
The ping command

The ping command tests for low level IP connectivity between two machines. In the simplest case, the
ping command accepts a hostname or an IP address as its single argument. The ping utility will then
deliver a low level (ICMP) "echo request" request to the specified host, which should respond with a
low level (ICMP) "echo reply". The ping command numbers the requests and responses, so that dropped
packets can be identified (implying a lossy network connection) and round trip times can be estimated.
The ping command will continue to ping the destination address at a rate of one echo request per second,
until a CTRL+C key sequence is used to terminate its operation, at which point a short summary of packet
statistics is displayed.
[root@station root]# ping server1.example.com
PING server1.example.com (192.168.0.254) 56(84) bytes of data.
64 bytes from server1.example.com (192.168.0.254): icmp_seq=0 ttl=64
time=0.170
time=0.231
time=0.106
time=0.180
ms
ms
ms
ms
(CTRL+C)
--- server1.example.com ping statistics --4 packets transmitted, 4 received, 0% packet loss, time 3018ms
The behavior of the ping command can be modified with some of the following command line switches.
Table 5.1. Command Line Switches for the ping Command

Switch
Effect
-c count
Send only count echo requests before exiting.
-i interval
Pause interval seconds between echo requests.
rha130-6.1-1
52
Network Diagnostic Utilities
Switch
Effect
-w timeout
Exit after timeout seconds have passed, even if all echo replies have not been
received.
-b
Allow the specified address to be a network or broadcast address, effectively pinging

every host on the specified network. (Only available to the root user.)
-f
Ping flooding. Send echo requests as quickly as possible. For every request sent,
print a .. For every reply received, print a backspace. A resulting progression of
periods across the screen implies packets are being dropped by the network. (Only
available to the root user).
The host Command

The host command is used to perform DNS lookups directly. At its simplest, when called with a single
hostname as an argument, the host command will perform a DNS lookup using the nameserver(s) defined
in the /etc/resolv.conf configuration file.
[root@rose root]# host server1.example.com
server1.example.com has address 192.168.0.254
If provided an IP address as its single argument, the host command will perform a reverse lookup on the
IP address.
[root@rose root]# host 192.168.0.254
254.0.168.192.in-addr.arpa domain name pointer server1.example.com.
Despite the odd reference to the 192.168.0.254 IP address in the output, the address is found to resolve
the hostname server1.example.com.
If a second argument is supplied, it is interpreted as the name of a nameserver to query directly (bypassing
any nameserver definitions in the /etc/resolv.conf configuration file). In this case, the identity
of the nameserver is included in the output. In the following example, the host command queries the
nameserver at 192.168.0.254 for the identity of the hostname station3.example.com.
[root@rose root]# host station3.example.com 192.168.0.254
Using domain server:
Name: 192.168.0.254
Address: 192.168.0.254#53
Aliases:
station3.example.com has address 192.168.0.3
The host command can be used to make versatile and exacting queries, though a significant amount of
knowledge about the design of the DNS database is required to make useful use of the output. More
information can be found in the host(1) man page.
The traceroute Command

The traceroute command provides a wonderful illustration of a packet's path as it proceeds from router
to router in route to its destination, listing every router encountered in route (one per line), and an estimate
of the round trip time required to access the router.
In the following example, packets travel trough 19 routers on their path from station.example.com to
www.yahoo.com.
[root@rose root]# traceroute www.yahoo.com
traceroute: Warning: www.yahoo.com has multiple addresses; using 216.109.118.72
traceroute to www.yahoo.akadns.net (216.109.118.72), 30 hops max, 38 byte packets
rha130-6.1-1
53
1
2
3
...
17
18
19
server1 (192.168.0.254) 0.221 ms 0.129 ms 0.095 ms

10.44.160.1 (10.44.160.1) 11.032 ms 7.102 ms 8.035 ms
srp2-0.rlghncg-rtr2.nc.rr.com (24.25.1.100) 7.987 ms 8.243 ms
8.095 ms
216.109.75.254 (216.109.75.254) 29.958 ms 34.727 ms 31.097 ms

vl30.bas1-m.dcn.yahoo.com (216.109.120.142) 32.085 ms 31.340 ms 38.428 ms
p9.www.dcn.yahoo.com (216.109.118.72) 29.954 ms 30.054 ms 30.248 ms
The information can be useful in determining if routing problems are local to your network (i.e., a badly
specified or misbehaving default gateway), or are occurring outside of an administrator's immediate
control.
Diagnosing Network Configuration Problems

Occasionally, problems in a Linux machine's networking configuration can crop up. Sometimes, problems
occur when the machine is receiving its initial network configuration. A file may get accidentally edited or
removed. Often, networking problems occur not because of the local machine, but because some element
of the local network configuration underwent a change (such as a nameserver malfunctioning, or a machine
acting as a default gateway changing identity).
The three utilities introduced above, in addition to the ip command, can be used to diagnose most of the
commonly encountered networking problems. Most networking problems can be resolved by answering
the following series of simple, direct questions, in the order in which they are presented.
1. Are my interfaces appropriately configured?
a. Use the ip addr command to confirm that the interfaces are active, and have the appropriate IP
address and network mask.
b. Use the ping command to ping your machine's local IP address. If your interface is unresponsive,
something is wrong with the interface definition or the kernel's device driver.
2. Can I communicate with my router?
Use the ping command to ping the IP address of your default gateway. If you are unable to ping the
gateway, the problem could be that your machine is not physically connected to the local network.
3. Can I communicate with an external machine?
Use the ping command to ping the IP address of a known machine which is not on your local IP network.
If you are not able to ping your gateway but not an external host, the problem is probably your gateway
definition (or the gateway itself). Use the ip route command to confirm that your routing table has one
(and only one!) default gateway listed.
4. Can I resolve hostnames?
Notice that, until now, we have not even used hostnames or DNS. Once you have confirmed IP
connectivity using only IP addresses, you are ready to consider DNS configuration. Use the host
command to query the local nameserver for a known hostname (such as yours). If you do not receive an
answer, examine the /etc/resolv.conf file to insure that your nameserver is correctly specified.
Examining Network Activity with tcpdump

Most networking problems can be diagnosed with the handful of utilities and commands mentioned above
(namely, ip addr, ping, ip route, and host). When trying to troubleshoot more subtle network problems,
however, the tcpdump utility can be helpful.
rha130-6.1-1
54
The tcpdump command allows administrators to monitor the network directly, displaying summary
information about individual packets as they are read from the wire, as in the following example. The
tcpdump command, unless told otherwise, will continue until canceled with CTRL+C.
[root@station root]# tcpdump
tcpdump: listening on eth0
10:19:57.151068 station.example.com.32897 > station4.example.com.6001: . 3987564
558:3987566006(1448) ack 3703593894 win 31856 <nop,nop,timestamp 170715 44377410
> (DF)
10:19:57.151480 station4.example.com.6001 > station.example.com.32897: . ack 144
8 win 30408 <nop,nop,timestamp 44377411 170715> (DF)
10:19:57.151508 station.example.com.32897 > station4.example.com.6001: P 1448:26
00(1152) ack 1 win 31856 <nop,nop,timestamp 170715 44377411> (DF)
10:19:57.152780 station.example.com.32897 > station4.example.com.6001: . 2600:40
48(1448) ack 1 win 31856 <nop,nop,timestamp 170715 44377411> (DF)
...
CTRL+C
To knowledgeable observers, the output of the tcpdump command is dense with information, giving a
summary of IP (and other protocol) related packet information for individual packets. Less experienced
observers can be easily overwhelmed by the information. In our discussion, we seek to introduce the utility,
and use it to observe some of the protocols mentioned within this Workbook. An entire course could be
based on a complete discussion of the information reported by the tcpdump command.
tcpdump Command Line Switches

The following table summarizes some of tcpdump's more commonly used command line switches.
Table 5.2. tcpdump Command Line Switches

Switch
Effect
-w filename
Store output in the file filename in binary format, rather than write text to
standard out. The file may later by "replayed" with -r.
-r filename
"Replay" input from the file filename, which was collected previously with -w.
-c num
Exit after filtering num packets.
-e
Include data-link header information in output.
-i interface
Listen on interface interface. By default, tcpdump the "lowest numbered"

active interface. Using -i any specifies all interfaces.
-n
List IP addresses numerically, not as hostnames.
-q
Quick/Quiet output. Display less information for each packet.
-s packetlen
Observer the first packetlen bytes of each packet. The default is 68, which
is enough to observe information found in Ethernet, IP, and TCP/UDP headers.
Larger packet lengths will significantly slow performance, possible resulting in lost
packets.
-v, -vv, -vvv
"Verbose", "Very Verbose", "Very Very Verbose": Include more and more
information in each packet summary.
-x
Include a dump of the raw packet data in hexadecimal format in the output.
As an example, the output of the tcpdump command can be reduced to more succinct output using the n and -q command line switches.
[root@station root]# tcpdump -qn
10:49:40.985728 192.168.0.130.32897 > 192.168.0.4.6001: tcp 1448 (DF)
rha130-6.1-1
55
10:49:40.985744
10:49:40.986235
10:49:40.986260
10:49:40.986266
...
192.168.0.130.32897 > 192.168.0.4.6001:

192.168.0.4.6001 > 192.168.0.130.32897:
192.168.0.130.32897 > 192.168.0.4.6001:
192.168.0.4.6001 > 192.168.0.130.32897:
tcp
tcp
tcp
tcp
608 (DF)
0 (DF)
544 (DF)
0 (DF)
tcpdump Filters
After some experimentation with the tcpdump command, users quickly discover that the output can
become overwhelming. In order to effectively use tcpdump to troubleshoot a particular problem, the
output must be reduced to only relevant packets. Fortunately, tcpdump supports a robust filtering syntax,
which can be specified on the command line after any relevant command line switches.
A full appreciation of the various filter options requires a detailed knowledge of networking protocols. In
the following table, we summarize some of the simplest or most commonly used filter options.
Table 5.3. Specifying tcpdump Filters

Filter Expression
Effect
arp|tcp|udp
Only observe packets using the specified protocol.
host hostname
Only observe packets with a host or destination IP

address or hostname of hostname.
port portnum
Only observe packets with a source or destination

port of portnum. Implies either TCP or UDP
protocols.
Although this selection of filtering options only represents the tip of the iceberg, they can go a long way
towards narrowing tcpdump output to more meaningful data.
As a quick example, suppose an administrator is trying to diagnose a broken DNS configuration. Knowing
that DNS servers usually use the "well known" port 53, the administrator uses the tcpdump command
to eavesdrops on the conversation between her machine and the DNS server. She runs the tcpdump
command from a terminal, and opening another terminal, uses the host command to resolve the hostname
www.redhat.com. Returning to her original terminal, she finds the following.
[root@station root]# tcpdump port 53
17:26:15.193128 station.example.com.32775 > server1.example.com.domain:
A? www.redhat.com. (32) (DF)
PTR? 254.0.168.192.in-addr.arpa. (45) (DF)
17:26:15.194846 server1.example.com.domain > station.example.com.32775:
/3/0 A www.redhat.com (102) (DF)
1/1/1 (114) (DF)
1/1/1 (116) (DF)
/3/0 (126) (DF)
CTRL+C
57039+
35446+
57039 1
35446*
35447+
35447*
35448+
35448 1
Satisfied by the output that two way communication is occurring between the DNS server
server1.example.com and the local computer station.example.com, the administrator terminates the
command with a CTRL+C.
rha130-6.1-1
56
Examining Network Activity with wireshark

The tcpdump command, introduced previously, provides a quick and easy way to confirm network
activity, as well as a wealth of information to the experienced eye. When new to network protocols,
however, tcpdump's terse output can be perplexing. Enter wireshark.
When an X graphical environment is available, the wireshark application provides a more detailed
and friendly interface for exploring network communications packet by packet. If wearing a white hat,
wireshark is known as a network analyzer. If wearing a black hat, wireshark is known as a "packet
sniffer". Essentially, wireshark can be thought of as a graphical front end to the tcpdump command, and
many of the techniques found in one are implemented in the other.
The wireshark application can be started by choosing Applications Internet Wireshark Network
Analyzer or with the wireshark command from a terminal.
If not installed, Wireshark's graphical front-end is provided by the wireshark-gnome package which is
available in the "Optional" channel of Red Hat Network.
Capturing Network Traffic

One started, wireshark can be used to capture live network traffic by choosing the Capture Options...
menu item, which presents the following dialog.
Figure 5.1. Capturing Network Packets with wireshark
The capture dialog specifies which packets wireshark should capture from the network. We introduce a
few of the important fields which should be understood from the outset.
Important wireshark Capture Specifications

Interface: The network interface which wireshark should monitor for packets. Usually, eth0 or lo is
appropriate.
Packet Capture Length: By default, wireshark only captures the first 68 bytes of each packet, which is
enough to examine Ethernet, IP, TCP and UDP headers, but not much packet payload. If the packet data
is important, this size will probably want to be increased. This is equivalent to tcpdump's -s command
line switch. (The maximum expected packet size can be gaged from the MTU associated with the
interface, as reported by the ip addr command. For Ethernet networks, the maximum packet size is a
little over 1500 bytes.)
rha130-6.1-1
57
Capture Filter: The capture filter uses the same expressions as the tcpdump command (i.e., the
keywords tcp, host, port, and others) to limit the number of packets captured. A well chosen capture
filter can easily reduce the amount of time spent wading through irrelevant network packets.
When the capture dialog is closed with "Start", the capture begins. To stop the capture, Capture Stop
Browsing captured Packets

The main wireshark window allows captured packets to be examined using three different views.
Figure 5.2. The wireshark Network Analyzer
The top panel displays a summary of all captured packets, including the highest level packet protocol,
source and destination address (IP or otherwise), and a protocol specific summary line. The list is also
used to select an individual packet for closer examination.
The middle panel displays a hierarchy of the translated contents of the selected packet, displaying the
encoded information relevant to each protocol layer in an easy to read and navigate format. The example
above displays TCP protocol information, including the source port 80 and the destination port 32771.
In the bottom panel, a raw dump of the binary contents of the packet is displayed, as well as a translation
of any ASCII characters. Any information highlighted in the middle panel will also be highlighted here.
Unfortunately, a full discussion of this information is beyond the scope of this course.
At the bottom of the window, a display filter can be specified, so that only a meaningful subset of packets
will be viewed at any one time. Unfortunately, the syntax for specifying display filters is not the same as
for displaying capture filters. More information can be found within wireshark's Help menu.
Assembling a TCP stream

The TCP protocol, which is perhaps the most prevalent Internet protocol, decomposes a two way stream
of information into individual packets. The wireshark application can perform the reverse operation. By
selecting an individual packet, and choosing "Follow TCP Stream" (either by right clicking on the selected
packet in the top panel, or selecting the Analyze Follow TCP Stream menu item, the packet will be
associated with other packets from the same capture which constitute a single TCP connection. A single
window then presents the reassembled conversation between a TCP client (such as a web browser) and a
TCP server (such as a web server), as seen below. (Note that the default packet length (68 bytes) should
be significantly increased in order to see a complete conversation.)
rha130-6.1-1
58
Figure 5.3. Contents of TCP Stream as Reassembled by wireshark
Note that assembling a TCP stream will cause the display filter to automatically be set to the relevant TCP
connection. Pressing the "Reset" button next to the display filter clears any display filter.
Examples
Diagnosing Network Problems 1: No Interface
An administrator is receiving complaints that something is wrong with a web browser. "Whatever website I
type into the web browser, it can't find it." The administrator starts by examining the network configuration
of the machine, first listing all active interfaces.
Concerned that no external interface (such as eth0) is active, the administrator looks to see if an interface
configuration file exists.
# Intel Corp.|82540EM Gigabit Ethernet Controller
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:08:74:35:00:1F
ONBOOT=yes
TYPE=Ethernet
The file exists and appears to legitimately configure the interface to use DHCP, so the administrator tries
to raise the interface manually.
ip_tables: (C) 2000-2002 Netfilter core team
rha130-6.1-1
59
Assuming that the configuration received from the DHCP server was correct, the administrator tries to
ping a remote site by hostname.
[root@station root]# ping www.yahoo.com
PING www.yahoo.akadns.net (216.109.117.107) 56(84) bytes of data.
CTRL+C
--- www.yahoo.akadns.net ping statistics --2 packets transmitted, 2 received, 0% packet loss, time 1012ms
Convinced that both DNS and routing is now working, the administrator confirms that he can use a web
browser to lookup a website. Once successful, he assumes that there was a temporary glitch with the DHCP
server. Perhaps it was temporarily unavailable when this machine was booted.
Diagnosing Network Problems 2: Bad Gateway

of the machine, first listing all active interfaces. Finding what appears to be an appropriately figured
interface, he gives it a quick ping test.
CTRL+C
...
Next, the administrator check to see if he can ping the default gateway. He first examines the routing table,
then attempts to ping the listed gateway.
From 172.16.63.226 icmp_seq=0 Destination Host Unreachable
CTRL+C
Ah ha. He cannot contact the assigned gateway, 172.16.63.18. In order to ensure a good physical
connection, he glances behind the machine and notes that his Ethernet NIC's link light is enabled. He next
attempts to determine if he has the correct gateway, by examining the two configuration files where a
gateway could be defined, the global network configuration file, and the interface specific configuration
file.
[root@station root]# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=station.rdu.redhat.com
# Intel Corp.|82540EM Gigabit Ethernet Controller
rha130-6.1-1
60
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:08:74:35:00:1F
ONBOOT=yes
TYPE=Ethernet
Seeing no reference to a gateway, and noting that the interface must have received its gateway
configuration via DHCP, he examines the DHCP lease information file.
[root@station root]# cat /var/lib/dhcp/dhclient-eth0.leases
lease {
interface "eth0";
fixed-address 172.16.63.226;
option subnet-mask 255.255.254.0;
option dhcp-lease-time 21600;
option routers 172.16.63.18;
option dhcp-message-type 5;
...
}
Now that he has confirmed that the DHCP server issued the IP address 172.16.63.18 for the default
gateway, he assumes that the gateway is down, or that the DHCP server has been misconfigured. Not being
able to resolve either of these situations, he informs his local network administrator of the problem.
Diagnosing Network Problems 3: No DNS

of the machine, first listing all active interfaces. Finding what appears to be an appropriately figured
interface, he gives it a quick ping test.
CTRL-C
...
Next, the administrator check to see if he can ping the default gateway. He first examines the routing table,
then attempts to ping the listed gateway.
CTRL+C
...
Knowing that he can contact his default gateway directly, he next attempts to ping a distant IP address of
a machine he knows is usually available.
64 bytes from 194.152.92.168: icmp_seq=0 ttl=53 time=117 ms
rha130-6.1-1
61
64 bytes from 194.152.92.168: icmp_seq=1 ttl=53 time=118 ms

CTRL+C
...
The gateway seems to be functioning, routing his packets out to Internet. Knowing that he has good IP
connectivity, the administrator he begins to focus his attention on DNS. He attempts to perform a direct
DNS lookup for a well known site.
[root@station root]# host www.redhat.com
;; connection timed out; no servers could be reached
The administrator now suspects problems with the DNS configuration. He examines the /etc/
resolv.conf configuration file.
[root@station root]# cat /etc/resolv.conf
search example.com
namserver 172.16.2.122
namserver 172.16.2.121
Noticing the sloppy spelling of the word nameserver, he uses a text editor to apply corrections. He again
attempts to perform a DNS lookup.
[root@station root]# host www.redhat.com
www.redhat.com has address 66.187.232.50
Success. He confirms that he can successfully use the web browser, and leaves, puzzled as to who would
have been editing the file.
Online Exercises
Lab Exercise
Objective: Use tcpdump and wireshark to monitor a HTTP (Web) interaction.
Specification
You would like to examine in detail the interaction between your Web Client (Browser) and a Web Server.
You will use tcpdump to capture the transaction, and wireshark to examine the contents of the TCP/IP
stream between the two.
You will probably need to run the applications as root, but the resulting files should be stored in the home
directory of your academy user.
As written, this lab assumes your station's primary network interface is the interface eth0, and web servers
are contacted directly. If you are using a proxy server, replace port 80 below with the proxy server's port
number (provided by your instructor).
1. In a terminal, use the tcpdump command to monitor all traffic over your network interface eth0 which
involves the port 80, with a packet capture length of 1600. Leave tcpdump running it the foreground.
2. While tcpdump is running, use a web browser (such as mozilla or links) to access the site http://
www.redhat.com. As the transaction happens, the tcpdump command should report activity, similar
to the following.
[root@station root]# tcpdump -q -i eth0 -s 1600 port 80
03:42:47.139189 station.example.com.32994 > www.redhat.com.http: tcp 0 (DF)
rha130-6.1-1
62
03:42:47.167857 www.redhat.com.http > station.example.com.32994: tcp 0 (DF)

...
3. Cancel the tcpdump command with a CTRL+C. Rerun tcpdump adding the -w command line switch
to specify that captured packets should be written to the file ~/http.capture instead of summarized
to the console.
4. With the second tcpdump command running, again access the site http://www.redhat.com with a web
browser.
5. This time, the tcpdump command should not report any activity directly. Cancel tcpdump with a
CTRL+C. As it exits, tcpdump should report that a number of packets were "received by filter".
[root@station root]# tcpdump -q -w http.capture -i eth0 -s 1600 port 80
CTRL+C
62 packets received by filter
0 packets dropped by kernel
6. Use tcpdump with the -r command line switch to "replay" the captured transaction stored in the file
~/http.capture.
[root@station root]# tcpdump -r http.capture
03:48:17.749642 station.example.com.33010 > www.redhat.com.http: S 3242369745:32
42369745(0) win 5840 <mss 1460,sackOK,timestamp 258777 0,nop,wscale 0> (DF)
03:48:17.779164 www.redhat.com.http > station.example.com.33010: S 1935430624:19
35430624(0) ack 3242369746 win 8760 <mss 1380,eol> (DF)
03:48:17.779174 station.example.com.33010 > www.redhat.com.http: . ack 1 win 584
0 (DF)
...
7. Start wireshark, and load the contents of the file ~/http.capture (either by specifying the file on
the command line, or "opening" the file once wireshark has started).
8. From within wireshark, select any packet, and choose "Follow TCP Stream" (either from the context
sensitive menu raised by right clicking on the packet, or from the Analyze menu). Examine the contents
of the stream.
9. In the "Contents of TCP Stream" window, observe the transaction between the web client and server.
Save the text contents of the stream into the file ~/http.stream by selecting "Save As" from the
bottom of the "Contents of TCP Stream" window.
Optional Additional Exercise
1. Repeat the exercise, instead capturing a transaction between your web client and https://rhn.redhat.com.
You will need to filter on the port 443 instead of the port 80. Do not clobber (overwrite) any of the
files produced above in the process. How does the contents of the TCP stream differ between the http
and https protocol?
Deliverables
1.
1. In your home directory, the file ~/http.capture, which contains a (binary) captured
conversation between your web client and the web server at http://www.redhat.com (or an
intermediate proxy server).
2. In your home directory, the file ~/http.stream, which contains the contents of the (ASCII)
extracted TCP/IP conversation between the web client and web server.
rha130-6.1-1
63
Questions
1.
Which of the following utilities is used to confirm low level IP connectivity between two machines?
a.
host
b.
netstat
c.
ip
d.
ping
e.
None of the above
2.
Which of the following utilities is used to perform DNS hostname resolutions directly?
a.
tcpdump
b.
host
c.
netconfig
d.
ip
e.
traceroute
In the following scenarios, you are trying to resolve networking problems on the Red Hat Enterprise Linux
machine station5.example.com. Your default gateway to the Internet should be the machine 192.168.0.254,
and your nameserver should be the machine 172.16.18.1. (Ignore the fact that these IP addresses should
be reserved for private networks. Instead, assume they are all fully routable by the Internet.)
Figure 5.4. Network Configuration
rha130-6.1-1
64
Scenario 1 A web browser on the machine station5.example.com is having difficulty accessing the
website www.redhat.com. Running the following commands at the terminal produces the following output.
(Several seconds elapses between the starting of the ping command, and the interrupting with a CTRL+C,
with no output reported.)
[root@station5 root]# ip addr
link/ether 00:08:74:35:00:1F brd ff:ff:ff:ff:ff:ff
[root@station5 root]# ping 192.168.0.8
CTRL+C
3.
Which of the following is the most likely explanation of the difficulty?

a.
The nameserver is configured incorrectly.
b.
The network interface is configured incorrectly.
c.
The default gateway is configured incorrectly.
d.
The Ethernet cabling behind the machine has become detached.
e.
The network interface, though correctly configured, is not active.
Scenario 2 A web browser on the machine station5.example.com is having difficulty accessing the website
www.redhat.com. Running the following commands at the terminal produces the following output.
CTRL+C
[root@station5 root]# ip route
CTRL+C
4.
rha130-6.1-1
What is the most likely explanation of the difficulty?

a.
b.
65
c.
d.
e.
5.
Editing which file would most likely solve the problem addressed above?
a.
b.
c.
/etc/sysctl.conf
d.
/etc/resolv.conf
e.
/etc/hosts
Scenario 3 A web browser on the machine station5.example.com is having difficulty accessing the website
www.redhat.com. Running the following commands at the terminal produces the following output.
CTRL+C
[root@station5 root]# ip route
[root@station5 root]# cat /etc/resolv.conf
search example.com
[root@station5 root]# host www.redhat.com
;; connection timed out; no servers could be reached
6.
What is the most likely explanation of the difficulty?

a.
b.
c.
d.
e.
7.
rha130-6.1-1
Which file should be edited to correct the problem?

a.
b.
/etc/resolv.conf
66
c.
/etc/sysconfig/ifcfg-eth0
d.
/etc/hosts
e.
/etc/sysctl.conf
8.
Which of the following utilities is used to trace a packet's path as it traverses from IP network to
IP network on its way to a destination?
a.
traceroute
b.
ping
c.
host
d.
tcpdump
e.
wireshark
9.
Which of the following command lines would capture transactions between a web browser and
a web server using the HTTP protocol (with a well known port 80), but only transactions to a
webserver at port 80, and record the transactions in the file http.capture (in binary format)?
a.
tcpdump -o http.capture -p 80
b.
tcpdump -p 80 > http.capture
c.
tcpdump 80
d.
tcpdump -c http.capture -s 80
e.
tcpdump -w http.capture -s 1600 port 80
10.
rha130-6.1-1
Which of the following utilities can be used to analyze entire transactions between network clients
and servers?
a.
host
b.
netmon
c.
traceroute
d.
ping
e.
wireshark
67

Part Workbook 6. Network Configuration

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Part Workbook 6. Network Configuration

Cargado por

Copyright:

Formatos disponibles

Part Workbook 6.

Copyright 2011, Red Hat Inc.

Online Exercises ...................................................................................................... 35

Copyright 2011, Red Hat Inc.

Chapter 1. Managing Network

Figure 1.1. Enabling and Disabling Interfaces with Network Manager

Copyright 2011, Red Hat Inc.

Managing Network Interfaces

Figure 1.2. Configuring Network Settings with Network Manager

Red Hat Enterprise Linux as a Networking Machine

Copyright 2011, Red Hat Inc.

Managing Network Interfaces

Configure one or more DNS nameservers.

Network Interface Cards (NICs)

Table 1.1. Common Linux Interface Names

The (virtual) loopback device

Serial Line (usually a Modem), using the PPP protocol

Examining Interfaces with ip addr

Copyright 2011, Red Hat Inc.

Managing Network Interfaces

link/ether 00:00:86:4d:f0:0c brd ff:ff:ff:ff:ff:ff

Configuring Network Interfaces with ip

Table 1.2. Common ip link set commands

Activate the interface.

Deactivate the interface.

Set the MTU (maximum transfer unit) for the interface to

Copyright 2011, Red Hat Inc.

Managing Network Interfaces

Interface Configuration Files: ifcfg-eth0

Table 1.3. Variables Relevant to Interface Configuration Files

A required entry, which defines the interface for which this

How the interface should receive its configuration

The IP address to associate with the interface.

Copyright 2011, Red Hat Inc.

Managing Network Interfaces

The network mask to associate with the specified IP

Should the interface be started automatically as part of the

Can normal users control the interface? By default, only the

Gateway to use for routing packets out of the local network.

Indicates if the Network Manager service should control

Controlling Interfaces with ifup and ifdown

Copyright 2011, Red Hat Inc.

Managing Network Interfaces

inet6 ::1/128 scope host

state UP qlen 1000

state UP qlen 1000

state UP qlen 1000

state UP qlen 1000

Configuring Interfaces as a DHCP Client

Copyright 2011, Red Hat Inc.

Managing Network Interfaces

[root@station130 root]# cat /etc/sysconfig/network-scripts/ifcfg-eth0

[root@station root]# ip addr

Before the interface is raised, only the loopback device is active.

Copyright 2011, Red Hat Inc.

Managing Network Interfaces

link/ether 00:00:86:4d:f0:0c brd ff:ff:ff:ff:ff:ff

Copyright 2011, Red Hat Inc.

Managing Network Interfaces

In the output of the lspci command, he observes a single Ethernet device.

Copyright 2011, Red Hat Inc.

Managing Network Interfaces

2 packets transmitted, 2 received, 0% packet loss, time 1007ms