NIM Networks

In order to perform certain NIM operations, the NIM master must be able to supply information necessary to configure client network interfaces. The NIM master must also be able to verify that client machines can access all the resources required to support operations. To avoid the overhead of repeatedly specifying network information for each individual client, NIM networks are used to represent the networks in a NIM environment. When NIM clients are defined, the associated network for the client must be specified. During NIM operations, the NIM master is able to use information from the client's network definition when necessary.

When the NIM master is configured, the network associated with the master is automatically defined in the NIM environment. It is only necessary to define additional NIM networks if clients reside on other local area networks or subnets. The procedures described in this guide and reference are designed to automatically define NIM networks, if necessary, when clients are added. However, this section is included to describe NIM networks in detail in case manual definition of networks and routes is required.

Supported NIM Network Types

The currently supported network types are:

• Ethernet
• Token-Ring
• FDDI
• Generic

Network boot support is provided for Ethernet, Token-Ring, and FDDI. The Generic network type is used to represent all other network types where network boot support is not available. For clients on Generic networks, NIM operations that require a network boot, such as bos_inst and diag, are not supported. However, nonbooting operations, such as cust and maint, are allowed. Diskless and dataless clients cannot be associated with Generic networks, since they inherently rely on network boot capability.

Defining NIM Networks

Networks are defined in the NIM environment using the NIM define operation. The command line syntax is as follows:

nim -o define -t NetworkType -a Attribute=Value ... MachineName

where the following attributes are required:

The following attributes are optional:

It is also possible to define NIM networks automatically when client machines are defined. To do this, use the find_net and net_definition attributes when defining the client. For more information, see "NIM Machines".

Determining a Network's IP Address

NIM determines a network's IP address by performing a bitwise "AND" on the binary representations of the network's subnet mask and the address of any machine's IP address on the same network. For example:

   subnet mask = 255.255.254.0
client address = 129.35.58.207
   
In binary:
    subnet mask = 11111111.11111111.11111110.00000000
 client address = 10000001.00100011.00111010.11001111
network address = 10000001.00100011.00111010.00000000
   
In decimal:
network address = 129.35.58.0

NIM Routes

Routing information is used internally by NIM to ensure that a client on one network can communicate with a server on another network. It defines the gateway to use to go from one network to the other network.

NIM provides the ability to define default or static routes. Default NIM routes provide the following advantages over static routes:

• They more closely model the network configuration of common network environments.
• They also permit resources that are distributed throughout a NIM environment to be more easily accessed by any client in the NIM environment.

Static NIM routes are supported for backward compatibility with NIM environments defined on machines running Version 4.1 (and later).

To determine the gateway used by machines on a given network, run netstat -rn on a running machine on the network to see if a default gateway is listed. You can also issue traceroute Host_Name from a running machine on the network in question, where Host_Name is the name of the master's primary network interface if determining the gateway for a client, or the name of a target client if determining the gateway used by the master. The first gateway listed is the gateway used by machines on the specified network.

Note that NIM routes are not required if the only networks defined in a NIM environment are associated with interfaces (if attributes) defined on the NIM master and if all resources will be defined on the master. If resources are served by machines other than the master to clients that do not reside on the same network as the server, NIM routes are required between those networks even if all networks are attached to interfaces belonging to the master. In this case, the master must act as a gateway (with IP-forwarding switched on), and the host name of the interface on the master should be used as a gateway.

Networks with default routes may be created automatically when NIM machines are being defined.

It may be observed that communications between networks go through several gateways. However, it is important to remember that when defining NIM routes for networks, the only gateways of interest are the first ones used by the networks to reach their destinations. Intermediate gateways between the originating and destination networks are irrelevant for NIM routing purposes.

For more information on adding and changing routes, see "Establishing a Default NIM Route Between Networks" and "Establishing a Static NIM Route Between Networks".

Defining a Heterogeneous Network

This section describes a feature of NIM that enables it to model networks consisting of different data link protocol segments. These kinds of networks use bridges to connect two segments that have different data link protocols. A network consisting of a Token-Ring and an Ethernet segment can be connected to form a single logical network, as shown in the Heterogeneous Network figure:

Because a single NIM network object is used to represent one network, the other_net_type attribute is reserved for a different type of interface that can exist in a network. The other_net_type attribute can be added to the definition of a network object. When present in a network definition, the other_net_type attribute tells NIM that this logical network uses a bridge to connect the other network type to the network type that was specified when the object was defined.

When you define a machine object to be connected to a network object, NIM checks to see if the network has any other_net_type attributes. If so, NIM requires that the fourth field, which is usually optional, in the if attribute, be specified. This field specifies the logical name of the client's network adapter. The following example defines a network object that has a bridge joining a Token-Ring and an Ethernet segment:

nim -o define -t tok -a net_addr=129.35.129.0 \
    -a snm=255.255.240.0 -a other_net_type1=ent b905net
   
lsnim -l b905net
   
class           =  network
type            =  tok
net_addr        =  129.35.128.0
snm             =  255.255.240.0
other_net_type1 =  ent
Nstate          =  ready for use
prev_state      =  information is missing from this object's def>

Note that other_net_type requires a sequence number. This is because a network could be composed of all three types of interfaces linked by bridges.

When you define a client's interface that is physically connected to an Ethernet segment joined with a Token-Ring network using a bridge (with master being on the Token-Ring side), you must supply the fourth field:

nim -o define -t standalone -a if1='find_net mymac 08005ac9430c \
ent' -a cable_type1=bnc mymac

Adding Another Network Type to a NIM Network

From Web-based System Manager

1. In the NIM Network container, double-click on the network. The General page of the properties notebook displays.
2. Use the General page to add a network type to the network.

From SMIT

1. To add another network type, enter the smit nim_chnet fast path.
2. Select the network to change.
3. Specify the additional network type to be supported.

From the Command Line

To define a NIM network, enter:

nim -o change -a other_net_typeSequenceNumber=NetworkType \
NetworkName

For example, to change a Token-Ring network called network1 to also support Ethernet and FDDI, enter:

nim -o change -a other_net_type1=ent -a other_net_type2=fddi \
network1