Connecting GNS3 and Microsoft Hyper-V

Most network administrators identify complex pieces of their networks that they would prefer to test changes in a lab environment with. This can include everything from simple routing changes to complex issues involving Network Address Translation, Policy Based Routing, Quality of Service, and complex access control lists and tunneling.  With the world becoming more virtual and the cost of downtime increasing, companies and individuals are increasingly looking to sophisticated, cost effective alternatives to maintaining a complete separate lab environment. One example of an alternative to a physical lab environment is to create a virtualized test environment using Dynamips/GNS3.

Dynamips/GNS3 allows network engineers to test complex pieces of routing configurations in an environment running actual Cisco IOS before putting changes into production that could disrupt network operation and cost the company thousands (or millions) of dollars. Out of the box, it is not always possible to test specific configurations, particularly if the desired changes affect routing, filtering, or NAT between specific hosts. Another piece that is missing from a straight Dynamips/GNS3 environment is the simulation of actual traffic flows between endpoints. This becomes especially important when dynamic ports are being used for applications such as SQL Server or Microsoft RPC/DCOM.

Utilizing Dynamips/GNS3 along with Hyper-V allows a true end-to-end simulation of an application environment to test/debug routing configuration changes. The routing environment (or at least the critical pieces) can be created using the routers/IOS images that are compatible with GNS3 and the cloud object in GNS3 can be configured to bridge to a network adapter on the system. An Internal virtual network (one that allows connectivity between the host system and VMs) allows a virtual network adapter to be created in the OS that can be assigned an IP address and  connected to the GNS3 topology using the cloud object.



Internal networks in Hyper-V resemble managed switches because they allow a number of VMs (and the host system) to communicate and allow individual host network adapters to have VLAN tagging enabled. This allows an easy test of a router-on-a-stick configuration or allows the network model to be condensed in GNS3 and Hyper-V to save resources on the host system.



After the Internal network is created in the Virtual Network Manager of Hyper-V, the network can be included in the GNS3 topology and the virtual machines can communicate across the virtual network in GNS3.



In this example, I have attached a Cisco 3725 to my virtual network supporting my Exchange 2010 test system and a DC. I simply configured the fa0/0 interface to communicate with the other nodes and communication can occur regularly.



Using the combination of Hyper-V and GNS3 is particularly valuable because it allows end-to-end testing and verification of routing configuration and allows production traffic to be truly simulated by creating VMs with identical applications/configuration and testing the impact of changes on the traffic between systems.  Although this does not provide a complete solution from a switching configuration viewpoint, most of the changes that have a high impact on the network occur on routers and firewalls, both of which can be effectively simulated using GNS3.

See Also,
Emulating a Managed Switch With Dynamips/GNS3
The Road to the CCIE

Any source