Configuring Network Interfaces
Network Connectivity Tools
Basic Network Services
With nearly every corporate and government workplace making use of networked computers, being able to configure and troubleshoot network devices and services is a fundamental part of an administrator’s job. Like most modern operating systems, Linux supports the TCP/IP protocol and has a number of tools for managing network adapters and protocols.
Configuring Network Interfaces
Just like any other hardware in Linux, network interfaces are identified using a standard naming convention. The first Ethernet interface is always eth0. The second is eth1. Any additional Ethernet interfaces are numbered sequentially. Wireless Ethernet adapters are named starting at wlan0. Any PPP interfaces are named beginning with ppp0. The loopback interface is called lo0.
The network service is used to start or stop all network devices. This service is merely a script that starts each networking component in turn. On RedHat based distributions, this service first reads the contents of the file /etc/sysconfig/network to gather system wide network settings. An example /etc/sysconfig/network file looks like this:
The network service then checks whether nonstandard settings such as IPv6 or IPX are in use and starts them if needed. Next the network service looks for network adapters to start. Each network adapter will have a configuration script in the /etc/sysconfig/network-scripts directory. These configuration scripts use the following naming convention: ifcfg-<interface_name>. A script to configure the first Ethernet interface would be named ifcfg-eth0 and could look like this:
# Intel Corp.|82547GI Gigabit Ethernet Controller
Notice that these settings are specific to that particular adapter. The network service can be manually started, stopped or restarted by calling it with the appropriate parameter:
Starting or restarting the network service will result in a message that displays which network interfaces are trying to start and whether they were successful or not. You can also check the status of a system’s network interfaces using the ifconfig command. Used without any parameters, ifconfig will display the status of all active network adapters:
eth0 Link encap:Ethernet HWaddr 00:11:25:BA:5F:8C
inet addr:10.0.0.2 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:45135830 errors:0 dropped:0 overruns:0 frame:0
TX packets:56287524 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:315903775 (304.4 Mb) TX bytes:284703199 (278.7 Mb)
Base address:0x2000 Memory:d0120000-d0140000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:516385 errors:0 dropped:0 overruns:0 frame:0
TX packets:516385 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:94513448 (90.1 Mb) TX bytes:94513448 (90.1 Mb)
The -a option will display the status of all adapters including those that are down. Ifconfig is the most common command for checking basic information such as the IP address or whether an interface is enabled. The ifconfig command can also be used to configure an interface. A simple command using ifconfig shows how to set an IP address and subnet mask:
ifconfig eth0 10.0.0.3 netmask 255.0.0.0
Settings configured in this manner are only kept until the machine is rebooted. To make network settings permanent the changes must be made to the appropriate configuration file in the /etc/sysconfig/network-scripts directory. Ifconfig can be used with either the up or down parameter to start or stop an interface. This example disables the first Ethernet interface:
ifconfig eth0 down
Two other commands exist to manually start or stop a single network interface: ifup and ifdown. The first command enables the first Ethernet interface, while the following command disables it, for example:
Unfortunately, ifconfig cannot be used to configure DNS settings. To do this you must use a distribution specific tool (such as netconfig ) or edit the /etc/resolv.conf file directly. A list of DNS servers to query are listed in /etc/resolv.conf using the following format:
Network Connectivity Tools
The simplest tool for testing that your network card has been correctly configured is the ping command. This simple utility is part of the TCP/IP protocol suite and can be used to test communication between any two TCP/IP devices. The ping command accepts both IP addresses and hostnames as parameters and will continue to send packets until Ctrl-C is pressed:
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.226 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.186 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.155 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.220 ms
64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=0.171 ms
--- 10.0.0.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4998ms
rtt min/avg/max/mdev = 0.155/0.197/0.229/0.033 ms
The ping command can be used to isolate a failing network device and narrow down the cause of connectivity problems. A common strategy is to ping the nearest device and work outward until connectivity is lost. Generally, this involves pinging the loopback adapter (127.0.0.1) to make sure TCP/IP is correctly installed on the local machine. The next step is to ping the IP address of the local machine to make sure its network card is correctly configured. If the destination device is on a different network, the next step would be to ping the default gateway of the local machine to make sure you can communicate with other devices on the same network. Continue pinging devices further and further away until the problematic link is identified. Pinging a device by its hostname can also be used to test whether name resolution is working properly.
Often, a network problem lies outside of the local network. The traceroute command displays each gateway packets travel through to reach a destination. This command can be used to identify a router that is down or incorrectly routing packets. The –n option disables name resolution lookups which can significantly speed up a trace.
traceroute to google.com (18.104.22.168), 30 hops max, 38 byte packets
1 10.0.0.1 (10.0.0.1) 0.505 ms 0.468 ms 0.410 ms
2 10.0.56.133 (10.0.56.133) 3.648 ms 3.830 ms 3.815 ms
3 10.0.200.205 (10.0.200.205) 4.185 ms 3.802 ms 3.766 ms
4 sl-gw10-roa-3-2.sprintlink.net (22.214.171.124) 11.934 ms 13.095 ms 12.809 ms
5 po14-0.nykcr2.NewYork.opentransit.net (126.96.36.199) 90.060 ms 90.184 ms 89.995 ms
6 po10-0.nykcr3.NewYork.opentransit.net (188.8.131.52) 90.006 ms 90.260 ms 90.123 ms
7 po2-0.ashcr2.Ashburn.opentransit.net (184.108.40.206) 95.467 ms 95.418 ms 95.602 ms
8 so-6-0-0-0.atlcr1.Atlanta.opentransit.net (220.127.116.11) 89.134 ms 89.228 ms 89.374 ms
9 google-us-customers-3.GW.opentransit.net (18.104.22.168) 52.479 ms google-asia-customers-3.GW.opentransit.net (22.214.171.124) 49.140 ms google-us-customers-3.GW.opentransit.net (126.96.36.199) 50.243 ms
10 188.8.131.52 (184.108.40.206) 49.083 ms 220.127.116.11 (18.104.22.168) 50.620 ms 22.214.171.124 (126.96.36.199) 48.756 ms
11 188.8.131.52 (184.108.40.206) 50.368 ms 50.683 ms 51.950 ms
12 220.127.116.11 (18.104.22.168) 50.467 ms 50.695 ms 50.738 ms
The netstat command is used to show current network information such as open sockets, active connections, routing tables and interface statistics. The most common options are:
Shows all active and listening sockets
Shows updated information continuously
Shows statistics for each network interface
Disables name resolution
Shows routing tables
Shows only TCP connections
Shows only UDP connections
An alternate command for displaying routing tables is route.
Basic Network Services
Most system services, or daemons, run continuously in the background waiting for something to happen. Printing services are almost always configured this way. Network services are configured differently. Rather than having an instance of each needed service running 24 hours a day and using resources, most network services are managed by a super-service called xinetd. Xinetd runs continuously listening for network connections. When a connection is initiated, xinetd identifies the type of connection (ftp, telnet, ssh, etc.) and starts the appropriate network service to handle the connection. When the connection is closed xinetd stops the service.
Xinetd is actually an improved version of inetd (still found on older systems.) The main differences are that xinetd is modular (therefore more portable) and easier to configure. Inetd relies on a single configuration file, /etc/inetd.conf, to define all services that it manages. An example inetd.conf file contains several lines like this:
By comparison, the /etc/xinetd.conf file contains a few default settings and exists mainly to define a directory that contains definitions of each service xinetd manages. By default, this directory is /etc/xinetd.d. Each service is defined in its own configuration file. The telnet definition file looks like this:
# default: on
# description: The telnet server serves telnet sessions; it uses
# unencrypted username/password pairs for authentication.
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
The xinetd configuration is more intuitive and since services are configured as individual files, configuring a new service on several different machines is simply a matter of copying files.
In addition to services that provide resources to users, such as email, ftp or http, xinetd is often used to control services that provide remote management capabilities to administrators. Older services such as rsh (remote shell) and rlogin (remote login) are still in use but are inherently insecure and are rarely enabled on new servers. Telnet and ssh (secure shell) are the most common remote management services in use today. Telnet is bundled in nearly every distribution, is easy to install, and provides full command line access to a remote machine. The downside is that login information is not encrypted and can be captured by anyone on the network using a packet sniffer. Because of this, telnet should never be used to connect to a machine that is part of an untrusted network (such as the Internet.) The ssh package allows you to login and manage a server securely using a number of encryption algorithms including 3DES, Blowfish, AES and RSA.