The R/3 System uses IP names and IP addresses to identify R/3 servers and external communication partners. Therefore, the correct configuration for resolving IP names and IP addresses is extremely important for the R/3 System to function properly.

Read and take these rules into consideration before installing an R/3 System.

All the operating system platforms supported by SAP offer various mechanisms for name and address resolution (for example, the Hosts file and DNS). These are explained briefly in the second part with respect to the R/3 System.

Translating an IP name into an IP address or the reverse, is called resolution. This can occur in two directions (see graphic). The most common case involves resolving an IP name into an IP address. For the R/3 System, the opposite resolution is also very important (this is called reverse lookup).

Due to the client/server architecture of the R/3 System, there are specific requirements for R/3 servers and R/3 clients when resolving IP names and IP addresses.

• Reverse lookup for these IP addresses must be possible and they must return the same IP name. Resolution in the sequence IP name à IP address à IP name must yield the identical name.

• The IP name may not be an alias. On Windows NT, the sequence of the network adapters must be configured correctly in the system.

• The name localhost must be able to be resolved (normally, the accompanying IP address is 127.0.0.1).

The following requirements also apply for communication functions:

• The SAP gateway may start RFC or CPI-C server programs on another host. If this is the case, reverse lookup from the IP address of the host where the server program is started to the corresponding IP name must be possible. If you want to use host names to configure the RFC destinations, you must ensure that the IP name can be resolved.

• You do not need additional name resolution to print on the frontend, since the existing connection between the application server and SAPgui is used. If you want to address a printer or print server using names, these names also have to be resolved on the R/3 server. If you use one or more print servers, the names of the print servers do not have to be resolved by themselves.

In addition to the name resolutions necessary for the system to function, other reverse lookups occur that are not functionally necessary. This type of name resolution occurs, for example, so that the actual names are displayed in monitors and in the system log, instead of the numerical IP addresses.

• When the R/3 System is started, a reverse lookup is performed for the IP addresses of all the network adapters that are built into the application server. The IP addresses of the network adapters from other application servers are also resolved under certain circumstances.

• The R/3 System tries to resolve the IP addresses into IP names for all frontend computers that use SAPgui to log on to the system directly, and for all RFC and CPI-C client computers.

In these cases, the resolution does not have to return a valid result for the R/3 System to function properly. However, if the configuration for resolving names is incorrect (in the operating system or in the name server), there may be long wait times due to timeouts, which can have a highly negative affect on R/3 System performance. Therefore, ensure that the configuration is correct when using name resolution with DNS (Domain Name System).

The SAP Network Interface (NI) is a part of the R/3 System, and stores the result of the name resolution and reverse lookups in a special buffer. This means that the operating system only has to perform the name resolution once. Successful resolutions remain in the buffer until the R/3 System is shut down, or until an overflow, or until the buffer is manually deleted (Transaction SM51). Manually deleting the buffer does not include the message server. For this reason, restart the R/3 System to make the changes of IP names or IP addresses effective in the system.

If a resolution fails, this is noted for a duration of 10 minutes (as of R/3 Release 4.0). This is because the name server may not be available. If another attempt is made to resolve the name after this period of time, the R/3 System repeats the operating system call.

The advantage of buffering in the R/3 System is that it increases the performance during name resolution and it only very rarely reaches a critical situation.

To be able to use all of the R/3 functions, the frontend computer must be able to resolve the names of the message and application servers into IP addresses.

During load balancing, the SAPgui receives a list of IP addresses from the message server. Resolution does not occur.

If the frontend computer cannot resolve the names of the R/3 application servers, you can also start the SAPgui by using numerical IP addresses. However, the functions may become limited, for example, when you use certain desktop components.

An RFC or CPI-C client establishes a connection to the R/3 System. To do this, it requires the IP address of an application server. You can enter this address directly to establish the connection. In this case, no resolution occurs. You can also use load balancing with logon groups for RFC. Here, the RFC client connects to the message server and receives a list of IP addresses from the server. No resolution occurs here.

Server programs are usually started by an SAP gateway, or by a SAPgui. Each R/3 instance has a gateway. You can also operate an SAP gateway without an R/3 instance (standalone). After the server program starts, it must establish a connection with the gateway within a specific period of time. You can start the program in different ways:

Start using a remote shell: On the command line, the server program receives the IP name of the gateway to which it should connect. This name must be able to be resolved.

Start using the SAPgui (only RFC): The command line communicates the information with which the SAPgui was started to the RFC program. It also communicates a SAProuter string is used. This means that the resolution is identical to the resolution with the SAPgui.

There are four common mechanisms for assigning names with addresses:

• Hosts file
• Domain Name System (DNS)
• Windows Internet Naming Service (WINS)

• Network Information Service (NIS, used to be called Yellow Pages)

The operating system determines which mechanisms are available, which are active by default, and how they are configured. The administrator can decide which of the available mechanisms are used. In most operating systems, you can configure several mechanisms with different priorities. These are used one after the other, if the first mechanism does not give you the result you want.

The configuration of the naming resolution mechanism on R/3 servers must meet the following requirements:

• Robustness
• Flexibility
• Maintenance
• Simplicity
• Performance
• Integration in an existing infrastructure

WINS (Windows Name Service) is suited for use in a pure Microsoft Windows environment and cannot be directly compared with the other mechanisms described here for naming resolution. One main difference is that no IP names, but NetBIOS names, are mapped to IP addresses. The advantages of WINS are its simplicity, robustness, and flexibility. The disadvantage is that WINS is only suited for smaller, flatly structured and homogeneous Microsoft networks.

The Domain Name System (DNS) can map complex, hierarchical structures with a large number of hosts. It lets you use efficient centralized and decentralized administration. For example, the entire Internet uses a single DNS infrastructure for naming resolution. DNS is the most robust of all methods of naming resolution, and is the most well suited for the future, for example, for potential integration with directory services. DNS is available on all server and frontend platforms supported by SAP.

With regards to availability and wait times, the same applies here as it does for NIS. With DNS, planning is particularly important, since configuring and maintaining DNS is complex and, therefore, prone to errors. The most dangerous errors are not those that lead to a total failure, rather those that lead to performance problems, because they remain undiscovered.

The effects of an incorrect DNS configuration are explained in the following example:

If a reverse lookup in the DNS is not maintained, and the name server in the corporate internal network is configured incorrectly so that it accesses the central name server in the Internet for unknown domains (this is the default setting for certain name servers), the name server waits for several minutes for a response from the inaccessible Internet name server. During this time, the R/3 work process from the operating system is stopped and the user cannot continue working.

Wait times can also occur due to connection problems between the application server and the name server, or between two name servers.

If you want to use DNS (you need some basic knowledge of DNS):

• You need at least one backup name server. DNS contains methods for replicating the configuration data. In all operating systems, backup name servers can be configured that are automatically used if the first server does not respond within a specific period of time.

• Ensure that there is high availability for the DNS server and for the network connection between the DNS servers and to the SAP servers.

• You do not have to enter all your corporate computers in the zone files, if the information is not needed for operating your R/3 System. It is only important that the zones exist. The above sections have already described which name resolution is required to operate your R/3 System. If, for example, you do not need naming resolution from client computers, the zone files for the network domain and naming domain of your frontend network can remain empty.

• Ensure that queries for internal names or addresses are never forwarded to external name servers (for example, in the Internet). This is guaranteed if root name servers only are contained in the DNS cache files that are located in your local network.

Deciding on which mechanisms you should use for naming resolution depends on your priorities. When making your decision, remember that the name resolution is a critical function in the R/3 System that influences the system operation.

WINS is only used in pure Windows environments. In the future, it will not be supported in certain circumstances, and we therefore do not recommend it.

DNS is the most flexible and powerful solution, almost a standard. However, its use requires a high level of knowledge about implementation and maintenance. Buffering in the R/3 System means that wait times are not critical, within certain limits. However, you must have high availability for the DNS server and the related network connections. If you already have a functioning and well-maintained DNS infrastructure, we recommend using DNS on the R/3 servers and frontends.

Simplicity and robustness are the advantages of the Hosts file. It is therefore highly recommended for the R/3 servers. Generally, the R/3 server does not have to use the same mechanism as in the rest of your corporate network. However, maintaining and distributing the Hosts file may require a great deal of effort to administrate.

On UNIX servers, you can replace the Hosts file by NIS. Here, like DNS, you must pay attention to proper implementation and high availability of the NIS server to ensure that the R/3 System operates properly.