Connecting VMware Workstation and Cisco GNS3 Lab – Linux Edition

On August the 7th in 2013, we talked about connecting Cisco world made in GNS3 to another world, the VMware Workstation world. All on our laptops. We can recall this lab by clicking here. This way we could run Cisco ACS5.x, ISE1.x or any other Cisco product that can run as a virtual machine and connect those systems to our GNS3 virtual network, like the MPLS network shown in that article. We could connect our GNS3 network to the Active Directory Services or Certificate Authorities, for example. In that article, our host machine was a Windows machine. But what about Linux hosts? Keep reading.

I used to do Linux a lot, back in the days, but because of my job, I kinda drifted away to the Windows. I’m talking about PCs/Laptops, not servers. Recently, I met my old love, all dressed up in the new stuff, not anything like she used to be when she was called – Slackware. Now it’s called  – Debian 🙂

Ok, enough with the poetry, let’s go down to business. Here is what we will do:

gns3 topology

It is the most basic topology, but it can be easily expanded to the MPLS-like lab, or anything we want. Let me briefly describe this topology: we have a HP ProBook470 Core i7 with 16GB of RAM running Linux Debian 7.1 Wheezy (I guess this tutorial should work on any Linux distro, but I tested it on Debian). This laptop is depicted as LinuxBox on the above diagram. I’m running VMware Workstation 10 and GNS3 0.7.4 on this Linux. I must now say, that this lab would not work with Ubuntu 13.04 and Workstation 10, but should work with Workstation 9. I didn’t have time to figure this out. Inside the Workstation I’m running Cisco ACS5.x and in the GNS3 there is only one router for testing purposes.

First, let’s setup the Workstation. From within Virtual Network Editor (go to Edit->Virtual Network Editor) we will create a new network. Because we are using networks one through five for our vSphere lab, we will create VMnetwork vmnet11 for the sake of this lab:

vmware network editor

When creating this network, we select “Host-only (connect VMs internally in private network)“, deselect “Use local DHCP service to distribute IP addresses to VMs” and select “Connect a host virtual adapter (vmnet11) to this network“. In the “Subnet IP” field we can type anything we want (making sure we don’t create a conflict), because we will change this later to match our needs. We save our network.

Now we should prepare our laptop networking before going to GNS3. This was an easy task with Windows, but we need to do some preparations in Linux. This is the basic idea: we need to create a network bridge adapter and connect two parties using this adapter. One party is GNS3 world and another is VMware world. So those two parties could communicate with each other through this network bridge.

Before we can create our bridge adapter, we need a package called bridge-utils installed on our Debian:

root@pop-deb:~#
root@pop-deb:~# apt-get install bridge-utils
Reading package lists… Done
Building dependency tree
Reading state information… Done
bridge-utils is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@pop-deb:~#

I’m using root account instead of ‘sudoing’ every time. It is best practice to do “sudo apt-get install bridge-utils” instead but hey, this is not a Linux tutorial 🙂

As we can see, there is already bridge-utils package installed.

We also need uml-utilities package:

root@pop-deb:~#
root@pop-deb:~# apt-get install uml-utilities
Reading package lists… Done
Building dependency tree
Reading state information… Done
Suggested packages:
user-mode-linux
The following NEW packages will be installed:
uml-utilities
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 64.2 kB of archives.
After this operation, 257 kB of additional disk space will be used.
Get:1 http://ftp.ba.debian.org/debian/ wheezy/main uml-utilities amd64 20070815-1.3 [64.2 kB]
Fetched 64.2 kB in 1s (36.8 kB/s)
Selecting previously unselected package uml-utilities.
(Reading database … 153931 files and directories currently installed.)
Unpacking uml-utilities (from …/uml-utilities_20070815-1.3_amd64.deb) …
Processing triggers for man-db …
Setting up uml-utilities (20070815-1.3) …
[ ok ] Starting User-mode networking switch: uml_switch.
root@pop-deb:~#

So far we have one side of the bridge, the VWware side, which is represented by the vmnet11 adapter. Let’s create another side, the GNS3 side, which will be represented with the tap11 interface. This tap is kinda loop back adapter in Windows:

root@pop-deb:~#
root@pop-deb:~# tunctl -t tap11
Set ‘tap11’ persistent and owned by uid 0
root@pop-deb:~#

Now we will strip off IP addresses from both interfaces and bring them up:

root@pop-deb:~#
root@pop-deb:~# ifconfig tap11 0.0.0.0 promisc up
root@pop-deb:~# ifconfig vmnet11 0.0.0.0 promisc up
root@pop-deb:~#

OK, we have both sides of the bridge ready, now let’s build a bridge to cross the river 🙂

root@pop-deb:~#
root@pop-deb:~# brctl addbr br11
root@pop-deb:~# brctl addif br11 tap11
root@pop-deb:~# brctl addif br11 vmnet11
root@pop-deb:~#

First of brctl commands actually creates the bridge and other two add interfaces to the bridge. The bridge interface is named br11 to match other interface names involved.

Now we will assign IP parameters to this bridge adapter and verify settings:

root@pop-deb:~#
root@pop-deb:~# ifconfig br11 11.11.11.1 netmask 255.255.255.0 up
root@pop-deb:~# ifconfig br11
br11      Link encap:Ethernet  HWaddr 00:50:56:c0:00:0b
inet addr:11.11.11.1  Bcast:11.11.11.255  Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B)  TX bytes:8217 (8.0 KiB)

root@pop-deb:~#

Finally, we try to ping this adapter’s address:

root@pop-deb:~#
root@pop-deb:~# ping -c 5 11.11.11.1
PING 11.11.11.1 (11.11.11.1) 56(84) bytes of data.
64 bytes from 11.11.11.1: icmp_req=1 ttl=64 time=0.059 ms
64 bytes from 11.11.11.1: icmp_req=2 ttl=64 time=0.058 ms
64 bytes from 11.11.11.1: icmp_req=3 ttl=64 time=0.060 ms
64 bytes from 11.11.11.1: icmp_req=4 ttl=64 time=0.062 ms
64 bytes from 11.11.11.1: icmp_req=5 ttl=64 time=0.060 ms

— 11.11.11.1 ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.058/0.059/0.062/0.009 ms
root@pop-deb:~#

This stage of lab setup is now complete. What’s left is setting up our GNS3 topology.

In order to connect our GNS3 to this bridge, we need to run GNS3 as root. This can be achieved many ways, one of which is executing “gksu gns3” from command shell. We give the root password and GNS3 powers up. We then drag our router and our cloud to the topology. Before we can connect these two, we need to set up our cloud. We can change the symbol and host name, then we right click the cloud and click Configure. This is what we need to do:

gns3 acs cloud config

Under the “NIO TAP” tab, in the “TAP interface (require root access)” field we type in the name of the GNS3’s part of the bridge we created – tap11. We click Add and OK. Now we can connect our router to the cloud.

Before powering the router up, let’s deal with the ACS Server. We edit virtual machine’s network settings:

acs network settings

Under the “Virtual Machine Setting“, we change from vmnet1 to vmnet11. Please note that we are modifying our previous settings regarding the ACS. This and the following few steps are not needed if building the ACS from the scratch. If this is a brand new installation of the ACS, we just need to select the “Custom: Specific virtual network” and chose “/dev/vmnet11“.

Now we can power the ACS on. Because we have changed the network, we need to log in to the ACS console and make some changes. We need to change the IP address for sure, and optionally NTP server and DNS server. Because the change of the IP address requires ACS appliocation restart we will do that as well. This is our minimal ACS configuration after all changes made:

!
hostname acs52
!
ip domain-name popravak.local
!
interface GigabitEthernet 0
ip address 11.11.11.2 255.255.255.0
!
ip name-server 11.11.11.1
!
ip default-gateway 11.11.11.1
!
clock timezone UTC
!
ntp server 11.11.11.1
!
username admin password hash someencryptedpassword role admin
!
service sshd
!
password-policy
lower-case-required
upper-case-required
digit-required
no-username
disable-cisco-passwords
min-password-length 6
!
logging localhost
logging loglevel 6
!
cdp timer 60
cdp holdtime 180
cdp run GigabitEthernet 0
!
icmp echo on
!

Now let’s stop the ACS application:

acs52/admin#
acs52/admin# application stop acs

Stopping ACS.
Stopping Management and View…………………..
Stopping Runtime……
Stopping Database….
Cleanup…..

acs52/admin#

Then we start it:

acs52/admin#
acs52/admin# application start acs

Starting ACS ….

To verify that ACS processes are running, use the
‘show application status acs’ command.

acs52/admin#

After a while we should get a running status for all components:

acs52/admin#
acs52/admin# show application status acs

ACS role: PRIMARY

Process ‘database’                  running
Process ‘management’                running
Process ‘runtime’                   running
Process ‘view-database’             running
Process ‘view-jobmanager’           running
Process ‘view-alertmanager’         running
Process ‘view-collector’            running
Process ‘view-logprocessor’         running

acs52/admin#

And let’s not forget to save our config:

acs52/admin#
acs52/admin# copy running-config startup-config
Generating configuration…
acs52/admin#

Once again, we don’t need to do these steps if we use a fresh installation of the ACS server.

Let’s now create a network device and an user in the ACS so we can do a testing. We know how to do that, but we want this tutorial to be complete. First we create a router as a Network Device:

acs R1 setup 1

And a test user:

acs user setup 1

Now we can power on and setup our router. This is the basic configuration which allows us to telnet to the router and be authenticated against our ACS server:

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$bWzG$pmg7R1HI85Spod00SXUn.0
!
aaa new-model
!
!
aaa authentication login default group radius
aaa authentication login CONSOLE none
!
!
aaa session-id common
memory-size iomem 5
ip cef
!
ip domain name popravak.local
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
multilink bundle-name authenticated
!
!
archive
log config
hidekeys
!
!
interface FastEthernet0/0
ip address 11.11.11.3 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
!
radius-server host 11.11.11.2 auth-port 1645 acct-port 1646 key spop123
!
control-plane
!
!
line con 0
logging synchronous
login authentication CONSOLE
line aux 0
line vty 0 4
!
end

What is important about this configuration is the IP address of the interface connected to the VMware world. It has to be from the 11.11.11.0/24 segment. If we take a look to the GNS3 topology, we can see that our laptop has the IP address of 11.11.11.1/24, the ACS has 11.11.11.2/24 and our router has 11.11.11.3/24. This way all parties can communicate with each other.

Now we can telnet from our laptop to the router and try to authenticate against the RADIUS server:

telnet login 2

And finally, let’s verify our login attempt on the ACS server:

auth log 2

So, we are good 🙂

One thing is left to be done. Our bridge interface configuration on which our lab depends will *not* survive the reboot of the Linux box. So we need to find a way of make these changes persistent across reboots. We could do that several ways. One of which is editing a “/etc/rc.local” file. We can place our bridge setup related commands in this file. So it could look like this:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will “exit 0” on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

tunctl -t tap11
ifconfig tap11 0.0.0.0 promisc up
ifconfig vmnet11 0.0.0.0 promisc up

brctl addbr br11
brctl addif br11 tap11
brctl addif br11 vmnet11

ifconfig br11 11.11.11.1 netmask 255.255.255.0 up

exit 0

Now our lab will continue to work event after our Linux host reboots.

Thanks for reading and happy learning!

Advertisements
This entry was posted in ACS 5.x, Cisco, GNS3, LINUX, Virtualization, VMWare and tagged , , , , , . Bookmark the permalink.

2 Responses to Connecting VMware Workstation and Cisco GNS3 Lab – Linux Edition

  1. Mikica says:

    greate job!

  2. Pingback: Spanning Tree Protocol (STP) on Linux with GNS3 and VMware | popravak

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s