Joey's Notes: Basic Networking and IP Forwarding
By Joey Prestia
Linux is a networking powerhouse. It can act as a DHCP server, a network router, a simple client, a gateway, a bridging firewall -- well, you get the idea. To accomplish these tasks - indeed, to make it to work at all - there are several key files that must be configured properly. That is the subject of this month's article.
Working in the computer lab at the college's Red Hat Academy, I am often faced with helping students fix their network configuration so they can get out to the Internet through the network. Since our computer lab is shared with the Microsoft lab, all the computers are labeled, and have removable hard drives to allow for easy switching between Red Hat Linux and Windows. This would be an excellent way to do things - if students would put the proper drive in the proper computer in the Red Hat Lab. They don't, of course, and they constantly move them - so I get to assist in the proper reconfiguration of their networking.
To verify your specific configuration, you need to first find out what your specific network configuration should be, either from your ISP or your network administrator. Please do not go by the settings I have used as examples here; they will not be correct for your machine and specific setup. And always make a backup of your configuration files (e.g., cp /etc/sysconfig/network /etc/sysconfig/network.bak) before you make any changes to them! I don't suggest making any changes to your system if your networking is already working; this is intended to be a starting point for understanding how these files control basic networking on a Linux machine. If you do modify any settings, you will probably need to at least bring the network interface down, then back up, or restart networking on the machine to see if the changes worked.
To configure basic networking on a Red Hat system, there are several key configuration files we must check. They are:
- /etc/sysconfig/network-scripts/ifcfg-eth0 This file contains your network card settings
- /etc/sysconfig/network This file contains various other settings, mainly the hostname and gateway
- /etc/resolv.conf This file contains our search domain and nameservers
- /etc/hosts Hostname and other entries for local machines not in DNS
To configure IP forwarding on a Red Hat system, the configuration file we must check is:
- /etc/sysctl.conf Configuration file for various aspects of kernel routing and IP forwarding
Configuration of the "/etc/sysconfig/network-scripts/ifcfg-eth0" file
In this file, you would find your basic network device configuration. Here, ifcfg-eth0 is the first Ethernet device; ifcfg-eth1 would be the second Ethernet NIC (network interface card), and so forth. In this file, you can have quite a few settings.
|Directives||Required / Optional||Expected Settings||Comment|
|DEVICE=||Required||ethX||You must have this entry specifying the Linux device name.|
|ONBOOT=||Optional||yes / no||Start the device on boot? This will default to yes.|
|BOOTPROTO=||Required||static / dhcp / none||Static hard set our IP, or do we want a dhcp assignment? "dhcp", "none" is the same as static.|
|IPADDR=||Optional||IP address of machine||The address we want if we are setting a static IP for the interface.|
|NETMASK=||Optional||Subnet mask||Required for static IPs. The subnet mask.|
|NETWORK=||Optional||Network address||Recommended for static IPs. The network that we are on.|
|BROADCAST=||Optional||Network broadcast address||Recommended for static IPs. The broadcast address.|
|HWADDR=||Optional||Device MAC address||The MAC address of our network card. Normally provided by the Anaconda installer at install time.|
|USERCTL=||Optional||yes / no||Allow normal non-administrative user to take down and bring up the device. Defaults to "no".|
|GATEWAY=||Optional||IP address of gateway||The network gateway IP address.|
Not all of these are necessary for proper operation, and the order they are in is irrelevant. I prefer to specify the additional directives of NETWORK and BROADCAST in my /etc/sysconfig/network-scripts/ifcfg-eth0 on machines that I want to have a hard-set IP address, mainly servers of any sort. If you want to use a DHCP-assigned address, your /etc/sysconfig/network-scripts/ifcfg-eth0 file would look something like this:
# Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] DEVICE=eth0 BOOTPROTO=dhcp HWADDR=08:00:27:4B:3B:06 ONBOOT=yes
Of course, your HWADDR address would be different. In addition, the comment would reflect your network adapter or may not even be present. Here are some guidelines (I left my settings in as an example, just to give an idea what it would look like):
Recommended Static Directives Sample Configuration
DEVICE=eth0 ONBOOT=yes BOOTPROTO=static IPADDR=192.168.0.17 NETMASK=255.255.255.0 NETWORK=192.168.0.0 BROADCAST=192.168.0.255Minimum Recommended Static Directives Sample Configuration
DEVICE=eth0 BOOPROTO=static IPADDR=192.168.0.17 NETMASK=255.255.255.0
Minimum DHCP Directives Sample Configuration
Configuration of the "/etc/sysconfig/network" file
This file defines the basis for networking on the machine; again, not all directives have to be set for our network configuration to work. A lot depends on the configuration.
|Directives||Required / Optional||Expected Settings||Comment|
|NETWORKING=||Required||yes / no||Enable networking.|
|HOSTNAME=||Required||Hostname||The machine hostname. It's a good practice to put the Fully Qualified Domain Name in here.|
|GATEWAY=||Recommended||IP address of gateway||The gateway out of our network.|
|NETWORKING_IPV6=||Optional||yes / no||Enable IPV6 networking capability.|
|NISDOMAIN=||Optional||NIS domain name||The name of our NIS domain, if we are connecting to one.|
|GATEWAYDEV=||Optional||ethX||Gateway device to use if we have more than one NIC.|
The /etc/sysconfig/network file should contain the IP address of the gateway device through which the traffic leaves your network. In a simple home network configuration, this would be your router's internal IP address. This file can be as simple as this example below, and may contain any number of the above elements, depending on your configuration. For DHCP configurations, you may not even have a gateway listed in this file, and will probably have only the NETWORKING and HOSTNAME elements defined.Recommended Static Directives Sample Configuration
NETWORKING=yes HOSTNAME=localhost.localdomain GATEWAY=192.168.0.254Minimum DHCP Directives Sample Configuration
Configuration of the "/etc/resolv.conf" file
This file deals with DNS nameserver resolution. If you executed, e.g., "nslookup google.com" and didn't get an answer, this would probably be the culprit. This file usually contains the search domain and nameserver IP address. It may contain the word "domain" in place of the word "search".
|Directives||Required / Optional||Expected Settings||Comment|
|search||Optional||Domain name||The search domain.|
|domain||Optional||Domain name||The domain the machine is on.|
|nameserver||Required||IP address of nameserver||One or more nameservers are required to perform name resolution.|
Here is what a typical /etc/resolv.conf looks like, just as it was generated by the DHCP script.
; generated by /sbin/dhclient-script search example.com nameserver 10.0.2.3
You can have multiple nameservers listed in this file, which is a good practice and provides a type of fault tolerance in case the first nameserver fails. In that case, it would then go on to the next one in the list. As matter of fact, you can lighten the load on nameservers this way, by specifying that half of a large network gets a certain nameserver as the primary, and the other half has the order of the nameservers reversed.Recommended resolv.conf Directives Sample Configuration
search example.com nameserver 10.0.2.3 nameserver 188.8.131.52Minimum resolv.conf Directives Sample Configuration
Configuration of the "/etc/hosts" file
This is the file that resolves our loopback IP address 127.0.0.1 to our hostname localhost.localdomain. This is also the first place that your machine will attempt to resolve hostnames to IP addresses, unless the lookup order in the /etc/nsswitch.conf file has been changed. The line "hosts: files dns" says to look first in the /etc/hosts file then to DNS for answers.
One way to prove that the machine will look in the /etc/hosts file for name service is to try this little exercise:
My daughter is a normal teenager obsessed with Myspace, and, if I let her, would spend her entire life, wasting away, on this site. According to her, all is meaningless compared to this site. At the college, it gets an astounding 20,000 hits a day -- an incredible waste of time, especially for college students. To remedy this at home, I have implemented a minor modification on her Windows computer, and all my Linux machines. I edit the hosts file on the machines. In Windows, it's in c:\Windows\system32\drivers\etc\hosts; in Linux, /etc/hosts. I ping the site I want her to view instead (i.e., 'ping www.cnn.com') to get the IP address. I then take the IP address and add that to the hosts file, across from the hostname of www.myspace.com, like this:
# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 184.108.40.206 www.myspace.com myspace.com
Now, when she gets home from school and tries to go to Myspace, it will resolve by first checking this file, and looking up the IP address for Myspace as being 220.127.116.11, which is really the IP address of CNN news, so she gets to instead view the current world news. She soon gets disgusted by the war in Iraq and Middle East terrorism, and resumes the functions of a normal human teenager instead of that of a Myspace addict. Now, she's thinking that there is a problem with the Myspace Web site. To verify that this works, open a Web browser and try to go to Myspace with the new addition to your /etc/hosts file. You will be redirected to cnn.com.
[ Of course, now that Joey has written this article
and explained his
base treachery perfectly reasonable
parental control measures, his daughter will happily reverse the procedure
by pinging myspace.com, etc. Sorry, pal - you'll have to think harder than
that to outwit your teenager! :) -- Ben ]
A typical /etc/hosts for a networked computer could look like this:
# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 192.168.0.17 station17.example.com 192.168.0.100 workbox.example.com workbox 192.168.0.110 nfsbox.example.com nfsbox 192.168.0.120 mail.example.com mailMinimum Configuration IPV4
127.0.0.1 localhost.localdomain localhostMinimum Configuration IPV6
127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6
IP ForwardingConfiguration of the "/etc/sysctl.conf" file to enable IP forwarding
For basic network configuration, you should not need to change anything in this file, but I believe it is important to be aware that the option to enable IP forwarding exists in this file. IP forwarding would be enabled to allow use of the system as a router or gateway for our network, and is only one of the steps involved in the process. This file has several advanced kernel configuration options that are beyond the scope of this article, so we will just discuss IP forwarding at this time. The comment section at the top of this file says it uses binary values -- a "0" indicates the option is disabled and a "1" indicates enabled, as stated in the comments below. If we make changes to this file, we would need to make the kernel re-parse the /etc/sysctl.conf file. You would use the "sysctl -p" command to get this to happen. It will produce some output, as I have shown below.
# Kernel sysctl configuration file for Red Hat 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 # Controls source route verification net.ipv4.conf.default.rp_filter = 1 # Do not accept source routing net.ipv4.conf.default.accept_source_route = 0 # Controls the System Request debugging functionality of the kernel kernel.sysrq = 0 # Controls whether core dumps will append the PID to the core filename # Useful for debugging multi-threaded applications kernel.core_uses_pid = 1 # Controls the use of TCP syncookies net.ipv4.tcp_syncookies = 1 # Controls the maximum size of a message, in bytes kernel.msgmnb = 65536 # Controls the default maximum size of a message queue kernel.msgmax = 65536 # Controls the maximum shared segment size, in bytes kernel.shmmax = 4294967295 # Controls the maximum number of shared memory segments, in pages kernel.shmall = 268435456
Here is the output produced from re-parsing this file after IP forwarding was turned on in /etc/sysctl.conf:
[root@localhost ~]# sysctl -p net.ipv4.ip_forward = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 kernel.sysrq = 0 kernel.core_uses_pid = 1 net.ipv4.tcp_syncookies = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 4294967295 kernel.shmall = 268435456 [root@localhost ~]#
[ Note that the same functionality can be achieved within a given session and without any need to reboot, etc., by setting the values in the appropriate files in the /proc directory - e.g., 'echo 1 > /proc/sys/net/ipv4/ip_forward' will enable IPv4 IP forwarding. A more permanent configuration, however, is done just as described above. -- Ben ]
That about sums it up. Remember to always comment out items you don't plan on using in these files, instead of deleting them from the files. Then, to verify that things work, you will need to restart networking on the machine and verify connectivity. This way, if you need to, you can re-enable the option again very easily, and you don't lose the settings as they were originally. If you are not in this habit already, this is one that you will need to develop, as it will save you a lot of headaches.
- Red Hat Enterprise Linux Documentation
- Michael Jang's book Red Hat Certified Engineer Linux Study Guide, Fifth Edition
- Mark G. Sobell's book A Practical Guide to Red Hat Linux, Third Edition
Joey was born in Phoenix and started programming at the age fourteen on a Timex Sinclair 1000. He was driven by hopes he might be able to do something with this early model computer. He soon became proficient in the BASIC and Assembly programming languages. Joey became a programmer in 1990 and added COBOL, Fortran, and Pascal to his repertoire of programming languages. Since then has become obsessed with just about every aspect of computer science. He became enlightened and discovered RedHat Linux in 2002 when someone gave him RedHat version six. This started off a new passion centered around Linux. Currently Joey is completing his degree in Linux Networking and working on campus for the college's RedHat Academy in Arizona. He is also on the staff of the Linux Gazette as the Mirror Coordinator.