In my last post about SSD storage, I introduced you to my friend Dave. Dave is getting into data hoarding with aggression and he keeps asking me questions about storage. He called me last week and asked “what layer is iSCSI?“. I was a little thrown at first but after some probing, I was able to deduce Dave’s real question. He’s been reading about SAN, NAS, DAS, etc and this had led him to iSCSI. Dave wanted to know which OSI later iSCSI sat at. I had to sit down and think about it for a minute because it’s not something we typically need to worry about every day. After some head-scratching and a quick confirmation from Wikipedia, I was able to confidently assure him that iSCSI uses layer 5 within the OSI model.
Are you sure iSCSI uses OSI layer 5?
Yes, I am now, after doing a little reading. The reason I’m sure is that iSCSI relies on TCP (Transmission Control Protocol), usually using ports 860 and 3260. It’s widely accepted that TCP falls firmly into layer 4 of the OSI model (layer 4 is the Transport layer after all). As iSCSI sits on top of TCP it’s only fair to conclude that it operates at layer 5, the session layer. At this point I feel a simple diagram might come in handy:
As you’ll be able to see from this diagram, the iSCSI “packets” are assembled in the Session layer, transmitted using the TCP protocol that exists at the Transport layer. Once received these packets will traverse upwards, finally making their way through the Presentation layer to the Application layer.
Can I pass iSCSI through a network switch?
Since we now know that iSCSI operates at OSI layer 5, some may be wondering whether the traffic can be switched. It would seem logical, as the traditional Ethernet switch operates at OSI layer 2. These “layer 2 switches” maintain a table of which devices are connected to which ports and pass on the data as necessary. Being layer 2, this is done at the Data Link layer, by inspecting the destination MAC address and finding the port that corresponds to this address using the aforementioned table. These switches introduce a negligible delay so ordinarily shouldn’t negatively affect iSCSI traffic. That being said, in an enterprise environment, you’ll want to invest in enterprise-grade, more expensive switches. Don’t risk sending any traffic, let alone iSCSI traffic over switches designed for home use (I’m looking at you TP-LINK!).
Can I send iSCSI traffic through a layer 3 switch?
In short, yes, iSCSI traffic can pass through a layer 3 switch without impact. Again, just be sure the switch is decent quality and manufactured by a big name. If you’re just setting up a home-lab or doing a quick test you can ignore this advice. If you’re setting up an enterprise environment, don’t risk using cheap layer 3 switches. Always stick to a known, reliable brand. My current switch brand of choice is HP Aruba.
Is it OK to route iSCSI?
It depends on what you mean by “OK”. It’s certainly possible as we’ve already established that iSCSI operates at layer 5, over TCP at layer 4. This means the iSCSI packets have an IP header, making them possible to route. Remember, that layer 3 switching is synonymous with routing in the majority of use cases.
This doesn’t mean that you should though. iSCSI accesses stored data at the block level and this makes it sensitive to latency. If you’re routing between two networks, within you’re own building, using a hardware router, you’re likely going to be fine. If you’re not routing any other traffic over this infrastructure then you’ll almost definitely be fine. The problems arise when you’re either routing traffic so it can then travel a long distance over a different network (e.g. passing your iSCSI traffic through a router so it can travel across the Internet), or you’re routing is inefficient. An example of inefficient routing would be using a cheap software-router or standard, low-end PC. If you’re going to route iSCSI traffic, you really want to be using a decent hardware router to minimize latency.
Is iSCSI traffic encrypted?
No, iSCSI traffic isn’t encrypted. We’ve established that iSCSI packets are crafted at OSI layer 5, the presentation layer. No encryption is performed at this point so it’s trivial for snooped packets to be re-constructed to reveal valuable data. In the vast majority of cases, iSCSI traffic remains local, between a local server and a SAN, for example. This means the risk of someone snooping the traffic is much lower than with traffic carried over the Internet, but in an enterprise environment, it’s still possible. Even in a home environment without other risky “users”, it’s still possible that a device can be hacked and used to intercept iSCSI storage traffic. If you decide to carry iSCSI traffic over the Internet, a WAN, or in another scenario in which it could be snooped, you’ll need to find a way to encrypt it. The easiest way to encrypt iSCSI traffic is by carrying it over a VPN or IPSEC tunnel. On a LAN you’ll likely choose not to encrypt iSCSI traffic for performance reasons. You should look at giving it a dedicated VLAN though.
Does iSCSI need to be on a VLAN?
If you’re using iSCSI in your home or small lab, then no. iSCSI can operate fine without being on a separate VLAN to other traffic, providing bandwidth is sufficient. You may choose to not separate iSCSI in this case if, for example, you’re on a budget and can’t afford managed switches. The story is different in an enterprise environment, however. It’s extremely rare to find any large business that doesn’t have the network infrastructure to support VLANs. There are no real downsides to carrying iSCSI on a separate VLAN to your other traffic, only benefits. The benefits of using a VLAN include security and performance. The subject is too deep to explore here but if you’re not familiar with VLANs and are about to deploy iSCSI, the topic is well worth reading about.
What’s an iSCSI LUN?
An iSCSI LUN is a logical unit of storage. Some people ask which OSI layer iSCSI LUNs operate at but this often indicates they don’t understand what a LUN is. A LUN can be thought of as a virtual or logical block device, like a hard drive. You create an iSCSI LUN, connect to it from your operating system, and your OS will see it the same as it sees a hard drive. In other words, your system will see the LUN in the same was as it would see a physical, directly attached SCSI device. For completeness, LUNs are of course accessed at OSI layer 5, as they’re just one aspect of the iSCSI protocol which we’ve already established operates at layer 5 of the OSI model.
What filesystems does an iSCSI LUN use?
As I’ve already explained, a LUN is seen by your operating system (e.g. Windows, Linux, etc) as a physical disk. This means you can format or mount an iSCSI LUN using whichever filesystem your OS supports. For example, in Windows, you may format your LUN as NTFS or ReFS. If you’re running Linux you may decide that EXT4, BTRFS or ZFS are better choices for your iSCSI LUN. This will of course depend on your workload, as different filesystems provide different benefits.
What’s an iSCSI target?
Conceptually, an iSCSI target is simply the iSCSI storage system itself. This is the device into which you would install the physical hard disk drives that you intend to later access using the iSCSI protocol (at OSI layer 5!). If you have a Qnap for example, you may refer to this as the iSCSI target. If you’re accessing the Qnap from a virtual machine running Windows Server 2019, you’ll likely refer to this client VM as the initiator. It’s a little more complicated than this, you could, for example, have multiple targets hosted from a single device, such as your Qnap. For the purposes of this article, however, this high-level overview is sufficient, in my opinion. If you’d like a deeper explanation then leave a comment and I’ll write a separate piece.
What’s an iSCSI initiator?
The iSCSI initiator is the part of the iSCSI system that allows you to interact with your iSCSI device. Typically nowadays you find that initiators are software-based rather than physical hardware devices. You’ll also likely discover that your operating system already includes an iSCSI initiator. Microsoft Windows for example has natively been able to operate as an iSCSI initiator since 2003. Third-party drivers to allow even Windows 2000 to operate as an initiator have been available since 2000.
Very occasionally you’ll find larger enterprises using hardware-based iSCSI initiators. These improve performance to some extent as they free the task of dealing with iSCSI from the client’s CPU. There are often referred to as iSCSI HBAs or iSCSI offload devices.
Summary
We’ve opened with the question that many people ask when it comes to iSCSI and the OSI model. We then established (hopefully I’ve convinced you!) that iSCSI operates at layer 5 of the OSI model. We’ve then touched upon the switching and routing of iSCSI traffic and discussed the OSI layers that these events operate at. For completeness, we then looked at a handful of iSCSI terms that new data hoarders are often not familiar with.