Linking your Host PC and Guest OS to devices in GNS3 WorkBench


Once you become familiar with GNS3, the thought soon strikes – how can I get my PC to talk to the routers in my GNS3 configuration? Since GNS3 WorkBench operates within a virtual machine, the process is a little more complicated than running GNS3 directly on your PC because you have to understand the relationship between your Host PC, your Guest OS (Ubuntu in this case) and the virtualised devices in GNS3. If you’d like to learn about that relationship, then read on.

Preparation

This is the third and final article of a series. The first article was a tutorial on VMware Interfaces as they relate to your Host PC. In this article, I explained the relationship between your Host PC and the Virtual Interfaces that VMware creates when you install VMware Player, and how to use vmnetcfg.exe.

The second article dealt with linking your Virtual Machine’s adapters to your Host PC within the Ubuntu/GNS3-WorkBench environment. The emphasis here was to show you that the interfaces on your guest OS (Ubuntu) are determined by the Network Adapter Settings of your VMware Player. It was also while writing this article that I realised that GNS3 Workbench v5.6 was configured with the primary interface (eth0 on Ubuntu) linked to non-existent host interface.

It is important that you configure your GNS3 WorkBench Virtual Machine so that your first Virtual Network Adapter is Bridged to your Host PC as explained in my previous post

For the remainer of this article, I’ll assume you are running GNS3 WorkBench v5.6 within a VMware Player (v3.1.4) environment on a Windows based Host PC. Your host PC will need its Ethernet port connected to some physical device to ensure that it is up. [If you host PC only has wireless, then make sure it is turned on and that should do].

Getting Started

If you have been following the previous articles, you will have a Windows PC host OS and your Ubuntu Guest OS with IP addresses something like:

Host PC InterfaceIP address Guest OS InterfaceIP address
Local Area Connection 192.168.1.105 eth0 192.168.1.159
VMnet1 192.168.80.1 eth2 192.168.80.151
VMnet8 172.16.101.1 eth1 172.16.101.237/24

Have the GNS3 Workbench VM running, and bring up a konsole command prompt. Check the ip address of your Ubuntu interfaces using the ifconfig command:

user@GNS3WB:~$ ifconfig | grep -A 1 eth. 
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

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

Checking the plumbing

You might want to check that your Host PC and guest OS (Ubuntu) can ping each other on these addresses. You will need to have your Host PC set up to obtain an address automatically for this to work for the eth0 address.

If you can’t, then reading my previous posts (1) & (2) may help you troubleshoot.

Starting the router

Let’s start in the GNS3 WorkBench environment by opening the Desktop shortcut Standard Layouts. From here, open the lab 1 Router (reset lab).

Take a look at the icon that says Local Network/Your Windows PC. This is the link to your Ubuntu’s eth0 interface and your host PC’s Local Area Connection.

Right-click on this PC icon and select configure.

In the Node configurator dialogue that opens, select Local Network in the left-hand pane, and then select the NIO Ethernet tab. Notice that there is already a mapping for nio gen_eth:eth0 associated with this particular node – which by the way is a node of type Cloud in the GNS3 configuration, but has had an icon looking like a PC associated with it. The other PC icon vPCx and the SerialCloud are also cloud type nodes.

Close the Node configurator and click the green “go” icon on the toolbar to start your router.

Key Point #1 – Access to external devices in GNS3 is achieved by using Cloud Node types.

After a giving your router a chance to boot, open a console session to the router by clicking the black “console” icon on the toolbar. If you have a DHCP server on your network you might see that your router is already communicating through your host machine by virtue of the fact that it is trying to download a configuration file – something like:

%Error opening tftp://192.168.1.12/network-confg (No such file or directory)
%Error opening tftp://192.168.1.12/cisconet.cfg (No such file or directory)
%Error opening tftp://192.168.1.12/router-confg (No such file or directory)

You should also see the usual System Configuration Dialogue prompt “Would you like to enter the initial configuration dialog? [yes/no]:”

Answer no, and Press RETURN to get started!

Connecting your router to your Host PC

Again, if you have a DHCP server connected to your host PC, you will probably see that an IP address gets allocated to the router’s Fa0/0 interface, as shown by:

*Mar  1 00:17:48.723: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.1.158, mask 255.255.255.0, hostname Router

And a quick show ip interface brief will verify this

Router>show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.1.158   YES DHCP   up                    up
Serial0/0                  unassigned      YES unset  administratively down down
FastEthernet0/1            unassigned      YES unset  administratively down down
Serial0/1                  unassigned      YES unset  administratively down down

If you do not have a DHCP server running on your test network, then you will have to manually assign a spare IP address that matches the subnet your host Local Area Connection is on.  So assuming that your local subnet is 192.168.1.0/24, and you wish to assign the ip address 192.168.1.158, you would enter the following on your router:

Router>enable
Router#configure terminal
Router(config)#interface fa0/0
Router(config-if)#ip address 192.168.1.158 255.255.255.0
Router(config-if)#no shutdown

Now your router has access to your local network; from your router you should be able to ping your Host PC, and if you have a real router that connects you to the internet, you can even reach any public address. (Theoretically, you should also be able to reach your Ubuntu Guest OS, but I often find this doesn’t work)

My network has a router at 192.168.1.1, and a DNS server at 192.168.1.2, so I’ll show you how I could have configured my router to reach the rest of the world:

Router#configure terminal
Router(config)#ip route 0.0.0.0 0.0.0.0 192.168.1.1
Router(config)#ip name-server 192.168.1.12
Router(config)#end

Now the test results:

Router#ping 192.168.1.1    !My router

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/14/28 ms
Router#ping 192.168.1.12   !My DNS

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.12, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/16 ms
Router#ping 192.168.1.105   !My Host PC (Windows)

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.105, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 8/24/40 ms
Router#ping 192.168.1.159   !My Guest OS (Ubuntu) Doesn't work

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.159, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Router#ping google.com    !The Internet!!!

Translating "google.com"...domain server (192.168.1.12) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 74.125.237.82, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 12/33/64 ms

Now configure your router to allow telnet access, and even SDM (Security Device Manager) access, and you will be able to access your router from your host PC. To do this in my example, I will allow full open access (privilege 15) on telnet, and to allow SDM access, I’ll need to create a user with level 15 privileges and start the http secure server and specify that we want to authenticate using the local username.

Router#configure terminal
Router(config)#line vty 0 15
Router(config-line)#no login
Router(config-line)#privilege level 15
Router(config-line)#exit
Router(config)#user admin privilege 15 secret cisco
Router(config)#ip http authentication local
Router(config)#ip http secure-server
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

Router(config)#
*Mar  1 03:44:35.227: %SSH-5-ENABLED: SSH 1.99 has been enabled
*Mar  1 03:44:36.807: %PKI-4-NOAUTOSAVE: Configuration was modified.  Issue "write memory" to save new certificate
Router(config)#end
Router#
*Mar  1 03:45:20.131: %SYS-5-CONFIG_I: Configured from console by console
Router#write memory
Building configuration...
[OK]
Router#

Testing from other network devices back to your router

Now to test from the host PC!

C:\WINDOWS>ping 192.168.1.158

Pinging 192.168.1.158 with 32 bytes of data:

Reply from 192.168.1.158: bytes=32 time=20ms TTL=255
Reply from 192.168.1.158: bytes=32 time=5ms TTL=255
Reply from 192.168.1.158: bytes=32 time=5ms TTL=255
Reply from 192.168.1.158: bytes=32 time=9ms TTL=255

Ping statistics for 192.168.1.158:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 20ms, Average = 9ms

C:\WINDOWS>telnet 192.168.1.158
Router#show users
    Line       User       Host(s)              Idle       Location
   0 con 0                idle                 00:08:48
* 98 vty 0 idle 00:00:00 192.168.1.105

  Interface    User               Mode         Idle     Peer Address

Router#exit

And now try SDM. My Host PC didn’t have SDM installed, so I ran it from another PC on the network! (After disabling pop-ups on that PC’s browser)

This causes your default browser to launch, and you’ll be prompted for Authentication credentials:

You may have to allow active-x, diable popup, accept certificates etc to get past this point. Eventually you may see yet another authentication window (however, if this one doen’t come up, don’t get upset – just be grateful):

And SDM should open:

Challenge for readers

Back in GNS3, look at the Node configuration settings for the Serial Cloud. You will see that it has been configured with a NIO UDP connection to 192.168.255.11:5000.

Now your challenge is to join this SerialCloud with another copy of GNS3 WorkBench running the same lab on another computer. Lets assume that the GuestOS (Ubuntu) IP address on the remote machine is 192.168.1.142

On each GNS3 WorkBench you will have to:
Stop the router.
Delete the serial link between the router and the SerailCLoud
Configure the SerialCloud (double click on it)
Remove the existing NIO UDP connection to 192.168.255.11:5000
Create a new connection from Local port: 5000 to Remote host: 192.168.1.142 and Remote port: 5000
Add this connection and Apply it
Re-create the serial link between the SerialCloud and S0/0 on the router
Re-start the router

If you now assign appropriate IP addresses to each router’s serial 0/0 interfaces, they should be able to communicate!

Key Point #2 – Cloud Node types can be linked not only to physical interfaces, but to other ‘Cloud‘ interfaces on other computers, or other ‘Cloud‘ processes on the same PC, such as the VPCs application.

Wrap up

In this article I have shown you the relationship between the NIO Ethernet interfaces and your Host PC and your Ubuntu Guest OS. You have learned how to use these interfaces to interact with the outside world – from your local network to anywhere in the internet. The exception is that your router doesn’t want to talk directly to your Guest OS interface, but this doesn’t stop your router connecting to the Guest OS IP hosted on another PC.

Once you have connectivity between your Host PC and your router, you can telnet directly to your router, or even use Cisco’s Security Device Manage (SDM) to access the router if you desire.

I have shown you the bare essentials to connect NIO UDP interfaces from one system to another, ans left it as a challenge for you to ponder and complete. I encourage feedback about your success and/or frustration.

This concludes my 3 article series, be sure to check out the first two articles (Tutorial on VMware Interfaces, and Linking your Virtual Machine’s adapters to your Host PC using GNS3-WorkBench) if you have not already done so.

RedNectar

Advertisements

About RedNectar Chris Welsh

Professional IT Instructor. All things TCP/IP, Cisco or VoIP
This entry was posted in GNS3, GNS3 WorkBench, Ubuntu, virtual interface, Virtual Machine, vmnet, vmnetcfg, vmnetcfg.exe, VMware, VMware Player and tagged , , , , , , , . Bookmark the permalink.

12 Responses to Linking your Host PC and Guest OS to devices in GNS3 WorkBench

  1. csontee says:

    Hi,
    Good article. But what about the inverse direction. When I have a GNSlab in my home network and I would like to reach the individual routers in that particular network? How can I do that? I know I can telnet to the 2501 or 2001 ports(some additional setting needs on the local router), but it has limitation. Any other solution?
    Thanks

    • rednectar says:

      Apart from tedious tweaking of your home router settings for mapping different port, then most practical solution is to set up a VPN on your home network. If your access-router doesn’t have VPN functionality, you can probably at least set it up with a DMZ host (or something similar) and then run an ASA as your DMZ host. Someone should write an article how to do this one day. Any takers?

  2. Rashad says:

    Thanx alot!!!very very nicely explained!!!

    • rednectar says:

      You are welcome. However, I would very much appreciate it if you used links back to my blog rather than copying my post to put on your blog.
      CW

  3. rednectar says:

    Hi Ryan,

    I haven’t used Workstation 9, but it should follow the same principles as all other VMwares.

    Firstly, it doesn’t matter that you are using 10.10.10.x – the fact that all the examples use 192 & 172 is immaterial.

    Not sure of the exact steps in VMWS 9, but check you network adapter settings to the VM. Check that the first adapter is a) enabled and b) bridged to your Local Area Network connection.

    IN Ubuntu, check your interfaces are properly numbered. From a terminal in Ubuntu, issue the command:

    ifconfig

    and you should see that eth0 is the first interface. If not, read the README files (there is a shortcut on the desktop to ‘READMEs & Utilities’. In fact there is also a script there to fix that problem)

    Assuming eth0 is the first interface, then in GNS3, when you want your router to connect to the local LAN, create a cloud, configure it so that it is linked to eth0 of your host, then join the cloud to your router interface. Your router interface should then be able to ping 10.10.10.1 (so long it has a 10.10.10.x IP address)

    HTH

  4. Ryan Coombs says:

    Rednectar, I have tried for days to get my Briged Interface working. My Host PC is Windows 7 and im running your GNS3 Workbench in Workstation 9. The host only is fine and it appears i can ping from GNS3 Console to the internet just fine but I am unable to bridge the Bridged interface to allow my Router to get ot to the NET. My ip schema is 10.10.10.0 and 1 being the default gateway. Also In the network editor Ive noticed everthing is 192. or 172 should i change my home network to reflect that scheme? Any help would be appreciated this sucka has taken alot of my nights away from me and i have not being able to get something working. Especially something im really looking forward to getting working! All your blogs and write ups are great by the way….Keep up the good work!

    Ryan

  5. Jay Kuhne says:

    Hi Chris, Great job on this 3 part series. I followed along and brought up workbench and network scheme that will work for my CCIE Voice studies. I was using Workstation7 but all the principals were the same. I was able to extend more host-only VMNets as well for my branches. I ou taking the time to write this out, it was helpful. I found I was able to share/switch other existing VMs (Unified Components) i was hosting on VMware onto the GNS3 networks through the Workbench host. I now have a nice home setup to continue the Blindhog virtualized env. and continue labs. Most importantly I can now route call scenarios properly between VMs. Please keep this blog going… I got a chuckle on the Native VLAN post… it has baffled me for a long time, we’re on the same page brotha…

  6. Sayeed Khan says:

    No words to express how well you have written these 3 articles.
    For same information i did google and saw so many articles but still it was not clear for me.
    Your information is very well explained and i learnt a lot about vmware from you.
    Thanks a lotttttttttttttttttttttt!!!!!!!

  7. cli friendly says:

    Excellent, helpful series of posts. Taught me much about VMware AND GNS3 networking. Still pondering the layered virtuallity of it all.

    • rednectar says:

      Thanks for the kind words. Believe me, you will need to get a good grasp on all things virtual as you go forward!

  8. Pingback: Linking your Virtual Machine’s adapters to your Host PC using GNS3-WorkBench | RedNectar's Blog

Comments are closed.