Snapmirror failure

[wary epoch]

We have a cascade relationship A1->B1 (snapmirror) -> C1 (Snapvault), A1 and B1 have recently been upgraded to 9.17.1 with C1 running 9.13.1 and since then the vault backups are failing with below error:

(Failed to start transfer.(Destination not supported(Operation not supported)))

Found this KB but it doesn't seem be to be applicable here, we are also not using -is-large-size option (https://kb.netapp.com/on-prem/ontap/DP/SnapMirror/SnapMirror-KBs/Failed_to_start_transfer_Destination_not_supported_Operation_not_supported)

Found this as well but not having permission to view the content - https://kb.netapp.com/on-prem/ontap/Ontap_OS/FS_Issues/CONTAP-599697

Snapmirror compatibility looks correct, any leads ?

[pine halo]

can you upgrade the destination to 9.17 as well? Usually, best practices say you should start with upgrading the destination and then the source

[chrome gull]

For some reason someone flipped the KB internal. Should be fixed soon.
This isn't timely, but there is a fixed 9.17.1 version now available for that issue which you can also use to fix this issue by installing it on your A1/B1 clusters.

[wary epoch]

Update: we patched the A1 and B1 clusters to a fixed version (9.17.1P5) but it did not fix the issue, upgrading the destination is not an option at the moment as we are hosting backups from a customer running ONTAP 9.8 😲,raised a support case for next steps

[wary epoch]

Update: NetApp support seems to be clueless at the moment and have no idea on how to fix this issue

[ancient ferry]

Not sure it helps, but we have a customer on 9.8P21 who backup their volumes (snapvault) to a ONTAP 9.16.1P10 (which I also think is't supported, but works)... (we also have Lenovo branded ONTAP customers which also works...)

we have yet to upgrade to 9.17...

I think it makes a difference if it's a DP or XDP relationship as well...

[chilly yew]

Destinations should always be a later version. Upgrading the destination should always be first, least disruptive, then generally there’s a failover for the primary/production to be upgraded, then a resync, because if a catastrophic event occurred why destination is later than source, a resync can’t occur because destination (primary/prod) is now lower than source (the DR that is serving data). Specific plan depending on your requirements.

The window of time of differing major versions should be as short as possible.

All of this is major versions… 9.15, 9.16. Patch releases within the same major release are expected to be fully compatible in both directions.