cluster replication using eom ports on one side, intercluster LIFs on other

[uphill]

Hi, I have noticed slow throughput initializing replicated vols across a WAN. It finally dawned on me to check the paths in use, and on the source cluster it's sending traffic out both controllers over e0m ports but it is coming on on the far side ports using the preferred IC LIFs which are setup with jumbos whereas the e0m's are not.

My question is would IPspaces be the use case for solving this or just adding specific routes to the vserver for the cluster?

When our VAR helped set these up they had us put "all" broadcast domains into the default IPspace and I'm not sure if I want to monkey with those thus the question. Both running 9.11.1

thanks!

[TMACMD · Accepted solution]

You may want to check that. 
i didn’t think it was even possible to put a lif on e0M. But if you have an older system, maybe it was possible. I don’t think e0M can hold a port with a service policy unless it’s default-management. Someone has tested putting a data lif there and it fails. I suspect it will for intercluster

 you should at a minimum create one lif per node that is not on e0M. Most just create a vlan for this purpose. 

Typically, if I have a dedicated vlan for intercluster traffic i will create an ipspace called ic then assign the ports to that ipspace. When you set up the cluster peering you need to identify the correct ipspace. 

also there are a couple of scenarios where placing intercluster lifs in a dedicated ipspace cause issues. Unfortunately i have forgotten what they are and I typically do not hit those issues anyway

[uphill]

I probably made that more confusing than worth. No LIF on e0m, but I just solved trial by fire - adding specific route to each cluster SVM using the preferred path via dedicated LIF's which happen to be IC's. So, the throughput went from ~100MB/s to over 500 per LIF (that's what I wanted). 

The IPspace thing seems like it would have been better to build up front rather than putting them all into default, but, the installer was not keen on anything other than "how they usually do it". 

Regardless adding the route to the "right" SVM using the preferred GW solved it. thanks for the fast reply!.