Creating a Virtual Cisco Switch

White Paper: Creating a Virtual Cisco Switch:

Many people who work in my field of expertise sell, install, or support end point security software that used 802.1x to provide Network Admission Control (NAC) features. Dot1x, as I'll call it, is a great technology that enables switch ports to be disabled, or to be reconfigured, according to the security posture of the machine that plugs into it. For example, a foolish individual brings in their own virus riddled laptop into the company, our NAC software detects that it's not a company owned machine and connects the machine to a quarantine VLAN so all the nasty bugs can't damage our important servers.

However, one of the big downsides of dot1x is that to carry out demonstrations or to get to know it as a technology can be hard as you need a real switch. You can't really turn up to a meeting with a Cisco 3750 under your arm. Primary you look like an idiot, but more importantly you might catch your nice shiny suite jackets on one of the mounting ears. Ouch.

And now the solution! Whilst VMware (and VirtualBox - try it!) allowed the consultant to leave his servers at home, GNS3 allows us to leave our switches at home too! GNS3 is a open-source graphical network simulator that provides a front end for Dynamips (a Cisco device emulator - amazing work) and pemu (a PIX device emulator based on qemu). Once, you've downloaded it, installed it, and added a real Cisco IOS or PIX image (you must source these your self*) you boot up a virtual machine of the device you wish to use.

So that is our use case.

This white paper will focus on setting up the Virtual Cisco Swith. In a later paper, I'll then show you how to add dot1x to it. But that can wait for the time being. Lets get on with the basics.

Preparation

Before you begin, please ensure you have downloaded and installed GNS3 and pointed it to IOS images for the 3745 and 1700 router. You should also set the IdlePC values for both the 3745 and 1700 devices to stop them from eating all of your host CPU%. I'll not detail how to do this as there is much help available elsewhere (hint: setting idlePC value is as simple as booting the router, waiting for it to finish booting and become idle, right clicking on the router and saying 'IdlePC'. Then trying different values until your host CPU settles down from 100%).

I will not send you IOS images.

Once you are at this point pictured below do continue!

Currently GNS3 is limited to Cisco 1700, 2600, 2691, 3600, 3700, 7200 series routers. Yep. That's right there are no switch listed. But fear not!

The Cisco 3745 router is a great piece of kit. By default, it's a standard Cisco router, with the capability to host many WAN interfaces. However! It also has the ability to host an EtherSwitch module which turns the chassis into a layer 3 switch. Luckily, the writers of dynamips emulated this hardware for us too. All we need to do to make a switch is to load up a 3745 with a couple of NM-16ESW modules.

Heavy, noisy, costly, and non-portable in hardware

Easy in Software! Take it where-ever you go!

Lets get our hands dirty!

Drag a Cisco 3740 device into the field, right click it to configure it, and add an NM-16ESW module. Right click it and say 'Start' then right click it and say 'Console'. Watch in amazement as your device boots! Say 'no' to the kind offer to run through the initial configuration and continue to read below.

The rest of the configuration is as you would expect with one caveat. I'll mention it here. When you carry out a 'wr' command on a real 3745 the config is saved along with the contents of the NRVAM. However, when using GNS3, only the configuration is saved. The result? Any configuration that is not included when you execute 'Router# show run' will be lost between GNS3 sessions.

So far, the only thing I've noticed this affecting is the configuration you add through the enable command Router# vlan database. Do read on!

Create the VLAN

Ok, lets set up some VLANs! It is this configuration that is not saved between GNS3 sessions. Do a 'Router# show run' you will see it's nowhere to be seen. As a work around I just paste it in each time I boot up the device. Not pretty. I'm sure there is a better way.

Configure the VLAN interface

We do nothing more than create the VLAN and give it 'no' IP address. After all, we don't want to route between VLANs so we don't need an IP address.

Configure the physical interfaces

Here I did the normal sort of configuration you'd do on any old Catalyst. It's worth noting here that I was lazy (efficient?) and used the 'interface range' command as to configure all the interfaces in one go. A life saver. Also note that the ports I configured we're those on the EtherSwitch. The ports hosted directly by the 3475 router (FastEthernet 0/0 & FastEthernet 0/1) are routed ports and do not accept the 'switchport' command. On a real 3745, these would be used for WAN connections (say, an external Satellite link that presents as ethernet) and cannot be added to a VLAN. Any traffic from a non-EtherSwitch interface you wish to go to an EtherSwitch interface must be routed through the CPU. You cannot switch between the non-EtherSwitch and EtherSwitch interfaces.

Check the interface status

At this point were showing that the VLAN interface and the switch ports are down (see no asterisk by any of them).

This is because we need to 'connect cables' to them to bring the link lights up. The easiest way to do this in GNS3 is using a Ethernet Switch. Make sure to connect an ethernet switches to FastEthernet 1/0 and FastEthernet 1/1.

Tickle the interfaces

Now the cables are in we have to tickle the interfaces in order for them to recognise the 'virtual' cables. Normally you wouldn't need to, but it's a virtual world after all so we have to make an allowance or two ;)

Note that the VLAN line protocol came up too... If you find that the VLAN line protocol won't come up, a possible cause is a missing vlan database. Run 'Router#vlan database' and make sure your VLANs are configured there.

Testing!

Ok, you're going to need to plug hosts into those ethernet switches. Now you have some choice:

Choice 1: For the advanced IT guy, who know their network-fu:

Create two virtual machines using VMware or Virtual Box or w-h-a-t e-v-e-r you like

Put both Virtual Machines on the same subnet (VM1: 10.0.0.1/24 VM2: 10.0.0.2/24)

Crate two TAP interfaces in the OS - tap1 and tap2

Connect VM1's network interface onto tap1

Connect VM2's network interface onto tap 2

Now in GNS, replace the ethernet switches with Connectivity Clouds, call them cloud1 and cloud2

Configure cloud1 to connect to tap1

Configure cloud2 to connect to tap2

Now, we've configured this:

VM1 <=> tap1 <=> cloud1 <=> fa 1/0 SWITCH fa 1/1 <=> cloud2 <=> tap2 <=> VM2

On VM1 ping VM2

It works?! REJOICE! You just mastered some cool virtual networking that will serve you well! I hope you had a moment!

OR

Oh, it didn't work? Oh well.... read on

Choice 2: For the regular chaps, who's 'fu' is only slightly lacking, but who soon will become masters

Create two 1700 series routers (ANY router will do, I used 1700 as they boot up fast in emulation). Cable both f0 interfaces to the switches as shown.

Run though the initial set up and give f0 the appropriate IP address as shown.

Now, ping from R2 to R1 and rejoice!

Now to check you didn't do something silly... check the Mac Address Table of your switch...

You should see that after you run the ping the switch adds the two MAC addresses to it's forwarding table. You now have your software switch! All that's left to do is feel bad if you weren't man enough to setup the tap interfaces and cheer yourself up with a Mountain Dew, Pepsi Cola, or sugar water of your choice (caffeine optional).

Summary

So at this point, you have a fully working Cisco Switch in software ready to use for your demo's, testing, or education! No more dragging that 6500 chassis onto the tube. Your back will thank you :)

Next time we'll look at doing something a little more fun with our switch. I am hoping for some dot1x excitement or perhaps some spanning tree between multiple switches. But for now at least, it's time for bed.

Notes

Saving your Lab

Most users of GNS3 realise at some point that saving their project can be done in a few ways.

1 - Typing 'save' in the Dynagen Console

2 - Clicking File => Export

3 - Clicking File => Save

I would highly recommend that you use method 3. But by default option three only saves the network topology (the pretty picture) not your router configs, even though I tick the 'Save nvrams and other disk files'. Perhaps this is only my setup, but I'll document it here anyway.

When you create your new GNS3 project ensure you click 'Export router configuration files'.

Then when you do a File => Save, ensure that see the below lines. You can even check the .cfg files to be sure that configs are complete.

Device boots up with an empty config

I've found a few times, that I've started GNS3 up, started my routers and found that they have a completely blank config (it boots to the initial configuration dialogue). I've found to fix this you should close down GNS3 (and ANY running Dynamips processes - use task manager) and then clean out the projects working directory, the global working directory (you will find these in the GNS3 preferences) and your profiles 'temp' folder.

It's a clumsy fix. I've not spent a great deal of time looking into it. Perhaps there is a better way. I'm not sure.

Start up GNS3 and you should find that all is well!