ONTAP Discussions
ONTAP Discussions
Hello folks,
Im not able to estabilish a relantioship between 2 FAS: 2240-4 (source) and 2220 (destination), both in DOT 8.2.1 7-Mode.
Below is the config:
2220> ifconfig -a
ifgrp01: flags=0x26f4c863<UP,BROADCAST,RUNNING,MULTICAST,TCPCKSUM,NOWINS> mtu 9000
inet 192.168.1.226 netmask 0xffffff00 broadcast 192.168.1.255
partner ifgrp02 (not in use)
ether 02:a0:98:5b:06:1a (Enabled interface groups)
2240-4> ifconfig -a
ifgrp01: flags=0x22f4c863<UP,BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
inet 192.168.1.172 netmask 0xffffff00 broadcast 192.168.1.255
partner ifgrp02 (not in use)
ether 02:a0:98:50:96:8a (Enabled interface groups)
2220> options snapmirror
snapmirror.access host=192.168.1.220,192.168.1.222,192.168.1.172,192.168.1.173
snapmirror.checkip.enable off
snapmirror.cmode.suspend off
snapmirror.delayed_acks.enable on
snapmirror.enable on
snapmirror.log.enable on
snapmirror.use_references on (value might be overwritten in takeover)
snapmirror.vbn_log_enable off (value might be overwritten in takeover)
snapmirror.volume.local_nwk_bypass.enable on
snapmirror.vsm.volread.smtape_enable on
2240-4> options snapmirror
snapmirror.access host=192.168.1.226,192.168.1.227
snapmirror.checkip.enable off
snapmirror.cmode.suspend off
snapmirror.delayed_acks.enable on
snapmirror.enable on
snapmirror.log.enable on
snapmirror.use_references on (value might be overwritten in takeover)
snapmirror.vbn_log_enable off (value might be overwritten in takeover)
snapmirror.volume.local_nwk_bypass.enable on
snapmirror.vsm.volread.smtape_enable on
2220> rdfile /etc/log/snapmirror
dst Thu Jan 8 11:51:49 BRS 2240-4:vol1 2220:vol1 Abort (transfer aborted because of network error)
2240-4> rdfile /etc/snapmirror.allow
2220:vol1
Anymore information needed?
Solved! See The Solution
The solution was the /etc/hosts.
There are wrong entries, IP and hostname different.
After i changed to the correct IP/hostname, works well.
Thank you all
Wow, you are really making management of your systems challenging in my opinion.. Unless you work in a secure infrastructure where it is required to lock down transfers to a specific controller and volume, it's easier to set access to "legacy" and put the host in without the volume.
Also, paste a few lines from the destination snapmirror log in /etc/log
I assume you restricted the destination volume
JGPSHNTAP thank you for you response,
I already have tested both controllers in "legacy", but the error persist.
The destination volumes are restricted.
Below are the messages:
dst Thu Jan 8 11:51:47 BRS 2240-4:vol1 2220:vol1 Request (Initialize)
dst Thu Jan 8 11:51:49 BRS 2240-4:vol1 2220:vol1 Abort (transfer aborted because of network error)
Observation: If i invert the source and destination, replication works well.
Thank you in advice!
Ok, let's rule out dns...
Are you using DNS names 2240? Is that the real name?
What's your initialize command look like (please paste)
Do a traceroute from the dst to source with the name in initialize statement.
2240 is not the real name, the real name is composed by words, consider "2220" and "2240-4" fictitious names.
Below is the output of command to initialize the transfer:
snapmirror initialize -S 2240-4:vol1 2220:vol1
Below is the output of traceroute, form destination to source:
2220> traceroute 192.168.1.173
traceroute to 192.168.1.173 (192.168.1.173), 30 hops max, 40 byte packets
1 "2240-4" (192.168.1.173) 0.000 ms 0.000 ms 0.000 ms
2220> traceroute "2240-4"
traceroute to "2240-4" (192.168.1.173), 30 hops max, 40 byte packets
1 "2240-4" (192.168.1.173) 1.000 ms 0.998 ms 0.000 ms
2220>
2220> ping "2240-4"
"2240-4" is alive
2220> ping 192.168.1.173
192.168.1.173 is alive
2220> rdfile /etc/hosts
#Auto-generated by setup Wed Jan 7 03:51:53 BRST 2015
127.0.0.1 localhost localhost-stack
127.0.10.1 localhost-10 localhost-bsd
127.0.20.1 localhost-20 localhost-sk
192.168.1.226 "2220" "2220"-ifgrp01
192.168.1.173 "2240-4"
Thanks in advice!
I assume you are running this command on the 2220, as it's the destination. You need to show me the snapmirror.allow file on that system
The 2220 system has no snapmirror.allow file, only the source (2240-4).
Thanks.
Yes, that's correct.. so you aren't doing bidirectional replication? Just using 2220 as your mirror destination.
It's perplexing to me b/c the network traces look good.. You have the allow file on the source, your dst is restricted, bu your getting network error.. hmm..
Yes, my 2220 is only the destination, there is not a bidirectional replication.
The tracert is good, the destination is allowed in the source and restricted...
You think i will need to open a case on NetApp Support?
Well at this point it must be something simple.. I think we covered all our basis on this.. i must just be missing this...
The Destination has MTU 9000 on it's network configuration, the source only 1500.... could be something related to that.....
Check KB2014392
Matt G.
Hi,
I see that you configure jumboframes on one node and no jumboframes on the other node. You need to configure (or not) jumboframes on both nodes and make sure that the complete path between the two nodes use jumboframes as well (or not).
Kind Regards,
personaly i would start with simple thing
- configure access on both nodes as legasy, as it has been already said
- configure snapmirror.allow on _both_ controllers
- set MTU to 1500 on both ends.
in regards of jumbo frames - it has to be configure on switch as well. I usually bug my network guru to do that 🙂
once you get it working start implementing more secure enviroment if needed.
keep in mind that snapmirror is the destination driven technology and everything should be done on destination node.
(you might know it already)
Cheers
Guys,
I changed the MTU to 900 on source and tried to estabilish a connection but with no success.
After i change the snapmirror.access file to "legacy", already with no success...
I think is not needed to create a file snapmirror.allow on the destination, i have other snapmirror relationships and this are working well...
My environment (switches) support jumbo frames.
Any other ideas?
Thanks in advice.
Hi,
You say that the switches support jumbo frames but are jumbo frames also configured for the ports that the netapp filers connect to?
Gr.
Hello HTGPETERVG,
The switch in question (3com baseline 2928-SFP) are jumbro frames enabled on all ports by default:
http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c02601119&sp4ts.oid=4218346
Thank you.
As a troubleshoot step I would disable jumboframes on source and destination and see if it works with mtu size 1500.
Hello folks,
Apologize for the delay.
I testes with both dest. and source with MTU 1500 and the result is the same... =(
Any other ideas?
Thanks in advice
Folks,
I opened a case with NetApp Support.
When i have a solution, i will post it here.
Thank you.
Do the packet trace , your source might be doing
TCP Dup and CheckSum error
The solution was the /etc/hosts.
There are wrong entries, IP and hostname different.
After i changed to the correct IP/hostname, works well.
Thank you all