GNS3 + hardware switches

mapletune

The youtube and other forum posts are from over a year ago... so pardon if I'm just re-making more threads of the same...

BUT!! I've been SOO excited about this Lab solution that I can't stop thinking about it!! =D

GNS3 + 3x 4port PCI network card -> connected to real Cisco
Youtube: CCIE Lab using GNS3 and Quad NICs for Switches - YouTube
Forum: CCIE Lab using GNS3 and Quad Nics for Switches | FAQ

Official GNS3 FAQ
Website: Switching - GNS3

---

I do have a small small Lab (2514, 2611, 1721, 2950)
But I find myself just using network simulations. The problem with simulations is that many of the features are not supported + bugs, etc...
Thus, to simulate real IOS, I finally got GNS3 working on my PC... just to find out switches aren't supported. = =

Anyway, I've been hyperactive ever since I ran across the above links. I want to build my own GNS3 + Switches Lab!!!

There are mainly 4 ways of doing this as described on the official GNS3 FAQ.

dedicated interfaces
Using Quad-NIC PCI network cards
Using USB-to-Ethernet network adapters


802.1Q trunk
QinQ with virtual switch
Direct VLAN mapping

---

How did you guys build/set up your GNS3 Lab + connecting real equipment?

---

mapletune

So after considering all of the options for GNS3 Lab + Switches, (nic cards, usb cards, QinQ, VLAN), I've decided to pursue the QinQ solution.

This way, I pretty much get the best of both worlds; Versatility of 1-to-1 connection between GNS3 router interfaces and real hardware Cisco switches. As well as; only needing 1 cable connecting my GNS3 computer to the breakout switch.

However, here's where I hit a snag...


Switching – QinQ with virtual switch option - GNS3

• Cisco 2950: CDP will not work in both direction as layer 2 tunneling is not supported on this switch.
• Cisco 3550: CDP work only in one direction, neighbors cannot be seen on the switches. Regardless of the IOS version.
• Cisco 3560: CDP work only in one direction, neighbors cannot be seen on the switches. Regardless of the IOS version.
• Cisco 3750: Bidirectional CDP and fully functioning lab (layer 2 and layer 3) using IP Services image. IP Base image does not support tunneling.
• Cisco 4948: Bidirectional CDP and fully functioning lab (layer 2 and layer 3) using minimum of IP Services image.

Basically, not only do you need to support 802.1q to trunk all the data between different GNS3 routers into the different real hardware Cisco switches... You also need a breakout switch that supports QinQ tunneling (802.1ad) so that this data can pass transparently between GNS3 virtual switch and your breakout switch, thus essentially, passing data from GNS3 routers to each Cisco switch "directly".

So... that means I have to spend a lot of money for a 3750 or 4948 etc, a higher end switch that supports 802.1ad.. =(

---

BUT! then i thought of something!

This setup needs the 802.1ad tunnel only to enable L2 protocols such as VTP, CDP, STP, etc to pass through. Why? Let's say you use a 2950 for your breakout switch. It gets a CDP/VTP/STP, what's it going to do? Forward it to your real switches? No, it'll process it and terminate it. That's where the problem occurs. That's why you need a tunnel so that the breakout switch doesn't touch L2 frames, just forwards them.

now.. HOW ABOUT!!!

Just use a third party switch. All it needs is 801.q VLAN tagging to properly forward between GNS3 virtual switch to the appropriate Cisco switch.

Since a "dumb" third party switch doesn't understand CDP, VTP, STP frames, and that they are multicast addressed, it should do the default action which is to flood unknown mac addressed frames.

Viola~! doesn't that mean you get bi-directional forwarding of every L2 frame? Thus, you get the "functionality" of a 802.1ad QinQ tunnel... without actually making a tunnel!

---

I'm really excited about the prospects of making this work without having to buy expensive switches like a 3750.

What do you guys think? Do you think this will work? Or I got it all wrong? =p

Let me know what you think!

NetworkVeteran

All it needs is 801.q VLAN tagging to properly forward between GNS3 virtual switch to the appropriate Cisco switch. Since a "dumb" third party switch doesn't understand CDP, VTP, STP frames, and that they are multicast addressed, it should do the default action which is to flood unknown mac addressed frames.

I don't have time to analyze your proposed solution just now, but a couple thoughts--

A third-party switch should flood CDP and VTP frames as they would any multicast traffic.

Be aware that STP, 802.1X and LLDP are sent to 01-80-C2-00-00-0x addreses, also known as Bridge Filtered MAC Addresses. Just because a switch doesn't support those protocols or you've disabled its support for those protocols, doesn't mean that it will forward them. That is something separate you will need to confirm when you're purchasing switches.