03-03-2018 08:33 PM
03-05-2018 04:58 AM
03-06-2018 03:41 AM
The problem is that it most often works two ways. If a initiators observes a problem it'll propagate to a target at some stage. When that port is going in an error recovery scenario it will have an onflow effect on all initiators mapped to it. That is irrespective of how zoning is configured.
A fan-in ratio of 170 to one (NPIV or not) isa very, very bad idea.
03-06-2018 08:32 AM
Any port may be configured to supress RSCN and notification.
portcfg rscnsupr --enable (*two dashes in front of 'enable'*)
Use with caution. This does not address the original issue of devices leaving the fabric without explanation. However, it will reduce the RSCN issue. I suggest you resolve the device dropping problem, and the RSCN issue will not cause trouble, unless it is the RSCN traffic which is causing the device to drop?
03-06-2018 04:18 PM
Which I think is a very, very bad idea. The RSCN's are there for a reason.If you disable this on the array-port thanthat port has no idea if one or more initiators or NPIV addresses have left the fabric or if a zone-change has occured.
This subsequently incurs the problem that the array is required towait for each outstanding exchange to timeout for at leastan R_A_TOV timeout and it will not be able to use those resources during that time.
On a normal operating workload thou shall not exceed a 40:1 fan-in ration which personally think is still a potential killer when workload is uncontrolled.
03-06-2018 10:38 PM