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.

IOU file for MPLS for Cisco Networks now available

I had been meaning to finish this off for a while, but what with the studying and all, it kind of got put to the side. Anyway, I got sent an email, from a very friendly guy, asking if I could send the initial configs so that he could create the IOU files himself.

Instead I created the IOU file, including a clickable image map (again this is a real push towards going solely IOU for the next volumes). It looks much cleaner than the GNS3 version, and I can reuse the image that's in the book, so it keeps a much more consistent feel.

Obviously the interface names will be different (no GigabitEthernet in IOU), but you are a bunch of clever people, so I am sure you'll be fine!

So far the majority of people responding to the poll on the right hand side are in favour of IOU, but there is still quite a few days left, so who knows which way it will swing.
The IOU-web file for MPLS for Cisco Networks is available to download from the books section above.

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.

First steps with Unetlab

Andrea, the guy behind the great IOU-WEB, has released Unetlab (Unified Networking Lab). It's still in beta at the moment, but I thought I would have a look.

Even though I have not finished my CCIE R&S yet, I am looking towards the Service Provider CCIE, which I plan to do straight after the R&S. With the SP track (as it stands at the moment), you need to get your hands on the XRv. This will run, happily, on ESXi, and can be connected to IOU, or even into GNS3 (using VirtualBox). I had started to play around with this, but it's not exactly the easiest thing in the world. So I was very pleased when Unetlab came out, as everything can be within one environment.

So I decided to get my hands dirty and have a go.

I am using an ESXi server, with 32GB ram, but it'll run in VMWare player, workstation, Fusion, and VirtualBox as well.

Once I had downloaded it (its about 300Mb give or take), and imported it into ESXi, I followed the Unetlab install guide. It's a simple process, and you are guided through it. It's well worth doing an update as well to get the home page displayed below.

The interface is sparse (at the moment, remember this is a beta), but has everything that I need at the moment.

My first step was to import the IOU images. The caveat here is that you need to generate the IOU license, I won't go into details, but it's easy to google how to do this. The only gotcha I came across was that the images must have a .bin extension - so make sure that you add this first.

Following the install doc I copied the files, using FileZilla, to /opt/unetlab/addons/iol/bin, and fixed the permissions using the command "/opt/unetlab/wrappers/unl_wrapper -a fixpermissions". Then I went back into the gui and created my first lab.

From the Actions menu, I create a new lab, and call it IOL test

From the Actions menu, I then create a network:

Then I add a Node, also from the Actions menu:

I add 2 nodes, and from the drop down select an IOL image (that I have already uploaded through FileZilla):

My two nodes appear on the screen:

I then right click on a node, and select "Interfaces", and point R1 to use the network I just created:

My first node is added to the network

I then repeat on R2, and my two nodes are connected:

From the Actions menu I then select "Open this Lab", and now I can start my two routers:

If you havn't followed the guide on the website, then you will find that the nodes do not start, so please do follow the guides to the letter.

Give them a few minutes to fire up, assign an IP address, and all works well:

So far memory usage is pretty good (remember that this is on a 4GB VirtualBox VM):

Let's add the XRv image.

This is slightly more complex, but again the documentation for importing XRv into Unetlab explains every step.

Now I can add multiple XRv routers, and connect them to the IOU images.

I am going to edit my original lab, so we need to go to the Actions menu, and select "Edit this lab":

I then add the XRv router:

Connect to interfaces to our network

Once we add the network to the new router, and also set another interface on both of the IOL routers, we get something like this:

Going back to the Actions menu, select Open this lab, and start the router. Here I did see an error, but after a few attempts, it did start:

Memory usage has now pretty much hit the ceiling, as the XRv takes quite a chunk (3GB), but nonetheless, it serves to prove that the system works. Adding more memory is clearly required here if you want to run a decent sized topology with a range of devices.

It takes a long time for the XRv to fire up, again this is down to the memory I have available, it worked much better on my ESXi server, but it does work:

It's a little untidy at the moment, so let's do a bit of reconfiguration:

We'll add a new network, and set the XRv to use this, as well as moving the E0/1 interface of both the IOL routers to use this:

Now the topology looks much cleaner!

 Still, let's clean it up even more, and add another network, and reconfigure it a bit:

Much cleaner!

CDP looks a bit funky, and pings don't work, but then I think I just need to play around with it a bit. It's only my first real go at playing with this, so there are bound to be teething troubles!

With this in mind, I shut everything down, and fired them all up again. Now things look much better:

RP/0/0/CPU0:XRv-1(config)#interface Gi0/0/0/0
RP/0/0/CPU0:XRv-1(config-if)#ipv4 address 10.1.1.1 255.255.255.0
RP/0/0/CPU0:XRv-1(config-if)#cdp
RP/0/0/CPU0:XRv-1(config-if)#no shut
RP/0/0/CPU0:XRv-1(config-if)#int gi 0/0/0/1
RP/0/0/CPU0:XRv-1(config-if)#ipv4 address 10.1.2.1 255.255.255.0
RP/0/0/CPU0:XRv-1(config-if)#cdp
RP/0/0/CPU0:XRv-1(config-if)#no shut
RP/0/0/CPU0:XRv-1(config-if)#exit
RP/0/0/CPU0:XRv-1(config)#cdp
RP/0/0/CPU0:XRv-1(config)#commit
RP/0/0/CPU0:XRv-1(config)#exit
RP/0/0/CPU0:XRv-1#sh ip int bri
Wed Feb 18 13:18:20.485 UTC

Interface                      IP-Address      Status         Protocol
MgmtEth0/0/CPU0/0              unassigned      Shutdown       Down
GigabitEthernet0/0/0/0         10.1.1.1        Up             Up
GigabitEthernet0/0/0/1         10.1.2.1        Up             Up
GigabitEthernet0/0/0/2         unassigned      Shutdown       Down
RP/0/0/CPU0:XRv-1#ping 10.1.1.2
Wed Feb 18 13:18:26.475 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/61/279 ms
RP/0/0/CPU0:XRv-1#ping 10.1.2.2
Wed Feb 18 13:18:32.994 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/29 ms
RP/0/0/CPU0:XRv-1#sh cdp neigh
Wed Feb 18 13:22:11.959 UTC
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID       Local Intrfce    Holdtme Capability Platform  Port ID
R1              Gi0/0/0/0        163     R          Linux Uni Et0/1
R2              Gi0/0/0/1        138     R          Linux Uni Et0/1
RP/0/0/CPU0:XRv-1#


R2#sh ip int bri | e unas
Interface                  IP-Address      OK? Method Status  Protocol
Ethernet0/0                192.168.1.2     YES NVRAM  up      up
Ethernet0/1                10.1.2.2        YES NVRAM  up      up

R2#ping 10.1.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/14 ms
R2#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R2#

R1#sh ip int bri | e unas
Interface                  IP-Address      OK? Method Status  Protocol
Ethernet0/0                192.168.1.1     YES NVRAM  up      up
Ethernet0/1                10.1.1.2        YES NVRAM  up      up

R1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/6 ms
R1#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/8/10 ms
R1#

There we have it, two IOL routers, one XRv router, all communicating happily, all contained within one environment.

Where Unetlab is superb, is that everything is within the same environment. There is no mucking about with creating multiple networks in VMWare. To be honest, some will probably find that easy, but I like to have it all contained, like Unetlab does.

Running two XRv routers did cause the default memory to top out, so I shut down the VM, and increased the memory to 20GB. Now I can run loads of routers, and the memory usage (as reported on the "Home" page remains within reasonable levels. Please note though that I am showing screenshots from a VirtualBox install, with a lower amount of memory.

So what's next?

The vendor support in Unetlab is very wide-ranging. I havn't tried all of them, but will add some dynamips images, CSR1000v and the vIOS images this week.

At the moment the supported images are:

• Aruba ClearPass
• Alcatel 7750 SR
• Arista vEOS
• CheckPoint Security Gateway VE
• Cisco ASA (porting)
• Cisco ASAv
• Cisco CSR 1000V
• Cisco IPS (porting)
• Cisco IOS 1710 (dynamips, ethernet only)
• Cisco IOS 3725 (dynamips, ethernet only)
• Cisco IOS 7206VXR (dynamips, ethernet only)
• Cisco IOL (for Cisco internal use only)
• Cisco Titanium (for VIRL customers only)
• Cisco vIOS (for VIRL customers only)
• Cisco vIOS L2 (for VIRL customers only)
• Cisco XRv
• F5 BIG-IP LTM VE
• Fortinet FortiGate (new)
• HP VSR1000
• Juniper Olive (porting)
• Juniper vSRX
• Palo Alto VM-100 Firewall
• VyOS

The scope of Unetlab is immense. Clearly this will work well for when I do the SP track, as the IOL and XRv images are supported, and work nicely.

This also gives scope for the Security track as well. It will "natively" run the ASAs and the IPS, and you can connect clouds to run things like an Active Directory server, WSA (Web Security Appliance), ACS (Access Control Server), WLC (Wireless Lan Controller), ISE, and all the rest (there is a LOT of components in the Security track). I would probably need to invest in a second ESXi server in order to run all of the above, but then for the sum of £200, it's a worthwhile investment.

Unetlab is superb, already, and it is still very early days. While the interface can be a little slow to update  (such as moving objects around, but then this is less of a concern than the amazing functionality that it offers), Andrea has excelled himself again, he deserves a big thanks for all his hard work and dedication to the community. It's just a shame that he hasn't done a kickstarter, like GNS3 did as I am sure that people would support him. I'd certainly give him some money!

BGP for Cisco Networks for IOU!

Hot on the heels of releasing the topology for BGP for Cisco Networks for GNS3 1.0 Beta comes the topology for IOU-WEB.

Firstly I must say that I did not create this, not that this is any form of get-out-clause, but because all the thanks go to a great guy, who has done a GREAT job on it, it really does look fantastic!

I mean check this out, how good does this look?

That's one lovely diagram there.  I wish my Visio diagrams looked that good!

Along with the IOU topology is a Visio drawing of the topology.
I have updated the downloads section for the book with the links to the files. Now it's just waiting for ViRL to be released and we have every platform covered!

I am very thankful to the guy who has done this, and he's offered to do the IOU typologies for the MPLS volume as well. If they look anything like the ones that he's done for the BGP book then they will be great as well!

Either way I will be sending him a free copy of the MPLS book when it's published. I have just completed a couple of chapters this week, and this weekend should finish another, then it's just one last chapter to do, which is all planned out, then ready for proofing and publishing!

How to implement HSRP on Cisco IOU and GNS3

Lots of people have said that HSRP does not work in either GNS3 or IOU. It does, but both softwares are very particular about what they require for it to work.

HSRP on Cisco IOU

For HSRP on Cisco IOU I have used the IOS image i86bi_linux_l2-ipbasek9-ms.jan24-2013-team_track.

To upload the image fire up IOU web and click on Manage.

Click on Manage IOSes

In the Upload IOS bit at the top of the page enter the filename - this must be the same as the file you are going to upload or else it won't work. The alias can be anything you want it to be. Then browse to the image from the Choose File button.

Your page should look like this:

When you are ready click on Upload.

Once its uploaded your Manage IOSes bit of the page should look like this:

You can see our added IOS at the bottom.

We can now start with a basic lab, using a netmap of 1:0/1 2:0/1.

SW1 is configured as follows:

SW2 is set up similarly (excuse the typing mistakes)

After a few seconds we can start to see HSRP messages coming through:

And using the command "sh standby vlan 10" we can confirm that the HSRP is working as it should:

HSRP on GNS3

For HSRP on GNS3 I am using the image c3660-is-mz.124.25b.

Fire up GNS3 and go into Edit > IOS images and hypervisors, add your image for the c3660 (if you don't already have one, but your mileage may vary with other images), and set it as the default.

Next go into Edit > Symbol Manager, find an image you like, personally I like the route_switch_processor, highlight it and press the arrow button. Change the type to Router c3600 and give it a good name, then click Apply, then click OK.

Now we can drag two of our new HSRP switches onto the canvas:

Now configure both the new switches and add an NM-16ESW to each:

Once you have done that you can cable them together and start them up, you must use the connections on the newly added module though - I have used 1/10 on each.

The configs are the same as above for IOU and are a very simple implementation:

Once you give the switches a few seconds once everything is plumbed in you should see the HSRP messages start to flow:

And there we have two ways to get HSRP working in a home environment without needing to purchase separate hardware.

Cisco IOU and Frame Relay

As part of the big lab I am doing I want to do some work with Frame Relay. Nothing to exciting at the moment, but I do want to touch on it.

So with IOU I want a Frame Relay connecting to four other routers in a hub and spoke topology. Pretty simple right?

Well using this netmap:

5:0/0 1:0/0
5:0/1 2:0/0
5:0/2 3:0/0
5:0/3 4:0/0

I get what I want:

And I can set up my FR switch as follows:

hostname FR1
!
boot-start-marker
boot-end-marker
no aaa new-model
clock timezone CET 1 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
ip auth-proxy max-login-attempts 5
ip admission max-login-attempts 5
ip cef
no ipv6 traffic interface-statistics
no ipv6 cef
frame-relay switching
multilink bundle-name authenticated
crypto pki token default removal timeout 0
redundancy
!
interface Serial0/0
 description Connected to R1
 no ip address
 encapsulation frame-relay
 no keepalive
 serial restart-delay 0
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 frame-relay route 102 interface Serial0/1 201
 frame-relay route 103 interface Serial0/1 301
 frame-relay route 104 interface Serial0/1 401
!
interface Serial0/1
 description Connected to R2
 no ip address
 encapsulation frame-relay
 shutdown
 no keepalive
 serial restart-delay 0
 frame-relay intf-type dce
 frame-relay route 201 interface Serial0/0 102
!
interface Serial0/2
 description Connected to R3
 no ip address
 encapsulation frame-relay
 no keepalive
 serial restart-delay 0
 frame-relay intf-type dce
 frame-relay route 301 interface Serial0/0 103
!
interface Serial0/3
 description Connected to R4
 no ip address
 encapsulation frame-relay
 no keepalive
 serial restart-delay 0
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 frame-relay route 401 interface Serial0/0 104
!

Ok so nothing too complicated here.

Looking at R1 and R4 (truncated):

hostname R1

!

interface Serial0/0

 no ip address

 encapsulation frame-relay

 serial restart-delay 0

 frame-relay lmi-type ansi

!

interface Serial0/0.14 point-to-point

 ip address 10.1.14.1 255.255.255.0

 frame-relay interface-dlci 104   

!

hostname R4

!

interface Serial0/0

 no ip address

 encapsulation frame-relay

 serial restart-delay 0

 frame-relay lmi-type ansi

!

interface Serial0/0.41 point-to-point

 ip address 10.1.14.4 255.255.255.0

 frame-relay interface-dlci 401   

!

I should be able to ping R4 from R1 and R1 from R4, but sh ip int bri shows that the sub-interfaces are down/down and the physical interface is up/down. If I add "no keepalive" to the physical interfaces they come up, but I still can't ping across them:

So the config looks ok, the interfaces are up, and we know from part two of the big lab series that serial interfaces do work on IOU, so whats the problem? Well it looks to be an issue in IOU:

Look at the result of the "sh int serial 0/3" it clearly shows that its set to Frame Relay DCE, but the result of the "sh controllers serial 0/3" shows a very different story:

It's showing a cable type of DTE.

Having a look at the netmap tutorial on Route Reflector page it shows a Frame Relay switch sitting in the middle of a bunch of routers and the netmap has 107 at the end of the connections, 107 being the Link-Layer header type for Frame Relay. So if I change my netmap to:

5:0/0 1:0/0 107
5:0/1 2:0/0 107
5:0/2 3:0/0 107
5:0/3 4:0/0 107 

I get this:

Clearly this is not what I am looking for!

Means I have to rethink how my big lab topology will pan-out. I am guessing it'll be without Frame-Relay for the time being! Even Andrea over at Route Reflector states that serial interfaces appear as DTE in the FAQs.

If anyone knows how to get around this, I'd love to hear from you. I have tried a number of different images but so far nothing works.

I am going to continue playing around, so hopefully will be able to pull something out of the hat, unless there is someone out there that can point me in the right direction...

*Update* GNS3 works fine with the same configs.