Archive:10054 en/en

From SEPsesam
Icon archived docs.png THE CONTENT OF THIS PAGE IS OUTDATED
SEP AG has discontinued support for obsolete SEP sesam versions. Instructions are still available for these SEP sesam products, however, SEP AG accepts no responsibility or liability for any errors or inaccuracies in the instructions or for the incorrect operation of obsolete SEP sesam software. It is strongly recommended that you update your SEP sesam software to the latest version. For the latest version of SEP sesam documentation, see documentation home.

Template:Copyright SEP AG en

Disconnections during backups

Symptom

Network Connections fail on physical or virtual systems. The log files contain one of the following error messages:

10054 An existing connection was forcibly closed by the remote host
Error : Network communication problem: SOCKET error: 10054 - The virtual circuit which reset by the remote side . recv () call failed .

Cause

Virtualization Solutions

Citrix XenTools and Installing VMware Tools may also create your own network card driver in the virtual machine , which will then be used instead of the regular Windows system drivers .

The Paravirtual network drivers can sometimes cause the following problems to occur :

  • General CPU load of about 30% within a VM when idle
  • Very poor transfer rates , even in 10 Gigabit networks or 1 Gigabit LAN
  • Disconnections

The above error message says from Microsoft documentation that the connection was reset by the *client *, so the tcp RST comes from the client system.

On the SEP sesam server , the problem can be visible as follows :

  • The backup remains in the status "active" with a 0 GB/h performance
  • There are sm_sms_backup processes active
  • There are sm_stpd processes active

-> In The SEP sesam definitely has no feedback from the client that the backup was aborted: The connection was "hard" reset.

Network / Port Trunking

In several customer environments, the port trunking has been identified to either side of the system to be backed up or the backup server side. After the trunk has been dissolved, the actions were able to be performed without problems. Commonly this type of disconnect happens in less then 5 minutes but can happen randomly. This is almost always related to a Trunking problem but could be TSO corruption on virtual machines or even physical machines with first revision 10/100 network cards. Use this trunking configuration guide to resolve trunking issues http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1004048

Firewall

Firewalls reach through stateful inspection measures active in the transport of data and can therefore represent the cause of the problem. Commonly if the disconnect is < 5 min it's a TSO/Trunking issue and if the disconnect happens at almost exactly 5 or 60 or 120 minutes it's a KeepAlive problem on NAT/PAT router or firewall

Virus Scanner

Virus scanner intervene actively in the data transmission as well as in the processes involved and thus may represent the cause of the problem. A false positive from and antivirus application will cause failures intermittently or randomly. It is recommended to use the antivirus exclusions for SEP sesam. For details, see Special:MyLanguage/FAQ#What_effect_does_an_antivirus_scanner_have_on_SEP_sesam.3F.

Error on SEP sesam server side

  • If the time of abandonment of the backup in the event viewer or the dmesg output of a SEP sesam server a problem with the process sm_stpd.exe or sm_stpd on, so the problem of sesam server side to be analyzed.
  • Incorrect routing can also be a cause for this problem.

Example:
The SEP sesam server and client are in two different networks. The routing is not controlled by one central router, but via Static Routes in the other network. A ping from the SEP sesam server to client works, but not the other way around.

In the case described in the SEP sesam server was the Permanent set route in the network of clients, but she was not part of the active routes.
Delete and re- add the route has fixed the problem.

route delete <NetzwerkdesClients>
route add -p <NetzwerkdesClients> mask <NetzmaskedesClientnetzwerkes> <IPdesSesamServers>

Solution

Task Offloading off

' VMs '

In the VM off the feature " TSO " (TCP segment offloading ) .

Both Citrix XenServer as well as VMware ESXi is available in the network , the existing types " TSO " (TCP segment offloading ) .
This feature allows you to swap out different operations that must be performed during the fragmentation of network packets to the network interface card ( checksum calculation) .
Sense, it is the CPU load thereby reduce because the actual calculation is then performed on the network card.

The XenServer NIC drivers are more affected by this problem.

Windows

The following Microsoft article describes how this feature on Windows Server 2003 systems can be disabled:

http://support.microsoft.com/?scid=kb % 3ben -us % 3B904946 & x = 12 & y = 10

In the end, is in the registry of the key set "is DisableTaskOffload " to prevent the " offloading " on the network card :

http://technet.microsoft.com/en-us/library/cc959732.aspx

Under this option set on the backup client and rebooting additional backups are running smoothly.

' Linux '

On Linux, you can enable or disable the TSO settings via the Tools ethtool at run time:  ethtool -K eth0 tso off

TCP Retransmission

The remedy of " TCP Retransmission " errors on the network level removes the root cause of the problem.

To find " TCP Retransmission " error , the network analysis tool [ http://www.wireshark.org/ Wireshark ] is needed.

Start with Wireshark network analysis on the affected system : " Capture - > Interfaces "

'Note :' Retransmission error appear as black lines in the Wireshark log.