• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3080
  • Last Modified:

iSCSI traffic on it's own vlan vs. the production vlan

I was trying to find information on why it is best practices to migrate your iSCSI traffic to a sperate VLAN from your production VLAN?  It seems redundant since you have to add the routes to allow for traffic to flow between both VLANs.  Why not keep them on the same VLAN?
2 Solutions
If not on a seperate, dedicated switch, it is generally best practice to put the iSCSI traffic on its own VLAN to isolate it from the other network traffic, and reduce the ability of packet sniffing and other types of data breaches. If on a seperate switch you could also gain performance benefits if your regular network is under heavy load (I believe the same is true on a VLAN, but not to the same scale as on seperate switch hardware).

You shouldn't need to route data in or out of the iSCSI VLAN; it should be contained within it self, with one or more NIC's on the servers dedicated to iSCSI, and one or more seperate NIC's attached to the rest of the network. Your regular network should not be able to talk to any of the iSCSI ports/NIC's, nor vice versa.
Think of the iSCSI VLAN as if it were a special kind of I/O controller bus rather than a network.  This VLAN should be, internal to itself, very flat (no subnets or gateways).  It is holding the place that a SAS or SATA controller's cable would hold in direct attached storage.

If the server is connected to the LAN, for example, and you access it through an address on that LAN, your iSCSI VLAN might be  Only the servers using the iSCSI targets and the iSCSI host itself need be on the iSCSI VLAN and there is never a need to route traffic from over to  Each server sees both networks since each server has an address on each network (either two different NICs or one NIC with two IP addresses.  Two different NICs is preferable).  In this way, you can monkey with the properties of the iSCSI LAN to tune it for I/O (jumbo frames, larger windows, etc..) without affecting the communication LAN and all the clients on that LAN.  Also, since iSCSI will often put a lot of data on a network, your regular communications are not squeezed out in favor of iSCSI traffic.
It depends on what you plan to build.  If you intend to build a real enterprise solution you should get separate switches and they should be good quality - like cisco 3750.  Iscsi traffic can easily overwhelm your switch if not configured properly.  The port settings for iscsi are particular and not to be overlooked vs a servers port settings which are pretty much the default.  Flow contol config is essential, jumo frames and others to be considered.  I will try to find a great doc and post it when I am not on my blackberry.

Become an IT Security Management Expert

In today’s fast-paced, digitally transformed world of business, the need to protect network data and ensure cloud privacy has never been greater. With a B.S. in Network Operations and Security, you can get the credentials it takes to become an IT security management expert.

Re-reading your question (when not on my BB) I see you are more focused on VLANs as opposed to separate switches and I agree with the other two posts that answer this question though I would add that the separation is all about performance and less about data breaches.  However to follow up on my post, the specific port configuration is listed in this document and you should review it if you are building an iSCSI SAN even if you are not buying the Equallogic product.  Also keep in mind that the backend iSCSI switch design often times employs stacked switches with EtherChannels spanning both switches for redundancy and dual controllers on the arrays;  all in the name of uptime.

I dont know what you're trying to do, but I can convey some experiences I've had lately that may help...

I recently created an iSCSI host at home to experiment with ESX, and get familiar with the vMotion and other options that become available after moving to a SAN storage environment...

My first shot was simply to put the iSCSI server on the same subnet as my regular machines, buy a small 5 port gig switch to put my 2 ESX hosts, one iSCSI host, and an uplink to my other 10/100 switch for management and communication..  I had ONE network card on the ESX machines.

Everything worked great for a while as I set all this stuff up.  I was pleased with new machines I installed on the iSCSI host, although they were a little slow, they worked...  Until I started MOVING existing virtual machines over to the SAN.  When throughput became an issue, I would lose management control of the servers because I was communicating over the same connection as the iSCSI, and the ESX machines would crash...

What I ended up doing was to add another NIC to each of the ESX and to the iSCSI hosts, and created a different subnet address (went to 172.16.3.x instead of my normal 172.16.2.x) for the iSCSI.

I DO NOT have any way to route between 172.16.2 and 172.16.3 addresses, so you DEFINITELY dont have to do that..

Now, I have one NIC dedicated GIG for iSCSI, and another NIC, plugged into 10/100 which is used by the management, as well as the network traffic to/from the virtuals...

The moral of the story, I believe is that the iSCSI, being on the same network, will probably degrade performance of the data network enough that you'll want to be separate, either by physical switch, or by VLAN...

The other reason to do it is that iSCSI can take advantage of large packets, but the packet size has to be the same on all devices on the collision domain, so by putting it on it's own switch, you dont have to change the packet size on all your other workstations and servers...


Your iSCSI should be on a separate network
BTW..   My iSCSI host is "OpenFiler" which is a linux based free appliance..  Works great... was a little tough to figure out how to configure it!!


Featured Post

Identify and Prevent Potential Cyber-threats

Become the white hat who helps safeguard our interconnected world. Transform your career future by earning your MS in Cybersecurity. WGU’s MSCSIA degree program was designed in collaboration with national intelligence organizations and IT industry leaders.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now