Please enter search query.
Search <product_name> all support & community content...
Backup and restore operation fail with status 25 when multi-homed Windows 2008 clients have stronghost enabled
Article: 100019161
Last Published: 2013-04-16
Ratings: 0 0
Product(s): NetBackup
Problem
Backup and restore operation for Windows 2008 clients fail with status 25 when the host is multi-homed and the master or media servers are on the same multiple network segments and using either REQUIRED_INTERFACE or the Source setting on PREFERRED_NETWORK.
Error Message
<16> bpcd main: read failed: An existing connection was forcibly closed by the remote host.
Solution
Overview:
The default configuration for Windows 2008 requires that network traffic must travel on the expected network per the strong host model as documented in RFC 1122. This is a security mechanism which can cause backup or restore failures if the NetBackup server configuration includes
When connecting to the remote host, the transmitting host will utilize the local routing configuration to select the outbound network interface for the outbound packet. But if
The remote host will receive the inbound connection and present the data to the application, but may then close the socket if these conditions are met.
The default configuration for Windows 2008 requires that network traffic must travel on the expected network per the strong host model as documented in RFC 1122. This is a security mechanism which can cause backup or restore failures if the NetBackup server configuration includes
REQUIRED_INTERFACE or PREFERRED_NETWORK options that restrict the source interfaces .
When connecting to the remote host, the transmitting host will utilize the local routing configuration to select the outbound network interface for the outbound packet. But if
REQUIRED_INTERFACE or PREFERRED_NETWORK is configured to prohibit or select source interfaces, the source IP address within the packet will be derived from the specified hostname.
The remote host will receive the inbound connection and present the data to the application, but may then close the socket if these conditions are met.
- The receiving host has a network interface on the same network as the
REQUIRED_INTERFACE or PREFERRED_NETWORKof the transmitting host. - The packet was received on a different network interface.
- The receiving host is configured for the strong host model.
If closed, the application layer on both hosts will receive an error when the expected data cannot be sent or received. The operating system may also mask the destination IP address from the receiving application if the integrity of the packet source is suspect.
Troubleshooting:
Check the NetBackup logs and confirm that the sockets are established, but then removed within a few milliseconds before utilized by the application. The getsockname system call may also return '0.0.0.0' for the local IP address if the receiving network interface was not on the expected network.
Log Files:
This bpcd log shows a connection that was received by bpcd, but was already closed when the application tried to read the data that should have been presented along with the connection. Notice that the destination IP address is 0.0.0.0, indicating that although the source IP address is 192.168.1.2, it was received on a network interface other than 192.168.1.0.
...snip...
...snip...
This vnetd log shows a connection that was received by vnetd, but was already closed when the application tried to read the vnetd version number from the socket, VN_STATUS_CONNECT_RESET = 43.
This bpbrm log is only verbose 1, but shows a connection was attempted to bpcd on the client via vnetd. The connection reaches the remote host, but attempts to read the socket options were not successful as the socket was never fully established. Consequently bpbrm suffers a timeout (errno 145 = ETIMEDOUT, VN_STATUS_CONNECT_FAILED = 18) and fails the operation with status 25.
Resolution:
This situation is best resolved by configuring NetBackup to use host names that resolve to IP addresses associated with the desired network paths. This eliminates the need to configure
In those instances where it is necessary to configure NetBackup to connect to a host over one network (e.g. public.domain.com) but utilize required interface to ensure that return traffic is over a different network (e.g. backup.domain.com), then the strong host model must be disabled or the weak host model must be enabled.
This can be accomplished on Windows 2008 using the following commands.
Additional information is available from these Microsoft TechNet articles;
https://technet.microsoft.com/en-us/magazine/cc137807.aspx
https://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx
Please also see the Related Articles.
Troubleshooting:
Check the NetBackup logs and confirm that the sockets are established, but then removed within a few milliseconds before utilized by the application. The getsockname system call may also return '0.0.0.0' for the local IP address if the receiving network interface was not on the expected network.
Log Files:
This bpcd log shows a connection that was received by bpcd, but was already closed when the application tried to read the data that should have been presented along with the connection. Notice that the destination IP address is 0.0.0.0, indicating that although the source IP address is 192.168.1.2, it was received on a network interface other than 192.168.1.0.
13:22:51.186 [8588.2032] <2> logconnections: BPCD ACCEPT FROM 192.168.1.2.592 TO 0.0.0.0.13782
...snip...
13:22:51.201 [8588.2032] <2> bpcd peer_hostname: Connection from host nbu-mm (192.168.1.2) port 592
...snip...
13:22:51.217 [8588.2032] <4> bpcd valid_server: hostname comparison succeeded
13:22:51.217 [8588.2032] <16> bpcd main: read failed: An existing connection was forcibly closed by the remote host.
This vnetd log shows a connection that was received by vnetd, but was already closed when the application tried to read the vnetd version number from the socket, VN_STATUS_CONNECT_RESET = 43.
13:22:30.188 [9928.5332] <2> ProcessRequests: .\vnetd.c.281: msg: VNETD ACCEPT FROM 192.168.1.2.37634 TO 0.0.0.0.13724 fd = 556
13:22:30.188 [9928.5332] <2> vnet_pop_byte: ..\libvlibs\vnet.c.184: errno: 10054 0x00002746
13:22:30.188 [9928.5332] <2> vnet_pop_byte: ..\libvlibs\vnet.c.186: Function failed: 43 0x0000002b
13:22:30.188 [9928.5332] <2> vnet_pop_string: ..\libvlibs\vnet.c.266: Function failed: 43 0x0000002b
13:22:30.188 [9928.5332] <2> vnet_pop_signed: ..\libvlibs\vnet.c.310: Function failed: 43 0x0000002b
13:22:30.188 [9928.5332] <2> vnet_version_accept: .\vnetd.c.1102: Function failed: 43 0x0000002b
13:22:30.188 [9928.5332] <2> ProcessRequests: .\vnetd.c.285: version_accept failed: 43 0x0000002b
13:22:30.188 [9928.5332] <2> ListenForConnection: .\vnetd.c.586: Function failed: 43 0x0000002b
13:22:30.188 [9928.5332] <16> main: Terminating with status 43
This bpbrm log is only verbose 1, but shows a connection was attempted to bpcd on the client via vnetd. The connection reaches the remote host, but attempts to read the socket options were not successful as the socket was never fully established. Consequently bpbrm suffers a timeout (errno 145 = ETIMEDOUT, VN_STATUS_CONNECT_FAILED = 18) and fails the operation with status 25.
13:21:59.400 [17203] <2> vnet_async_connect: vnet_vnetd.c.4217: getsockopt SO_ERROR returned: 145 0x00000091
13:22:09.410 [17203] <2> vnet_async_connect: vnet_vnetd.c.4019: connect in progress: 0 0x00000000
13:22:19.419 [17203] <2> vnet_async_connect: vnet_vnetd.c.4217: getsockopt SO_ERROR returned: 145 0x00000091
13:22:30.428 [17203] <2> vnet_async_connect: vnet_vnetd.c.4019: connect in progress: 1 0x00000001
13:23:16.425 [17203] <2> vnet_async_connect: vnet_vnetd.c.3801: ran out of time before connect: 302 0x0000012e
13:23:16.426 [17203] <2> vnet_async_connect: vnet_vnetd.c.3801: ran out of time before connect: 302 0x0000012e
13:23:16.426 [17203] <2> vnet_connect_to_service_or_vnetd: vnet_vnetd.c.3570: vnet_async_connect failed: 18 0x00000012
13:23:16.426 [17203] <2> nb_connect_to_vnetd_or_legacy: comm.c.2030: vnet_connect_to_vnetd_or_service failed: 18
13:23:16.426 [17203] <2> local_bpcr_connect: nb_connect_to_vnetd_service(nbu-client) failed: 25
13:23:16.426 [17203] <2> local_bpcr_connect: Can't connect to client nbu-client
13:23:16.426 [17203] <2> ConnectToBPCD: bpcd_connect_and_verify(nbu-client, nbu-client) failed: 25
13:23:16.426 [17203] <16> bpbrm start_bpcd_stat: timed out trying to connect to nbu-client
Resolution:
This situation is best resolved by configuring NetBackup to use host names that resolve to IP addresses associated with the desired network paths. This eliminates the need to configure
REQUIRED_INTERFACE or PREFERRED_NETWORK and the transmitted packets will not conflict with the strong host model.
In those instances where it is necessary to configure NetBackup to connect to a host over one network (e.g. public.domain.com) but utilize required interface to ensure that return traffic is over a different network (e.g. backup.domain.com), then the strong host model must be disabled or the weak host model must be enabled.
This can be accomplished on Windows 2008 using the following commands.
netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enable
netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enable
netsh interface ipv4 show interface [InterfaceNameOrIndex]
Additional information is available from these Microsoft TechNet articles;
https://technet.microsoft.com/en-us/magazine/cc137807.aspx
https://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx
Please also see the Related Articles.
Related Knowledge Base Articles
Was this content helpful?
Translated Content
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.