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