topic Re: Issue with snapmirror in ONTAP Discussions

Issue with snapmirror

Afridi — Wed, 08 Jan 2020 06:27:28 GMT

hi there

we have NetApp 8.1 7 mode

i am trying to initiate snapmirror . i am destination and source is other remote side

i have issue wtih snapmirror initiliazation i did following

vol create vol_dr aggr02 9974g

qtree create /vol/vol_dr/qtree_01

snap reserve vol_dr 0

snap sched vol_dr 0

vol options vol_dr nvfail on

vol options vol_dr minra on

vol restrict vol_dr

snapmirror initialize  -S soucefiler:vol_source destinationFiler:vol_dest

[destinationFiler:replication.dst.err:error]: snapmirror: destination transfer from sourcefiler:vol_source to vol_dr :

transfer aborted because of network error.

transfer aborted because of network error

now i have ping sourcefiler and it is ok and traceroute sourcefiler is also ok and reaching the remote filer

pl help i dont know where is the issue

regards

Re: Issue with snapmirror

Afridi — Wed, 08 Jan 2020 08:35:06 GMT

we have no bidirectional replication. it worked fine as i did many time this mirroring .so what chnaged? i have destroyed the destination voloume and re creat it but this time the aggregate is diferent which should not worrying?

plz guide

Re: Issue with snapmirror

Afridi — Wed, 08 Jan 2020 08:49:02 GMT

the rdfile /etc/log/snapmirror says ---transfer aborted due to network error

snapmirror.access *

any more info required?

Regards

Re: Issue with snapmirror

Ontapforrum — Wed, 08 Jan 2020 15:02:00 GMT

Hi,

First thing:
I see you have created qtree on the destination, what are you trying to achieve ?

Snapmirroring to where ?
1) Vol to vol
2) vol to qtree
3) qtree to qtree

To replicate complete copy of the source volume to dest vol:
dest> snapmirror initialize -S systemA:vol0 systemB:vol2
Note:destination volumes must be restricted and destination qtrees must not yet exist.

To replicate non-qtree data from a source to a destination:
Note: Do not use the vol restrict command on a qtree. If you are initializing a qtree, run the following cmd.
dest> snapmirror initialize -S source_system:/vol/source_volume/- dest_system:/vol/dest_volume/qtree_name

To replicate qtree data from a source to a qtree destination
systemB> snapmirror initialize -S systemA:/vol/vol1/qtree4 systemB:/vol/vol1/qtree4bak

Furhter:
Is there more info available in the snapmirror log file:
/etc/log/snapmirror

Also check: (When you initiate snapmiror initialize)
/etc/messages

what is the setting on your source filer?
source> options snapmirror.access

Thanks!

Re: Issue with snapmirror

Afridi — Thu, 09 Jan 2020 10:39:37 GMT

thank you for your time

yeagh there is no need for qtree so i elimante that from vol

but issue resolved just now but still dont know how?

i did following

1. i put the source filer ip in /etc/snapmirror.allow (which is not required as i am the destination and it is required on source side)

2. vol options vol_dr nosnap on

i just did above and then initalize so it worked but at the same time i have asked newtwork resource to check at their side so they confirm that no port block etc so i dont know how it is solved

plz reply

Re: Issue with snapmirror

Ontapforrum — Thu, 09 Jan 2020 11:28:16 GMT

You're welcome.

SnapMirror operation is a PULL mechanism, hence Source must trust destination. As destination is trying to Pull data from the source. Therefore, having destination filer in the snapmirror.allow file is necessary if snapmirror.access is se to legacy. If it's not legacy then it does not bother to check 'allow' file. You can simply put hostnames in the snapmirror.access switch.

Eliminating qtree makes sense otherwise initialization will not start, vol options vol_dr nosnap on is not needed and cannot be the show-stopper. Regarding firewall - Yes, you can veirfy with your Network team. On the filer if you do 'netstat -anMB' you should see source listening on 10566.

Specific to 7-mode:
All forms of SnapMirror and SnapVault use the standard bind/listen/accept sequence on a TCP socket. In an asynchronous SnapMirror or SnapVault relationship, the primary filer listens on TCP port 10566. The secondary filer, using an available user port (1024-65535), will connect to the primary filer or OSSV client on TCP port 10566 to initiate a transfer.

Re: Issue with snapmirror

Afridi — Fri, 10 Jan 2020 09:56:15 GMT

thnak u for reply

now if it was qtree issue so why it was saying about network error . like it should say something else

but as per my memory i use the same configuration many times in which the snapmirror was successfully initiated

Regards

Re: Issue with snapmirror

Ontapforrum — Fri, 10 Jan 2020 11:22:19 GMT

I never said that error happend due to qtree in place, I only said Initializaiton will not happen if there is a qtree in place and this information is well documented in google and on NetApp knowledgebase and I hope you have access to it. Regarding the Network error, not every erorr is coded specific to one issue and it might be number of reasons, sometimes not even related to the error you expect.

You have the 'netstat' and 'pktt' tool at your disposal and along with your network team and I am sure you can investigate it.

Thanks!

Re: Issue with snapmirror

Afridi — Sat, 11 Jan 2020 13:16:19 GMT

Thank you for your help

Regards