Brocade troubleshooting: ports, zoning, segmentation, optics and slow drain

01Record the incident scope and last known good service

1. Record affected application, host WWPN, target WWPN, LUN identity, first failure time/timezone and recent changes. Determine whether I/O is stopped or continuing with reduced paths.
2. Confirm correct FID and observed physical port/index. Find the surviving client path before considering any physical or configuration change.
3. Preserve current counters, logs, effective zoning and endpoint evidence. Avoid resets/clears that destroy the failure timeline.

version
switchshow
fabricshow
mapsdb --show
mapsdb --show history
errdump

02Scenario: an endpoint port will not come online

1. Check administrative/operational state, port role and the exact failure reason. Compare the port with the worksheet and endpoint owner.
2. Verify the HBA/target is powered and enabled, supported speed and optics agree, port entitlement is available and cable polarity/route is correct.
3. Use approved connector inspection/cleaning or a one-component replacement only after alternate service is confirmed. Record each change instead of swapping multiple items at once.
4. Recheck stable online role, expected port WWPN login and interval error counters under traffic.

switchshow
portshow 0
portcfgshow 0
sfpshow 0
porterrshow
portstatsshow 0

03Scenario: online port but no expected initiator login

Verify the actual host HBA WWPN, cable endpoint, current logical fabric and relevant login/security/NPIV requirements. Multiple expected virtual identities can share a physical port, but a missing expected identity still requires investigation. Directory registration and target-side login are distinct checks.

portloginshow 0
nsshow
nsallshow
nodefind 10:00:00:90:fa:aa:00:01
portshow 0

04Scenario: zone exists but the host still cannot reach storage

1. Verify the exact alias WWPNs and conventional/peer-zone semantics, including any overlapping effective zone.
2. Check that the new zone belongs to the enabled complete configuration. A saved definition that was never enabled is not effective access.
3. Coordinate the current transaction owner and use a scoped correction/activation only after reviewing the complete candidate. Do not clear or disable all zoning.
4. After fabric permission works, check target initiator login, igroup/LUN mapping and supported host discovery.

cfgshow
cfgactvshow
cfgtransshow --opentrans
alishow
nsshow

05Scenario: an ISL is segmented or a fabric join failed

1. Read the stated segmentation reason rather than assuming every join failure is zoning. Determine whether physical link, logical context or policy merge failed.
2. Compare domain identities, effective/defined zoning types and contents, same-name object differences, default-zone policy and open transactions.
3. Review relevant security/authentication, encryption/compression, software interoperability and FID/base-fabric topology requirements for this design.
4. Resolve the exact conflict through an approved merge plan with backups and client resilience. Do not erase zoning, force a domain change or disable security as a generic fix.
5. Verify intended fabric members, remote endpoint directory, ISL state and host paths after the correction.

switchshow
fabricshow
islshow
portshow 16
cfgshow
cfgactvshow
defzone --show
errdump

06Scenario: ISLs are online but the expected trunk is absent

1. Confirm the links reach the same intended remote Brocade switch and eligible hardware port group.
2. Compare speed, distance, relevant QoS/FEC/security settings, entitlement and model-specific trunk restrictions. Physical link labels and port indices are not interchangeable.
3. Use the reported incompatibility to prepare a scoped change; trunk-enable changes can flap a port. Do not toggle healthy links as a diagnostic loop.
4. Accept actual member state, aggregate behavior, failure headroom and host service after correction.

islshow
trunkshow
trunkshow -perf
portcfgshow 16
portcfgshow 17
switchshow
# Use actual PORT INDEX values discovered above:
trunkdebug 104 105
license --show

07Scenario: increasing CRC, encoding or signal errors

1. Correlate CRC/encoding/PCS/uncorrectable-FEC and signal/sync/link events on the actual receiving path. A deliberate unplug also increments some counters.
2. Compare module-specific diagnostic thresholds, supported optics, cable type/reach and peer transmit evidence. Do not apply one universal receive-power threshold to every SFP.
3. Inspect/clean or replace one approved suspect component while the alternate service path is confirmed. Retain the original state and replacement identity.
4. Measure a comparable loaded interval afterward. A reset counter at zero or a green LED is not sufficient acceptance.

porterrshow
portstatsshow 0
sfpshow 0
errdump

Synthetic counter example:
09:00 receive CRC count = 24
09:10 receive CRC count = 64
Delta = 40 receive CRC errors in 10 minutes.

08Scenario: Class 3 discards and credit pressure with few CRCs

Credit starvation, Class 3 timeout/discard observations and optical corruption represent different evidence. A zero-credit counter alone does not identify a faulty SFP or prove which endpoint is slow. Backpressure can appear upstream of the actual receiver and affect other flows sharing an ISL. Compare timestamps, direction, traffic and endpoint behavior.

1. Map the affected host/target traffic and shared ports. Capture counter deltas and MAPS congestion observations over the same interval as application latency.
2. Distinguish a slow receiving endpoint from oversubscribed aggregate bandwidth. Adding ISL capacity can help oversubscription but does not repair an endpoint that cannot drain traffic.
3. Correlate host/HBA/OS and storage queue/latency events. Review platform-specific monitoring and licensing before interpreting absent MAPS detail.
4. Use SDDQ, fencing, port toggling or congestion-policy changes only through a reviewed supported design. First correct and measure the identified endpoint/path cause.

portstatsshow 0
portstatsshow 16
mapsdb --show congestion
mapsdb --show history
portperfshow 0 -t 0

09Scenario: Access Gateway hosts lose one uplink

1. Identify which F_Ports map to the failed N_Port/uplink and what failover policy actually permits. A second cable is not proof of a configured supported fallback.
2. On the native upstream switches correlate the expected virtual WWPNs with directory/logins and effective zoning. Verify core NPIV and relevant limits.
3. Correct the specific mapping, uplink or upstream permission through the planned change. A mode conversion is not a link repair.
4. Validate affected and unaffected hosts, expected remapping/failback and application path resilience.

ag --modeshow
ag --mapshow
ag --pgshow
ag --failovershow
ag --failbackshow
switchshow

10Scenario: switch path is healthy but a LUN remains missing

Check whether the storage sees the exact initiator, whether it belongs to the correct host group and whether the expected LUN is mapped and reported through those targets. Then verify the host’s supported discovery/multipath configuration and persistent device identity. A missing mapping is not fixed by default-zone all-access. Never initialize/format an unknown device to test FC connectivity.

# ONTAP admin:
vserver fcp initiator show -vserver svm_lab
lun igroup show -vserver svm_lab
lun mapping show -vserver svm_lab
# Linux host:
multipath -ll
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS
# Windows host:
mpclaim -s -d
Get-Disk

11Collect support evidence and prove the recovered service

1. Collect the affected switch and relevant adjacent peers with correct chassis/FID permissions, approved destination and unique names. Preserve timestamps, topology and both-end evidence.
2. Provide the exact model/release, interface/index, initiator/target WWPNs, failure interval, recent change and before/after observations. Store bundles securely.
3. Recheck hardware, fabric membership, expected logins, effective zones and stable relevant error/congestion deltas.
4. Have application owners confirm actual I/O, correct LUN identity and restored supported path resilience. Observe the interval/load that previously triggered the issue. Export accepted configuration after a configuration correction.

supportsave