Hi All,
urgent help indeed needed. We have an SAPBC installed in an VMWare instance (Linux !), identical to two installations outside the DMZ.
Equiped with jdbc driver, java. We are connecting to an SAP system and and an SQL server.
I made the preparation for running it in the DMZ, like firewall switching for port 3300 (sapgw00)/443 and dns settings and the routing to the firewall.
I did not change a thing in the configuration of the sbc, in relation to the previous installations. When I connect to the required sap system or database (different message though), I get the following message:
class com.sap.mw.jco.JCO$Exception
Message Connect to SAP gateway failed Connect_PM GWHOST=GIFD71.DE.ABB.COM, GWSERV=sapgw00, ASHOST=GIFD71.DE.ABB.COM, SYSNR=00 LOCATION CPIC (TCP/IP) on local host ERROR partner not reached (host GIFD71, service 3300) TIME Mon May 26 14:55:01 2003 RELEASE 620 COMPONENT NI (network interface) VERSION 36 RC -10 MODULE niuxi_mt.c LINE 1084 DETAIL NiPConnect2 SYSTEM CALL SO_ERROR ERRNO 113 ERRNO TEXT No route to host COUNTER 13
Service sap.admin.server:getInfo
I know the gate 3300 is derived from the sapgw(00) number, the jdbc driver uses it as well, althoug not relevant for the sap system connect.
I checked the firewall with nslookup and get a positive responce, the firewall monitor confirms that.
Anyboby ideas, I am getting desperate, since the three servers are identical, apart from the location !
Hi Frank,
I aint no SAP expert and this looks like a network issue. But I am sure that someone here will help you out soon. Its Monday morning and within an hour or two more experts will be logging on. So please be patient and try not to worry, you will get your answers soon.
Good Luck!
I am not too shure you are right, in the sence of network and os. If the nslookup on the servers in question works, and the firewall registeres the request, also a ping works, ever from the tarket servers, I would say, that is sound. I even put the servers into the /etc/hosts. Also I can verify the availability of the ports, if I got them all. So here is a recap: 443,4433,1433,3300(gateway00) I believe that the interface of the sbc can not communicate with the os. Sounds stupid, but I am running out of ideas.
Specifically, the problem seems isolated to the 3300 port on host GIFD71. It sounds like you have already deduced that part, but I thought I’d reiterate it anyway.
NSLOOKUP only looks for a server’s IP address or host name based on DNS so a positive NSLOOKUP result does mean that a specific port on the machine is available.
There may be some port access settings that need to be addressed on the target machine or in your firewall.
From you DMZ linux machine, I suggest you try the following
-check your network setup (/sbin/route -n), in particular that the IP of your gateway is properly configured
-check if the IP (I mean ipaddress, not nework name) of the remote machine is visible. Try goold old ping, if the firewall does not block ICMP, or try checking the port at the same time, try one of the following:
telnet ipaddress 3300
dig ipaddress
nmap ipaddress
If all fails, it is likely that either your gateway is not properly configured, or that an intermediate firewall filters packets going to port 3300 (would be my bet). Also does the connection use UDP or TCP packets? -check that the firewall does not block the one needed.
Hi Dan, now there is something I was a bit over selfconfident with. I think you are right, the nslookup only identifies the dns server entries in the os. I tried a telnet <ip> 3300 from the target server and the connection broke down ( a bit of a bad translation of a german warning message, sorry) Any good ideas on how to test the ports and from which side they should be tested to make shure the whole communication scenario works sound ? I would hestitate to trust our wan guy’s (historical issue)
The firewall should be able to tell you if packets are being dropped for port 3300. We have had this problem before and the only way we found is to check if traffic is flowing through the port. I suggest that you try to send the IDOC/transactions to/from SAP and check the firewall logs for that specific time.
Bruno got me on the right track. I checked the gateway settings and got the idea to add the two servers into the advanced gateway settings. The network guy turned on the logging in the firewall and there we go the telnet <ip> 3300 went through. And the connection worked.
Just a shame the sap base crew, forgot to activate the user…
There you go, Thank’s a million for your assistance…
Bruno, the Name implies, that you are German. In case you are, I am in the region of Mannheim. A couple of beer’s for the tip seem in order.
Contact me if your anywhere close :frank scharmann@de.abb.com