There are many ways to skin the proverbial cat when it comes to doing things on
UNIX® servers. Some people prefer to use the command line to execute
commands with all the flags, while others prefer GUIs and X window sessions.
While one person may modify a file directly with vi,
another will run a specialized command to update its contents automatically.
And the same is true with networking because of all of the options available to
systems administrators.
IBM AIX is one of the most robust operating systems around, but it can be somewhat confusing to find the best way of doing network-related tasks, like plumbing up an interface or modifying a default route. In my years of managing thousands of diverse servers, I've found all sorts of interesting ways of tackling network administration (and made mistakes along the way). And, in the process, I've found what I would consider to be the best, quickest, and easiest ways to manage AIX networking.
This article is intended to provide you with the basics of configuring network devices. It addresses areas such as the roles certain files play, how to set up and configure interfaces, and how to manage some of the nuances of routing and IP aliasing.
If you come from a background such as Sun Solaris, HP/UX, or Linux®, the
networking in AIX will seem like a radical departure from the standard flat-file
design that other flavors of UNIX employ. Much of the management of AIX
network administration is handled through the Object Data Manager (ODM),
a specialized database similar to the system registry in Windows®
operating systems. It is not directly manipulated through editing files but
instead tracks system information via specialized commands, like
mktcpip and lsattr.
However some areas, such as hostname resolution, still use flat files that you can
edit directly.
Likewise, when you use a new network card in a server, such as a dynamic I/O resource allocation to a logical partition (LPAR), at least two devices will be present in /dev: one represents the physical attributes of the card, while the other is a logical representation of the card. For example, the first Ethernet card in a server has three device files: /dev/ent0 (the physical interface representation), /dev/en0 (the logical interface representation), and /dev/et0 (the IEEE 802.3 logical interface representation). So, although you can change the media speed and duplex on the physical interface, you set up the IP address and subnet on the logical interface.
Note: This does change a bit if you are using virtualized adapters under Virtual I/O (VIO) control.
Similarly, although some commands have a permanent effect on the network
configuration, others have effects that last only until the next reboot. Therefore,
it is important to know the difference between turning off a network card on a
short-term basis with the ifconfig command versus
dropping it with the chdev command. In addition,
the commands that are executed via the System Management Interface Tool
(smit) might not call the particular one you want,
so it helps to double-check things with the F6 key before committing your
changes.
There is a common maxim around AIX systems administrators that you can tell
those who know what they're doing from the others by their reliance on
smit. A person who is overly dependent on
smit typically lacks many of the foundations and
knowledge of the operating system and uses the tool as a crutch. But, there
are some situations where smit is so much more
elegant and simple than trying to negotiate 200-character-long commands with
a dozen flags, and one of them is basic network configuration.
When you have your network card assigned and detected (by running
cfgmgr), the easiest way to set up your first
(primary) network interface is to run smitty tcpip.
Choose Minimum Configuration & Startup, and then select
the appropriate logical interface, as shown in Figure 1.
Figure 1. Minimum Configuration & Startup
Within this window, you must fill in several pieces of information, including the server's
hostname, the IP address, netmask, nameserver IP address and domain, and your
default route. When you are ready for this configuration to take effect, scroll down
to the START TCP/IP daemons, and press Option-Tab to
select yes.
When you press Enter, the settings take effect immediately. The system loads all of the relevant services that have been configured to run in the /etc/rc.tcpip file (that is, NFS, automounter), and the network interface will be available. The system also defines a logical device in the ODM—inet0—which is related to hostname and routing information.
Configuring additional network interfaces and parameters
At this point, you might want to configure an additional network interface for something like a backup network. For example, if your server name is test, you may want to call this IP address test-backup. Although your initial inclination might be to go back to the Minimum Configuration & Startup window, that would be the wrong choice.
If you went back to that window and supplied in the information you desired, it would
rename the entire server to test-backup and could potentially change
your default route when the inet0 device is modified. Also, as the TCP/IP services
are recycled, it is possible that you could lose connections such as NFS mounts.
Instead, another smit menu helps you out:
smitty chinet (see Figure 2).
Figure 2. Change/Show a standard Ethernet interface
The smitty chinet menu allows you to assign an IP address and netmask to a network interface without disturbing the underlying existing network interfaces or inet0. Enter the relevant information into the INTERNET ADDRESS and Network MASK fields, and then tab the Current STATE field to up. After you press Enter, the interface will immediately come up.
But how do you handle assigning the interface a host name on the server? This is where you need to modify two files directly. The first is the /etc/hosts file, which contains local definitions for IP addresses; you can specify the relationship between an IP address and a host name, just like with most other major flavors of UNIX. Here, you can provide additional host information, local name aliases, and hard-code IP addresses.
The second file is /etc/netsvc.conf. This file tells the server how to perform host name
resolution, much like how the nsswitch.conf file works on Solaris servers. By
entering a string like hosts = local, bind in the file,
the server will look to the local hosts file before going out to DNS. And, if you need
to change your DNS host name resolution parameters, you can modify the
/etc/resolv.conf file to include additional DNS servers, search specific domains,
and other options like retries or retransmissions.
When you have your network interfaces up and on the wire, it may be necessary to provide additional information about routes. These routes tell the server how to get to specific hosts or networks outside by going through the default gateway. And this is where I deviate slightly from the norm.
If you use smit to change your route information through
the smitty route menu, it calls a chdev
command to modify inet0 with the new route. This route change takes place
immediately and registers a new entry in the ODM’s Customized Attribute database
(CuAt). This process works perfectly well to accomplish the goal, but there are two
reasons why I do not advocate it.
First, if you need to check which routes are active, you have to look in two different
places. You have to look at the output from netstat –rn
to see which routes are live on the server, and then cross-check this information
against the ODM with a lower-level command like:
odmget -q "attribute = route" CuAt |
You do this to see which routes the system has stored that may go active at boot time, but it's inconvenient.
Second, if something gets messed up, you may have to go in surgically and modify the ODM directly. Although AIX has evolved greatly from the old days, when hands-on manipulation of the ODM was required and one errant keystroke could render a server unusable, it is still possible to mess things up in the ODM.
Instead, I advocate using the /etc/rc.net file as a storage place for routes you need to add. Within the file, there is a section pre-designed by IBM to hold route information. Look for "Part II - Traditional Configuration," and you will see an area in which you can add routes. This way, you have a flat file that is easily modified, contains the route information in a straightforward way, and doesn't manipulate the ODM.
The route commands are simple, as well. To add a route
to a host, run the command below with your appropriate information in place of
the variables, and add it to the /etc/rc.net file:
route add –host $HOST_IP $GATEWAY |
To add a route to a network, do the same with the following command:
route add -net $NETWORK -netmask $NETMASK $GATEWAY |
If you ever need to delete a route using this method, it is as simple as substituting
add with delete, running the
command, and removing the specific line from the /etc/rc.net file.
One other potential problem that can occur with route manipulation is
getting duplicate default routes. This usually happens when someone changes
the default route on the primary network interface with the Minimum
Configuration & Startup window. The new route takes effect
immediately, but the ODM stores both the old and new default routes.
Consequently, a reboot can cause the server to come up with two default
routes, resulting in all sorts of headaches, visible with
netstat -rn. The following process can fix this
issue easily:
- Flush the routing table from the ODM and on the live server by
running:
/etc/route -n –f and odmdelete -o CuAt -q "name=inet0 and attribute=route"
- Go back through the Minimum Configuration & Startup
page, re-enter the default route, and set the
START TCP/IPdaemon's Now option to yes. Press Enter. - Run all the
routecommands you added to the /etc/rc.net file at the command prompt.Do not run the /etc/rc.net file by itself, as doing so could cause other problems.
If you want to add another IP address from the same subnet to an interface, it's simple and can be done with IP aliasing. Simply run the following command to add this information to the ODM, substituting your appropriate information in place of the variables, and add the host name to the /etc/hosts file:
chdev –l $INTERFACE –a alias4=$IP,$NETMASK |
If you need to remove an alias, substitute alias4 with
delalias4, and run the same command.
Changing and deconfiguring network interfaces
There may come a point when you need to take down a network interface. This may
occur when doing something like replacing a piece of broken hardware or
changing the physical attributes of an Ethernet card to use jumbo frames (because
the physical attributes cannot be modified if a logical device is up and running on it).
If you have been a UNIX systems administrator for a while, you are probably familiar
with the ifconfig command as a means of bringing up
and taking down network interfaces. That command will do the work for you, and the
syntax is ubiquitous, but its effects are only temporary, lasting until the next time
you boot the system. This is why, instead, I prefer the chdev
command.
Running chdev –l $INTERFACE down brings the interface down
and notes the change in the ODM. If you need to bring it back up, just switch the
down with up. Taking it one
step further with the chdev –l $INTERFACE detach command
clears out the IP information from the ODM entirely. Then, you can safely and
completely change the IP information for the device. Or, you can delete the logical
and physical devices with the rmdev command outright.
This article provided a basic background for understanding how to do elementary network administration on AIX servers. Although it did not get into the deep details of network tunables, like optimizing Maximum Transmission Unit sizes, it walked through the key steps of getting systems administrators off the ground and getting servers on the wire.
Learn
-
VIO and
Virtualization wiki: Check out the developerWorks VIO wiki.
-
Chapter
10, "pSeries AIX System Administration": Read this chapter of the IBM eServer
Certification Study Guide.
-
AIX 5L Communications:
Read this chapter the IBM eServer Certification Study Guide.
-
TCP/IP tutorial:
Check out the TCP/IP tutorial and technical overview.
-
AIX
6.1 Information, TCP/IP: Check out the IBM Infocenter information on TCP/IP.
-
AIX and UNIX developerWorks
zone: The AIX and UNIX zone provides a wealth of information relating to
all aspects of AIX systems administration and expanding your UNIX skills.
-
New to AIX and UNIX?
Visit the New to AIX and UNIX page to learn more.
-
Technology
bookstore: Browse the technology bookstore for books on this and other
technical topics.
Discuss
- Follow developerWorks on Twitter.
- Get involved in the My developerWorks community.
-
Participate in the AIX and UNIX® forums:
- AIX Forum
- AIX Forum for developers
- Cluster Systems Management
- Performance Tools Forum
- Virtualization Forum
- More AIX and UNIX Forums
Christian Pruett is a senior UNIX systems administrator with more than 14 years of experience with AIX, Sun Solaris, Linux, and HP/UX in a wide variety of industries, including computing, agriculture, and telecommunications. He is the co-author of two IBM Redbooks on AIX, has served as a UNIX book review for O’Reilly Publishing, and has worked on several of the IBM AIX certification exams. He resides in Colorado with his wife and two children. You can reach Christian at pruettc@gmail.com.




