0

I am trying to create a SAP RFC connection to a new system.

AFAIK the firewall (in this case to port 3321) is open.

I get this message at the client:

RFC_COMMUNICATION_FAILURE (rc=1): key=RFC_COMMUNICATION_FAILURE, message=
LOCATION    SAP-Gateway on host ax-swb-q06.prod.lokal / sapgw21
ERROR       timeout during allocate
TIME        Thu Jul 26 16:45:48 2018
RELEASE     753
COMPONENT   SAP-Gateway
VERSION     2
RC          242
MODULE      /bas/753_REL/src/krn/si/gw/gwr3cpic.c
LINE        2210
DETAIL      no connect of TP sapdp21 from host 10.190.10.32 after 20 sec
COUNTER     3
 [MSG: class=, type=, number=, v1-4:=;;;]

And this message on the SAP server

sap-syslog-screenshot

Any clue what needs to be done, to get RFC working?

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
guettli
  • 25,042
  • 81
  • 346
  • 663

2 Answers2

1

With this little info no one can know what the issue is here. But it is something related to your network and SAP system configuration.

I guess your firewall does some network address translation (NAT) and the new IP behind the firewall does not match anymore with the known one. SAP is doing some own IP / host name security checks.

If not already done, check with opening the ports 3221, 3321 and 4821 in the firewall. Also check the SAP gateway configuration which IP addresses and host names are configured to be valid ones for it (look at what is traced in the beginning of the gateway trace file dev_rd at ABAP side).

Also consider if maybe the usage of a SAProuter would be the better option for your needs.

Trixx
  • 1,796
  • 1
  • 15
  • 18
  • you say SAP does security checks. Nice sounds good. If a security checks fails. What is the error message you get? I guess it is not "timeout during allocate" like in my case. What do you think? – guettli Jul 30 '18 at 08:46
  • I don't know, but I think you would get a "connection refused" or "not allowed" error message. "timeout during allocate" is surely some low level network error. However, it might be a follow-up error if the SAP gateway would use the wrong IP address for its internal communication to the work process dispatcher. So I really recommend to check the file dev_rd as the next step and see which host names and IP addresses are configured to be valid. – Trixx Jul 30 '18 at 10:16
0

it works in my case if ashost is the host name, and not an IP address!

Do not ask me why, but this fails:

Connection(user='x', passwd='...', ashost='10.190.10.32', sysnr='21', client='494')

But this works:

Connection(user='x', passwd='...', ashost='ax-swb-q06.prod.lokal', sysnr='21', client='494')

This is strange, since DNS resolution happens before TCP communication.

It seems that the ashost value gets used inside the connection. Strange. For most normal protocols (http, ftp, pop3, ...) this does not matter. Or you get at least a better error message.

guettli
  • 25,042
  • 81
  • 346
  • 663
  • No, the _ASHOST_ does not need to be a symbolic hostname. In general, one may also use the IP address. This must be something different. Can you ping 10.190.10.32 at OS level from the command prompt? Do you already use IPv6 and this is mandatory in your network infrastructure? – Trixx Jul 27 '18 at 11:05
  • @Trixx since I couldn't believe it. I tried it several times. With IP I got above error, with the host name it worked. The DNS resolves the host name to the IP and the host name is not in /etc/hosts. I checked the connection with tcptraceroute to the port 3321 and it worked with both versions. Both tcptraceroute outputs are equal. I am happy to have the solution, but no clue why this solved the issue. – guettli Jul 27 '18 at 12:56
  • @Trixx I rephrased the answer. I changed the bold wording from general truth to the answer of this particular case. I don't know more than the current case. Thank you for your feedback. – guettli Jul 27 '18 at 12:58