Symptom
Terminations in the communication with the application server.
The following is found in the dispatcher trace dev_disp, and corresponds to the message
LOG Q01=>NiPRead: recv (10054: WSAECONNRESET: Connection reset by peer).
The following is found in the dispatcher trace dev_disp, and corresponds to the message
LOG Q01=>NiPRead: recv (10054: WSAECONNRESET: Connection reset by peer).
Other Terms
Connection termination MTU, WAN
Reason and Prerequisites
Communication between the front end and R/3 server takes places only
using the TCP/IP protocol. TCP/IP is a connection-oriented protocol that
permits a certain amount of error tolerance. This prevents minor errors
in the network affecting SAP applications.
If the TCP/IP stack identifies a problem in the communication that
cannot be resolved, the existing connection is closed and an error
message transmitted to the application. The message'10054: WSAECONNRESET
: Connection reset by peer' from the TCP/IP stack has the following
meaning in this case:
An existing connection is terminated by the partner system. This
message is usually generated if the application is stopped suddenly on
the partner system, the host restarted or a "Hard Close" used.
An entry of this message in the SYSLOG and dispatcher trace for the
application server can be caused by the following reasons:
using the TCP/IP protocol. TCP/IP is a connection-oriented protocol that
permits a certain amount of error tolerance. This prevents minor errors
in the network affecting SAP applications.
If the TCP/IP stack identifies a problem in the communication that
cannot be resolved, the existing connection is closed and an error
message transmitted to the application. The message'10054: WSAECONNRESET
: Connection reset by peer' from the TCP/IP stack has the following
meaning in this case:
An existing connection is terminated by the partner system. This
message is usually generated if the application is stopped suddenly on
the partner system, the host restarted or a "Hard Close" used.
An entry of this message in the SYSLOG and dispatcher trace for the
application server can be caused by the following reasons:
- 1.
Either the front end PC was switched off or the PC operating system was
shut down even though connections to the application server were still
present.
- 2. The network connection was interrupted.
- 3.
If several network segments of different types are between the front
end and the R/3 server, and several large transfer blocks (frames) are
sent, the intervening routers may reject the frames without confirmation
("Black Hole" routers) => the connection is interrupted.
Solution
- 1. External error! First, check the hardware configuration of the
network cards and the network components involved. In particular, make
sure that the full and half duplex settings are consistent. Check the
hardware. Generate and evaluate a network trace simultaneously from the
server and front end. To test the network, you should use the "niping"
tool to run a continuous test. To do this, start "niping" in the server
mode on the R/3 server with the following command line from a command
prompt:
niping -s -I t=0
niping -c -H <R/3 hostname> -L 3600 -D 1000
Following this command, a packet of IKB is sent every second to the niping server and received again. The test is repeated 3,600 times (approx. 1 hour). An interruption can be taken as a sure sign of a network problem. If the test is successfully completed, the minimum, maximum and average runtime of a package is displayed. If the minimum and average runtime is much lower than the maximum runtime, this can also be a sign of problems in the network.
- 2. Windows NT uses PMTU discovery. For
this reason, the TCP maximum segment size (MSS) for both partners is
exchanged during connection setup. The lower MSS value is used for the
connection. 'don't fragment' is the flag set by default under Windows NT
for each frame in the IP header. This flag prevents fragmentation of
the frames. If you are operating a connection via a WAN network, the
Maximum Transmission Unit (MTU) of a router or another unit within the
connection link may differ from the MTU of the two end systems. If the
size of a frame sent exceeds the MTU of a router, the TCP/IP stack of
the sending system expects to receive an ICMP message 'destination
unreachable' as a reply. Most routers attach the relevant MTU for the
next hop of this ICMP message. The host sends the frames again with the
valid MTU or, if no MTU is received by the ICMP message, a lower one is
sent as for the previous attempt.
niping -s -I t=0
Then start "niping" in client mode on the front end PC:
niping -c - H <R/3 hostname> -B 5000 -L 1000
Following this command, 1000 packages of 5KB are sent to the niping server and received again. This test must cause an interruption. You must then repeat this test with a smaller buffer size:
niping -c -H < R/3 hostname> -B 500 -L 1000
As a result of this command, 1000 packages of 500 bytes are sent and received again. This test must be successfully completed. If you have noticed a problem with a "Black Hole" router, there are two ways of avoiding the problem:
- a) Release the PMTU Black Hole
Detection with the Registry Editor. As a result, the 'don't fragment'
flag is no longer set. The router can fragment frames and frames within
the LAN continue to be sent with the maximum MTU.
Windows NT, Windows 2000: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP\Parameters
Via the Edit menu, insert - Add Value 'EnablePMTUBHDetect' with the data type 'REG_DWORD' and set the value to '1'. To release 'don't fragment', the value is reset to '0'. Parameter 'EnablePMTUBHDetect' is not present by default and must be inserted.
Important: The parameter 'EnablePMTUBHDetect' is only activated after a restart.
Please note that the changes in the registry must only be performed by a system administrator. This is because incorrect changes can cause the operating system to crash.
- b) Use the Registry Editor to
reduce the MTU size (Maximum Transmission Unit). In this case, the size
of the MTU corresponds to the smallest MTU of the network link. This
value then also apply for communication within the LAN. Degraded
performance.
Windows NT:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP\Parameters
Windows 2000:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP\Parameters\
Interfaces\ID for Adapter
Use the Edit menu to insert 'MTU' with the 'REG_DWORD' data type and set the value for the MTU. Make sure that the entry is in decimal form. Always select a value that is lower than the standard value. You can determine the size using the "niping" tool.
The 'MTU' parameter is not present as default so you must enter it.
Important: The 'MTU' parameter is only activated after a restart.
Default MTU values:
Network MTU (bytes) ---------------------------------
16 Mbit/sec token ring 17914
4 Mbit/sec token ring 4464
FDDI 4352
Ethernet 1500
IEEE 802.3/802.2 1492
X.25 576
RESET N1
RESET N2
Other Attributes
|
Header Data
| Released On | 03.12.2002 13:37:37 |
| Release Status | Released for Customer |
| Component | BC-NET Network Infrastructure |
| Priority | Recommendations / Additional Info |
| Category | External error |
No comments:
Post a Comment