Detect, investigate, and respond to advanced threats. Confirm and manage identities. Ultimately, prevent IP theft, fraud, and cybercrime.
Explore products and solutions from RSA.
Category: Dell
VNX: File Replication – Completing transfer failed:DpRequest_vs_BranchExist. Session inactive (User Correctable)
| Article Number: 504636 | Article Version: 3 | Article Type: Break Fix |
VNX2 Series,VNX8000,VNX5200,VNX5400,VNX5600,VNX5800
A replication session may encounter the following rare error which halts the replication transfer:
“completing transfer failed:DpRequest_vs_BranchExist. Session inactive.”
“internal policy has become inactive:DpRequest_vs_BranchExist.”
/nas/log/sys_log will display the following:
Aug 9 06:53:38 2017:DART:REP:ERROR:18:Slot 4:Source=CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX(alias=repl_1), completing transfer failed:DpRequest_vs_BranchExist. Session inactive.Aug 9 06:53:38 2017:DART:DPSVC:ERROR:13:Slot 4:The replication session:CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX internal policy has become inactive:DpRequest_vs_BranchExist.Aug 9 06:57:48 2017:DART:REP:ERROR:18:Slot 4:Source=CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX(alias=repl_1), completing transfer failed:DpRequest_vs_BranchExist. Session inactive.Aug 9 06:57:48 2017:DART:DPSVC:ERROR:13:Slot 4:The replication session:CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX internal policy has become inactive:DpRequest_vs_BranchExist.Aug 9 07:01:38 2017:DART:REP:ERROR:18:Slot 4:Source=CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX(alias=repl_1), completing transfer failed:DpRequest_vs_BranchExist. Session inactive.Aug 9 07:01:38 2017:DART:DPSVC:ERROR:13:Slot 4:The replication session:CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX internal policy has become inactive:DpRequest_vs_BranchExist.
This error causes the replication session to come to an abrupt halt and can only be resumed when a replication stop and start is completed from the Source side array.
This error is logged when there are checkpoints with duplicate ID’s saved in DART memory at the time the message was logged. This state is temporary while checkpoints are being deleted or refreshed and new checkpoints are being created.
Perform a stop of the affected replication session from the Source side array. When the session is stopped, perform a replication start to resume the replication session.
Example:
(1) Stop the replication session from the Source side:
nas_replicate -stop repl_1
(2) Start the replication session from the Source side:
nas_replicate -start repl_1
(3) Verify that the replication session has resumed:
nas_replicate -i repl_1
In the case of further re-occurrences , please contact DELL EMC Customer Service and quote this service request for further assistance.
Related:
ViPR SRM: ViPR SRM Cannot display graphical report for more than 2 days
Detect, investigate, and respond to advanced threats. Confirm and manage identities. Ultimately, prevent IP theft, fraud, and cybercrime.
Explore products and solutions from RSA.
Related:
ECS: One node will not power on in an ECS Gen1 or Gen2 system.
| Article Number: 504631 | Article Version: 3 | Article Type: Break Fix |
ECS Appliance,ECS Appliance Hardware,Elastic Cloud Storage
This KB article addresses when only one node will not power-on in an ECS Gen1 or Gen2 system.
One node will not power on in an ECS Gen1 or Gen2 system.
Bad blade server or bad chassis.
N/A
For ECS Gen1 and Gen2 systems, there are redundant Power Supply Units (PSUs) which supply power to a chassis and up to 4 blade servers in the chassis.
Based on this, if 1 node out of 4 will not power on, the issue can’t be the PSUs because the other nodes in the same chassis are powered on.
The issue has to be the blade server or the chassis itself.
Using an example where node 4 will not power on, one can swap the blade server from the node 3 position to the node 4 position and vice versa.
If the issue stays with the slot where node 4 resides, the issue is the chassis. If the issue follows the blade server, then the blade server is at issue.
Note: This sort of troubleshooting can only be done at install time before the OS and ECS software is loaded on the system.
Related:
VIPR SRM: VIPR SRM upgrade fails at ‘go to maintenance mode’ step
Detect, investigate, and respond to advanced threats. Confirm and manage identities. Ultimately, prevent IP theft, fraud, and cybercrime.
Explore products and solutions from RSA.
Related:
Avamar: Avamar Callhome is not working after migration to Office365
To setup an SMTP Relay on Office365
In Office365, click Admin, then click Exchange to arrive on the Exchange Admin Center
Click mail flow, and then connectors
Use the “+” to start the wizard to create a new connector:
– From = your organisation’s email server
– To = Office 365
– Enter a name for SMTP Relay
– By verifying that the IP address of the sending server matches one of these IP addresses that belong to your organization sender’s IP address = all Avamar utility nodes that are configured on customer site (IP should match public IP address of location sending email).
And click save to create the connector.
Then you can test it by doing the telnet command:
telnet <smtp office365> 25
EHLO
MAIL FROM:avamar_user_configurated@xxxx.com
It return now:
250 2.1.0 Sender OK
Avamar callhome and dialhome is now working.
Related:
Connectrix B-Series: Device logging in as a loopback
| Article Number: 504622 | Article Version: 3 | Article Type: Break Fix |
Connectrix,Connectrix B-Series Hardware
Why does a HBA or storage device automatically configure to a loopback port?
This could be caused by controller configuration on the HBA or storage.
Check if the end device is configured for Fiber Channel Arbitrated loop (FC-AL). Also check the integrity of the SFP and cable and reset the port as follows
– portcfgpersistentdisable
– portcfgdefault
– portcfgpersistentenable.
If the status of the port is still loopback after doing the above, move the cable to a free port. If the issue follows then it could well be an issue with the connected device and more troubleshooting would need to be done at that end.
Related:
ScaleIO: ScaleiO Ready Node (AMS) reports “The SVM used disk space exceeds the configured threshold”
| Article Number: 504619 | Article Version: 3 | Article Type: Break Fix |
ScaleIO Ready Node Series
scaleio-trace-log reports:
NODE_SVM_OS_DISK_USED_SPACE_HIGH
Collected the following outputs from each node in order to determine where the space is being consumed.
# du -d 1 -h /
# find ./ -size +5M -exec ls -lh {} ;
Upon reviewing the above outputs, it could be seen that (/root/MegaSAS.log) was consuming the space.
MegaSAS.log filling up on each node.
The contents of these logs appear to be the controller configurations and version information, which are being repeatedly printed into the log file.
This is a known issue which is stated to be fixed in version 3.0.
The MegaSAS.log is only required if you have an issue with the RAID Controller.
Workaround:
Save off the logs, then run the following command on each server, to wipe out the contents of the MegaSAS.log.
# cp /dev/null /root/MegaSAS.log
This should stop the error being reported.
Related:
Is Unisphere for VMAX 8.3.0.x affected by CVE-2017-10078
Detect, investigate, and respond to advanced threats. Confirm and manage identities. Ultimately, prevent IP theft, fraud, and cybercrime.
Explore products and solutions from RSA.
Related:
ViPR SRM: After the upgrade of SRM to 4.1.1 SNMP Device Discovery and compliance frontend not working
| Article Number: 504610 | Article Version: 3 | Article Type: Break Fix |
ViPR Family,ViPR SRM 4.1
SNMP Device Discovery and Compliance Frontend URL’s doesn’t work, they just return blank page after the upgrade to 4.1.1
Errors seen on Catalina logs;
Sep 21, 2017 10:35:37 AM org.apache.catalina.core.StandardContext startInternal
SEVERE: One or more listeners failed to start. Full details will be found in the appropriate container log file
Sep 21, 2017 10:35:37 AM org.apache.catalina.core.StandardContext startInternal
SEVERE: Context [/device-discovery] startup failed due to previous errors
Sep 21, 2017 10:36:19 AM org.apache.catalina.core.StandardContext startInternal
SEVERE: One or more listeners failed to start. Full details will be found in the appropriate container log file
Sep 21, 2017 10:36:19 AM org.apache.catalina.core.StandardContext startInternal
SEVERE: Context [/compliance-frontend] startup failed due to previous errors
Errors seen on Localhost logs;
21-Sep-2017 10:35:37.739 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class com.watch4net.apg.gui.servlet.ApplicationListener
java.lang.IllegalStateException: Can’t create master accessor.
Caused by: javax.naming.NameNotFoundException: Name [jdbc/master] is not bound in this Context. Unable to find [jdbc].
21-Sep-2017 10:36:19.211 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class com.watch4net.apg.gui.servlet.ApplicationContextListener
java.lang.IllegalStateException: An error occurred notifying listeners !
Caused by: java.lang.IllegalStateException: An error occurred creating the datasource.
Caused by: javax.naming.NameNotFoundException: Name [jdbc/master] is not bound in this Context. Unable to find [jdbc].
Login to Frontend server via putty.
Navigate to the location:
/opt/APG/Web-Servers/Tomcat/Default/conf/Catalina/localhost
Edit the device-discovery.xml and compliance-frontend.xml files as below:
The device-discovery.xml file had the incorrect entry to the database entries;
<ResourceLink name=”jdbc/master” global=”jdbc/master” type=”javax.sql.DataSource”/>
Changed it to
<ResourceLink name=”dba/master” global=”dba/master” type=”com.watch4net.apg.gui.datasource.DatasourceConfiguration”/>
Compliance-frontend.xml file had incorrect master db configuration
<ResourceLink name=”jdbc/master” global=”jdbc/master” type=”javax.sql.DataSource”/>
Changed it to
<ResourceLink name=”dba/master” global=”dba/master” type=”com.watch4net.apg.gui.datasource.DatasourceConfiguration”/>
Restarted the tomcat and resolved the issue
Also, verify if the resource link entries are same as above in context.xml for both the modules under location:
context.xml for device-discovery:
/opt/APG/Web-Servers/Tomcat/Default/webapps/device-discovery/META-INF
context.xml for compliance-frontend:
/opt/APG/Web-Servers/Tomcat/Default/webapps/compliance-frontend/META-INF