ONTAP Discussions

Snapmirror (transfer aborted because of network error)

FABRICIO_ALMEIDA
17,389 Views

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?

 

 

 

 

1 ACCEPTED SOLUTION

FABRICIO_ALMEIDA
12,109 Views

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

View solution in original post

21 REPLIES 21

JGPSHNTAP
16,946 Views

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

FABRICIO_ALMEIDA
16,937 Views

hank 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!

 

 

JGPSHNTAP
16,931 Views

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.   

FABRICIO_ALMEIDA
16,923 Views

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!

 

 

JGPSHNTAP
16,917 Views

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

FABRICIO_ALMEIDA
16,915 Views

The 2220 system has no snapmirror.allow file, only the source (2240-4).

 

Thanks.

JGPSHNTAP
16,913 Views

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

FABRICIO_ALMEIDA
16,908 Views

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?

JGPSHNTAP
16,904 Views

Well at this point it must be something simple.. I think we covered all our basis on this.. i must just be missing this...

mglanville2
14,026 Views

The Destination has MTU 9000 on it's network configuration,  the source only 1500.... could be something related to that.....  

 

Check  KB2014392

 

Matt G.

HTGPETERVG
14,441 Views

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,

vims
14,434 Views

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

FABRICIO_ALMEIDA
14,430 Views

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.

HTGPETERVG
14,425 Views

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.

FABRICIO_ALMEIDA
14,422 Views

Hello 

 

 

 

HTGPETERVG
12,778 Views

As a troubleshoot step I would disable jumboframes on source and destination and see if it works with mtu size 1500.

FABRICIO_ALMEIDA
12,765 Views

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

FABRICIO_ALMEIDA
12,758 Views

Folks,

 

I opened a case with NetApp Support.

 

When i have a solution, i will post it here.

 

Thank you.

Uddhav
12,705 Views

Do the packet trace ,  your source might be doing

TCP Dup and CheckSum error

FABRICIO_ALMEIDA
12,110 Views

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

Public