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:
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:
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:~# 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.
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:~# apt-get install uml-utilities
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following NEW packages will be installed:
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.
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:~# tunctl -t tap11
Set ‘tap11’ persistent and owned by uid 0
Now we will strip off IP addresses from both interfaces and bring them up:
root@pop-deb:~# ifconfig tap11 0.0.0.0 promisc up
root@pop-deb:~# ifconfig vmnet11 0.0.0.0 promisc up
OK, we have both sides of the bridge ready, now let’s build a bridge to cross the river 🙂
root@pop-deb:~# brctl addbr br11
root@pop-deb:~# brctl addif br11 tap11
root@pop-deb:~# brctl addif br11 vmnet11
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:~# ifconfig br11 18.104.22.168 netmask 255.255.255.0 up
root@pop-deb:~# ifconfig br11
br11 Link encap:Ethernet HWaddr 00:50:56:c0:00:0b
inet addr:22.214.171.124 Bcast:126.96.36.199 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
RX bytes:0 (0.0 B) TX bytes:8217 (8.0 KiB)
Finally, we try to ping this adapter’s address:
root@pop-deb:~# ping -c 5 188.8.131.52
PING 184.108.40.206 (220.127.116.11) 56(84) bytes of data.
64 bytes from 18.104.22.168: icmp_req=1 ttl=64 time=0.059 ms
64 bytes from 22.214.171.124: icmp_req=2 ttl=64 time=0.058 ms
64 bytes from 126.96.36.199: icmp_req=3 ttl=64 time=0.060 ms
64 bytes from 188.8.131.52: icmp_req=4 ttl=64 time=0.062 ms
64 bytes from 184.108.40.206: icmp_req=5 ttl=64 time=0.060 ms
— 220.127.116.11 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
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:
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:
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:
ip domain-name popravak.local
interface GigabitEthernet 0
ip address 18.104.22.168 255.255.255.0
ip name-server 22.214.171.124
ip default-gateway 126.96.36.199
clock timezone UTC
ntp server 188.8.131.52
username admin password hash someencryptedpassword role admin
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# application stop acs
Stopping Management and View…………………..
Then we start it:
acs52/admin# application start acs
Starting ACS ….
To verify that ACS processes are running, use the
‘show application status acs’ command.
After a while we should get a running status for all components:
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
And let’s not forget to save our config:
acs52/admin# copy running-config startup-config
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:
And a test user:
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:
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
enable secret 5 $1$bWzG$pmg7R1HI85Spod00SXUn.0
aaa authentication login default group radius
aaa authentication login CONSOLE none
aaa session-id common
memory-size iomem 5
ip domain name popravak.local
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
multilink bundle-name authenticated
ip address 184.108.40.206 255.255.255.0
no ip address
ip forward-protocol nd
ip http server
no ip http secure-server
radius-server host 220.127.116.11 auth-port 1645 acct-port 1646 key spop123
line con 0
login authentication CONSOLE
line aux 0
line vty 0 4
What is important about this configuration is the IP address of the interface connected to the VMware world. It has to be from the 18.104.22.168/24 segment. If we take a look to the GNS3 topology, we can see that our laptop has the IP address of 22.214.171.124/24, the ACS has 126.96.36.199/24 and our router has 188.8.131.52/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:
And finally, let’s verify our login attempt on the ACS server:
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:
# 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
# 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 184.108.40.206 netmask 255.255.255.0 up
Now our lab will continue to work event after our Linux host reboots.
Thanks for reading and happy learning!