Hi guys.

We have a problem with our Linux servers which we are running our SAP environment on.

Users are able to connect and work via SAP-GUI on all systems without any problems. However, the SAP servers need to be able to make RPC calls to each other for the purpose of transporting data, configuration and so on from one server to another. These connections fail intermittently.

SAP Germany has stated that they believe it to be a network problem, which is - quite frankly - bullshit. Why then do our users not experience interruptions? Besides which, we have gone through the standard hardware troubleshooting cycle, and everything appears fine.

Last week I discovered that when I try to "rpcinfo -p servername" from one server to another, nothing happens at all. Yet if I ping the server I'm trying to "rpcinfo", and THEN run the command it immediately returns the list of listening services. It's almost like the rpcd (or whatever) goes to "sleep" and doesn't answer requests until some other sort of traffic is generateed.

Does anyone know of any configuration options with RPC stuff on Linux that could cause behaviour like this? I've been Googling without much success.

PS: Not a DNS resolution issue as testing with IP addresses yields the same results.

From RPC specifications (RFC1831)

http://www.ietf.org/rfc/rfc1831.txt

4. TRANSPORTS AND SEMANTICS

The RPC protocol can be implemented on several different transport
protocols. The RPC protocol does not care how a message is passed
from one process to another, but only with specification and
interpretation of messages. However, the application may wish to
obtain information about (and perhaps control over) the transport
layer through an interface not specified in this document. For
example, the transport protocol may impose a restriction on the
maximum size of RPC messages, or it may be stream-oriented like TCP
with no size limit. The client and server must agree on their
transport protocol choices.

It is important to point out that RPC does not try to implement any
kind of reliability and that the application may need to be aware of
the type of transport protocol underneath RPC. If it knows it is
running on top of a reliable transport such as TCP [6], then most of
the work is already done for it. On the other hand, if it is running
on top of an unreliable transport such as UDP [7], it must implement
its own time-out, retransmission, and duplicate detection policies as
the RPC protocol does not provide these services.

So as I can understand, the application chose what king of transport to use... So it might be a problem with the application it self ??

Good luck!