ONTAP Discussions

Issue with snapmirror


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








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 




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

snapmirror.access *


any more info required?









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



Is there more info available in the snapmirror log file:

Also check: (When you initiate snapmiror initialize)

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



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 




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.


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







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.




Thank you for your help