Using GNS3 for Switching Labs
I have been following the fuzz about the integration of switching emulation in the new 2014 release of GNS3. Have signed up for early release but noticed that this has now gone to Crowd Funding status and the only members that will possibly have access to this new version of GNS3 will be the ones who donate X amount of money. GNS3 is a free graphical network simulator capable of emulating a number of network devices. This makes it possible for anyone to quickly and easily spin up network hardware for testing and educational purposes without the heavy expense of physical hardware. Practical Packet Analysis. CompTIA Network+.
Gns3 Cisco Switch Emulation
For so long, I’ve heard - as have many of you I’m sure - that GNS3, though a GREAT emulator for Cisco IOS software, is not practical for studying anything related to switching. Routing is handled just fine, but because of the proprietary ASICs in Cisco switches, it is not something that can be easily reverse-engineered, thus GNS3 cannot do it. After all, all routing is essentially done in software in GNS3.
I actually wrote this article in part over a year and a half ago, but these concepts still hold up, and I decided to get it out of drafts and publish because I still believe it’s useful to those looking to get into this industry but don’t have real equipment to play with, as is most often the case.
I’d like to point out a very reasonable solution to this problem. Keep in mind that this will not be the same as having actual switches, because some of the syntax can be quite different, but if you’re vigilant, you’ll be able to interpolate between the syntax shown, and what you can expect on a real switch. These explorations will help a CCNA - and even CCNP - candidate get ready for the concepts they’ll be faced with on the exam.
You’ll notice that you have an “EtherSwitch Router” over to the left on your toolbar. This needs a c3700 image to run, and I selected the following:
Now that there’s an image selected, don’t forget to set an IDLE PC value, as you should with every platform in GNS3 so that your environment can run smoothly. There are walkthroughs all over the web on how to do this.
My main point in writing this article is to get some switches powered on and show you how to do some basic switching tasks on this platform. For that, we need to see a topology. I have thrown this lab together in GNS3:
You may need to enable “Always use manual mode when adding links” under Preferences » General » GUI Settings to pick these specific interfaces.
The first thing you need to do to get familiar with what’s going on here, is show the interfaces available:
You notice that there’s 16 interfaces in card 1. These 16 interfaces represent our NM-16ESW module, and is what allows us to perform our switching labs. We will be working with these interfaces (Fa1/0 - 15) to perform switching. The two ports in card 0 (Fa0/*) are not capable of L2, so you cannot make them into switchports.
However, this is still a router and should be treated as such until we sort of….make it a switch. To do that, we enable each interface and make them switchports:
These ports are now active, and are switchports, that is, they now operate at layer 2 rather than layer 3. These devices are now basically Layer 3 switches.
Now that we have functional switches, lets dig into some common switching concepts and see how much we’re able to play with in GNS3:
Spanning Tree is pretty easy. Once switching has been enabled as shown above on all devices, spanning tree operates exactly like one who is familiar with it would expect. The devices run traditional PVST by default, as is made evident by the output of the following:
This shows the spanning-tree information for VLAN 1. There are also vlan-specific spanning-tree configuration commands. What I don’t see, however, is any indication of rapid PVST, or even a way to configure it.
This is because this image does not support RSTP. We now come to a feature that we’re actually unable to lab in GNS3. While this may seem like a downer, I urge you to think about the syntax required for enabling RSTP on traditional switching platforms. Not too difficult, right? Really the only thing RSTP brings from a certification exam perspective is the new port states, which can be studied from a book. If it’s still not enough, this is something you’ll need physical equipment to try.
I don’t view this as a big deal. This DOES allow us to study basic things like port states, STP security features like backbonefast, and the effect of tweaking timers. That’s easily CCNA-level and even CCNP-level concepts.The fact that I can still lab PVST is enough for me, and I don’t feel like I’m missing much not being able to run RSTP. In a real enterprise environment, RSTP is a much preferred option, but since this is just for studying, and since RSTP requires only a single command to configure, we’re not missing much here.
EtherChannel, or “port channel”, is a way of grouping multiple links together for increased bandwidth and redundancy. Let’s see how GNS3 handles this.
Looks like it can be done, but there’s really not much available for us to do beyond simply statically bundling the ports together. We aren’t given the option to enable LACP or PAGP. We are, however, still able to configure the global setting for the hashing mechanism to load-balance traffic on these port channels:
While this is cool and fun to play with, it doesn’t really have a huge impact on Cisco curriculum, as port-channels are a light subject as it is. Good to know this is possible, though.
Like anyone who has actually run a functional network, I despise VTP, but Cisco has deemed it necessary to keep this “feature” in their curricula for the time being. The configuration for VTP is different than on a traditional Catalyst switch, but the bells and whistles are the same, and you can observe the same behavior.
The VTP configuration is found in the same place as the VLAN configuration - in the old VLAN configuration context, which any modern Cisco switch has since moved away from.
As you can see, the concepts are the same, and if you can interpolate between the subtle configuration differences, you can still use this to study for the exam - just make sure you spend some time in front of a real switch for at least a little bit so you can remember the actual context of the commands the exam will be expecting.
We also configure R3 to be a VTP client and see that it receives the new VLAN database revision.
VLAN 10 made it to R3 with the new configuration revision.
Layer 3 Switching
We’re running all of this in GNS3, which is good for practicing Layer 3 stuff, so who would write a blog post on this topic without addressing Layer 3 Switching?
Let’s change up the topology a little bit. I’ve placed R1 as the center of a now-linear network, where R2 must go through R1 to get to R3.
I placed each port on R1 in different VLANs (access), and assign IP addresses to each SVI:
Gns3 Switch Emulation Switch
With IP addresses assigned, it’s time to do our routing. The device is natively a router, so setting up a quick (and lazy) EIGRP configuration is as I expected, and our neighbors came up.
A quick ping from R2 to R3 shows we’ve got end-to-end connectivity.
In conclusion, we’ve run into a few caveats in dealing with GNS3 for switching labs, but on the whole they are manageable. Do NOT focus on the syntax, refer to real equipment or your curriculum books for that - use these tools for getting familiar with the concepts, and getting a minimal amount of command line syntax. Same as with routing labs - GNS3’s best trait is that it just gets you comfortable with the IOS CLI - something that will serve you well on the exams no matter what.