Loading...
Loading...
Cyber Recovery policies are affected if there is an MTU difference between Data Domain and Cyber Recovery interfaces. Protection jobs are failing, or jobs are running for long periods of time. Below is an example of a failed job: Error: Replication monitoring thread found stale replication context status data for DD: VaultDataDomain. Cache was last updated 338 seconds ago. severity":Critical summary:Unable to initiate a Data Domain replication synchronization job. description:An attempt to start a Data Domain replication synchronization job is unsuccessful. remedy: 1. Verify that Data Domain credentials were not updated. 2. Verify the health of the Data Domain storage system: DD Boost, Network, Filesystem status. 3. Verify connectivity from the Cyber Recovery Management Host to this Data Domain storage system. From mgmtdds.log (located at /opt/dellemc/cr/var/log/mgmtdds ): [INFO] [mgmtdds] [ddssh.go:732 CreateSSHClientConn()] : Establish SSH connection using ssh-key with credential [INFO] [mgmtdds] [ddssh.go:759 CreateSSHClientConn()] : SSH connecting to VAULT_NAME_CR:22 [INFO] [mgmtdds] [ddssh.go:339 func1()] : Running: VAULT_NAME_CR:22 net ping count 1 DATA_DOMAIN_NAME [INFO] [mgmtdds] [replicationMonitor.go:130 MonitorReplicationAndPortDetails()] : Scheduled DD monitor cache refresh [INFO] [mgmtdds] [ddssh.go:339 func1()] : Running: VAULT_NAME_CR:22 replication status all detailed [INFO] [mgmtdds] [ddssh.go:339 func1()] : Running: VAULT_NAME_CR:22 net config [DEBUG] [mgmtdds] [ddssh.go:366 RunSSHCmdWithTimeout()] : Exiting [DEBUG] [mgmtdds] [ddUtils.go:155 RunDDSSHCmdWithTimeout()] : Exiting [ERROR] [mgmtdds] [replicationMonitor.go:170 func1()] : The SSH command did not return within the specified timeout of 45s [ERROR] [mgmtdds] [replicationMonitor.go:249 RetrieveAndCacheReplicationStatusDetails()] : Mgmtdds monitoring thread could not retrieve the replication status details...Error retrieving replication status details from DD 6463667c7d9dc0937xxxfa331 : The SSH command did not return within the specified timeout of 45s [DEBUG] [mgmtdds] [replicationMonitor.go:250 RetrieveAndCacheReplicationStatusDetails()] : Exiting [ERROR] [mgmtdds] [ddssh.go:346 func1()] : Failed to run: 'replication status all detailed' err: wait: remote command exited without exit status or exit signal stderr: CTX: [ERROR] [mgmtdds] [ddssh.go:346 func1()] : Failed to run: 'net ping count 1 DATA_DOMAIN_NAME' err: Process exited with status 41 stderr: Net command system error. PING DATA_DOMAIN (xxx.xxx.xxx.xxx) 56(84) bytes of data. From xxx.xxx.xxx icmp_seq=1 Destination Net Unreachable — DATA_DOMAIN ping statistics — 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms [INFO] [mgmtdds] [syncDD.go:394 triggerVaultUnlock()] : Unlocking CR Vault at: vethx [INFO] [mgmtdds] [restauth.go:68 func1()] : POST /irapi/v7/mgmtdds/6463667c7d9dc0937xxxfa331/unlock Start PostUnlockEthInterface [ERROR] [mgmtdds] [syncDD.go:211 syncDD()] : Replication monitoring thread found stale replication context status data for DD: VaultDataDomain. Cache was last updated 325 seconds ago.
In this scenario, the Cyber Recovery interface is configured to use MTU 1442, while the Data Domain management interface is using MTU 1500. The SSH connection timeouts are related to MTU mismatch between the Data Domain and Cyber Recovery interfaces. This mismatch leads to the communication issues between Cyber Recovery and Data Domain.
To resolve the communication issues, configure the Cyber Recovery to use MTU 1500 which matches the Data Domain. This is the default value. It is recommended to engage the Network team to review if communication using MTU 1500 does not work. If the network cannot guarantee MTU 1500, adjust the Data Domain MTU on the management interface to match the Cyber Recovery interface.
Click on a version to see all relevant bugs
Dell Integration
Learn more about where this data comes from
BugZero Plan
Streamline upgrades with automated vendor bug scrubs
BugZero Prevent
Wish you caught this bug sooner? Get proactive today.