Cisco MDS basics: installation, initial setup, VSANs and FC host ports

01Identify the exact MDS platform and release

1. Record the switch model, serial, running NX-OS version and installed modules. Confirm that the command context is an MDS FC switch rather than an Ethernet Nexus example found online.
2. Check module state, fans, power and environmental conditions. For a director, include supervisor redundancy and every relevant fabric/line-card module.
3. Verify port licensing/entitlements and supported optics for the actual model. A port that is not licensed or supported cannot be fixed by adding a zone. Retain a timestamped baseline before connecting workloads.

show version
show inventory
show module
show environment
show interface brief

02Rack, power and cable the new switch

Use the hardware guide for your exact chassis and rack kit. The linked 9148T guide is an example, not a universal lifting, torque, airflow or power procedure. Separate power feeds only provide the intended resilience if their upstream dependencies are also understood.

1. Confirm rack support, depth, clearances and the cold/hot aisle direction. Verify all fitted airflow components match the selected airflow design.
2. Install the rails, chassis and protective grounding according to the model guide, then connect approved power and console/management access. Inspect boot messages and component status.
3. Label host, target and planned ISL ports by physical fabric. Confirm SFP compatibility, fiber type/reach, connector condition and routing.
4. Connect only the approved host/target links. Do not connect a new switch into an existing fabric until domain, zoning, software and merge prerequisites are reviewed in the advanced guide.

03Complete management bootstrap through the console

For a new isolated switch, follow the documented NX-OS setup utility. Maintain console access while setting management addressing and credentials. The utility can also ask about fabric and zoning defaults: review each choice rather than accepting an unintended default-zone access policy. Do not rerun initial setup against a live switch as a troubleshooting shortcut.

1. Complete the initial console prompts and record the resulting configuration securely. Use the correct management routing/context for the platform.
2. Open a second authorized SSH session and confirm identity and reachability before releasing the console session.
3. Apply the site’s AAA/RBAC and secure monitoring design, preserving a tested management recovery route. Test permitted and denied access from the intended management sources.

04Inspect VSAN and zoning state before allocating ports

A VSAN provides a logical fabric context. Its number and name do not create a separate power supply, chassis or host adapter. Each VSAN has its own zoning database. On independently managed A and B physical fabrics, the same numerical VSAN ID can be reused, but the worksheet must still distinguish the physical fabric and active zone-set name.

1. Confirm that VSAN 10 is free or already belongs to this intended lab. Check the existing membership of fc1/1, fc1/5 and fc1/6.
2. Inspect each selected port’s connected identity and running configuration. Stop if an apparently spare port carries an application, an ISL, an NPV uplink or a port-channel member.
3. Record actual zoning mode. Basic and enhanced zoning use different activation/commit behavior; the zoning guide branches explicitly.

show vsan
show vsan membership
show zone status vsan 10
show zoneset active vsan 10
show running-config

05Create the example VSAN and assign unused host/target ports

1. Create the approved VSAN name/number under vsan database. Place the designated host and target ports in that same intended context.
2. Inspect membership after leaving configuration mode. Match every interface to the cabling worksheet.
3. If a target was assigned to a different VSAN by mistake, correct only the reviewed port assignment. Broadly moving all storage ports would affect unrelated consumers.

configure terminal
vsan database
  vsan 10 name PROD_A
  vsan 10 interface fc1/1
  vsan 10 interface fc1/5
  vsan 10 interface fc1/6
exit
end
show vsan 10
show vsan 10 membership

06Configure endpoint links as F ports

An HBA or ordinary storage target connects to an F port in this lab. An ISL between switches uses E/TE behavior, while NPV uplinks have their own role. Set supported speed and other hardware-dependent parameters only when the design requires them; a copied forced-speed value can prevent a perfectly valid link from training.

1. Inspect administrative and operational state, negotiated speed and the reason for any down state.
2. If the link remains down, verify peer power/HBA state, correct fiber, SFP support and port entitlement before proceeding to zoning.
3. Preserve intentionally shut or reserved interfaces. A blanket no shutdown across a switch is not part of host commissioning.

configure terminal
interface fc1/1
  description app01_HBA_A
  switchport mode F
  no shutdown
exit
interface fc1/5
  description ontap_node1_FC_A
  switchport mode F
  no shutdown
exit
interface fc1/6
  description ontap_node2_FC_A
  switchport mode F
  no shutdown
end
show interface fc1/1
show interface fc1/5
show interface fc1/6

07Verify FLOGI and the fabric name server

1. Confirm the local HBA login maps fc1/1 to the expected port WWN, VSAN and FCID. Compare it with the host adapter inventory.
2. Find the ONTAP target LIF WWPNs in the appropriate fabric directory and correlate them with the intended physical uplinks. More than one logged-in identity on an uplink can be valid NPIV behavior.
3. Distinguish a local FLOGI from a remote FCNS registration. In a multi-switch fabric, a target can be known through an ISL without being locally attached to this switch.

show flogi database interface fc1/1
show flogi database vsan 10
show fcns database vsan 10
show fcns database detail

08Check optics and errors without erasing the baseline

1. Record counters and time, then collect again during a representative interval. Old lifetime counts alone cannot show that a fault is still active.
2. Compare transceiver readings with that optic’s diagnostic thresholds and supported reach. Investigate a rising CRC/invalid-word or signal-loss condition with the cable, peer and both transceivers.
3. Keep evidence before any counter reset or component replacement. Confirm scope and alternate path health before an approved cable/SFP change.

show interface fc1/1 counters detailed
show interface fc1/1 transceiver details
show logging logfile

09Save and export configuration with operational context

Use unique per-switch filenames and an approved reachable receiver. Authenticate through the interactive prompt; credentials do not belong in copied commands. Confirm that the remote files actually exist and are protected. Retain active/full zoning, aliases, port membership and login evidence with the configuration. A support bundle and a restorable configuration serve different purposes.

copy running-config startup-config
copy running-config scp://backupuser@192.0.2.80/backups/mds-a-running.cfg
copy startup-config scp://backupuser@192.0.2.80/backups/mds-a-startup.cfg
show zoneset active vsan 10
show zoneset vsan 10
show device-alias database

10Finish commissioning with explicit postchecks

This page ends at a correctly installed and identified switch with logged-in endpoints. Do not declare a mapped application healthy from a FLOGI listing. The zoning procedure adds connectivity permission; host and target checks then establish the intended LUN and service.