EVO offers a virtual switch feature, which can simplify the process of configuring workstations, allow for creative separation of network devices, and in some cases eliminate the need for additional network hardware. This enables the creation of private networks so machines can be isolated from general traffic, still have visibility of one another, and even for EVO to act as their gateway to the internet.
While this rather unique capability can provide several benefits in many scenarios, there are some things to keep in mind when taking advantage of this feature.
Here are some general recommendations when considering EVO's network configuration and virtual switch functionality in your workflow:
Use direct connections if possible
- The simplest, shortest, and most direct connection is always preferred. In other words, ideally, there's no need for any type of switch. EVO allows for Ethernet expansion to support a large number of ports and make it possible for many machines to connect directly to it without any added connection points. In this case, each workstation has a dedicated port, guaranteeing all bandwidth afforded by that EVO port belongs to that workstation. This is possible with or without a virtual switch -- if a virtual switch is used, all machines use the same IP address to reach EVO, and without a virtual switch, each machine uses the IP address of its reserved EVO port. Note also that virtual switch functionality does require additional processing. The consequence of this may never be noticed, or it may be very obvious, depending on several factors, including the number of and type of connections, the nature of the traffic they’re generating, and the amount of concurrent processes happening on EVO. A reasonable estimation of the impact would be between 0-2% total bandwidth reduction.
Use a physical switch if possible
- If the number of machines exceeds the number of EVO's available Ethernet ports, then a physical switch is recommended. As remarkable as we think EVO's virtual switch capability is, EVO's primary purpose is to provide high-speed access to media, and this type of added functionality is best offloaded to a dedicated device. A physical switch is designed specifically for this purpose, with traffic optimization as its primary objective. EVO also offers link aggregation capabilities to team ports together, and using a purpose-built switch with LACP to continually decide the best available path to use when managing network traffic is going to provide the most benefit.
Use another adapter for LAN traffic if possible
- In some environments, workstations may only have one Ethernet port available, and/or the internet router may only offer a small number of ports. It's possible for EVO to connect to the router to gain internet access, and for all workstations to use their Ethernet cable to connect to EVO, with it providing their internet connection (essentially adding ports to the router). For simplification, if Wi-Fi is an option, using wireless connections (or a USB or Thunderbolt Ethernet adapter) is still preferred, since the best practice is to isolate traffic of differing purposes. EVO may offer many Ethernet ports, but in this case the workstation only has a single cable available, and it's not necessarily going to prioritize production work over that link. While the workstation's network resources may still be required by other services, purposefully distinguishing traffic provides a cleaner representation of the workflow demands, and any difference in internet speed will likely be negligible, if present at all. Though a workstation may connect to EVO using a 10G connection, the internet connection is going to be limited to the slowest port in the path, which is likely at the router or ISP port.
Avoid mixing connection speeds if possible
-
EVO supports Ethernet ports ranging from 1GbE to 50GbE, all in the same chassis. While it's possible to add any port to a virtual switch, depending on the environment, it may be best to set differing MTU values on some ports, such as standard frames for 1GbE connections and jumbo frames for 10GbE or greater. The virtual switch requires a homogeneous MTU value, so it's best to isolate connection types when mixing speeds. It is possible to create more than one virtual switch on EVO, so a solution in that case may be to have one channel for 1GbE clients, and a second channel for 10GbE clients, keeping in mind that each channel does add some level of overhead.
If using a virtual switch and a physical switch, turn on STP
- In some cases, it makes sense to use both physical and virtual switches. If there's more than one route available to any destination as a result of having more than one link connected or using failover connections, routing decisions need to be made, and it's imperative that Spanning Tree Protocol (STP) be enabled on EVO to prevent loopback errors, or a broadcast storm. Using STP adds logic to ensure a switch has authority to decide how to route packets. Note that STP adds latency to transmissions, so simply ensuring there are no network loops is typically preferred over enabling this feature in most environments.