FC partner path misconfigured and lun config check

[#1]

Greetings,

We're seeing occasional autosupport riggers of (FCP PARTNER PATH MISCONFIGURED) ERROR.  99% of the time, there is usually a WWN listed under "lun config check" section of autosupport that stands way out and I can clearly say "this WWN did it" and we know the remedy is primary ports.

However, sometimes a message is triggered and the lun config check of the autosupport looks like this:

==== LUN CONFIG CHECK =====

The following FCP Initiators are sending Read/Write i/o over the

FCP Partner Paths during the last 19 seconds

WWPN                      Partner's Port       ops         bytes

21:00:00:1b:32:05:15:1c               0a         2          1024

21:00:00:1b:32:05:15:1c               0b         2          1024

21:00:00:1b:32:05:09:1c               0d         2          1024

21:00:00:1b:32:09:0b:47               0a         4          2048

21:00:00:1b:32:09:0b:47               0b         4          2048

21:00:00:1b:32:09:d9:48               0d         4          2048

21:00:00:1b:32:09:d9:48               0c         4          2048

Should 4 or 2 ops be triggering this error?

[#2]

Is this on an ESX box as we have the same issue?

Bren

[#3]

No, the WWNs I pasted all belong to properly configured RHEL 4.6 running the host utilities with correct dm-multipath priorities.

We have had ESX hosts on which the Netapp scripts were previously run, reset their paths to be suboptimal.  That's something we're planning on opening a case for if we see it happen again.

[#4]

I don't have an answer for the specific question I'm afraid....but at times when I haven't been able to track down which server/LUN is causing the issue I've....

• run "sanlun lun show" and pipe it to a file
• optimize paths (haven't had problems on AIX boxes at least with running this on the fly -- seems like we had to run it whenever adding LUNs actually as they never had the right paths initially)
• rerun "sanlun lun show" and pipe it to another file
• diff the files to see if any changes

That is, I've done this when I cared enough to take the time to find out.

[#5]

Hi Andrew,

It's definitely a good idea to check the san lun show -p paths, but on these initiators, they are correct.  My question is specifically regarding the ridiculously low number of partner ops/bytes that seem to have triggered this alert...

We are on 7.2.4

Any thoughts?

[#6]

Sorry it is not my area.  All I can offer is try logging a support call.  Or look on the RedHat forum.

Bren

[#7]

Very good question....I'm honestly not sure to be honest. Looking at one side of a 3050c (one has no FCP connections to it, the other has 100+ LUNs via FCP), I am seeing anywhere from 4-10 FCP ops per second when looking at sysstat.

[#8]

(Large multinational reseller/rebrander) support has told me that the time to collect the files necessary for an autosupport message content can outstrip the time period for which the "lun config check" section gets populated (60 to 90 seconds?), and thus that section might look misleading because it has no details against which WWNs are logging partner traffic if the autosupport was really issued for...120 seconds ago...

Does that sound right to anyone?

[#9]

That is possible (although I have never seen it take that long). But "lun stats" will show partner ops and this is complete in the AutoSupport, so NetApp support should be able to pickup on this.