Five Quirks I Noticed in GNS3 - A Begginers Guide

Greeting from Kailua Kona, Hawaii! I haven't used GNS3 in a few years. When I decided to use GNS3 as a study tool for my CCNA Security exam, I found some features didn't perform expected. In this post, I wanted to highlight some unexpected problems and lessons learned during my studies using GNS3.

1. Connecting anything other than a Dynamips device to a Cloud

The GNS3 cloud device is used to bridge a connect between your physical and virtual GNS3 equipment. The cloud can also be used for connecting to a remote GNS3 lab or even virtual machines using hypervisors other than VirtualBox. When designing my physical/virtual topology, one thing I  immediately noticed is that you could not directly connect a cloud to a qemu based device (Juniper Router, Cisco ASA, Cisco PIX, Cisco IDS) or a virtual box host to a NIO Ethernet cloud. In fact, doing so produces the following dynamips error message:

"Device does not support this type of NIO. Use an ETHSQ or hub to bridge the connection to the NIO instead."

This is a dynamips generated error message. My take is that dynamips is being used to bridge the connection between the physical NIC on the host machine to the qemu based device (which is essentially a virtual machine using the qemu wrapper). As a result, dynamips cannot detect the type of interface on the other end of the connection. This problem is mitigated by using an EtherSwitch or a GNS3 switch or hub device to bridge the connection between a non dynamips based device and a GNS3 cloud. I constructed the following connection guide to illustrate how this works.

 

 

  2. The Command "copy run start" is not Enough

 

Don't get me wrong, you should always issue this command to commit changes to the startup config. Omitting this important command in any lab simulation during the CCNA or CCNA Security will be a huge detriment to your overall score. However, expecting changes to the startup config to remain in GNS3 using the command "copy run start" will leave you sorely disappointed. I found this out after a half hour of aggravation.

 

Cisco routers and their file systems are emulated using Dynamips in GNS3. This is important to note because when a virtual dynamips router is powered down, in GNS3, the filesystem goes bye bye. As a result, issuing the command "copy run start" by itself will not allow any changes to remain on the next boot. To be certain configuration changes will persist, you must issue "copy run start" in the IOS command line and then navigate to the "File" dropdown menu of GNS3 and click either "Save project" or "Save project as...". Make sure to tick the following option when you save.

• Save nvrams and virtual hard drives

If these options are not enabled when saving a project then any changes made to the startup config will not persist during the next boot. When enabled and the project is saved, the startup configurations are exported and saved to local disk. These files are then imported by dynamips when the virtual router is powered back on. Just as a quick recap:

 

1.  Issue "copy run start"
2. Navigate to the "File" dropdown menu in GNS3 and click either "Save project" or "Save project as..."
1. Check the following options:
1. Save nvrams and virtual hard drives

This will save you the frustration of having to copy and paste your config back into the command line each time your virtual routers boot.

3. Cannot Modify the flash: Filesystem of dynamips (Cisco) Devices

This problem I ran into when trying to upload an IPS signature for Cisco IOS IPS. If you issue a "?" from privileged exec mode you will notice the command "mkdir" for creating a new directory is not present. The installation of an IPS signature file requires one to upload the sig file to a new directory in flash memory using tftp or by another file transfer protocol.

I tested this on the following devices:

2961
3745
7200

On the 2961 and 3745 the mkdir command is not initially supported. Trying to format the flash: filesystem produces the following error:

"%Error formatting flash: (No device available)"

In order to make changes to the flash file system, you must first issue an "erase flash:" to reinitialize flash: and then issue "format flash:" to reformat the file system. This is demonstrated below.

R1#erase flash:

Erasing the flash filesystem will remove all files! Continue? [confirm]

Current DOS File System flash card in flash: will be formatted into Low End File System flash card!  Continue? [confirm]

Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased

Erase of flash: complete

R1#format flash:
Format operation may take a while. Continue? [confirm]
Format operation will destroy all data in "flash:".  Continue? [confirm]
Current Low End File System flash card in flash: will be formatted into DOS File System flash card!  Continue? [confirm]
Primary Partition created...Size 16 MB
Drive communication & 1st Sector Write OK...
Writing Monlib sectors....
Monlib write complete
Format: All system sectors written. OK...
Format: Total sectors in formatted partition: 32736
Format: Total bytes in formatted partition: 16760832
Format: Operation completed successfully.
Format of flash: complete
R1#mkdir flash:ipsdir
Create directory filename [ipsdir]?
Created dir flash:/ipsdir
R1#sho flash:
-#- --length-- -----date/time------ path
1            0 Mar 01 2002 00:14:14 ipsdir
16564224 bytes available (2048 bytes used)

Oddly enough, the 7200 series router supports the "mkdir" command from the get go. However, trying to create a directory in flash: or view the flash card file system produces the following results:

R3#mkdir flash:ipsdir
Create directory filename [ipsdir]?
%Filesystem does not support mkdir operations
R3#sho flash:
Open device slot0 failed (Bad device info block)

This tells me that dynamips has a problem emulating the PCMIA card in the router and the flash: filesystem keeps corrupting itself. Trying to reformat the flash: file system also produces the following result:

R3#format flash:
Format operation may take a while. Continue? [confirm]
Format operation will destroy all data in "flash:".  Continue? [confirm]
Enter volume ID (up to 64 chars)[default slot0:]:
%Error formatting slot0: (Can not find flash algorithm)

Entering "erase ?" does not reveal an option for erasing flash: or slot0: which is also the PCMIA card (sometimes may also be disk0:). Ultimately, to fix the problem on the 7200 you have to issue "format disk0:".

The moral of the story is to always reinitialize the flash card and reformat the file system when creating a new router instance. Dynamips has problems emulating PCMIA flash card memory. Some potential workarounds are to try different IOS versions or a different series of router entirely. As a final note, I did not encounter this problem on ASA 8.4(2) which tells me this problem is specific to dynamips devices and not qemu based devices (ASA,PIX,IDS,Juniper).

4. Some IOS Commands Cause the Virtual Router Instance to Crash

In the end, there is no substitute for having access to a real rack of equipment. Emulation is never perfect, there will always be some feature that doesn't perform as expected. In my studies, I found that IOS resiliency features are not supported at all. Issuing a "secure boot-image" or "secure boot-config" causes dynamips to crash. As a result, you will have to restart your host machine for the virtual router instance to work again.

Another thing I learned is never to issue "reload" from the command line. Doing so causes dynamips to bug out and continually tries to start and close itself again. This results in a console window that will not respond because the device is continually trying to reboot itself. Always use the "Reload all devices" button or right click the virtual router and "Reload" (remember to copy run start and save the GNS3 project for configuration changes to persist). This problem was not present on the ASA.

5. Qemu Based Devices (Juniper, PIX, ASA, IDS) Take a Long Time to Boot

Another lesson learned is that devices virtualized under Qemu take a very long time to boot (7-8 minutes). If you install JunOS olives or Cisco IDS .iso to say something like VMware, the boot time is substantially reduced. Likewise, the same is true if you have access to a Virtual Adaptive Security Appliance image through a CCO account. Using VMware to virtualize some appliances yields a substantially less time to boot (1-2 minutes instead of 7-8). This is by no means is a deal breaker. If so, there are many guides out there that describe how to virtualize these devices in VMware. In a subsequent post, I will describe how to get JunOS and Cisco IDS up and running in GNS3 and possibly in VMware.