Why should iscsi SAN traffic be isolated? I'm trying to explain to my network guy why we should isolate the traffic.

  • Please read techrepublic.com/blog/data-center/…
    – Andy
    Sep 23, 2014 at 14:34
  • 11
    How could you be explaining it to him if you don't know? You're advocating for a particular architectural design and implementation without yourself knowing why that particular architectural design and implementation is important.
    – joeqwerty
    Sep 23, 2014 at 14:40
  • 1
    No I do know but these are old school network guys that just want to throw mor bandwidth at the issue. I was just hoping to get more info on what I could tell them on why and what can happen if its not isolated. Sep 24, 2014 at 17:59

3 Answers 3



  • Very, very bad things will happen if someone gains unauthorized access to your storage network
  • Very, very bad things will happen if you have your iSCSI traffic not separated, and someone finds it a great idea to muck around with the STP topology at an edge switch, with the result of your entire network AND your storage subsystem going down at once
  • Very, very bad things will happen if iSCSI network design isn't done carefully. Keeping it on isolated VLANs makes it much much harder to do something silly, like trying to carry iSCSI traffic across a router or a firewall (there shouldn't be any routers or firewalls on a iSCSI network)
  • Very, very bad things will happen if your storage/virtualization admin wants to implement jumbo frames, and your network admin doesn't want to implement jumbo frames. Keeping iSCSI separated on dedicated switches will prevent this from happening. Even sharing switches with regular network traffic will prevent MTU mismatch, as you would only increase the MTU on the switches that has iSCSI traffic - not the connected switches.

I could probably list more reasons, but I think it's enough to get an idea. Don't mix iSCSI traffic with any other kind of traffic on the same ports. If you have decent switches then go ahead and share the switch fabric with other traffic, but keep iSCSI on separate ports in separate VLANs.

  • 1
    Not to mention performance, performance and....performance.
    – symcbean
    Sep 23, 2014 at 15:44
  • So to sum up, very very bad things will happen :P.
    – TMH
    Sep 23, 2014 at 15:57

Because not doing so allows regular traffic to impact on storage traffic, which is a bad idea as it means that say a user's download could delay an important read or write.

  • That's an argument for QoS. Would you also argue in favor of isolating VoIP traffic?
    – MSalters
    Sep 24, 2014 at 14:24
  • So you don't need QoS, it has a latency cost usually
    – Chopper3
    Sep 24, 2014 at 14:32
  • That's by design - QoS lets non-timesensitive data wait for more urgent data such as iSCSI traffic.
    – MSalters
    Sep 24, 2014 at 14:45

You don't want side effects from traffic disturb your SAN access. We have a small VMWare VSphere environment where we at first had both VMotion and iSCSI traffic going through the same switches on the same network. Different network adapters, but the same network. A bug in ESXi 5.0 made the hosts randomly lose access to the iSCSI SAN whenever a longer VMotion action that made use of more than 1 network adapter was active. Depending on the SAN solution and the iSCSI clients used you can expect all sorts of funny behavior when you mix traffic. Of course it can run without any problem too, but that usually only lasts until that one day when your colleagues are all on vacation and suddenly all hell breaks loose.

Another problem when you have iSCSI SAN systems in your default network: someone could use an IP address assigned to your SAN node. That would probably not happen on accident, but someone trying to get you or the company in trouble could scan your network, discover the SAN and use any IP-enabled device to make your SAN magically disappear.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.