Learn the basics of IBM AIX networking

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.

Networking in AIX

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.

Basic network configuration

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
Screen shot of the Minimum Configuration and Startup window

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
Screen shot of the 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.

Routing and aliasing

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.

Duplicate default routes

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:

  1. 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"
  2. Go back through the Minimum Configuration & Startup page, re-enter the default route, and set the START TCP/IP daemon’s Now option to yes. Press Enter.
  3. Run all the route commands 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.

IP aliases

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.