LEARN. PRACTICE. GROW.Concept and mechanism
In iSCSI, finding a target during discovery does not prove a functioning login session exists. Even with a session, authorization and presentation of the expected LUN need validation. Observation should distinguish network, portal, target name, effective initiator identity, and mapping. On a reinstalled host, the IQN may differ from the one retained in the igroup or ACL. A successful ping does not eliminate that problem. RHEL documentation shows session inspection with iscsiadm, including associated device state. Use evidence from the failed stage to guide the next step without formatting disks to try to correct remote access.
Guided application
CHAP authenticates and does not itself establish payload encryption. Array protection at rest also does not prove confidentiality along the network path. The RFC reference distinguishes roles without recommending historical algorithms. If jumbo frames are used, validate MTU compatibility across the full path; small pings do not cover intended sizes. At boot, an iSCSI filesystem depends on networking and sessions. The _netdev option participates in marking that dependency but does not itself create an authorized session. In a fictional example, manual mounting works after login while boot fails; review startup preparation and ordering as well as persistent device identity.
Discovery shows a target; the session and LUN access still need evidence.
Common pitfalls
Ping as authorization; discovery as login; CHAP as encryption; _netdev as complete configuration.
Related topics: Topology and identity · Fibre Channel and LUN access · Multipathing and path states
Separate each stage and correct the dependency demonstrated by evidence.
Reference: RHEL 9 iSCSI discovery, login, boot and session inspection · DR SAN 2026-09; selected RHEL 9, ONTAP 9 and iSCSI behavior