A growing number of organizations are now standardizing in a virtualized server deployment and they want to consolidate servers that belong to different trust zones. A trust zone is loosely defined as a network segment within which data flows relatively freely, whereas data flowing in and out of the trust zone is subject to stronger restrictions. The introduction of virtual technology does not have to significantly change the network topology.
This blog post lists Virtual Network best practices that we use in our deployments and hopefully it will be used as a guide for your own deployment:
- As always, plan the virtual to physical networking integration. You will need to include all current and future considerations within your trust and untrust zones.
- If possible, maximize the number of physical network adapters (NIC ports) to provide flexibility in the virtual networking architecture. The minimum that we use for a deployment is 6 NIC with two or four ports per NIC card, this will be clear in the succeeding sections below.
- Separate the different VMware network services: Service Console, iSCSI, NAS, VMotion, Fault Tolerance (FT), and virtual machine trafﬁc across different physical networks pending the availability of network adapters, or use a VLAN architecture to segment the trafﬁc.
- Construct a virtual networking security policy for virtual switches, ports, and port groups.
- Create port groups with VLAN IDs to provide security, segmentation, and scalability to the virtual switching architecture.
- Create port groups for security, traffic shapping, or VLAN tagging.
- For optimal security, conﬁgure the virtual switch properties with the following settings:
- Promiscuous mode: Reject
- MAC Address Changes: Reject
- Forged Transmits: Reject
- Avoid VLAN tags used by common third-party hardware devices, like VLAN 1. Virtual switches do not support the native VLAN as physical switches do.
- Deﬁne trafﬁc shaping. This is to reduce the outbound bandwidth available either to the virtual machines that do not require full access to the bandwidth of the physical adapter or to the virtual machines that inappropriately monopolize bandwidth. Weigh the options of micro-managing virtual machine bandwidth against the conﬁguration of NIC teams with the installation of additional network adapters.
- Construct NIC teams on a physical adapter connected to separate bus architectures. For example, use one onboard network adapter in combination with an adapter from an expansion card. Do not use two adapters from the same expansion card in the same NIC team or two onboard adapters in the same NIC team. The exception to this recommendation would be in the case of multiple onboard adapters that are actually on separate I/O buses, like in some server hardware (i.e. HP DL380 G6).
- To eliminate a single point of failure at the physical switch, connect network adapters in a NIC team to separate physical switches that belong to the same broadcast domain. You will need physical switches that support cross-switch link aggregation in order to provide physical switch redundancy when using IP-hash-based load balancing on your vSwitches. An example of such a switch is the Cisco Catalyst 3750G series.
- Consider creating a NIC team for the service console. Otherwise, consider providing multiple vswif ports on different networks for redundant Service Console access.
- Construct a dedicated Gigabit LAN for VMotion. All physical network adapters in the server must offer support for Gigabit Ethernet.
- Provide a dedicated Gigabit Ethernet or 10 Gigabit Ethernet network interface card (NIC)for fault tolerance logging trafﬁc.
- And of course. Create separate networks for test and production virtual machines.
Here is a good reference for Network segmentation in a Virtualized Environments:
Watch out for the next topic in our series as we list other VMware best practices.
Oscar Bravo Jr.
CISSP, CISA, CCDP, CCNP, CCEE, CCSE, MCSE, MCITP, RSASE
Senior Consultant, Security Solutions Services