I’m not sure adding a VLAN will actually help performance.
Apologies if you all know this, I’m from a networking design/architecture background and have beta tested hardware and software networking products for a while now.
Ethernet switches, by design, do not send all traffic they receive on one port to all ports (that is what hubs do). They selectively forward traffic to ports where they know a destination to be (or to all ports, if the destination is unknown (aka the learning process)). So, if you have a DroboPro on a switch, it should only ‘see’ traffic addressed to it, broadcast and multicast traffic. Most home networks will have virtually no such traffic on them. Directed traffic is called Unicast (single destination) to complete the terms.
So, what will a VLAN add in this situation?
Well, it will mean the DroboPro will still see the traffic it needs to (as before), but misses out on the tiny quantity of other traffic. It will be ‘invisible’ to everything else not on that VLAN - which is a security enhancement. Although VLANs are not really rated a security ‘barriers’ in more than low security environments.
VLANs work by adding 4 extra bytes to each packet, containing the VLAN ID. In effect, the envelope containing your data is put into second slightly larger envelope for transport, then the outer envelope discarded and the original handed to the destination.
On any given ethernet port or cable, only one VLAN can be untagged but many other tagged VLANs can be carried. The extra tags mean anything else just ignores the packet. So, the MacMini is going to have tag traffic on the DroboPro VLAN. This requires CPU, and a slight increase in the usage on the wire (an extra 4 bytes per frame). The switch will take off the tag and forward the packet on the ‘untagged’ port the Drobo is on. Switches do this in hardware, so no problems there.
The computer (a MacMini for me) has a single ethernet interface, which means it has to carry all the traffic. The addition of the VLAN tagging on this interface seems to negate any potential benefit this may introduce - unless it is the Drobo itself which requires a ‘clean’ network to work from. Which would be a stunning bit of bad design on Drobo’s part which I seriously doubt.
I have the DroboPro connected to a MacMini, acting as a sevrer for the rest of the network. When everything was on an AirPort extreme to give a GB switch, transfers from my iMac to the DroboPro would run the ethernet at about 46MByte/sec. Since I put an HP 1810G-8 port GB switch in, these now often go up to 50 MByte/sec in my limited testing. This seems probably down to the very low latency on the HP switch over the Apple device. Just duplication of a folder on the Drobo with some large files in using the MacMini I’ve seen the network to the Drobo peak at 70MByte/sec in/out as the files are read and re-written back (this doesn’t touch the ManMini HD, so a handy quick and dirty test)
I would expect Drobo to state that the DroboPro should be connected to a dedicated port in the computer. This is the best way to ensure best performance, as no other (web browsing, e-mail etc.) traffic will ever impact the available bandwidth between the Drobo and the computer. As soon as you get into the VALN (or even multihoming) the available space for iSCSI is the ethernet speed less anything else going on at the time.
Apologies for the long post, hope it helps. I’d still be interested in any before and after tests though. If I get time, I may have a tinker and see that happens too.