iSCSI SAN Setup: Targets, Initiators, Multipath

An iSCSI SAN can be brought up in about twenty minutes and then spend three years being subtly wrong. The commands are the easy part. The order of operations is what decides whether the result survives a switch reboot.

This is a build order rather than a command dump: network first, naming second, access control third, multipath fourth, and nothing goes into production until the failover test has actually been run. It assumes the vocabulary in SAN fundamentals: fabrics, zoning, LUN masking and multipathing, and that iSCSI is already the chosen transport; if that is still open, see Fibre Channel vs iSCSI vs NVMe-oF.

Step 1: design the network before touching the array

iSCSI is SCSI over TCP, standardised in RFC 7143, listening on TCP port 3260. Everything that is true of a TCP network is now true of the storage path, which is why the network design is the first step rather than an afterthought.

Isolate the traffic. Storage gets its own VLANs, and where the budget allows, its own switches. Sharing a general-purpose VLAN with server traffic is the most common root cause of latency complaints that get blamed on the array.

Use two subnets, not one. A frequent mistake is putting both host storage NICs and both array ports on a single subnet. It works, and it produces paths that are not independent: the host’s routing table can send both sessions out of one interface, and a single switch failure takes everything down. Give path A its own subnet and switch, path B its own subnet and switch, and never route between them. The storage VLANs should have no gateway at all.

Decide on MTU once. Jumbo frames are optional. Consistency is not. Every hop between initiator and target — host NIC, both switches, array port — must agree on the MTU, because a mismatch does not fail cleanly; it degrades on large transfers while ping still works. If any device in the path cannot be changed, stay at 1500 everywhere and stop thinking about it.

Do not route storage traffic. No gateway, no inter-VLAN routing, no firewall in the data path. If the target is reachable only through a router, the design is wrong before any configuration begins.

Step 2: pick a naming scheme and write it down

iSCSI nodes identify themselves with IQNs, formatted as iqn.YYYY-MM.<reversed-domain>:<unique-string> where the date is a month in which the naming authority owned the domain. The format is arbitrary as far as the protocol is concerned and load-bearing as far as operations are concerned.

Make the unique string say what the node is, not what host it happened to be installed on first. iqn.2026-08.com.example.dc1:esx-cluster-a-node-03 survives a rename; iqn.2026-08.com.example:host7 does not survive anything. On Linux the initiator name lives in /etc/iscsi/initiatorname.iscsi and must be unique per host. Cloned virtual machines that keep their template’s IQN will collide in ways that look like array faults.

Step 3: configure the target

On a commercial array the target side is a portal, a set of target ports, and a volume mapped to a host or host group. On Linux, LIO with targetcli provides the same primitives. Windows Server provides the iSCSI Target Server role, which is well suited to a lab or a small deployment and documented by Microsoft.

Three things matter regardless of platform:

1. Bind the target to the storage interfaces only. A target listening on the management interface is reachable from everywhere on the management network, which defeats the isolation from step 1.
2. Create the host object before the volume mapping. Map volumes to a named host or host group whose member IQNs are explicit. Mapping to “all initiators” is how a volume already owned by another server gets presented to a new one, and the new administrator formats it.
3. Record which volume belongs to which host outside the array. The array knows the mapping. The change ticket six months from now will not.

Step 4: authenticate, because the network will not do it for you

A Fibre Channel initiator cannot see a target it has not been zoned to. An iSCSI initiator can see any target it has IP connectivity to. That gap is closed by configuration or it is not closed.

Enable CHAP on the target and set a per-host secret. Use mutual CHAP where the platform supports it, so the initiator also verifies the target and a rogue portal cannot answer discovery. Combine that with an explicit initiator allow-list on the target rather than relying on CHAP alone. For deployments where the traffic itself needs protection rather than just the session, RFC 3723 defines how IPsec applies to block storage protocols over IP.

CHAP secrets are credentials. They belong in the same store as every other credential, not in the runbook.

Step 5: connect the initiator

On Linux with open-iscsi, discovery and login are two separate operations, and the distinction matters because discovery against the wrong portal address is a common cause of paths that never appear.

Run discovery against each portal address separately — one per storage subnet — so that both paths are learned. Then log in to the target on each portal. Set node.startup to automatic so sessions are re-established after a reboot; a SAN that requires a manual login after every reboot will eventually be rebooted by someone who does not know that.

One setting deserves deliberate attention: node.session.timeo.replacement_timeout. Its default is generous, on the order of two minutes, which is correct for a single-path host that would rather wait than fail. When device-mapper-multipath is present it is the wrong default, because multipath is capable of failing over in seconds and is being held back by the initiator. Deployments running multipath commonly reduce it to a few seconds so that path loss is handled by the multipath layer rather than absorbed as application stall. Check the array vendor’s documented value before choosing one.

On Windows, install the MPIO feature and enable multipath support for iSCSI devices before creating any sessions. Then create one session per path with multi-path enabled on each. Sessions created before MPIO is enabled do not retroactively join a multipath set, and the resulting duplicate disks are a well-known and entirely avoidable mess.

Step 6: multipath, then prove it

Multipathing is what makes a single cable, optic, switch reboot or controller failover survivable, and it is the step most often declared complete without evidence.

On Linux, multipath -ll should show one multipath device per volume with the expected number of paths in the expected number of path groups. Several details are worth setting explicitly rather than inheriting:

• Path grouping should match how the array presents the volume. An active/active array wants all paths in one group; an ALUA array wants the optimised paths preferred and the non-optimised paths in a standby group. Getting this backwards sends every I/O down the slow route while every status display reports healthy.
• Path selector decides which path each I/O takes. The kernel documentation covers the available selectors, including service-time, which weights by recent throughput rather than round-robining blindly.
• no_path_retry decides what happens when the last path dies: queue indefinitely, or fail I/O up to the filesystem. Both are defensible and the choice must be conscious. Queueing hides an outage from the application until memory pressure ends the argument; failing surfaces it immediately as I/O errors.

The verification step is not multipath -ll. It is pulling one cable, watching the path count drop, confirming the workload continues, and putting it back. Do this on the storage side and the host side, and do it before the volume carries anything anyone cares about. Where the topology or the port count is still being sized, the SAN LUN and NVMe-oF sizer will convert raw capacity, RAID level, port speed and initiator count into usable capacity and aggregate throughput.

Pre-production checklist

• Storage VLANs isolated, no gateway, no routing between path A and path B.
• MTU identical on host NIC, both switches and array ports.
• Every host IQN unique and descriptive; no cloned initiator names.
• Volume mapped to a named host object, not to all initiators.
• Ownership of every volume recorded outside the array.
• CHAP enabled with per-host secrets, stored as credentials.
• Sessions set to reconnect automatically at boot.
• Multipath shows the expected path count and path grouping.
• Initiator timeout aligned with multipath rather than fighting it.
• A cable has been pulled from each side and the workload survived.
• Array capacity monitored on pool consumption, not allocation.

What goes wrong afterwards

Two patterns account for most post-deployment incidents. The first is drift: a switch is replaced and the MTU is not carried over, or a new host is built from a template that reuses an IQN. The second is a workload change that pushes the fabric past a threshold nobody was watching, which surfaces as latency rather than as an error and is diagnosed in SAN latency troubleshooting.

Neither is exotic. Both are cheaper to find in a checklist than in an incident.