GNS3 vs. IOU poll - who won?

I have been running a poll on the site to determine whether people would prefer the next volume (Multicast and QoS) to be designed for IOU or, like the previous three volumes, for GNS3.

At the start, IOU steamed ahead, but then GNS3 started to catch up.

The poll has now closed. We had 67 people take part. The end result?

IOU won by a large margin.

If it had won by any more, then the pie chart would look like Pacman.

So the book will be designed for...
UNetLab.

Here's why.

1. On the basis that if people are using IOU, then they will have probably heard of UNetLab.
2. If people have IOU images in IOU, they can be used in UNetLab.
3. UNetLab offers support for more systems then IOU, therefore we can have a Linux VM and PROPERLY test multicast AND QoS.

The thing about Multicast (and QoS) that it is hard, in a closed environment such as IOU, or even when you are restricted to just using routers and switches, is that you have to take output as an indication of whether something is working or not. If you could actually see a multicast stream, i.e. a video file playing on VLC, then it's easier to see cause and effect.

UNetLab will allow for a nicer book, we'll be able to see video being multicasted, and also implement QoS restrictions on this as well, rather than just seeing an ICMP response. 

It'll be fun, as networking should be.

Poll: Volume 4 - GNS3 or IOU?

So far GNS3 seems to have been working well for the first three volumes, but I feel like I should ask whether, for volume 4, a move to IOU (IOU-Web to be exact) would be preferred.

There are a couple of reasons that would make switching to IOU a good idea.

• IOU is very popular with many studying for the CCIE
• There would be a common platform - it would make life easier when moving between different OSes. 
• It would also allow for a nicer experience with clickable pictures. 
• I could use "proper" switches (though if you are running GNS3 with IOU integration, you can use IOU switch images as well). The new volume will use a couple of switches (as will version 5).
• The IOS images used would be more recent (but again, see the point above about GNS3/IOU integration
• IOU is closer to the actual exam environment, than GNS3 is. 

I have added a poll on the right-hand side, where you can vote for your preference.

Let me know your thoughts in the comments section below.

MPLS for Cisco Networks now available!

It's been a long ride. Finally, though, it's finished and being published.

MPLS for Cisco Networks is here!

So what has changed and what's stayed the same?

The format is the same. We have one main topology, it grows and changes as we cover all the topics on both the official CCIE v5 blueprint, and also the INE expanded blueprint. There are smaller, sub-contained, topologies where appropriate. We now have a longer troubleshooting section, with one topology and seven different tickets.

The biggest difference is that we have an editor for this one. Beau emailed me, asking would I like him to edit the second volume (after he read the first one). At first I was a little unsure. The BGP volume was my baby, in a way, and would you let a complete stranger look after your baby? Well, its not like handing over my children, and his credentials looked good (ex-Teacher, Network engineer - so what more could I want!). I do not regret taking the chance and asking him to join me. Together we have created, in my opinion, an excellent book. He's been juggling parenthood, work and being a husband, with hours and hours (and hours) of correcting my grammar, making sentences shorter and more concise. If I gave a penny to my children for every time he's had to add a comma, they'd be rich by now! Seriously, I cannot say enough how he turned the book around. It's far more readable. My sentences do have a tendency to be a little long, it's all to do with how it comes out of my head as I am working through it. So when you are reading it, and you pause for breath in a paragraph, you can thank him! It's not just the grammar though, he's been through the topology with such dedication. It's been excellent to have another pair of eyes on it. He must be a glutton for punishment though, as he's agreed to do number 3 as well!

We have more pictures. This does influence the size (for Kindle), and has meant that printing costs (as well as the fact that its much longer) have increased. It is slightly more expensive than the BGP book, but still very reasonable. I am not out to make a fortune from these, I am doing it because I enjoy it.

We are still using GNS3. It's probably the most familiar to people, but IOU topologies will follow in due course.
In all, I am more pleased with this one than the BGP book. In hind-sight I think I rushed the BGP book. I never expected it to ever be as popular as it has been. When I published on Kindle (not even thinking at that stage it would appear in printed format), I said to my wife that if a couple of people enjoyed it, then it would be worth it. I am still very proud of it, nonetheless. It's a learning process, not just in the material, but in how to write. It will become a more honed process as I write more. I hope I have listened to all of the requests that have come in (apart from one, which, I think, was just asking me to write it exactly like an O'Reilly book - still not sure of that conversation, I was very confused).

I hope you enjoy it.

Sneak peek at volume 2

It is not quite ready yet, it's still being proofed by my technical editor, but I thought I would get a proof copy or two so that I can make sure formatting is right  and that the pictures are coming out properly.

I must say I am pleased so far. So, want a sneak peak?

Here you go!

As you can see it has become a much longer book than the BGP volume! We have many more pictures for a start. 

It's still based around GNS3 and IOU topologies will follow. 

I am very excited by this latest volume. 

Work on volume 3 is already underway. 

What do people use the most for their CCIE studies?

I have been running a poll on the site for a while now, to get a feel for what people are using for the practical part of their CCIE studies. The results are in, and thank you to those who have taken part in the poll.

Here are the results in reverse order, and if you don't want to do the reading then skip to the end where there is a pie chart.

CCIE on VMWare

1% of respondents are using VMWare. VMWare is a great platform, but, historically, not ideally suited to the CCIE. This has started to change somewhat, as the CSR 1000v router works well on it, but, then there is the costs associated with using this platform, if you are running 10 routers then you are going to need 32GB of ram, running 20 you'll need 64GB ram, and this is all on the basis that you have a machine to hand that can run VMWare. Not a surprising result.

CCIE on Real Hardware

8% of you have either a very accommodating employer, or a lot of cash to drop. I did go down this route, and got all the hardware a couple of weeks before the V5 was announced and all my routers (barring the 18xx series) became pretty much obsolete. But there are a number of you lucky enough to have the full hardware based experience! Lucky you, really there is nothing like the real thing.

CCIE on IOU

25% of people are using IOU. IOU is great for many reasons, firstly the version level supported is much closer to the one used in the exam, it's free (yay!), and you can run a large topology inside a VM with very little memory overhead. The downside is that it is harder to get into, those without any Linux experience may be put off, and designing your own topologies does take some getting used to, It works great, but isn't for the faint-hearted.

Real switches + IOU or GNS3 or VMWare

25% have opted to use real switches and a virtualised environment. This setup does make the most sense, as all the virtualised environments have issues when it comes to layer 2 technologies. The switches can be bought (on eBay) for a few hundred (pounds), and as the routing functions work great in virtual environments it eliminates the chances of errors due to a layer 2 feature not being supported, or, if supported, not working as it should (I am looking at you HSRP!). There are some downsides to this setup, mainly the cost, portability and space concerns, but it does offer the best of both worlds.

CCIE on GNS3

36% of people are using GNS3. It has been around for years, and it making huge waves as it progresses from the 0.8 version that we have known and loved for ages to this all-encompassing vital tool, allowing you to run VirtualBox VMs, connect to IOU and to real hardware, if you don't want to do that then it runs 7200 series routers (which support IOS 15) very well. It is of no surprise then, that GNS3 is the tool of choice for the aspiring CCIE. The downsides of GNS3? Not many really, it does have a propensity to make your CPU run hot, but playing around with idle PC values can mitigate that, and you are limited by the amount of memory you have if you are running native GNS3 routers.

Final thoughts

The lines in this poll are slightly blurred though as some may be using real hardware and GNS3, or real hardware and IOU, for instance, which really does push their numbers up, but it does give a good indication as to what people are using.

Whatever platform you choose, I wish you all the very best in your studies.

BGP book topology updated for GNS3 1.0! MPLS book coming soon!

BGP for Cisco Networks & GNS3 1.0

I had a request hit my inbox last month for the topology for my book "BGP for Cisco Networks" to be updated for GNS3 1.0.

I must confess that with trying to finish off "MPLS for Cisco Networks", which is looking great and should be out soon(ish), I didn't do this very quickly.

But thanks to a great guy called Dan over at GNS3 and his nifty python based converter I have been able to do this in under half an hour.

So thanks Dan!

If you are currently using GNS3 1.0 and want to load up the topology, its available in the Downloads section.

MPLS for Cisco Networks

The MPLS book is taking a lot longer than the first, for a number of reasons.

I had a pretty good grounding in BGP when I started, but not so much with MPLS, and MPLS feels like such a bigger subject, the book is certainly longer if that's anything to go by!

I have learnt some things from the first book, mainly due to the comments made by my readers, so there will be more diagrams, more configurations, and hopefully a sense of being part of the book, rather than just a reader... That last bit should make more sense when you read it.

I am just finishing off a couple of bits; VPLS, OTV, IPv6 for VRF-Lite, and need to do the troubleshooting chapter - which is all planned out, and then its a matter of proofing, sending over to my technical ed, and then publishing!

Again topologies will be available in GNS3 0.8 first, with GNS31.0 and ViRL (whenever that eventually turns up) at a later stage.

Cisco CSR1000v - Part 2: Connecting to GNS3

Following on from part one where we downloaded and installed the CSR1000v router in VirtualBox, it would be great if we can use it in GNS3. We can do thanks to GNS3s integration with VirtualBox.

 I have switched from my 4GB Windows laptop to my 32GB Mac now (we'll see why later on), but the steps are all the same.

Fire up GNS3 and head into the preferences. Firstly make sure that GNS3 can talk to VirtualBox, the details should already be configured for you, so click on "Test Settings", and hopefully you should get the green OK message as shown below:

If thats all good then head into the VirtualBox Guest tab. Click on "Refresh VM List", and then hopefully you'll be able to select your VirtualBox VM from the VM List above:

Give it a name and click on "Save"

Then click on OK to return to the main screen.

Click on the "End Devices" icon on the left hand side, it looks like a PC. In there will be a VirtualBox guest icon, which you can drag onto your topology, and you'll see a prompt to select a VirtualBox guest to use:

Once you select the CSR1000v VM and press OK you'll see it on the topology. Personally I like to change the icon to something more router looking. Before we fire it up we need to make a couple of minor edits. Firstly right click on the router and select "Configure", then select the router.

If "Reserve first NIC for VirtualBox NAT to host OS" is ticked, then untick it, and make sure that "Enable console support" is ticked:

Click ok, and now switch it on. The router light in the topology window should turn green. Give it a few moments and you should be ready to rock:

You can connect the CSR1000v to native GNS3 routers, and the two will communicate happily:

If you try an add another CSR1000v router though you will find that you cant. You can only have as many instances from VirtualBox running as there are instances, so in order to have two CSR1000v routers running in GNS3, we'll need to have two CSR1000v VMs in VirtualBox.

Shut down your existing router for the moment, and back over in VirtualBox, select the CSR1000v VM and right click on it, and then select "Clone".

A new window should pop up, and you can give it a new name, and reinitialize the MAC addresses of the cards (if you want).

Choose "Full Clone", and then click on "Clone".

Repeat this as many times as you want to have as many routers as you need. Remember though that each router takes about 2.5GB of memory, so memory can be used up pretty quickly running CSR1000v routers! This is why I switched to a more powerful machine!

Once you have created as many VMs as you need head back into GNS3. We'll need to rescan the VirtualBox VM list for it to be picked up, but this is just the same as following the first couple of steps we did to get the first CSR into GNS3. You can also choose to untick the "reserve" button here and tick the console button, then save the VM:

You can then add it to GNS3 and start connecting your topology up:

At the moment with a few normal apps running and the above routers memory and CPU usage is quite low:

With enough memory you could run a whole stack of CSR1000v routers and have them play happily together. Fun, fun, fun!

GNS3 1.0 goes beta

GNS3 1.0 is now in beta. It's been fun watching the alpha, which was a complete redesign from the ground up, grow and expand, and now we have hit the beta stages.

So what's the difference in the beta, vs the alpha?

Initially it doesn't look like much has changed on the interface front since the initial alpha, so let's dig a little deeper.

The change log shows the following:

Change Log for Beta 1 of V1.0

The GNS3 all-in-one installer automatically installs a 32-bit or 64-bit version of GNS3.
Base VirtualBox support (still some issues, most of them on Linux and Mac OS X).
Prevent users to set the port and VLAN settings to 0 on Ethernet swithes.
Fixed issue when spaces are in capture file paths.
Fixed bug with live capture on Windows.
Work around for the c7200 reload bug in Dynamips <= 0.2.13.
Fixed some inconsistencies when exporting configs.
The early release dialog is gone! 

What's on the menu?

The menu has some cool new things on it, such as "Cloud" and "VirtualBox"

Its all about the Cloud these days

We have an option for "Cloud". But if you try and copy the link for "Create Cloud Account" you'll find that it doesn't go anywhere just yet. The only provider listed is Rackspace and they are pretty solid so it should be interesting.

Woo hoo VirtualBox!

VirtualBox is back, kind of. The menu items are all there:

But it doesn't work just yet:

I couldn't find any vboxwrapper files in the GNS3.app, so I thought I would give it a go myself:

I started by doing a git clone of the vboxwrapper files (you'll need xcode installed to run git):

Stuarts-MacBook-Air:~ stu$ sudo git clone https://github.com/GNS3/vboxwrapper
Cloning into 'vboxwrapper'...
remote: Reusing existing pack: 15, done.
remote: Total 15 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (15/15), done.
Checking connectivity... done.
Stuarts-MacBook-Air:~ stu$ cd vboxwrapper/

Next we need to run the setup:

Stuarts-MacBook-Air:vboxwrapper stu$ sudo python setup.py install
running install
running bdist_egg
running egg_info
creating vboxwrapper.egg-info
writing vboxwrapper.egg-info/PKG-INFO
writing top-level names to vboxwrapper.egg-info/top_level.txt
writing dependency_links to vboxwrapper.egg-info/dependency_links.txt
writing entry points to vboxwrapper.egg-info/entry_points.txt
writing manifest file 'vboxwrapper.egg-info/SOURCES.txt'
reading manifest file 'vboxwrapper.egg-info/SOURCES.txt'
writing manifest file 'vboxwrapper.egg-info/SOURCES.txt'
installing library code to build/bdist.macosx-10.9-intel/egg
running install_lib
warning: install_lib: 'build/lib' does not exist -- no Python modules to install

creating build
creating build/bdist.macosx-10.9-intel
creating build/bdist.macosx-10.9-intel/egg
creating build/bdist.macosx-10.9-intel/egg/EGG-INFO
copying vboxwrapper.egg-info/PKG-INFO -> build/bdist.macosx-10.9-intel/egg/EGG-INFO
copying vboxwrapper.egg-info/SOURCES.txt -> build/bdist.macosx-10.9-intel/egg/EGG-INFO
copying vboxwrapper.egg-info/dependency_links.txt -> build/bdist.macosx-10.9-intel/egg/EGG-INFO
copying vboxwrapper.egg-info/entry_points.txt -> build/bdist.macosx-10.9-intel/egg/EGG-INFO
copying vboxwrapper.egg-info/top_level.txt -> build/bdist.macosx-10.9-intel/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
creating dist
creating 'dist/vboxwrapper-0.9-py2.7.egg' and adding 'build/bdist.macosx-10.9-intel/egg' to it
removing 'build/bdist.macosx-10.9-intel/egg' (and everything under it)
Processing vboxwrapper-0.9-py2.7.egg
Removing /Library/Python/2.7/site-packages/vboxwrapper-0.9-py2.7.egg
Copying vboxwrapper-0.9-py2.7.egg to /Library/Python/2.7/site-packages
vboxwrapper 0.9 is already the active version in easy-install.pth
Installing vboxwrapper script to /usr/local/bin

Installed /Library/Python/2.7/site-packages/vboxwrapper-0.9-py2.7.egg
Processing dependencies for vboxwrapper==0.9
Finished processing dependencies for vboxwrapper==0.9

So can we now run the finished file?

Stuarts-MacBook-Air:vboxwrapper stu$ python /usr/local/bin/vboxwrapper 
Traceback (most recent call last):
  File "/usr/local/bin/vboxwrapper", line 8, in 
    load_entry_point('vboxwrapper==0.9', 'console_scripts', 'vboxwrapper')()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 318, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2221, in load_entry_point
    return ep.load()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
ImportError: No module named vboxwrapper

Nope, so let's make sure that things are installed properly:

Stuarts-MacBook-Air:vboxwrapper stu$ python
Python 2.7.5 (default, Mar  9 2014, 22:15:05) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from vboxapi import VirtualBoxManager
>>> g_vboxManager = VirtualBoxManager(None, None)
>>> print g_vboxManager.vbox.revision
91406
>>> exit()

At this stage I found the link that's mentioned below, so started to try those steps out:

Stuarts-MacBook-Air:vboxwrapper stu$ cd ~/Downloads/
Stuarts-MacBook-Air:Downloads stu$ cd vboxwrapper/
Stuarts-MacBook-Air:vboxwrapper stu$ ls
LICENSE   build   setup.py  vboxcontroller_4_3.py vboxwrapper.py
README.md  dist   tcp_pipe_proxy.py vboxwrapper.egg-info
Stuarts-MacBook-Air:vboxwrapper stu$ sudo cp vboxwrapper.py tcp_pipe_proxy.py vboxcontroller_4_3.py /Library/Python/2.7/site-packages/
Password:

So can we start the wrapper now?

Stuarts-MacBook-Air:vboxwrapper stu$ python vboxwrapper.py 
VirtualBox Wrapper (version 0.9)
Copyright (c) 2007-2014
Jeremy Grossmann and Alexey Eromenko
Using VirtualBox 4.3.6 r91406
VBoxWrapper TCP control server started (port 11525).
Listening on all network interfaces

Yes! We can! Let's try setting the vboxwrapper location to the new file and see what happens:

Balls, I still get the same error:

So with the new beta we can see a lot of features on the horizon, every so slightly out of reach, but hopefully, and given the speed at which the GNS3 guys are pushing out the updates, it won't take long for VirtualBox to be working again. I'd love to connect up some CSR1000v routers to some IOU routers and I am sure that this is just around the corner, yet in some ways though it's also very frustrating to be teased like this.

It's important to remember that this is still beta, so things may be limited in functionality, or missing completely. There are reports of getting virtualbox running on the new beta over on the forums, but that looks to be for Linux, and probably done by someone who has more of a clue about python than I do!

GNS3 1.0 Alpha 7 is out - labels are back!

It feels like ages since the last alpha release of GNS3 1.0. But its certainly been worth the wait.

What's new in GNS3 1.0 Alpha 7 

Packet capture for IOS routers.
Packet capture for the Ethernet hub and Ethernet, ATM and Frame relay switches.
Packet capture for IOU (not working, issue with iouyap).

Every one loves a good packet capture. Being able to do packet captures is an integral part of every engineers toolkit - as for that matter is GNS3! :)

Right click a link, select "Start capture", and wireshark fires up. This does seem much quicker than on the 0.8.6 release.

The link in the Topology Summary pane then changes to show a magnifying glass, signifying that there is a packet capture happening. It would be nice though to be able to set up packet capture straight from the Topology Summary menu.

Add notes, rectangles & ellipses to topologies.
Duplicate option for notes, rectangles and ellipses.
Style settings for note, rectangle and ellipse items. Possibility to edit interface and node labels.

It's a small thing really, but I have missed the ability to add notes, it does make things much easer to understand when you have labels!

Show/hide interface labels.

Same as above really, it does make life much easier to be able to turn this on and off at will!

Contextual device menu.

You can get the same menu by right clicking, but it is useful to have it in more than one place.

Recent file menu.

This is on the old 0.8.6:

This is the new version:

Not sure which version I prefer really.

Lab instructions support (automatically open any file named instructions.* in the project directory or from the Help menu)

Just add any file called instructions to the project folder and open the project, it'll open up in the appropriate program:

Load a project by dropping the project file on the view.

Pretty cool, means it is quick to jump from topology to topology. It is fast and responsive.

Option to uncompress IOS images.

Makes booting router a little quicker.

Other stuff:

Fix: use Dynamips, IOU and VPCS identifiers to correctly load topologies.
IOU: rename startup-config to initial-config (makes more sense for IOU).
Check for sticky bit when checking for executable access.
Fix: IOS image relative path problems.
Lots of small bug fixes.

Building a CCIE home lab using breakout switch and GNS3 - Part 1

I am starting to get myself ready for the Narbik course in a few months time. I have brought all my routers and switches home from work and now the routers are sitting in the garage and the switches are racked and ready. I am using a 12u desktop rack which was a good price at just over £30 from Amazon.co.uk, you can get the same rack in the USA for just under $50.

I did realise though that now the v5 has replaced the v4 all my routers are redundant. I will still be able to find a use for the 1841s, but as far as the others go, they are just space fillers in the garage. But it also means that I need to use GNS3 and a breakout switch to connect to the real switches.

This also meant having to buy another switch, so there is a space to fill in between the 3560 and the cable management bit. I am also still waiting for the rack ears for the top 3550 to arrive. The rack ears for the 3550 arrived a few moments ago and now the switch is sitting properly in the rack.  The ASA is just for fun, and I need a couple of crossover cables for the 3550s.

So now comes the fun part, making the GNS3 topology and connecting it from my iMac to the real switches.

Narbik's foundation guides are designed to start bridging the gap between the CCNP and CCIE, so that when you go to his class you are ready to hit the ground running. The foundation guides (there are two parts) run to around 800+ pages, and are based around a singular topology. And this is what I have come up with so far:

The routers are all connected to SW1, which is just there to carry the vlan traffic, and will pass it through to the 3750 breakout switch, which in turn will pass it down to the 3560, which will be switch 1 on Narbik's topology. There are other switches as well, which will also connect to the real switches (SW2, SW3 and SW4).

Connecting GNS3 to a breakout switch

Connecting to a switch is pretty easy in GNS3, just drag over a cloud icon, right click and select configure. Once you are there select the first tab and connect it to the relevant ethernet interface.I changed the icon on mine to a nice layer 3 switch icon

With that all done and the first couple of routers fired up we can check for basic connectivity:

R1#sh int fa 0/0 | i line|address
FastEthernet0/0 is up, line protocol is up
  Hardware is i82543 (Livengood), address is ca09.0443.0008 (bia ca09.0443.0008)
R1#

R2#sh int fa 0/0 | i line|address
FastEthernet0/0 is up, line protocol is up
  Hardware is i82543 (Livengood), address is ca06.0442.0008 (bia ca06.0442.0008)
R2#

So we have both lines up that connect us to the real network, let's see if we can see them on the breakout switch:

Breakout#sh mac-address-table int fa1/0/48
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
   1    10dd.b1b3.6ba6    DYNAMIC     Fa1/0/48
   1    ca06.0442.0008    DYNAMIC     Fa1/0/48
   1    ca09.0443.0008    DYNAMIC     Fa1/0/48
Total Mac Addresses for this criterion: 3
Breakout#sh cdp neigh fa 1/0/48
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone

Device ID            Local Intrfce         Holdtme   Capability    Platform   Port ID
R2                  Fas 1/0/48            135             R       7206VXR   Fas 0/0
R1                  Fas 1/0/48            157             R       7206VXR   Fas 0/0
Breakout#

No problems there! But what we actually need is for them to be connected to SW1.

The first (proper) task on the Narbik workbook is to put both R1 and R2 in VLAN 12 and make sure that they can ping each other.

SW1(config)#vlan 12
SW1(config-vlan)#exit
SW1(config)#int ra f0/1-2
SW1(config-if-range)#switchport mode access
SW1(config-if-range)#switchport access vlan 12
SW1(config-if-range)#no shut

R1(config)#int fa 0/0
R1(config-if)#ip address 12.1.1.1 255.255.255.0
R1(config-if)#end
R1#

R2(config)#int fa 0/0
R2(config-if)#ip add 12.1.1.2 255.255.255.0
R2(config-if)#

R1#ping 12.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#

We know that the interfaces are up because they are in the MAC address table on the breakout switch. There is a great article over at gns3.net about how to set this up, and the original article from which it is based is also well worth a look. Following these guides I got a bit further:

Breakout(config)#int fa 1/0/1
Breakout(config-if)#desc Down to SW1 f0/1
Breakout(config-if)#switchport access vlan 12
Breakout(config-if)#switchport mode dot1q-tunnel
Breakout(config-if)#l2protocol-tunnel cdp
Breakout(config-if)#l2protocol-tunnel stp
Breakout(config-if)#l2protocol-tunnel vtp
Breakout(config-if)#no cdp enable
Breakout(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
 host. Connecting hubs, concentrators, switches, bridges, etc... to this
 interface  when portfast is enabled, can cause temporary bridging loops.
 Use with CAUTION

%Portfast has been configured on FastEthernet1/0/1 but will only
 have effect when the interface is in a non-trunking mode.
Breakout(config-if)#int fa 1/0/2
Breakout(config-if)#desc Down to SW1 f0/2
Breakout(config-if)#switchport access vlan 12
Breakout(config-if)#switchport mode dot1q-tunnel
Breakout(config-if)#l2protocol-tunnel cdp
Breakout(config-if)#l2protocol-tunnel stp
Breakout(config-if)#l2protocol-tunnel vtp
Breakout(config-if)#no cdp enable
Breakout(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
 host. Connecting hubs, concentrators, switches, bridges, etc... to this
 interface  when portfast is enabled, can cause temporary bridging loops.
 Use with CAUTION

%Portfast has been configured on FastEthernet1/0/2 but will only
 have effect when the interface is in a non-trunking mode.
Breakout(config-if)#int fa 1/0/48
Breakout(config-if)#desc Uplink to iMac
Breakout(config-if)#switchport trunk encap dot1q
Breakout(config-if)#l2protocol-tunnel cdp
Breakout(config-if)#l2protocol-tunnel stp
Breakout(config-if)#l2protocol-tunnel vtp
Breakout(config-if)#no cdp enable
Breakout(config-if)#spanning-tree portfast

Now things look a bit better:

R1#sh cdp neigh | beg Device
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
SW1              Fas 0/0            176             S I   WS-C3560- Fas 0/2
SW1              Fas 0/0            163             S I   WS-C3560- Fas 0/1
R2               Fas 0/0            169              R    7206VXR   Fas 0/0
R1               Fas 0/0            159              R    7206VXR   Fas 0/0
R1#

R2#sh cdp neigh | beg Device
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
SW1              Fas 0/0            150             S I   WS-C3560- Fas 0/2
SW1              Fas 0/0            138             S I   WS-C3560- Fas 0/1
R2               Fas 0/0            143              R    7206VXR   Fas 0/0
R1               Fas 0/0            133              R    7206VXR   Fas 0/0
R2#

We are getting double entries though, and a ping from R1 to R2 still does not work. Hmmm.... Well let's double check our configuration, starting with our virtual switch:

 

That's all fine, we have the correct ports in the correct vlan. Let's check the physical switch:

SW1#sh run int fa0/1
Building configuration...

Current configuration : 84 bytes
!
interface FastEthernet0/1
 switchport access vlan 12
 switchport mode access
end

SW1#sh run int fa0/2
Building configuration...

Current configuration : 122 bytes
!
interface FastEthernet0/2
 switchport access vlan 12
 switchport trunk encapsulation dot1q
 switchport mode access
end

Looks like we have a lingering remnant from previous work... Let's get rid of that and see what happens:

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#int fa 0/2
SW1(config-if)#no switchport trunk encapsulation dot1q
SW1(config-if)#end
SW1#

R1#ping 12.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/18/24 ms
R1#

R2#ping 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/27/44 ms
R2#

Hurrah!

So far so good. I still need to get the second switch racked and cabled, it's waiting for me back at the office, I also need to sort out the USB NICs, or re-do part of the topology. Switches 2, 3 and 4 on the GNS3 topology either need to connect to SW1, and then to the breakout switch, or have separate USB connections to separate "clouds". I have the USB nics (Dynamode USB-NIC-1427-100) but my iMac doesn't seem to want to play ball with them, the lights all flash and look impressive blinking away as they do, but I cant seem to get them recognized as an ethernet interface yet.

Nevertheless it's all off to a good start, and we can save the rest for part two, when I figure out how to finish it off!

If you have any suggestions then please do comment.

GNS3 1.0 Alpha 6 - Mac OS X support is back!

GNS3 1.0 Alpha 6 is out today and with it is native Mac OS X support!

The full list of changes in the latest alpha release is:

• Mac OS X DMG package (Only tested on OSX Mavericks).
• New host names management.
• New project dialog (in preparation for cloud support).
• Logs saved to files (GNS3_client.log and GNS3_server.log).
• Relative paths support for IOS/IOU images in project files. Fixed decoding errors when reading device configs.
• Fixed privileged access checks for IOU.
• Fixed validation issue with c2600 XM chassis.
• Fixed VPCS start on Linux/UNIX. Fixed Ethernet hub when loading a project.

And here we are running the new version, natively on my Macbook Air:

It runs perfectly fine on my Macbook Air, but I do think that this machine is a bit underpowered for running anything intensive, with just the below set up my fan sounds like a small engine trying to take off!

With a medium sized topology my CPU is pretty maxed out.

The routers are all running natively in GNS3 though, if I were to harness the new ability of GNS3 1.0 to work with IOU then I could offload the running of the routers to a more suitable server, and leave all the fun stuff (GUI and configuration) to run on my laptop. The original GNS3 runs great on my iMac though, and it's nice to have a native version of the new alpha release.

GNS3 1.0 Alpha 5!

It seems like it was just a couple of days ago that GNS3 1.0 Alpha 4 came out, and already the team at GNS3 are back with another new update.

What's new in GNS3 1.0 Alpha 5?

• VPCS support (only version >= 0.5b1, available on https://github.com/GNS3/vpcs/releases)
• Fixed console port errors when loading a project.
• Fixed startup-config errors when loading a project.
• Fixed minor issues on Mac OS X (DMG file coming soon).
• IOU default startup-configs for layer 2 and layer 3 images. Allowing for faster loading times too.
• Option to prevent starting the local server when opening the GUI.
• Prevent devices to be started, stopped or suspended if their status is not right
• More checks for cloud connections.
• Show item coordinates in the status bar.
• Amend device configs (hostname) when renaming.
• UDP connection checks.

So some cool stuff here, especially the Virtual PC Simulator support, and more hints that the Mac OSX version is about to drop imminently. I am certainly looking forward to the Mac OSX version, hopefully the separation of gui from workload (i.e. IOU) will mean that my Macbook Air fans wont sound like that are about to send my laptop into the air like an aeroplane. I won't be switching to it on my iMac just yet as I need the current version for writing my next book.

Things are moving along at a pretty rapid pace over at GNS3 HQ, they are making great strides! Well done guys!

GNS3 1.0 Alpha 4!

GNS3 1.0 Alpha 4 is out today, coming in a week or so before the next bank holiday in the UK. I am sure that the bank holiday releases are just a coincidence, unless the developers are really keen on celebrating the "International Day of Families" (yeah I don't know what it's about either - alternatively it could be released in celebration of Paraguay's Independence Day).

So anyway, enough about random world wide holiday talk, let's have a look at what's new (and fixed):

Whats new in GNS3 1.0 Alpha 4?

Now we have the following changes:

• Show Windows interface names in cloud tooltips.
• Disconnect the server if the version differs from the GUI version.
• Move cloud code to a builtin module and support for clouds on remote servers.
• Options to use the default IOU RAM & NVRAM values.
• Changed the name of default base startup and private configs.
• Added “All files” filter when looking for an IOU or IOS image in the file broswer.
• Graceful server shutdown on Windows.
• Error message that JIT sharing is only supported in Dynamips unstable.
• New UDP and console port allocation system for IOU. Fixes duplicated port issues.
• Delete some Dynamips files that are useless to save in projects.
• Fix: the path to GNS3 server was not saved.
• Fix: RAM and NVRAM IOU image settings not propagated when creating an IOU device.
• Fix: bug where IOS nvram/disk files were not kept after closing a topology.
• Fix: bug that prevented changing any IOU device setting when connected to another node.
• Fix: duplicated node id issue.
• Fix: major bug with ghost instance overwriting any second router files (R2).
• Fix: error when ldd cannot be found.
• Fix: issues with local base configs for IOS.

Some pretty cool stuff here, especially the third item - "support for clouds on remote servers", this isn't to say that we can have multiple IOU servers sitting out there, it's close, very close, but not there just yet:

So close!

Still no sign of the ability to add text to topologies though. I do miss that.

HSRP, Cisco Emulation software and ASICs

I wrote sometime back about how to implement HSRP using Cisco IOU and in GNS3, but it has been pointed out that even though it might look like it works, in fact it's actually a little more hit and miss, with some people having issues, such as not being able to ping the Virtual IP address configured on the HSRP standby group - check out the comments to follow the reference, hopefully you'll understand why I am writing this subsequent post.

A recap on HSRP

HSRP (Hot Standby Routing Protocol) allows you to set up the same SVI (Switched Virtual Interface) on a pair of switches so that you have some redundancy, in the event that one switch is unavailable then the virtual IP address assigned to the standby group will still be available. The virtual IP address is given the same MAC address, which is a combination of the well-known HSRP MAC address (0000:0c07:ac) and the standby group number (in our case this is 10, which is 0a in hexadecimal).

HSRP is Cisco specific, other vendors user the industry standard of VRRP (Virtual Router Redundancy Protocol), there is also GLBP (Gateway Load Balancing Protocol) for routers.

We will be using two different versions of GNS3 for this, the first is the publicly available 0.8.6 version, because that can still use qemu, which means that we can use the IOSv images to try this out on, as well as the image c3660-is-mz.124.25b referenced in the first article. If you haven't checked out how to get the IOSv images from onePK into GNS3 then you might want to have a quick read of it.

So the goals for this post are to prove that we can get HSRP working between two devices. One should show up as the active and one as the standby, and we should be able to ping the virtual IP assigned to the HSRP group. As per the original post we need to create a multi-layer switch to enable the required functions, this still holds true today, so do have a read over the original article.

For each example we will have an HSRP group, number 10, one switch will use the IP address 10.10.1.2/24, the other will use 10.10.1.3/24 and they will have a virtual IP address of 10.10.1.1. The HSRP MAC address will be 0000.0c07.ac0a, so this is what we will be looking for in our ARP table.

Let's check out GNS3 first.

HSRP using native GNS3

Once we have set up our multi-layer switch in GNS3, the configurational steps for our first switch are as follows:

R4#vlan database
R4(vlan)#vlan 10
VLAN 10 added:
    Name: VLAN0010
R4(vlan)#exit
APPLY completed.
Exiting....   
*Mar  1 00:00:35.719: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int vlan 10
R4(config-if)#ip add 10.10.1.2 255.255.255.0
R4(config-if)#standby 10 ip 10.10.1.1
R4(config-if)#standby 10 pri 150
R4(config-if)#standby 10 preem del min 60
R4(config-if)#no shut
R4(config-if)#int fa 1/10
R4(config-if)#switchport mode trunk
*Mar  1 00:02:00.087: %DTP-5-TRUNKPORTON: Port Fa1/10 has become dot1q trunk
*Mar  1 00:02:00.563: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
R4(config-if)#no shut
R4(config-if)#
*Mar  1 00:02:30.687: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
*Mar  1 00:02:30.695: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up
R4(config-if)#
*Mar  1 00:02:51.699: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Speak -> Standby
*Mar  1 00:02:52.199: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Standby -> Active
R4(config-if)#exit
R4(config)#exit
R4#
*Mar  1 00:03:34.879: %SYS-5-CONFIG_I: Configured from console by console
R4#

So far our first device is looking healthy for HSRP. The second switch is very similar:

R5#vlan database
R5(vlan)#vlan 10
VLAN 10 added:
    Name: VLAN0010
R5(vlan)#exit
APPLY completed.
Exiting....
R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#int fa1/10
R5(config-if)#switchport mode trunk
*Mar  1 00:02:45.687: %DTP-5-TRUNKPORTON: Port Fa1/10 has become dot1q trunk
*Mar  1 00:02:46.159: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
R5(config-if)#no shut
R5(config-if)#exit
R5(config)#int vlan 10
R5(config-if)#
*Mar  1 00:02:53.711: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up
R5(config-if)#ip add 10.10.1.3 255.255.255.0
R5(config-if)#standby 10 ip 10.10.1.1
R5(config-if)#standby 10 pri 90
R5(config-if)#
*Mar  1 00:03:16.291: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
R5(config-if)#
*Mar  1 00:03:40.299: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Speak -> Standby
R5(config-if)#

With our trunk setup to carry the VLAN information, as well as the HSRP multicast, we should be able to check that everything is in order. Using the command "sh standby vlan" with the vlan number we can check the HSRP settings and status. Let's check to see if we have everything we are hoping for, including the correct ARP entries and making sure that the interfaces are pingable:

R4#sh standby vlan 10
Vlan10 - Group 10
  State is Active
    2 state changes, last state change 00:03:19
  Virtual IP address is 10.10.1.1
  Active virtual MAC address is 0000.0c07.ac0a
    Local virtual MAC address is 0000.0c07.ac0a (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.724 secs
  Preemption enabled, delay min 60 secs
  Active router is local
  Standby router is 10.10.1.3, priority 90 (expires in 7.344 sec)
  Priority 150 (configured 150)
  IP redundancy name is "hsrp-Vl10-10" (default)
R4#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.1.1               -   0000.0c07.ac0a  ARPA   Vlan10
Internet  10.10.1.2               -   cc04.38a1.0000  ARPA   Vlan10
R4#ping 10.10.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R4#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.1.1               -   0000.0c07.ac0a  ARPA   Vlan10
Internet  10.10.1.3               0   cc05.38a1.0000  ARPA   Vlan10
Internet  10.10.1.2               -   cc04.38a1.0000  ARPA   Vlan10
R4#

R5#sh standby vlan 10
Vlan10 - Group 10
  State is Standby
    1 state change, last state change 00:03:22
  Virtual IP address is 10.10.1.1
  Active virtual MAC address is 0000.0c07.ac0a
    Local virtual MAC address is 0000.0c07.ac0a (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.992 secs
  Preemption disabled
  Active router is 10.10.1.2, priority 150 (expires in 7.376 sec)
  Standby router is local
  Priority 90 (configured 90)
  IP redundancy name is "hsrp-Vl10-10" (default)
R5#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.1.3               -   cc05.38a1.0000  ARPA   Vlan10
R5#ping 10.10.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/21/24 ms
R5#ping 10.10.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/21/24 ms
R5#sh arp        
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.1.1               0   0000.0c07.ac0a  ARPA   Vlan10
Internet  10.10.1.3               -   cc05.38a1.0000  ARPA   Vlan10
Internet  10.10.1.2               0   cc04.38a1.0000  ARPA   Vlan10
R5#

So arp looks good and we can ping the Virtual IP address for the standby group, with no problems here. Let's check out HSRP on IOU next.

HSRP using IOU

With the same configuration (apart from the priority of 150 on the first device) as before running on the IOU routers do we have the same level of visibility?

Switch#sh standby vlan 10
Vlan10 - Group 10
  State is Active
    2 state changes, last state change 00:00:34
  Virtual IP address is 10.10.1.1
  Active virtual MAC address is 0000.0c07.ac0a (MAC In Use)
    Local virtual MAC address is 0000.0c07.ac0a (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.984 secs
  Preemption enabled, delay min 60 secs
  Active router is local
  Standby router is 10.10.1.3, priority 90 (expires in 9.904 sec)
  Priority 100 (default 100)
  Group name is "hsrp-Vl10-10" (default)
Switch#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.1.1               -   0000.0c07.ac0a  ARPA   Vlan10
Internet  10.10.1.2               -   aabb.cc80.0100  ARPA   Vlan10
Internet  10.10.1.3               0   aabb.cc80.0200  ARPA   Vlan10
Switch#ping 10.10.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms
Switch#sh ver | i IOS
Cisco IOS Software, Solaris Software (I86BI_LINUXL2-IPBASEK9-M), Experimental Version 15.1(20130124:233217) [dstivers-jan24-2013-team_track 101]
Switch#sh ip int bri     
Interface              IP-Address      OK? Method Status                Protocol
Ethernet0/0            unassigned      YES unset  up                    up      
Ethernet0/1            unassigned      YES unset  up                    up      
Ethernet0/2            unassigned      YES unset  up                    up      
Ethernet0/3            unassigned      YES unset  up                    up      
Vlan10                 10.10.1.2       YES manual up                    up      
Switch#

Switch2#sh standby vlan 10
Vlan10 - Group 10
  State is Standby
    1 state change, last state change 00:00:29
  Virtual IP address is 10.10.1.1
  Active virtual MAC address is 0000.0c07.ac0a (MAC Not In Use)
    Local virtual MAC address is 0000.0c07.ac0a (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.912 secs
  Preemption disabled
  Active router is 10.10.1.2, priority 100 (expires in 9.696 sec)
  Standby router is local
  Priority 90 (configured 90)
  Group name is "hsrp-Vl10-10" (default)
Switch2#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.1.3               -   aabb.cc80.0200  ARPA   Vlan10
Switch2#ping 10.10.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
Switch2#ping 10.10.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
Switch2#sh ver | i IOS
Cisco IOS Software, Solaris Software (I86BI_LINUXL2-IPBASEK9-M), Experimental Version 15.1(20130124:233217) [dstivers-jan24-2013-team_track 101]
Switch2#

Again arp looks good and we can ping the virtual IP address again.

EDIT:-

It just goes to show that image is everything. As Maureen (in the comments below) has pointed out whilst following this blog and my posts about HSRP, nothing is 100% guaranteed when using a virtualized environment.

If you try adding a guest to the mix then it probably won't be able to ping the standby address, and if you do, it probably won't last. I will go into it in more depth in my post about IOU Images and functions.

Finally lets check out IOSv.

HSRP using IOSv on GNS3

HSRP is slightly different on IOSv, there are no vlan commands, and instead everything is performed under the interface, so technically it's not enabling redundancy for a vlan, it's enabling it for the interface, but the principal remains the same, it still requires the same coding within IOS for the feature to work, and multicast for the communication to flow over. I am including it here because of this. 

SW1(config)#int gi 0/0
SW1(config-if)#ip add 10.10.1.2 255.255.255.0
SW1(config-if)#standby 10 ip 10.10.1.1
SW1(config-if)#standby 10 pri 150
SW1(config-if)#standby 10 preem delay min 60
SW1(config-if)#no shut
SW1(config-if)# 
*May 11 16:11:44.818: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
*May 11 16:11:45.818: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
*May 11 16:12:05.647: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 10 state Standby -> Active
SW1(config-if)#exit
SW1(config)#exit
SW1#sh standby
*May 11 16:12:25.655: %SYS-5-CONFIG_I: Configured from console by consoleand 
GigabitEthernet0/0 - Group 10
  State is Active
    2 state changes, last state change 00:00:27
  Virtual IP address is 10.10.1.1
  Active virtual MAC address is 0000.0c07.ac0a
    Local virtual MAC address is 0000.0c07.ac0a (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.272 secs
  Preemption enabled, delay min 60 secs
  Active router is local
  Standby router is 10.10.1.3, priority 90 (expires in 9.232 sec)
  Priority 150 (configured 150)
  Group name is "hsrp-Gi0/0-10" (default)
SW1#

SW2(config)#int gi 0/0
SW2(config-if)#ip add 10.10.1.3 255.255.255.0
SW2(config-if)#standby 10 ip 10.10.1.1
SW2(config-if)#standby 10 pri 90      
SW2(config-if)#no shut
SW2(config-if)#
*May 11 16:11:44.460: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
*May 11 16:11:45.460: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
*May 11 16:12:29.371: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 10 state Speak -> Standby
SW2(config-if)#
SW2(config-if)#exit
SW2(config)#exit
SW2#sh stand
GigabitEthernet0/0 - Group 10
  State is Standby
    1 state change, last state change 00:00:23
  Virtual IP address is 10.10.1.1
  Active virtual MAC address is 0000.0c07.ac0a
    Local virtual MAC address is 0000.0c07.ac0a (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.744 secs
  Preemption disabled
  Active router is 10.10.1.2, priority 150 (expires in 10.480 sec)
  Standby router is local
  Priority 90 (configured 90)
  Group name is "hsrp-Gi0/0-10" (default)
SW2#

So it certainly looks like HSRP works on IOSv, let's make sure by looking at arp, and seeing if we can ping the virtual IP address:

SW1#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.1.1               -   0000.0c07.ac0a  ARPA   GigabitEthernet0/0
Internet  10.10.1.2               -   00ab.60a2.3000  ARPA   GigabitEthernet0/0
SW1#ping 10.10.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 3/8/11 ms
SW1#ping 10.10.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
SW1#sh ver | i Version
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.4(1.24)T0.9, MAINTENANCE INTERIM SOFTWARE
SW1#

SW2#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.1.2               0   00ab.60a2.3000  ARPA   GigabitEthernet0/0
Internet  10.10.1.3               -   00ab.1061.0700  ARPA   GigabitEthernet0/0
SW2#ping 10.10.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/7/11 ms
SW2#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.1.1               0   0000.0c07.ac0a  ARPA   GigabitEthernet0/0
Internet  10.10.1.2               0   00ab.60a2.3000  ARPA   GigabitEthernet0/0
Internet  10.10.1.3               -   00ab.1061.0700  ARPA   GigabitEthernet0/0
SW2#sh ver | i Version
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.4(1.24)T0.9, MAINTENANCE INTERIM SOFTWARE
SW2#

So again, all good and we are three for three.

So why am I going over this again, if actually I am only proving that it does work? Well, it's all to do with mileage, and your mileage may vary. Remember we are dealing with emulated, or virtualized hardware, so there will be issues, especially when we come across things that the router, or more specifically switch, generally offload to ASICs. With all the benefits that Cisco emulation software offers, the one thing it cannot do is truly emulate the functions contained within the ASIC.

What's a running shoe brand got to do with Cisco emulation software?

An ASIC is an Application-Specific Integrated Circuit, not to be confused with ASICS the running shoe manufacturer. These ASICs are so complex that they can (depending on the type of ASIC) be referred to as a system on a chip. It is this off-loading that makes running a virtualised switch, with the full functionality and speed as a proper hardware one, extremely difficult to implement.

The most common Cisco specific ASIC you will encounter is the port ASIC, and these handle traffic forwarding, QoS and ACL lookups. A number of switches have within these port ASICs their TCAM, which holds the IPv4 and IPV6 addresses, MAC addresses, and Access Control Entries.

For a greater understanding of packet flow within a switch and how this is governed by the ASIC then have a look at this PDF from Cisco Live.

So in short, we can get close, but close is a very relative term, finding the right IOU or GNS3 image can be a bit of a mission.

It will be interesting to see how CML stands up to higher-level switch functionality when it is finally released. One would think that as it is the basis for the new version of the CCIE exam then it will be supported. Time will tell on that!

In an ideal world we would all have the required hardware, it wouldn't cost more than a cup of coffee, and it would fit into your pocket. But for the moment we'll have to see how far our mileage gets us.

IOSv in GNS3

Following on from the Cisco ViRL - a first taste! post where I said that I was going to try and get the IOSv image working in GNS3 I have done a bit of playing around. After a few misses I finally got it working. So here is my walk through.

Firstly you need to get the ova file out of the onePk image - once you have loaded the onePk vm you can connect to it using WinSCP and get the ova file from /usr/share/vmcloud/data/images/vios.ova.

Importing the onePK vIOS ova file into VirtualBox

I first tried setting the IOSv image up as a VirtualBox guest and adding it to GNS3 that way. No go, and it bluescreened my laptop. DONT TRY THIS AT HOME KIDS!

Creating a vIOS Qemu guest (attempt 1)

Secondly I tried to create a Qemu guest by extracting the files from the ova and running a bunch of qemu commands to create an img file. I didn't get a bluescreen, and the image loaded, but nothing much happened after that, and I couldn't console onto it. So it was pretty useless.

Creating a vIOS Qemu guest (attempt 2)

The second attempt, and the one that works it to first extract the contents of the ova file. make sure that the Qemu settings in GNS3 work, so the All-in-One version of the GNS3 software is best, so that you get all the Qemu goodness.

The resulting vmdk can be run directly as a qemu guest. So with the following settings:

Qemu-flavor: -x86_64
Identifier name: anything you like
Binary Image: the extracted vmdk file
RAM: 384Mb works well, though Cisco recommend 512Mb
Number of Nics: anyting up to 8
NIC Model: e1000

You can then drag a Qemu guest onto GNS3. If you want one, drag on two and delete the first one, for some reason it didnt seem to like the first one, probably due to a numbering thing with the telnet ports.

When you click on boot the Qemu screen will come up, it will appear to hang at "Booting 'IOSv', this is fine, you should now be able to console onto the devices. I added one 7200 router (R1) with two gigabit ethernet interfaces (1.1.1.1/24 and 2.2.2.1/24) and three vIOS images (deleting the first one). The IOSv images had IP addresses 1.1.1.2 and 2.2.2.2 connecting them to the 7200 via gi 0/1, and 3.3.3.1 and 3.3.3.2 connecting them to each other vis gi 0/0. CDP worked, and so did ping:

I have uploaded a video showing all of the steps.

Enjoy your brand new IOSv!

GNS3 Alpha 3 is here

Another long bank holiday weekend in the UK heralds another GNS3 alpha release, it's not as much of a huge change as going from Alpha 1 to Alpha 2 was (as that brought with it the ability to connect native GNS3 routers to IOU images), but there is some cool stuff anyway. The changes with GNS3 1.0 Alpha 3 are:

• Follow the “VMware model” to organize projects.
• Topology files have the .gns3 extension instead of .net (they are still supported).
• Fixed problem to capture on TAP or Ethernet interfaces when not root.
• Updated the upload page.
• Server request validations.
• Graceful shutdown for the server & modules
• Checks for valid IOS & IOU images
• Checks for missing shared library dependencies in an IOU image.
• Explicit error message for missing 32-bit binary support on 64-bit Linux when starting IOU.
• Check if iouyap can access Ethernet and TAP devices.
• Windows network interfaces support in clouds (need improvements but it works…)
• Update tooltips to show node IDs.
• Ranges for Dynamips UDP, console, auxiliary console and hypervisor ports.
• Use Dynamips UDP NIO auto back-end for UDP tunnel connections (excepting stubs).
• The GUI can check the server version.
• Explicitly show an error if an IOS network module cannot be added or removed.
• Support for –version on the command line for both the server and GUI.
• Delete IOS ghost files when closing a project.
• Check for the correct locale on Linux/UNIX.
• Fixed bugs with duplicated node IDs.
• Save exception.log in the same directory as the GNS3 settings file.
• Added the view -> docks menu.
• Checks on node ID returned by the server.

So what are the important things here? Well it looks like the cloud support (for connecting GNS3 to real equipment) is working again, but most of the things above are little fixes than major changes.

The speed in which alpha 2 followed alpha 1, and now alpha 3 has followed alpha 2 in an equally short space of time, does show the commitment from the GNS3 folks. It probably won't be long until we see the first beta being released!

I would like to have the ability to add notes back again soon though please!