Replication failure troubleshooting

Question

We have a PS4100 running v6.0.11 that replicates three volumes over a VPN WAN tunnel to a PS4000 running the same version of firmware. Normally, replication is rock solid, but all replication jobs stalled permanently a couple of days ago. Console error msg: 'replTunnel.cc:1642:ERROR:7.4.78; Partner APPLE: iSCSI: login timed out. Make sure the partner IP address is correct and reachable.' Sad to say, we do not have an up-to-date service contract on either; so I'm seeking help triaging this issue. The VPN tunnel has been restarted and is up; I've successfully pinged 64-byte packets across it. I know that the first test is to successfully pint every destination interface address from every source interface address. Pls remind me of the CLI syntax to do so. My only clue is that the running replication job seems to have stalled about the time that I did a controller restart on the source SAN to swap out the cache battery. Is it possible that the jumbo frames setting has to be set on both controllers? Anyway...guidance would be appreciated; I really have to get this replication rolling again! Thanks!

mrchongo_81d4bc · Answer

Thanks. I did the restart. Same result.

mrchongo_81d4bc · Answer

I worked through a very similar issue last year with EQ support. One of the things the tech did was to restart the MgtExec service. Would you tell me the su command syntax to do that? What I'm finding online isn't working. Thx. J

mrchongo_81d4bc · Answer

I have verified that I can ping across the VPN from the group address and all 'up' Ethernet interfaces to the group address and all 'up' Ethernet interfaces BOTH ways. Also can verify that the repl-use-jumbos value for both groups is set to NO. Tried a test replication after verifying that; still fails; on the PROD group, the replication job shows as 'in progress' in the GUI but with 0 bytes transmitted, and on the DR group, nothing changes in the GUI.

mrchongo_81d4bc · Answer

Since I'm running a VPN tunnel over the WAN, it's kind of an 'all or nothing' situation, wouldn't you say? Either the WAN firewall is going to allow the VPN tunnel, or it's not; it won't be able to parse the tunnel by protocol. The tunnel is up and I can communicate over it with 64-byte ping packets. I need to try packets at the MTU, 1500-bytes. What is the CLI syntax to manipulate the packet size? Thanks!

mrchongo_81d4bc · Answer

Thank you. I'll get with my firewall team to verify that 3260 & ICMP traffic are passing.

Sorry, I wasn't clear in my packet size question. What I meant to ask is "What is the CLI syntax to manipulate the PING packet size? I need to test at the MTU of 1500 bytes, not the default ping packet size of 64 bytes.

I appreciate all of your help!

mrchongo_81d4bc · Answer

Even with an MTU of 1500 bytes, trial and error testing shows that the command ping 's- 1472 192.168.x.x' works, returning a console response: 1480 bytes from 192.168.x.x: .....' anything larger fails. Is that significant to the console error msg of 'iSCSI login failure'?

mrchongo_81d4bc · Answer

I had previously run the comprehensive set of ping commands, from all interfaces to all interfaces, successfully.

I have received confirmation from our NOC that port 3260 and ICMP traffic flow across the WAN unimpeded.

The console output on the iSCSI login failure is: "4271:2570:NILS:MgmtExec: 8-Aug-2016 12:22:38. 182571:relTunnel.cc:1642:ERROR:7.4.78:Partner APPLE: iSCSI: login timed out. Make sure the partner IP address is correct and reachable."

I learned during a previous troubleshooting exercise for a similar issue that replication includes an iSCSI login.

Thanks.

EqualLogic

Was this post helpful?