GNS3-Workbench uses multiple virtualisation techniques – not only do you have to be comfortable that the GNS3 routers use virtual hardware, but you also have to understand the implications of running the GNS3 application in a Virtualised Ubuntu Machine. Hopefully, you are familiar with the fact that your routers in the GNS3 topology have virtual interfaces, your Guest OS (Ubuntu) has virtual interfaces and your Host PC has virtual interfaces. Trying to join the dots can be daunting, but that is what this article attempts to do.

Preparation

This is Part 2 of a 3 article series. Part 1, a Tutorial on VMware interfaces, explains how VMware adds virtual interfaces to your Host PC. If you are not familiar with this concept or the use of vmnetcfg.exe, then please read Part 1 first.

Also, if you are not familiar with the virtualisation aspects of GNS3, Dynagen and Dynamips, then read a little history on GNS3.
Part 3, Linking your Host PC and Guest OS to devices in GNS3 WorkBench will be published soon.

The Virtual Machine that will be used in this article will of course be the GNS3 Workbench, which runs on Ubuntu. It will be helpful if you have your copy of GNS3 WorkBench running (using VMware Player) while you read this.

This article also assumes your Host PC has its Ethernet adapter connected to a network with DHCP services available and was written assuming a VMware Player (v3.1.4) environment on a Windows Vista based Host PC.

Exploring Ubuntu’s virtual interfaces

In your GNS3 WorkBench environment, start by opening a Konsole window by double clicking the shortcut on the GNS3 WorkBench Desktop. Any future references to issuing a command will assume you know you need to enter the command in this window. Issue the command ifconfig, or to save space and make reading easier, filter the command output through grep looking for addr or encap like this:

user@GNS3WB:~$ ifconfig | grep 'inet addr\|encap'
eth0      Link encap:Ethernet  HWaddr 00:0c:29:d1:e5:82
eth1      Link encap:Ethernet  HWaddr 00:0c:29:d1:e5:8c
          inet addr:172.16.101.237  Bcast:172.16.101.255  Mask:255.255.255.0
eth2      Link encap:Ethernet  HWaddr 00:0c:29:d1:e5:96
          inet addr:192.168.80.151  Bcast:192.168.80.255  Mask:255.255.255.0
eth0:avahi Link encap:Ethernet  HWaddr 00:0c:29:d1:e5:82
          inet addr:169.254.9.240  Bcast:169.254.255.255  Mask:255.255.0.0
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
vlan16    Link encap:Ethernet  HWaddr 00:0c:29:d1:e5:82
vlan17    Link encap:Ethernet  HWaddr 00:0c:29:d1:e5:82
vlan16:avahi Link encap:Ethernet  HWaddr 00:0c:29:d1:e5:82
          inet addr:169.254.9.240  Bcast:169.254.255.255  Mask:255.255.0.0
vlan17:avahi Link encap:Ethernet  HWaddr 00:0c:29:d1:e5:82
          inet addr:169.254.9.240  Bcast:169.254.255.255  Mask:255.255.0.0

As it ships, GNS3-WorkBench has three ethernet interfaces (eth0, eth1, & eth2) and two vlan interfaces (vlan16 & vlan17). Since eth0, vlan16 & vlan17 were unable to get ipaddresses via dhcp, you also see what looks like three more interfaces in the list above – eth0:avahi, vlan16:avahi, and vlan17:avahi. And of course there is the loopback interface.

Relating Host PC interfaces to Guest (Ubuntu) Interfaces

Recall that in my previous post, the virtual interfaces that the VMware Player install created on my host (Windows Vista) PC were:

Ethernet adapter VMware Network Adapter VMnet1:

Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet1

DHCP Enabled. . . . . . . . . . . : No
IPv4 Address. . . . . . . . . . . : 192.168.80.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter VMware Network Adapter VMnet8:

Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet8

DHCP Enabled. . . . . . . . . . . : No
IPv4 Address. . . . . . . . . . . : 172.16.101.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : nnk.com.au
Description . . . . . . . . . . . : Intel(R) Wireless WiFi Link 4965AGN
DHCP Enabled. . . . . . . . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.1.105(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0

If you compare these to the Ethernet interfaces on the GNS3 Workbench Ubuntu machine as shown above, you can see that two of these interfaces share a subnet with each of the Ubuntu interfaces:

However, you will notice that the eth0 Ubuntu interface attempted to get an ip address, but failed. TO see why, you need to examine the Virtual Machine Settings from within VMware Player. So click Virtual Machine->Virtual Machine Settings.

Note that the settings for the first Network Adapter are Custom (vmnet3). If you recall from my previous post, VMware installs by default a bridged interface on vmnet0, a Host-only interface on vmnet1 and a NAT interface on vmnet8. By default, nothing is assigned to vmnet3! (To be honest, this was a mistake – I had meant to have left the first interface bridged to vmnet0).

What you need to do now, is change that setting so that the first network adapter is set back to the default Bridged mode, and I’d recommend also setting the option to Replicate physical network connection state.

Once you have done this, click OK and then force your Ubuntu adapter to renew it’s IP address – unplugging & reinserting your Host PC’s Ethernet cable may do it, or issue the dhcient command in super-user mode on your Ubuntu guest.

user@GNS3WB:Project$ sudo dhclient eth0
[sudo] password for user:
Internet Systems Consortium DHCP Client V3.1.3
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
<snip>

and now check eth0, assuming your Host PC’s Ethernet network has a DHCP server available – you should see something like:

user@GNS3WB:Project$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0c:29:d1:e5:82
          inet addr:192.168.1.159  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fed1:e582/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:61 errors:0 dropped:0 overruns:0 frame:0
          TX packets:208 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8992 (8.9 KB)  TX bytes:44526 (44.5 KB)
          Interrupt:18 Base address:0x2024

Note that the IP address obtained on eth0 (192.168.1.159/24) is on the same subnet as the Host PC’s Local Area Connection (192.168.1.105/24). It will have the same default gateway and DNS server as the Host PC as well, because it obtained its IP addressing information from the same DHCP server. You can see this by checking eth0’s dhcp config file – /var/lib/dhcp3/dhclient.eth0.leases.

user@GNS3WB:Project$ cat /var/lib/dhcp3/dhclient.eth0.leases
lease {
  interface "eth0";
  fixed-address 192.168.1.159;
  option subnet-mask 255.255.255.0;
  option routers 192.168.1.1;
  option dhcp-lease-time 43200;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.1.12;
  option dhcp-server-identifier 192.168.1.12;
  option domain-name "nnk.com.au";
  renew 1 2011/07/25 11:49:33;
  rebind 1 2011/07/25 16:50:45;
  expire 1 2011/07/25 18:20:45;
}

Key Point #1 – Always check that your Virtual Interface(s) on your Guest Virtual Machine is/are linked to the correct vmnet interface(s) on the Host PC. Failure to do so can lead to tricky problems to troubleshoot.

In the final instalment of this series, I’ll relate both the vmnet interfaces on the Host PC and the Virtual Interfaces on the Guest OS to the Virtual Interfaces of the Virtual routers in GNS3.