Cisco MDS advanced: ISLs, FC port channels, NPV and NX-OS upgrades

01Review the entire merge before enabling an ISL

1. Verify software and hardware interoperability, unique domain IDs in the intended fabric and compatible security/fabric settings. Do not cable Fabric A to Fabric B.
2. Compare active and full zoning, default-zone policy, device aliases and transaction state. Resolve conflicting same-name objects or stale source databases before merge.
3. List VSANs that should traverse the link and check that each exists and is active on both sides. Confirm bandwidth and failure-state capacity.
4. Back up both switches and establish an approved isolation/recovery decision. Connecting an unmanaged spare switch can import an unexpected control-plane state.

show version
show inventory
show vsan
show fcdomain domain-list vsan 10
show topology vsan 10
show zoneset active vsan 10
show zoneset vsan 10
show zone status vsan 10
show device-alias status

02Configure a designated standalone trunking E port

An E port links FC switches; a trunking E port carries supported VSAN contexts and is commonly shown as TE. An allowed VSAN list alone does not prove operational carriage. Check the allowed/active, up and isolated states on both ends. The shown allowed-list command replaces that interface’s list; on an existing trunk, a reviewed switchport trunk allowed vsan add 20 extends rather than silently removes existing membership.

configure terminal
interface fc1/47
  switchport mode E
  switchport trunk mode on
  switchport trunk allowed vsan 10,20
  no shutdown
end
show interface fc1/47
show interface trunk vsan 10
show trunk protocol

03Build an FC port channel on two unused links

MDS FC port channels use FC channel behavior. Do not paste Ethernet LACP syntax such as channel-group 10 mode active; channel mode active belongs to the logical port-channel configuration in this example. Adding a live member or changing channel mode can flap a link and needs its own impact review.

1. Match supported speed/capabilities, rate mode where relevant, port VSAN, trunk mode and allowed VSAN settings. Confirm that every member reaches the same peer switch.
2. Apply the intended channel configuration on both ends and add only the designated new members. Avoid force options that can overwrite member settings.
3. Inspect member state and the logical channel. Confirm remote target discovery and traffic, then test approved member-loss behavior in the lab with host service monitoring.

configure terminal
interface port-channel 10
  switchport mode E
  channel mode active
  switchport trunk mode on
  switchport trunk allowed vsan 10,20
exit
interface fc1/47 - 48
  switchport mode E
  switchport trunk mode on
  switchport trunk allowed vsan 10,20
  channel-group 10
  no shutdown
end
show port-channel summary
show port-channel database
show interface port-channel 10

04Distinguish NPIV from an NPV edge

Inspect actual NPIV state rather than assuming a new-release default survived an upgrade. If an approved core change needs it, feature npiv is the configuration command; verify the intended platform and current state first. NPV conversion is much broader: enabling feature npv erases the existing configuration and reboots supported devices. Disabling the mode also involves reload behavior. That conversion does not belong in a beginner setup clipboard.

1. For an NPV design, document core NPIV support, VSAN mapping, NP uplink placement, host traffic mappings and failure distribution.
2. For any mode conversion, preserve backups and console recovery, drain affected service, and follow the model-specific rebuild/migration procedure.
3. After commissioning, validate every host’s login through the intended uplink and test the supported failure behavior.

show feature
show npv status
show npv flogi-table
show npv traffic-map

05Treat IVR and FCIP as separate architecture exercises

Ordinary zoning within a VSAN does not route between VSANs. Inter-VSAN Routing provides a controlled supported design for selected inter-VSAN communication, with its own topology, licensing, zones and failure analysis. FCIP extends FC connectivity over IP through supported extension interfaces and requires explicit IP transport, latency, MTU, security and resiliency planning. Neither is an automatic repair for a wrong VSAN assignment.

1. State the business requirement: shared target access across logical fabrics, or extension between sites. Confirm that preserving isolation is part of the design.
2. Check exact platform/module/release and entitlement support. Create an approved topology and restricted access policy using the matching Cisco guide.
3. Rehearse link, core and site failures with real host/application recovery objectives. Keep this work separate from a local host-zone addition.

06Establish a recoverable maintenance baseline

1. Retain active/full zoning, device aliases, VSAN/port membership and expected host devices/paths. Confirm that the backup file arrived on the authorized receiver.
2. Check usable alternate paths from each affected host/application before maintaining Fabric A. A second switch in the diagram is insufficient evidence.
3. For a director inspect supervisor state with show system redundancy status, confirm HA standby and access to the necessary consoles. A fixed switch has different redundancy assumptions.
4. Coordinate monitoring, backup and application windows. Fix active hardware/ISL/congestion faults before adding upgrade risk.

show version
show module
show environment
show interface brief
show zone status vsan 10
show zoneset active vsan 10
show flogi database
show fcns database vsan 10
show port-channel summary
copy running-config startup-config
copy running-config scp://backupuser@192.0.2.80/backups/mds-a-pre-upgrade.cfg

07Select images through the actual supported upgrade path

1. Record exact current version, model, supervisors, line cards and enabled features. Read the target release notes, compatibility matrix, supported nondisruptive path table and feature-specific upgrade restrictions.
2. Choose the supported target and every required intermediate step. A higher version number does not establish a direct supported path. Complete acceptance at each required stage.
3. Download the platform-correct images from Cisco and verify their supplied integrity information. Where the selected release uses paired kickstart/system files, both must be the correct matching release and platform.
4. Check bootflash capacity, transfer the approved images over the authorized management path and verify the actual copied files. Review whether separate BIOS, EPLD, transceiver, SAN Analytics/FPM or other component work is needed.

dir bootflash:
# Example transfer form; replace both approved filenames and endpoint:
copy scp://imageuser@192.0.2.80/images/SYSTEM_IMAGE.bin bootflash:SYSTEM_IMAGE.bin
copy scp://imageuser@192.0.2.80/images/KICKSTART_IMAGE.bin bootflash:KICKSTART_IMAGE.bin
dir bootflash:

08Assess installation impact before accepting the change

1. Read compatibility failures, module actions and disruptive/nondisruptive classification. Resolve blockers instead of bypassing checks.
2. Compare the impact with the maintenance plan, host path resilience and application timeout behavior. An impact command does not validate host multipathing.
3. Review component-specific activation caveats even when the base software step qualifies for ISSU. The 9.x guide includes platform/release-specific disruptive BIOS and EPLD cases; a universal zero-downtime promise would be incorrect.
4. Reassess the decision if the real impact differs from the approved plan. Preserve the output and consult the release-specific recovery/escalation process.

show install all impact system bootflash:SYSTEM_IMAGE.bin kickstart bootflash:KICKSTART_IMAGE.bin

09Install through the supported upgrade workflow

Use the install all workflow and prompts specified for the selected MDS release. Do not substitute a Nexus Ethernet install syntax or merely edit boot variables and reload as a generic upgrade method. Keep console/recovery access and application monitoring available. Do not start a second install, reboot a peer supervisor or maintain the other fabric while the operation owns the transition.

1. Review the final prompts and start once after the gates pass. Timestamp the operation and retain status output.
2. Observe module/supervisor progress and real client service. Handle a reported failure through its exact phase and documented action; repeated restarts are not a diagnosis.
3. Wait for completion before initiating another switch change. A reconnected SSH session alone is not upgrade acceptance.

install all kickstart bootflash:KICKSTART_IMAGE.bin system bootflash:SYSTEM_IMAGE.bin
show install all status

10Verify software, hardware and complete fabric service

1. Verify running versions and expected modules. For directors recheck HA standby; check separately required BIOS/EPLD/component activation evidence.
2. Compare expected endpoint logins, operational VSANs, channel members and effective zones with the pre-upgrade inventory. Resolve a missing object even if other workloads still run.
3. Confirm correct LUN identity, expected usable path count and supported multipath states from each representative host. Run the application-native transaction and check host logs for I/O timeouts.
4. Observe counters and relevant busy/backup periods. Save/export the accepted post-change configuration and record exceptions with owner and due date.

show install all status
show version
show module
show environment
show interface brief
show port-channel summary
show interface trunk vsan 10
show zoneset active vsan 10
show flogi database
show fcns database vsan 10
show logging logfile

11Restore Fabric A before proceeding with Fabric B

An operational change across two physical fabrics is sequential. Accept the changed A fabric and its restored client paths before scheduling B. If A is still degraded, progressing to B removes the intended safety margin. Within a larger fabric, also observe the release-qualified sequence and failure capacity of individual switches, channels and redundant supervisors.