6    Managing Networks in a Cluster

This chapter discusses the following topics:

See the Tru64 UNIX Network Administration: Connections and Network Administration: Services manuals for information about managing networks on single systems.

6.1    Updating ifaccess.conf When Changing Network Interfaces

Whenever you add a new network interface, or change or replace an existing interface in a manner that causes the known interfaces to change, you must update the /etc/ifaccess.conf file on the cluster member where the change occurred. You do this to deny access from untrusted subnets to the cluster interconnect.

In a cluster with a Memory Channel interconnect, you need to add a line for the address of the cluster interconnect virtual interface (ics0). In a cluster with a LAN interconnect, you must add a line for the address of the cluster interconnect virtual interface and another line for the address of the cluster interconnect physical interface.

By default, the installation programs offer IP addresses on the 10.0.0 subnet for the cluster interconnect virtual interface, with the host portion of the address set to the member ID. In a cluster with a LAN interconnect, the installation programs offer IP addresses on the 10.1.0 subnet for the cluster interconnect physical interface, with the host portion of the address set to the member ID.

Make the change as follows:

  1. Log in to the member where the network interface changed.

  2. Use the ifconfig command to learn the names of the network interfaces. For example: 

    # ifconfig -l
ics0 lo0 sl0 ee0 ee1 ee2 tu0 tun0
 

  3. Determine the cluster interconnect addresses used by the member. To do this, look in the member's /etc/ifaccess.conf file for the 10.1.xxx.xxx and 10.0.xxx.xxx entries.

    You can also use the ifconfig command to determine the cluster interconnect addresses used by a member and to identify the network interface for the cluster interconnect. The output of the command depends on whether you are using the Memory Channel interconnect or a LAN interconnect. The following example shows output for Memory Channel: 

    # ifconfig -a | grep -p CLUIF
ics0: flags=1100063<UP,BROADCAST,NOTRAILERS,RUNNING,NOCHECKSUM,CLUIF>
     inet 10.0.0.2 netmask ffffff00 broadcast 10.0.0.255 ipmtu 7000 
 

    The following example shows output for a LAN: 

    # ifconfig -a | grep -p CLUIF
alt0: flags=1000c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,SIMPLEX,CLUIF>
     inet 10.1.0.20 netmask ffffff00 broadcast 10.1.0.255 ipmtu 1500
 
ics0: flags=1100063<UP,BROADCAST,NOTRAILERS,RUNNING,NOCHECKSUM,CLUIF>
     inet 10.0.0.20 netmask ffffff00 broadcast 10.0.0.255 ipmtu 7000 
 

  4. Edit the /etc/ifaccess.conf file appropriately for each changed interface. Use the following format for each line: 

    interface-name interconnect_net_address 255.255.255.0 deny

    This line is read as "deny all packets to interface-name from hosts that claim they originated from interconnect_net_address." The mask contains 1s (ones) for the bit positions in interconnect_net_address that are significant.

    For example, if the address of the cluster interconnect virtual interface is 10.0.0.1 and a new tu0 interface card has been added to a cluster member, add a line similar to the following to /etc/ifaccess.conf: 

    tu0 10.0.0.1 255.255.255.0 deny

    This line is read as "deny all packets to tu0 from hosts that claim they originated from 10.0.0."

    If the cluster has a LAN interconnect, you must also add a line for the address of the cluster interconnect physical interface. Suppose the address of the cluster interconnect physical interface is 10.1.0.1. In addition to the line for the virtual network address, you must add a line similar to the following: 

    tu0 10.1.0.0 255.255.255.0 deny

    Note

    Do not add an entry that denies packets to the cluster interconnect virtual interface (ics0) and the cluster interconnect physical interface. These interfaces must be accessible from the cluster interconnect. For example, if the network interface used by a member for the cluster interconnect is alt0, an entry such as the following would deny access from the cluster interconnect and must not appear in the /etc/ifaccess.conf file: 

    alt0 10.1.0.0 255.255.255.0 deny

For more information, see ifaccess.conf(4).

6.2    Providing Failover for Network Interfaces

The Redundant Array of Independent Network Adapters (NetRAIN) interface provides protection against certain kinds of network connectivity failures. NetRAIN integrates multiple network interfaces on the same LAN segment into a single virtual interface called a NetRAIN set. One network interface in the set is active while the others remain idle. If the active interface fails, one of the idle set members comes on line with the same IP address.

The Network Interface Failure Finder (NIFF) is an additional feature that monitors the status of its network interfaces and reports indications of network failures. You can use NIFF to generate events when network devices, including a composite NetRAIN device, fail. You can monitor these events and take appropriate actions when a failure occurs.

The NIFF daemon, niffd, starts automatically in a cluster.

For information about providing failover for applications that depend on network resources, see the TruCluster Server Cluster Highly Available Applications manual.

For more information about NIFF and NetRAIN, see the Tru64 UNIX Network Administration: Services and Network Administration: Connections manuals, niffd(8), niff(7), and nr(7). For more information on the rcmgr command, see rcmgr(8).

6.3    Running IP Routers

Cluster members can be IP routers, and you can configure more than one member as an IP router. However, the only supported way to do this requires that you use the TruCluster Server gated configuration. You can customize the gated configuration to run a specialized routing environment. For example, you can run a routing protocol such as Open Shortest Path First (OSPF).

To run a customized gated configuration on a cluster member, log on to that member and follow these steps:

  1. If gated is running, stop it with the following command: 

    # /sbin/init.d/gateway stop

  2. Enter the following command: 

    #  cluamgr -r start,nogated

  3. Modify gated.conf (or the name that you are using for the configuration file). Use the version of /etc/gated.conf.membern that was created by the cluamgr -r nogated,start command as the basis for edits to a customized gated configuration file. You will need to correctly merge the cluster alias information from the /etc/gated.conf.membern file into your customized configuration file.

  4. Start gated with the following command: 

    # /sbin/init.d/gateway start

The cluamgr -r start,nogated command does the following tasks:

The option to customize the gated configuration is provided solely to allow a knowledgeable system manager to modify the standard TruCluster Server version of gated.conf so that it adds support needed for that member's routing operations. After the modification, gated is run to allow the member to operate as a customized router.

For more information, see cluamgr(8).

Notes

The cluamgr option nogated is not a means to allow the use of routed.

Releases prior to TruCluster Server Version 5.1B required that you run the gated routing daemon in a cluster. Section 3.14 describes Version 5.1B routing options.

We strongly recommend that cluster members use routing only for cluster alias support, and that the job of general-purpose IP routing within the network be handled by general-purpose routers that are tuned for that function.

6.4    Configuring the Network

Typically, you configure the network when you install the Tru64 UNIX Version 5.1B software. If you later need to alter the network configuration, the following information might be useful. Use the sysman net_wizard command or the equivalent command, netconfig to configure the following:

You can run the nfsconfig command without any focus. In this case, the configurations that are performed are considered to be clusterwide, and all configurations are placed in the /etc/rc.config.common file.

If you specify a focus member, either on the command line or through the Sysman Menu, the configurations are performed for the specified member. All configurations are placed in the member-specific /etc/rc.config file.

The following configuration tasks require a focus member:

Starting and stopping network services also requires member focus.

The preceding tasks require focus on a specific member because they are member-specific functions. A restart or stop of network services clusterwide would be disruptive; therefore, these tasks are performed on one member at a time.

The following configuration tasks must be run clusterwide:

For information about configuring DHCP, see Section 7.1.