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
8 REPLIES 8
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?
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
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.