GNS3 1.2.1 installation on Ubuntu 14.04

As mentioned in an earlier post GNS3 is moving ahead fast. Currently at version 1.2.1 the GNS3 is looking great. Compared with the version 1.0 Beta 1 which I had installed, the 1.2.1 is not only more stable, but it has the Menu more clean and compact. For example now there is only one Preferences menu where you can adjust all your settings.

During the installation of 1.0 Beta 1 I made some notes in Evernote and it prove to be very useful as the installation was pretty messy. With 1.2.1 I did the same thing, but the installation was very smooth. Still, I said that if I made those notes maybe I should share them for those interested in a quick installation. A more complete guide can be found on GNS3 Community.

1. Download GNS3 1.2.1

Head over to, create and account and download the bundle archive for Linux.

If you for some reason you don’t want to create an account, you may download each package individually from

The following lines will assume that you have the bundle archive.

2. Install Ubuntu 14.04 dependencies

3. Unzip the bundle archive

You should see 5 packages in GNS3-1.2.1 folder:

4. Install Dynamips

To check if the correct version is install:

You should see in the output 0.2.14

5. Install GNS3 Server

To check if the GNS3 Server is installed correctly:

If you see some output other than an error, than you’re fine.

6. Install GNS3 GUI

To test if the installation is working:

You should see a graphical interface of GNS3 launched.

At this moment you have a working GNS3 environment if you want only want to test Cisco hardware emulators. I strongly recommend to continue and install also the rest of the components. Who knows when you’ll need them

7. Install IOUyap (Optional, if you will use IOU images)

To test the installation:

If you encounter an error, please check the [Update 1] section at the bottom of this article.

8. Install VPCS (Optional, if you want to use VirtualPC)

For the third line, the 64 represent 64bit, as my Ubuntu 14.04 is build on 64bit.
The values can be:
– 32 or i386 for 32bit OS
– 64 or amd64 for 64bit OS

Please be sure to use the correct one for your OS.

To test the VPCS:

You should see a Virtual PC being launched. Leave the console with letter q.

9. Install VirtualBox (Optional, if you want to launch VMs)

Download the correct version for your system from The following lines will assume an Ubuntu 14.04 64bit OS.

You can also use the instructions at and go for an APT installation.The choice is yours.

10. Install Qemu (Optional, if you want to use qemu images)

11. Install IOU (Optional, if you want to use IOU images)

I’m not a legal matter expert, and the usage of IOU is sort of grey area. Because of this, I’m not going to cover this chapter.

You’re ready to go. Start the GNS3 GUI:

Some things to check before going live:

  • check in the menu Edit > Preferences to set your desired Paths (in General sections) and to check the paths for the binaries (dynamips, vpcs, iou, virtualbox…)
  • add the IOS, virtualbox vm, iou images
  • in case of Cisco hardware emulators don’t forget to find the IdlePC value (when you add the IOS image or later with the start of your first router with a certain image) otherwise your CPUs will cry.

If something does not work as described or you need help please let me know in Comments.

[Update 1]

If you get the following error during installation of iouyap:

Try to install the iniparser as follows:


and finally iouyap

Thanks to mweisel @ for this update!

Cisco BGP soft-reconfiguration and received-routes relation

A while ago I received the following question:

“Why I’m not seeing the prefixes received from the BGP peer when using the show ip bgp neighbors x.x.x.x received-routes while the soft-reconfiguration inbound is not enabled?”

I must admit that I had to stop and think for a second before giving my response.

Simple BGP

For the above diagram I have a simple BGP configuration:

Focus is on the secondary router. I’m trying to see what prefixes I receive from my BGP neighbor, so I rapidly hit the following command:

OK, that’s not good. Am I missing the command? Let’s see:

-> received-routes – Display the received routes from neighbor

OK, I know the soft-reconfiguration inbound is not enabled, but what has this to do with the fact that the command is not showing me what routes I receive from BGP neighbor?

Let’s recall what “soft-reconfiguration inbound” command actually does.

BGP soft-reconfiguration inbound
*Cisco BGP-4 Command and Configuration Handbook

According to the above explanation, if you have an inbound policy (like a route-map) applied to a BGP neighbor and you change that policy, you need to clear the BGP session before it take effect. This is the procedure without having “soft-reconfiguration inbound” configured. I remember it like this and most of the network engineers out there remember this behavior associated with the “soft-reconfiguration inbound” command.

Still, I just want to see what routes I received from BGP neighbor and according with “sh ip bgp neighbors received-routes” description is the right command . I have no inbound policy on R2 for R1 BGP neighbor.

A less remembered fact about the “soft-reconfiguration inbound” command is that when added, the router begins to store updates from the specified neighbor. These updates are unmodified by any existing inbound policies so that the router can correctly apply the new policies when soft reconfiguration is triggered.

Where are these updates stored?

In the BGP Adj-RIB-in (Adjacent Routing Information Base, Incoming) table. So, what the “received-routes” command does actually is looking in the BGP Adj-RIB-in table for the received routes from the BGP neighbor. I consider that the “received-routes” command has an ambiguous explanation leading to confusion.

When “soft-reconfiguration inbound” is not present, the BGP router does not store anything in Adj-RIB-in. Rather it process the update and discard the Adj-RIB-in table, but not before adding the information in the Loc-RIB (Local Routing Information Base) table. Knowing these facts of course the BGP router returns an error when trying to check the received prefixes using the “received-routes” command.

To check actually what’s received from BGP peer and stored in the Loc-RIB (after being processed by inbound policies) use only the “routes” parameter in the command:

-> routes – Display routes learned from neighbor

The output is what exists in the Loc-RIB table, after processed by the inbound policy.

Let me show you an example of the above explanation.

I’ll apply the “soft-reconfiguration inbound” first:

Now I’ll check again the received routes:

OK, so I have three prefixes, reflected in the Adj-RIB-in table.
Checking next the Loc-RIB tables (so the routes installed after being processed by inbound policies):

The Adj-RIB-in and Loc-RIB tables are identical.

Now, I’ll apply an inbound policy that will filter the prefix.

OK, we have the “soft-reconfiguration inbound” in place, so the inbound policies should be applied automatically denying the prefix.

The above output is what we receive from BGP peer. Notice that the prefix is still there, in the Adj-RIB-in table, as the inbound policies are not applied yet. The only visible change is the missing > sign (best).

Now we can see that the inbound policy is working fine as the prefix is not installed in the Loc-RIB table. This is also the explanation why the > (best) sign was missing from the prefix in Adj-RIB-in.

I hope you understood the logic behind the confusion which these commands “received-routes” and “routes” and their explanation in IOS is creates.

Please let me know in Comments if you have any questions.

Cisco switches and smartport macros

Smartport macros are not more than some templates you can define on Cisco switches that will apply the same configuration on multiple ports. It’s not a subject that needs too many discussions, but it can be useful for your Cisco certification preparation or real life Cisco switch administration.

Configuration is very simple and it goes something like this:

After this you apply the macro to a port or a range of ports:

That’s it :)

A less known fact is that Cisco switches are having some predefined smartport macros, which can be really helpful. The smartport macros which you configure can be spotted with a simple “show running-config” command. This is not the case for the default smartport macros which cannot be seen in the running-config, so you may not be aware that they exist.

The default smartport macros can be seen using the following commands:

This will show you only a summary of the default smartport macros. If you want to see what are they configure to do, check the following command:

To be honest I never used them like this, but they were a pretty good starting point to customize new smartport macros.

If you are rather interested in the Cisco switch interface macro command, I did write a post on this topic some years ago and you can read it here.

Cisco STP forward-time command trick

This is more a topic for exams, like Cisco CCIE, but also it can appear in real-world environments.

Consider the following simple topology:
Simple L2 topology

SW1 is the spanning-tree root bridge for all VLANs. Imagine that you have a request which ask you that when a port becomes active, no matter of VLAN, it should wait 10 seconds until it transition to forwarding state.

You look into configuration mode and spot the “spanning-tree .. forward-time..” command. OK, simple enough, you go there and type:

Task completed. This is what I also thought. Looks pretty straight forward, but it’s a mistake which I learned from and I hope you will read this before doing it.
Lucky for me it was just a test lab not the real CCIE lab, but if I don’t teach this kind of things or spend the entire day fine-tuning STP, I tend to forget.

Back to this example, let’s see on the SW2 what’s happening after I did configure the above command on SW1. By the way, you need to configure this command only on the STP root bridge because the downstream devices will inherit the values.

On the SW2 I shutdown the root interface to force the alternate interface (which is in blocking state) to transition to forward state and check the output of “debug spanning-tree events” :

From :15 seconds when the port entered Listening state until :35 seconds when it went into Forwarding state there are 20 seconds. We were required to have 10 seconds not 20. That’s not good.

Going back and checking the parameters of a STP for a particular VLAN did not give me too much information to clarify the issue:

OK, after reading again carefully the documentation I came to the understanding that value added to this command is applied to each state towards the forwarding state.
The STP Port States are: Blocking, Listening, Learning, Forwarding and Disabled.

When I did shutdown the root port, the alternate port when immediately to Listening state then waited for 10 seconds until it transition to Learning state and again 10 Seconds to achieve Forwarding state.

The correct solution was obvious now to decrease the forward-time to 5 seconds.

Let’s check again:

Now the total time is 10 second.

I hope this will help others to avoid my mistakes.

EtherChannel over 802.1q Tunneling

Consider the following topology:
EtherChannel over 802.1q Tunneling Topology

We have one Customer with two distributed locations (SW1, R1 and SW2, R2) connected over Provider backbone. What we want to create is something like this:

EtherChannel over Provider L2 cloud

If Provider support 802.1q and L2 tunneling we can achieve a nice Etherchannel between our 2 remote locations with direct CDP visibility. Also STP and VTP is supported, just like when these SW1 and SW2 switches are directly connected.

First, lets configure SW1 and SW2 Customer devices.

On the three interfaces connected to provider devices we want to configure LACP Etherchannel:

SW1 / SW2 Customer

Next we will configure the SW1 and SW2 ports connected to R1 and R2 devices:

SW1 / SW2 Customer

Of course another approach can be taken in terms of VTP, like having Server / Client configuration, but this was the simplest one to illustrate here.

Let’s add some IP addresses on the two routers R1 and R2:

R1 Customer

R2 Customer

Our job, as Customer, is done. What about the Provider configuration? Here is where “the magic” happens.

To provide our Customer with three end to end 802.1q tunnels, we need to create three VLANs, assign them to the interfaces pointing to Customer SW1 and SW2 and enable the 802.1q tunnels.

SW1 / SW2 Provider

Of course SW1 and SW2 from Provider should have 802.1q trunk enable and allow the tranport of VLANs 10, 20 and 30:

SW1 / SW2 Provider

OK, we have the dot1q tunneling enabled now:

SW1 / SW2 Provider

Still, the Customer wants Etherchannel functionality, CDP visibility and the ability to transport own VLAN information (remember we did configure Vlan 100 on the interface of SW1 / SW2 Customer pointing to R1 / R2). Let’s enable also these ones:

SW1 / SW2 Provider

Perfect, now let’s do some “show” commands to see that everything is working.

SW1 / SW2 Customer

OK, the Etherchannel is UP and the STP is showing correct values. Let’s see if we can do a simple “ping” from R1 to R2

The Customer is happy, but what about the Provider, what does it see on the L2 infrastructure?

SW1 / SW2 Provider

So, the Provider has no idea about Vlan 100 used by the Customer. This is because STP BPDUs from SW1 / SW2 Customer are tunneled inside dot1q-tunnel and hidden by the metro tags 10, 20 and 30.

One note for real life example, the Provider needs to support at least MTU 1504 so that Customer does not deal with packet fragmentation.