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?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MSSPs - Are you paying too much?

WEBINAR: Managed security service providers often deploy & manage products from a variety of solution vendors. But is this really the best approach when it comes to saving time AND money? Join us on Aug. 15th to learn how you can improve your total cost of ownership today!

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!!

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.