GNS3 on Fedora


GNS3 is based on Dynamips and Dynagen (a text-based front-end for Dynamips) to create a complex virtual Cisco networks, adding many additional features and most  importantly making it easy to create, change and save your network topologies. It was also extended for Qemu virtualizer/emulator and VirtualBox support.

Reference
http://www.gns3.net/

In next few steps we will show how to install GNS3 and other additional software such as Dynamips, Qemu, VirtualBox and cpulimit on Fedora Linux.

1.  Dynamips

Dynamips is a software that emulates Cisco IOS on a traditional PC. It has been made by Christophe Fillot who started his work in August 2005. Dynamips Linux binaries for x86/x86-64 architecture can be downloaded from GNS3 website:

http://www.gns3.net/dynamips/

Once you download it copy Dynamips  to /usr/local/bin.

sudo cp ~/Downloads/dynamips-0.2.8-RC3-community-x86_64.bin /usr/local/bin

Assign run privilegies to the binary with following command.

chmod +x /usr/local/bin/dynamips-0.2.8-RC3-community-x86_64.bin

If you wish to compile Dynamips by your own in order to  achieve better performance,  here is my tutorial.

http://brezular.wordpress.com/2011/03/14/dynamips-0-2-8-rc3-installation-from-source-on-linux-fedora/

Reference:
http://en.wikipedia.org/wiki/Dynamips

2. VirtualBox

VirtualBox is a powerful x86 and AMD64/Intel64 virtualization product for enterprise as well as home use. The following guide helps you to download and install the latest VirtualBox from repository. It also shows how to configure GNS3 for VirtualBox support.

http://brezular.wordpress.com/2011/08/02/virtualbox-0-4-1-installation-and-configuration-for-gns3-0-8-0-on-fedora-15-linux/

Reference
https://www.virtualbox.org/

3.  Qemu

QEMU is a generic and open source machine emulator and virtualizer. Qemu compilation and installation on Fedora is explained here in detail.

http://brezular.wordpress.com/2012/02/12/installation-solaris-sparc-2-6-sunos-5-6-on-qemu-part-1-qemu-installation/

Reference
http://wiki.qemu.org/Main_Page

4.  Kernel Based Virtual Machine KVM

KVM (for Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). A tutorial describing kvm installation on Fedora is here.

http://brezular.wordpress.com/2012/11/07/%EF%BB%BFkvm-installation-on-fedora/

Reference
http://www.linux-kvm.org/page/Main_Page

5.  CPU limit

Cpulimit is a simple program which attempts to limit the cpu usage of a process (expressed in percentage, not in cpu time).

a) Install git-core package

yum install git-core

b) Get the last pulimit from git and compile it

cd ~/Downloads
git clone https://github.com/opsengine/cpulimit.git

cd ~/Downloads/cpulimit

Compile source and copy binary to /usr/local/bin.

make
sudo cp ./src/cpulimit /usr/local/bin

Reference
http://cpulimit.sourceforge.net/

6.  GNS3

Finally, download and extract GNS3.

wget http://sourceforge.net/projects/gns-3/files/GNS3/0.8.3.1/GNS3-0.8.3.1-src.tar.bz2 -P ~/Downloads/

cd ~/Downloads/
tar jxvf GNS3-0.8.3.1-src.tar.bz2

If you want to connect GNS3 device to the real network you have to run GNS3 as root:

sudo ~/Downloads/GNS3-0.8.3.1-src/gns3

GNS3 Qemu Troubleshooting


Many GNS3 users use Qemu emulator to run various network OS installed on Qemu images – for example Olive, ASA, Vyatta and many others. Some users complain about not having a network connections between these devices or a console window appears and disappears  after the short time. In both cases Qemu hosts are not started properly and Qemu images don’t work.

This issues are typically caused by entering a wrong parameter in GNS3 setting.  For instance  when user checks a box “Use kvm” in GNS3 settings and CPU doesn’t support kvm or kvm is not enabled in BIOS, it ends with warning message “unknown parameter kvm” and Qemu image is not started. Please remember that  kvm is not supported by Windows so you shouldn’t have  “Use kvm” checked if GNS3 is installed on Windows.

Another issue mainly occurs on Linux and Mac OS and it is caused by using unpatched Qemu binary. GNS3 create UDP tunnels in order to make connection between Qemu devices  and that is why  Qemu source have to be patched for UDP tunnels, compiled and installed by user. Although many Linux distributions already have Qemu installed in /usr/bin/ directory, this version of Qemu is unlikely to be patched for UDP tunnels. For this reason the Qemu doesn’t understand parameter -net type udp and it is halted after its start.

As long as patched Qemu binary is included in GNS3 all-in-one package, the Windows users  don’t need to patch, compile and install Qemu by themselves.

Except of the wrong parameters I have already mentioned there can be another problems which  prevent Qemu  starting successfully.  If you find Qemu difficult to start you should consider to do following troubleshooting to find out the reasons why Qemu doesn’t work.

1/ Start qemuwrapper.py script from Linux terminal console.  The script is located in a in  the GNS3 root directory, in the directory ./qemuwrapper

sudo /home/brezular/Download/GNS3-files/GNS3/Stable/GNS3-0.7.3-src/qemuwrapper/qemuwrapper.py

Qemu Emulator Wrapper (version 0.7.3)
Copyright (c) 2007-2010 Thomas Pani & Jeremy Grossmann

Unpacking pemu binary.
Qemu TCP control server started (port 10525).
Listenning on all network interfaces

The script has started Qemuwrapper server on TCP port 10525.

2/ Start GNS3 application

Create a new blank project and save it. Drug two Qemu hosts or Junipers from left panel and drop them in to the GNS3 Desktop (Figure 1). You should see a warning message – Qemu is already running on port 10525, it will not be shutdown after you quit GNS3.  It simply means that GNS3 has tried to start Qemu wrapper server on TCP port 10525 but another Qemuwrapper server is running on this port. We started it by ourselves with qemuwrapper script.

It is time to make connection between nodes . Connect them with Ethernet link and  start both Qemu hosts.

Figure 1. Qemu hosts connected through e0 interfaces

3/ Check the output of qemuwrapper script in console window. It should look like this:

Qemu path is now /usr/bin/qemu
Qemu-img path is now /usr/bin/qemu-img
!! QEMU1.console = 3000
!! QEMU1.netcard = e1000
!! QEMU1.image = /home/brezular/Download/GNS3-files/PC/Microcore/Stable/Host/3.4/linux-microcore-3.4.img
!! QEMU1.ram = 48
!! QEMU1.options = -no-acpi -nographic
!! QEMU2.console = 3001
!! QEMU2.netcard = e1000
!! QEMU2.image = /home/brezular/Download/GNS3-files/PC/Microcore/Stable/Host/3.4/linux-microcore-3.4.img
!! QEMU2.ram = 48
!! QEMU2.options = -no-acpi -nographic
command: ['/usr/bin/qemu', '-name', 'QEMU1', '-m', '48', '/tmp/QEMU1/FLASH', '-hdb', '/tmp/QEMU1/SWAP', '-net', 'nic,vlan=0,macaddr=00:aa:00:18:6c:00,model=e1000', '-net', 'udp,vlan=0,sport=20003,dport=20002,daddr=127.0.0.1','-net', 'nic,vlan=1,macaddr=00:00:ab:da:3d:01,model=e1000', '-net', 'nic,vlan=2,macaddr=00:00:ab:c3:46:02,model=e1000', '-net', 'nic,vlan=3,macaddr=00:00:ab:e9:c9:03,model=e1000', '-net', 'nic,vlan=4,macaddr=00:00:ab:77:f1:04,model=e1000', '-net', 'nic,vlan=5,macaddr=00:00:ab:f2:3c:05,model=e1000', '-serial', 'telnet::3000,server,nowait', '-no-acpi', '-nographic']
Invalid -net type ‘udp’
pid: 30268
Renicing to 19
30268: old priority 0, new priority 19
command: ['/usr/bin/qemu', '-name', 'QEMU2', '-m', '48', '/tmp/QEMU2/FLASH', '-hdb', '/tmp/QEMU2/SWAP', '-net', 'nic,vlan=0,macaddr=00:aa:00:98:21:00,model=e1000', '-net', 'udp,vlan=0,sport=20002,dport=20003,daddr=127.0.0.1', '-net', 'nic,vlan=1,macaddr=00:00:ab:09:1d:01,model=e1000', '-net', 'nic,vlan=2,macaddr=00:00:ab:26:50:02,model=e1000', '-net', 'nic,vlan=3,macaddr=00:00:ab:25:86:03,model=e1000', '-net', 'nic,vlan=4,macaddr=00:00:ab:6d:a3:04,model=e1000', '-net', 'nic,vlan=5,macaddr=00:00:ab:53:34:05,model=e1000', '-serial', 'telnet::3001,server,nowait', '-no-acpi', '-nographic']
Invalid -net type ‘udp’
pid: 30367
Renicing to 19
30367: old priority 0, new priority 19

The green lines refer to Qemu1 device. They are several parameters there such as RAM , console port, netcard type and path to  the base image. Please, notice QEMU1.options  parameters – no-acpi and -nographic.  If you have any problems with Qemu it is probably a good idea to leave this Qemu option box blank in GNS3 setting. Likewise blue lines refer to QEMU2 device.

As you can see from Figure 1 QEMU1 and QEMU2 are connected together via their eth0 interfaces.  They both use UDP tunnels for traffic transferred between them – QEMU1 sends all the traffic destined for QEMU2 to IP address 127.0.0.1,  destination UDP port 20002. QEMU2 is listening to traffic from QEMU1 on its source UDP port 20002. Likewise QEMU2 sends traffic destined for QEMU1 to IP address 127.0.0.1, destination UDP port 20003 and QEMU1 is listening to traffic from QEMU2 on its source port 20003.

If the Qemu had been properly patched for UDP tunnels a network connection would have been working between Qemu hosts.  For this demonstration  unpatched qemu binary in /usr/bin/ directory is used thus Qemu is stopped with  an error message Invalid -net type ‘udp’. If I edit .net file and set qemu path to /usr/local/bin/qemu ,  hosts will be started correctly because version of Qemu located in /usr/local/bin/ directory  is patched for UDP tunnels.

4/ Conclusion

You should have now a brief  idea of Qemu  troubleshooting for GNS3.  At least you know how to get an output of qemuwrapper and post it on GNS3 forum.  More about Qemu patching is on GNS3 blog:

http://blog.gns3.net/2009/10/olive-juniper/2/

In addition to stable UDP and multicast patch which is available for download in GNS3 Download section there is continuously  updated  patch for almost each new Qemu version in the  GNS3 Development section.  As I wrote Windows users don’t need to patch source by themselves due to the fact that GNS3 all-in-one package contains patched Qemu version.

GNS3: How to run multiple Qemu instances in Windows


Hi,

I created video in which I showed how to run multiple Qemu instances in  GNS3 installed on Windows.  There is a bug in Qemu, installed on Widows  which prevents you to run more than one Qemu instance. This video is mainly for Windows users because bug is presented only in Windows OS. Copying base image to the directory where FLASH is not properly created  and its renaming to FLASH is workaround for this bug.

Linux users need to set only Qemu General setting and Qemu Host setting table and they can run multiple Qemu instances without any tricks.

There is also Qemu – General Setting and Host setting configuration showed in this video.  Vyatta, LiSA (Linux l3 switch) and Microcore Linux should be configured in GNS3 Qemu Host Table.

JunOS configuration is similar to Qemu Host configuration  but it is done in JunOS table (not showed in this video).

You should consider RAM requirements for JunOS, Vyatta and LiSA.  RAM 48MB is enough for small Microcore  image but you need minimum 128 MB for those three Qemu images.

You can download a video from here:

http://www.4shared.com/video/8JmJRYQI/multiple-qemu-instances.html

Follow

Get every new post delivered to your Inbox.

Join 61 other followers