What are the common indications for Hostname resolution problems (DNS timeouts)?
There are a number of problems which may occur in every release, but are often seen for the first time after upgrade to release 4.0 or after upgrading the 4.6D kernel to patch level > 1078. The common indications of these problems are listed below:
- Hanging of the SAPgui for a long time (about 20 seconds up to some minutes) during the logon or logoff processes (especially after upgrade to release 4.0).
- Blocking of the SAPgui for a long time due to poor performance levels.
- Entries in dev_w*: Could not get hostname for 'XX.XX.XX.XX' (will retry in 600 secs).
- Hanging of the processes in program SAPLTHFB for a long time.
- Unavailability of free dialog work processes, because of all being busy.
- Hanging of the "netstat -i" command, whereas the "netstat -in" gets completed fast. (on Windows, the used commands are: "netstat -a" and "netstat -an")
- System startup times getting longer.
- Getting error messages of the functions DpNetCheck, NiHostToAddr or NiAddrToHost.
What are the main causes for these problems?
The above mentioned problems can occur due to several reasons. The common reasons which often lead to these problems are as follows:
- The problem may occur because the name servers only know the resolution of names into IP addresses but not the corresponding reverse lookup.
- They may even occur because of the new networks or subnets which are not entered into the name server's database. However long timeouts are not caused due to these reasons but occur only if another problem comes on top of them. Name servers are often configured in such a way that they can access other name servers to resolve addresses which are not known to them.
- A name server waits for an answer for a long timeout period, if it tries to contact another name server which is not reachable (for example, a server on the public Internet). This happens because of the protocol used by name servers.
- There can also be communication problems between primary and secondary name servers or between host and name server.
How can I get these problems resolved?
There can be a number of approaches for resolving these problems. Some of them are listed below:
- In order to verify that DNS is the main cause for the problems, one should disable it on the application server. The procedure for this is specific to the operating system. "Network" control panel is used by NT, the files "/etc/resolv.conf", "/etc/nsswitch.conf", "/etc/netsvc.conf" are used by UNIX, the environment variable "NSORDER" or others. One can easily consult to his operating system documentation. Now in order to make the R/3 system to function, the other application servers and the database server should be entered manually into /etc/hosts.
- Hanging of the "netstat -i" command, but getting the "netstat -in" completed fast is another clear indication of the DNS problems. The only difference between these two commands is, that "netstat -i" tries to resolve IP-addresses into network and host names. (On Windows "netstat -a" and "netstat -an" commands are used.
- If the DNS server has been identified as the cause for the problems then some of the options for solving the problems are as follows:
- Configuring the DNS correctly, this means that all of the internal networks should be represented as “zone” in the DNS server. It makes the name server to know that it is responsible for these networks and hence can answer the queries to the best of its knowledge.
- Most of the R/3 systems do not rely on the client IP-address resolutions results. Even if the resolution fails, the functionality remains unaffected. Hence entering all computers into the zone files is not necessary – an error message is immediately returned to the caller by the name server, if they are not present.
- All the name server configuration files which are for the references to Internet name servers should be checked. The "Root Cache Data" can have the Internet root name servers configured by default (this usually happens with the Microsoft DNS server that comes with Windows NT Server). All the references to inappropriate or unreachable external name servers should be removed.
- The DNS lookup should be disables on the application servers. In order to run, the R/3 System needs only the addresses of all other application servers and the database server of the same R/3 system. A static file /etc/hosts can easily be used for keeping this information.
- The addresses of the other external communication partners, like print servers, and CPI-C and RFC server hosts, also need to be entered in addition. There are no entries necessary for the frontend printing.
- A SAP router should be used for accessing the R/3. The SAProuter should be run on a host that is either kept in the file /etc/hosts or is known to the DNS. For the SAProuter host, the best choice can be the server of the central R/3 instance.
- The R/3 Online Documentation under BC-Basis -> Kernel Components or SAP 30289 contains the configuration of SAP routers.