Subscribe
Accepted Solution

Snapmirror error: cannot connect to source filer (Error: 13102)

I have set up a snap mirror from source filer srcfiler to destination filer destfiler on a different network.  I specified a multiplexed configuration in the snapmirror.conf to force replication to occur on a particular interface.  The error I am getting is below:

==ERROR==

com.netapp.sysmgr.client.api.NaApiFailureException

==TIME==

2012-01-11 11:46:55,282

==MESSAGE==

Snapmirror error: cannot connect to source filer

(Error: 13102)

==DETAILS==

No details are available.

==CORRECTIVE ACTION==

No suggested corrective action is available.

==LOCATION==

Location is not specified.

==BROWSER INFO==

App Name: Microsoft Internet Explorer

App Version: 5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; CMDTDF; .NET4.0C; .NET4.0E)

App Codename: Mozilla

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0; .NET CLR 2.0.50727; SLCC2;

.NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; CMDTDF; .NET4.0C; .NET4.0E)

Platform: Win64

Cookie Enabled: true

I have tried setting up this replication job normally (without a multiplexed configuration) and it works.  Other replication jobs I have set up between these two filers work in the opposite direction with the multiplexed configuration.  The designation destination volume does exist (I have tried this replicating both a volume and a qtree and both fail).  Any ideas why I get this error in one direction only?

Highlighted

Re: Snapmirror error: cannot connect to source filer (Error: 13102)

I figured it out with the help of Scott Owens.  It turns out it's the same issue that has bitten others before.  At Scott's suggestion I ran a packet trace on the destination filer while kicking off the snapmirror initialization.  Traffic was exiting on the wrong interface.  I fixed it by adding a route statement on the destination filer that specifically directs traffic to the source filer to use the desired interface (in this case, the iSCSI VIF).  Thanks to Scott for pointing me in the right direction.