Re: SnapMirror handshake change between ONTAP 7.3.6 and 8.0.3

LKHAIMOVICH · ‎2013-02-21

Hi,

I am working on the code processing Snapmirror traffic. It worked with ONTAP 7.3.6, but fails with a setup, which has 8.0.3 installed. I can see a considerable change in the way handshake is performed and wonder if it's a general change made between the above two versions, or the 8.0.3 systems I inherited have some kind of unusual setup. If it's the general change, when exactly did it occur and what was the goal of introducing it? If the difference is caused by a specific setup, which one?

Here is the description of the differences captured by tcpdump:

ONTAP 7.3.6, the source volume, dest volume/host name are sent in one packet from

dest filer:

68 28.579160 10.5.129.241 10.5.129.221 TCP 128 52802 > 10566 [PSH,

ACK] Seq=9 Ack=9 Win=5840 Len=62 TSval=101187495 TSecr=10305856

Data&colon; 00701e0005000000766f6c34000b000000766f6c3164656d...

0x701e00 5 vol4 10 vol1demo4 7 lsnap2 ...

ONTAP 8.0.3, the source volume, dest volume/host name are sent in separate packets:

first dest filer sends two packets with volume info:

64 58.164679 10.5.140.169 10.5.140.157 TCP 70 41555 > 10566 [PSH,

ACK] Seq=9 Ack=9 Win=5840 Len=4 TSval=98444041 TSecr=1944069156

Data&colon; 00701e00

68 58.204660 10.5.140.169 10.5.140.157 TCP 79 41555 > 10566 [PSH,

ACK] Seq=13 Ack=9 Win=5840 Len=13 TSval=98444081 TSecr=1944069156

Data&colon; 09000000746573745f79616f00

9 test_yao

then the source filer send back its filer name

73 58.244352 10.5.140.157 10.5.140.169 TCP 76 10566 > 41555 [PSH,

ACK] Seq=13 Ack=26 Win=7340800 Len=10 TSval=1944069165

TSecr=98444041

Data&colon; 69726f6e666f72676500

ironforge

75 58.256681 10.5.140.169 10.5.140.157 TCP 70 41555 > 10566 [PSH,

ACK] Seq=26 Ack=23 Win=5840 Len=4 TSval=98444133 TSecr=1944069165

Data&colon; 09000000

after that, the dest filer sends the volume/host name

80 58.296662 10.5.140.169 10.5.140.157 TCP 116 41555 > 10566 [PSH,

ACK] Seq=30 Ack=23 Win=5840 Len=50 TSval=98444173 TSecr=1944069165

Data&colon; 746573745f79616f000a00000073746f726d77696e64000b...

test_yao stormwind ....

Thank you,

--Leon.

aborzenkov · ‎2013-02-21

TCP stream does not have packets, your application should not depend on it.

LKHAIMOVICH · ‎2013-02-25

I am not sure what you mean. Maybe you could explain (or point me to the right source) how SnapmMirror handshake is done in ONTAP 8? I hope it's not a proprietory information.

aborzenkov · ‎2013-02-26

I mean that TCP is stream based, so there is no packet boundary in TCP. No, I do not have any information about internal implementation of SnapMirror, sorry.

LKHAIMOVICH · ‎2013-02-26

Sure, TCP is stream based. How is this relevant for the handshake question I have? During the handshake there should be a very structured and repeatable exchange of clearly defined packets ( or we may call them segments), right?