Hyper-V Networking

Basic Hyper-V Networking

There are three kinds of virtual switches in windows Hyper-V, and each kind will connect the virtual NICs of virtual machines to a different kind of network:

External Virtual Switch:

The role of the external virtual switch, shown in Figure below, is to connect virtual NICs to a physical network. Each virtual NIC is connected to a single virtual switch. The switch is connected to a physical network. This connects the virtual NICs to the physical network.

Private Virtual Switch:

This type of virtual switch has no connections to either the management OS or the physical network; it is completely isolated, and therefore any virtual NICs that are connected to a private virtual switch are isolated too.

The private virtual switch was often used to secure sensitive workloads that should not be open to contact by the physical network.

Internal Virtual Switch

The internal virtual switch isolates connected virtual NICs from the physical network, but it connects the management OS by using a virtual NIC.

As with the private virtual switch, you do have to take care to keep virtual machines on this switch together on the same host. Otherwise, the machines will not be able to reach each other across the network.

Note:

If you choose either of the following configurations for the virtual switch, a management OS

virtual NIC will be created and connected to the virtual switch:

1-An external virtual switch that is shared with the management OS

2- An internal virtual switch

 

Distribution Switch:

Virtual switches (of any type) are not distributed. This means that a virtual machine connected to a private network on Host1 cannot communicate with a virtual machine connected to a similarly named private network on Host2. This could cause issues if the cooperating Virtual machines were migrated to different hosts.

There are new techniques we can use instead of private networks, such as Port ACLs (access control lists) or third-party solutions, that can isolate our workloads without the use of private virtual switches.

Distributed switch adding Cloud networking functionality to Windows Server 2012

Extensible virtual switch

Adding Virtual Switch Extensible: The Hyper-V virtual switch is a powerful network appliance, but it can be given more functionality by installing third-party extensions. Each of these extensions adds functionality to the Hyper-V virtual switch instead of replacing it. The extensions are certified Network Driver Interface Specification (NDIS) filter drivers or Windows Filtering Platform (WFP) filters/drivers.

Capturing Extension: Monitor network traffic as it passes through the virtual switch. It may not alter this traffic. (Analyze problems between two computers; report back to a central monitoring service)

Filtering Extension: inspect (doing everything a capturing extension can do), modify, and insert packets in the virtual switch. It can also drop packets or prevent packet delivery to one or more destinations. (Virtual firewall functionality)

 Advantage

Flatter networks and leverage software-defined networking (SDN) with less human involvement 

Forwarding Extension: make the Hyper-V virtual switch look like a completely different switch to third-party administration software.

The forwarding extension is the first extension to see incoming data and the last extension to see outgoing data.

Cisco has the Nexus 1000V, described as a distributed virtual switching platform that extends Cisco functionality into the Hyper-V extensible virtual switch.

Note: Enable and disable extensions.

1. Open Virtual Switch Manager.
2. Click the expand button on the relevant virtual switch to expand its properties.
3. Click Extensions.

VLAN: dividing a physical LAN into multiple subnets is called VLAN, divide into smaller broadcast domain and isolate traffic for security and management reason.

Note:    traffic between VLANs are routed and filtered by firewalls.

VLAN have and ID

Devices can communicate only with device within the same VLAN

Approach 1:

The old Approach is to have one physical NIC for every required VLAN; a port is configured on the physical switch for each VLAN

This approach is works fine for a lab or small IT, but it is not flexible, it is not scalable, and it will require lots of NICs if you have lots of VLANs

You must have same number on NIC and VLANs in all servers (if are moving VMs between servers), and it is not suitable for cloud

Approach 2:

Assigning VLAN IDs to Virtual NICs

Create a single external virtual switch and then configure the VLAN ID of each virtual NIC to link it to the required VLAN.

1- The solution is software based, so it can be automated or orchestrated for self-service cloud computing.

2- Scalable and requires very little infrastructure configuration.

3- The solution is secure because only the virtualization administrator can configure the VLAN ID.

The network administrator creates the required VLANs and sets up a trunk port in the switch.

The physical NIC in the host is connected to the trunk port.

An external virtual switch is created, and connected to the physical NIC.

Virtual machines are created, and their NICs are connected to the single virtual switch,

The virtualization administrator assigns each virtual NIC to a specific VLAN.

Approach 3:

Pass the VLAN trunk up through the virtual switch port and into the virtual NIC of the virtual machine.

The virtual NIC of Virtual Machine 2 will be configured in trunk mode to allow VLANs that are specified by the Hyper-V or Cloud administrator.

Certain level of trust being placed on the administrator of the guest operating system; virtual machine is granted trunk mode access to VLANs.

The guest OS administrator should know the following:

1. How to configure VLANs in the guest OS
2. What traffic to send over what VLAN
3. Not to misuse this delegated right

 

As mentioned certain amount of control assigned to the Hyper-V or cloud administrator. Only specified VLANs will be trunked, so the guest OS administrator can successfully tag traffic for only the delegated VLANs.