ONTAP Discussions

SnapMirror IP Multipath fails (IP Multipath failed to connect to 192.168.x.x)

CohenGrigsby
6,768 Views

I have tried setting up IP multipath (multi) for SnapMirror on my filer with no luck. I believe that I have followed the instructions correctly, however, when a SnapMirror transfer ensues, I always receive the same error(s):

cgsan-pitt-02> Mon Mar  1 13:20:04 EST [cgsan-pitt-02: ipmultipath.setup.connFailed:warning]: IP Multipath failed to connect to 192.168.14.12.
Mon Mar  1 13:20:06 EST [cgsan-pitt-02: ipmultipath.setup.connFailed:warning]: IP Multipath failed to connect to 192.168.14.13.
Mon Mar  1 13:20:06 EST [cgsan-pitt-02: snapmirror.src.multipath.connErr:error]: SnapMirror is unable to set up a multipath/failover connection from cg_vol01_summation_repl to CGSAN-DR-02:cg_dr_vol01_summation_repl, SnapMirror is resorting to a single TCP connection. Please ensure ports 10565 and 10566 are open in the firewall configuration.

There is no firewall in between these filers. They're on the same LAN/WAN. My SnapMirror.conf file is as straightforward as they come....

pittTOdr=multi(192.0.0.173,192.168.14.12)(192.0.0.174,192.168.14.13)
pittTOdr:cg_vol01_summation_repl CGSAN-DR-02:cg_dr_vol01_summation_repl compression=enable,restart=always,kbs=5120 20 * * *

What throws me for a loop is the error about IP Multipath failed to connect to 192.168.14.12/13. From each filer, I can ping the other. I can do a traceroute using either or of the IPs listed in the snapmirror.conf file also. Everything is definitely talking to each other. So why is the multipath connection failing? I've checked my snapmirror.allow.... all of the IPs are in the appropriate files (all of the IPs and hostnames from destination filer are in the source filer's snapmirror.allow and vice-versa). So it doesn't seem to be a security issue either. Is there something here that I'm missing to get this working? Thanks in advance.

1 ACCEPTED SOLUTION

ussenate2008
6,768 Views

From what I read.It has to be on different subnet.Incase of failures.What is the max kbs that you can set for single path replication

View solution in original post

8 REPLIES 8

ussenate2008
6,769 Views

From what I read.It has to be on different subnet.Incase of failures.What is the max kbs that you can set for single path replication

jthaloor
6,768 Views

IF max is not specified, then SM will use whatever is available. While it is tempting to set this from the filer side, you should set this on the router QoS policy so that the entire link is shared equitably.

jthaloor
6,768 Views

I think having the sources IPs on the same subnet (and for the destination) may not work since routing will be an issue. Try changing the two IP to different subnets atleast on one side.

JT

CohenGrigsby
6,768 Views

You both were right on the money. After changing the IP of my secondary NIC (e0b) to a different subnet than that of the primary NIC (e0a), multipath now works properly. No more errors. Thanks a bunch for the assistance.

ussenate2008
6,768 Views

Can you send me the syntax.Did you setup multipath or for fai

lover?

  .

ussenate2008
6,768 Views

.

scottgelb
6,768 Views

One workaround if on the same subnet, is to add two route statements for each IP on the same subnet, and specify a metric of 0...don't use a metric of 1... a route add host for each IP to the destination should fix it...but different subnets is a more elegant way to do this.

CohenGrigsby
6,768 Views

One other thing to note that I found.... the paths used by the two connections MUST be different. We have 2 different routes used for SnapMirror replication.... one route over a fat pipe (100Mbps) and one route over a slow pipe (T1). I configured the replication to use source-e0a --> dest-e0a and source-e0b --> dest-e0b. Straightforward enough. The compression/multipath will only work if the two connections use different lines. I put both connections on the fat pipe and it wouldn't work. I then put only one connection on the fat pipe and one on the slow pipe.... it started working. So in order for this to work properly, from what I've seen in my testing, the two connections must take different paths. Hope this helps anyone who comes across the same issues.

Public