Same problem here.  Instead of disabling/enabling iSCSI you can just run a connectivity test and it seems to come back to life.  Hasn't been that big of an issue for me as the link is solid.  Perhaps there is a way to run the connectivity test via cli?

Dan

Problem the client wants everything automated , doesn't want manual intervention.

Do  you have an open case with EMC abou this issue?

Have you looked into fixing the network issues - making the link more stable?

glen

Yes there is an open case with EMC , who have looked at the SP collect logs without giving any solution so far . According to them this might a bug which will be fixed by flare code (Zeus 10 ) upgrade to be releases by end of March 2012

We started running into the exact same problem with mirroview after we upgraded to flare 30.  The SAN initiating the connection is on flare 04.30.000.5.523.  The target SAN is on flare 04.30.000.5.517.  Before the upgrade, we never experienced problems with recovery.  We would get the mail home, but mirrors never became fractured.  It seems the upgrade in the flare made this function more sensitive to network connectivity problems.  The network errors are so minimal, we cant even capture them with the tools we are using.  the problem is getting worse.  Now the SP on both sides is in a "logged out" state.  We have to trespass all our mirrors to the other SP.  To get the problem SP logged back in, we have to reboot the SP.  The when the other SP starts running into the same problems, we have to trespass everything back and reboot that SP.  Not A VALID WORKAROUND!  Support is trying to tell us it is our network, but I pointed out the fact that this got worse after our flare upgrade.  Now SPB is logged out on both SANs.  SPA is starting to hiccup now, and only fractures some of our mirrors, not all.  We have also been able to restore connectivity in the past by pulling the cable and reseating it.  Also not a valid work around. 

The original post described using this method to re-establish connectivity:

"What I have noted is the ISCSI Login is not automatic when the link resumes and according to EMC Support the only solution is to disable and enable ISCSI connection  from  manage connections for the replication to continue  which is a manual  way not automatic."

How can I do this?  The only option I see is to de-register/re-register the port.  Also, SPA is currently in this state:

A login session to the iSCSI target device is already active. (0x712b8008)

The problem was sorted  after the Flare code was upgraded and a patch named Zeus 10 applied  , Now the Recovery Policy works Perfect without any intervention

Thanks Jsang. I was not sure anybody would still be using this post   You described a work around disable/enable iscsi connection.  Were you de-registering then re-registering?

No just disable and enable iscsi connection under manage connections , initially I used to reboot the remote SP's but was adviced by EMC support otherwise

You will have  to disable iscsi connection , disconnect the iscsi port wait for like 5 minutes ,then connect back and enable iscsi connection

Hi Danjost

This used to fix the problem, but has become ineffective.  The problem is gradually getting worse.  Even rebooting the sp's no longer fixes it.