RPC Error: The remote procedure call failed: Code 0x6BE

[ernest_brant]

Hello All

Can someone please assist with the following issue

We are using NetApp PowerShell Toolkit version 3.2.0.68

The version of DataONTAP on the filer is 7.3.7P1

when issuing a Get-NaSnapShot against a filer (from any version of Windows and using various versions of PowerShell) we often get (but not always) the same error (after about 70 seconds of waiting) for a couple of specific volumes.

RPC Error: The remote procedure call failed: Code 0x6BE

I switched to the HTTP protocol instead of using RCP and performing the same action gives a different error as follows

Object reference not set to an instance of an object

listing the snapshots via get-naSnapShot on other volume on the same filer works OK (at least in all the tests) it is just a couple of volumes on the filer will often (more often than not) fail with the above errors (depending if using RCP or HTTP to connect).

Has anyone seen this before?

the volumes it seems to fail lon are largish (not sure if that is relevent)

Are there known issues with the version of DataONTAP on the filer i.e. 7.3.7P1 particularly in relation to the issues we are seeing.

Any suggested causes/fixes please?

Thanks All

[ernest_brant]

PS

I forgot to mention I have also tried adjusting the following global variable upto 400 seconds, but this made no difference

global:CurrentNaController.TimeoutMsec

Thanks

[mark_schuren]

I have noticed a similar issue, which only happened to appear when querying snapmirror destination volumes.

E.g. when you are trying to "Get-NaSnapshot" from a VSM destination that has a very frequent update schedule (e.g. all 3 minutes), then some API/powershell calls to this volumes sometimes work, and sometimes throw errors like the one you are seeing. This is related to the nature of snapmirror (which lets the volume "jump in time" briefly after every snapmirror tranfer). Don't know if there is a real fix for this.

Could that be related to your issue?

[ernest_brant]

Thanks very much for the input Mark

On this occasion we are querying the source volumes (they are snap-mirrored but we are querying the source for a list of snapshot rather than the destination). I will check the SnapMirror schedule just to check if the errors coincide with the snap mirrors.

Thanks