Brocade advanced: ISLs, trunking, Virtual Fabrics and FOS upgrades

01Prepare a controlled fabric join

1. Confirm that both links belong inside Fabric A. Review unique domain identities, FID/logical context, software interoperability and topology limits.
2. Compare defined/effective zoning, same-name object contents, default-zone policy, security/authentication and any open transactions. Reconcile the actual conflict before cabling a join.
3. Check approved optics, speed, distance and port allocation, plus required feature entitlements. Preserve both peers’ configuration and operational baseline.
4. Define a reviewed isolation/recovery action and verify host alternate access before enabling the planned join. A spare switch with an unknown database is not ready for production connection.

version
switchshow
fabricshow
cfgshow
cfgactvshow
cfgtransshow --opentrans
defzone --show
license --show
fosconfig --show
lscfg --show

02Verify ISLs before assuming a trunk exists

An operational ISL joins switches in the intended fabric. A trunk aggregates qualifying links under the supported Brocade design. Independent operational ISLs may exist without forming one trunk. Read actual role, peer identity, link speed and trunk membership on both ends; do not infer a trunk from two green LEDs.

1. Confirm expected E_Port links and peer switch identities. Inspect segmentation reasons if a link is isolated.
2. Compare every intended member’s supported hardware port group, speed, distance mode and relevant QoS/FEC/security settings.
3. Check trunking entitlement on participating switches for non-ICL trunking; ICL support has separate platform rules. Keep model-specific restrictions in the change plan.

switchshow
fabricshow
islshow
trunkshow
portcfgshow 16
portshow 16

03Diagnose trunk formation with the correct identifiers

A change such as portcfgtrunkport <port> 1 is not a harmless query: it can disable/re-enable that port and interrupt traffic. Use the exact model/release procedure in a scoped maintenance window. Do not toggle every link until a trunk happens to form. Distribute physical dependencies where the platform supports it, and measure the actual traffic/failure result.

trunkshow
trunkshow -perf
switchshow
# Example PORT INDEX values from switchshow, not blindly copied port labels:
trunkdebug 104 105

04Conditional lab configuration for eligible trunk ports

Use this branch only when ports 16 and 17 are designated new links between the same approved switch pair, their hardware grouping and all trunking prerequisites have passed, and trunking is not already enabled as intended. Configure the corresponding eligible peer ports through the same reviewed procedure. These commands can disable/re-enable each target port; they are not safe baseline collection commands.

1. Verify the complete merge prerequisites and current physical/link configuration on both ends before enabling the designated link.
2. Change only the required named ports, then inspect actual member/peer state. Do not repeat disruptive enablement when the expected setting is already present.
3. Verify fabric membership, remote endpoint registration and host service, then measure the supported member-failure behavior and capacity in the approved lab.

portcfgshow 16
portcfgshow 17
# Only if the approved eligible new ports require trunk enablement:
portcfgtrunkport 16 1
portcfgtrunkport 17 1
portcfgshow 16
portcfgshow 17
islshow
trunkshow

05Understand Virtual Fabrics and chassis-wide effects

A FID selects a logical fabric context; it is not the same value as a domain ID and does not use Cisco VSAN syntax. Selecting an existing context affects the CLI session’s target. Moving a port between logical switches changes actual connectivity. Enabling/disabling VF is a chassis-level migration with reboot effects and is not part of a routine zone addition.

1. Document every logical switch, its FID, domain, ports, base/default role where applicable and allowed administrator scope.
2. Before a port move, inventory all attached logins, zones and traffic, then rehearse the supported movement and recovery procedure. Confirm alternate service and the destination fabric policy.
3. After an approved VF change, verify port ownership, expected logins, effective zoning and client paths in every affected context. Logical separation still shares chassis dependencies.

fosconfig --show
lscfg --show
# Select an existing approved context only:
setcontext 20
switchshow
fabricshow

06Use Access Gateway as an edge design, not a zoning shortcut

An Access Gateway maps host-facing F_Ports to fabric-facing N_Ports and uses NPIV toward the upstream fabric’s F_Ports. The native upstream fabric provides zoning. NPIV supplies multiple logical port identities; it does not create a second physical failure path. AG mode support must be checked for the specific edge model.

1. Record host-to-uplink mappings, port groups, failover/failback policy, upstream NPIV support and expected login limits.
2. Verify the virtual initiator WWPNs in the upstream directory and effective zoning. Validate the intended uplink distribution instead of only the physical HBA’s identity.
3. Treat native/AG mode conversion as a separate disruptive migration: preserve backups, management recovery and the model-specific procedure. Conversion affects configuration/security/zoning and reboot behavior.
4. After commissioning, test the supported uplink failure/failback pattern in an approved lab with real host path and application observations.

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

07Preserve both Virtual Fabrics and system configuration

The VF definition/status backup and the all-logical-switch/chassis system configuration backup serve different recovery needs. configupload -all does not replace the separate VF backup. A current-context configupload is useful but has narrower scope. Use unique filenames/directories per switch, chassis and backup type, and verify the remote files.

1. Preserve actual FID definitions and all applicable system/logical configuration with the appropriate permissions. Record the exact scope and restoration procedure.
2. Collect an authorized supportsave when needed for upgrade readiness or incident analysis. It exports diagnostics, traces and potentially cores; it is not just a read-only display and can contain sensitive information.
3. Keep backup and diagnostic files in approved restricted storage and confirm recovery/support owners can retrieve the correct set. Do not use destructive/remove-core options as part of generic collection.

# Chassis-authorized backup sequence for a Virtual Fabrics deployment:
configupload -vf
configupload -all
# Separate diagnostic export when required:
supportsave

08Choose the supported FOS path and maintenance method

1. Inventory the exact switch/director, current FOS build, licenses, blades and enabled features. Read the target release notes, supported hardware and upgrade/downgrade guide.
2. Select the supported current-to-target route, including intermediate releases and OEM support requirements. A family label such as 9.x does not establish that a direct jump is supported or nondisruptive.
3. Check applicable TruFOS/license/certificate requirements, interoperability, feature constraints and free-space prerequisites for the exact target. Download the approved package from the authorized source and verify its integrity.
4. For directors, confirm the required CP state and recovery access. For a fixed switch, use its own HA/traffic assumptions. BIOS, hardware-specific or disruptive branches may require different treatment.
5. Confirm usable alternate host/storage paths and application timeout behavior. Schedule Fabric A first and keep Fabric B healthy.

09Run prechecks, export evidence and validate space

1. Compare all expected ports, fabric members, endpoint logins and effective zones with the accepted healthy baseline. Investigate unresolved hardware, segmentation or congestion conditions.
2. For dual-CP platforms include hashow and the exact release’s HA prerequisites. Retain the supported configuration/VF backups and authorized support evidence.
3. Use the documented firmwaredownload -v space check where supported. It does not replace the compatibility/path/feature checks from the release notes.
4. Verify the staging server is reachable using the supported secure transfer method and the correct package path. Preserve console and recovery access.

firmwareshow
version
switchshow
fabricshow
nsshow
nsallshow
license --show
sensorshow
mapsdb --show
cfgactvshow
porterrshow
firmwaredownload -v

10Start the approved interactive firmware download

1. Review every prompt and the intended target before starting. Do not choose single-CP or force/disruptive options merely to bypass an unexplained condition.
2. Monitor firmwaredownloadstatus, control-plane/CP status where applicable and actual client service. Preserve failure phase/messages if it stops.
3. Wait for the full required download/activation/commit sequence to complete. Do not start another upgrade, reboot a CP or maintain the other fabric during an unresolved operation.
4. If status reports a failure, follow that release’s recovery procedure with support as needed. A guessed firmwarerestore or repeated reboot is not a universal repair.

firmwaredownload
firmwaredownloadstatus

11Verify running firmware and restored fabric service

1. Confirm the approved running release and the expected partition/CP state after all required commit stages. Merely seeing a downloaded package is insufficient.
2. Compare every intended port, ISL/trunk member, logical fabric and endpoint login with the baseline. Investigate missing members even if some application traffic still works.
3. Verify host persistent LUN identity, expected usable paths and an application-native transaction. Check endpoint logs for I/O errors during and after the window.
4. Observe comparable traffic and relevant backup/busy periods for new link errors or congestion. Export an accepted post-change backup and retain actual results.

firmwaredownloadstatus
firmwareshow
version
switchshow
fabricshow
nsshow
nsallshow
cfgactvshow
islshow
trunkshow
sensorshow
mapsdb --show
porterrshow
errdump

12Hold the next switch or fabric until resilience is restored

Complete and accept one switch’s operation before the next supported step. Across independent physical fabrics, restore A and verify clients before proceeding with B. Keep a record of release, target, timestamps, before/after counts, application owner acceptance and any approved exception. A supported nondisruptive switch method still relies on a compatible and resilient end-to-end service design.