USING 802.1q, QnQ AND A BREAKOUT SWITCH
A brief overview
GNS3 is an excellent platform for simulating a good sized router environment for testing and more importantly for preparing for your CCIE lab. There are, however, some known limitations. The Dynamips software does not currently support more up to date switches like the 3560s used in version 4 of the CCIE Routing and Switching lab. In GNS3 on Ubuntu, you were provided with guidance on setting up GNS3 on Ubuntu GNU/Linux. You were shown how to run it as root and also introduced to the .net file that ultimately drives your lab topology. Dynamips and GNS3 (for the purpose of this article we will refer to it simply as GNS3) both support extending your virtual topology to your physical Ubuntu host. This gives us some very creative options for merging our virtual topology with physical hardware. We will use this article to demonstrate one of two different ways to extend your virtual topology to your physical hardware via some simple .net file adjustments and network configurations. You should already have a reasonable understanding of the fundamentals of Dynamips, GNS3, and the .net files before going too deep into this. You also are expected to have a reasonable knowledge of GNU/Linux and of course Cisco switching. Remember. Google is your friend.
Getting the virtual portion of our GNS3 lab up and running
Let’s start off with a simple setup. This will consist of just a few routers and switches. This will give you insight into the logic and a chance to understand the .net file layout without burying you in a complicated setup. We will get to that later. Here’s a sample config below showing a collection of routers. R3 is acting as a switch. This is completely virtual within GNS3. Nothing physical is being used yet. Here (below) is our GNS3 visual reference:
Below is our complimenting .net file:
Note: All file paths you see in configuration are relative to the host we are using for this article. Please make sure to adjust your paths accordingly.
autostart = False [localhost:7200] workingdir = /tmp udp = 10000 [] image = /home/foo/GNS3/images/c3725-advipservicesk9-mz.124-15.T14-uncompressed.bin ram = 256 ghostios = True sparsemem = True [[ROUTER R1]] model = 3725 console = 2001 f0/0 = R3 f1/1 x = -362.0 y = -214.0 [[ROUTER R2]] model = 3725 console = 2002 f0/0 = R3 f1/2 x = -119.0 y = -214.0 [[ROUTER R3]] model = 3725 console = 2003 f1/1 = R1 f0/0 f1/2 = R2 f0/0 slot1 = NM-16ESW x = -240.0 y = -17.0
Notice on R3, we have populated slot1 with a NM-16ESW card. Without the ability to emulate a newer switch (like a 3560) this is really the best option for defining a VLAN and bridging between R1 and R2 across R3. The problem is that R3 is still a router. The NM-16ESW card does not give R3 the full flexibility and feature set of a switch. Only some of the more primitive switching options can be accomplished. We can’t test a lot of switch related features that we need to master for our labs. This is our dilemma.
Options for integrating physical components into your GNS3 environment
There are two main ways to integrate physical switches into your lab topology. Both have pros and cons.
1. Bind every respective Ethernet port on every virtual router to a dedicated physical interface on your Ubuntu host. Each dedicated interface would then connect to its respective downstream switchport thus connecting “R1 f0/0 to Cat2 f0/1” transparently thru the host. This could be done with 4xFE PCI cards or with USB-Ethernet cards as long as your operating system recognizes the hardware. The biggest pro for this solution would be that there is no need for a breakout switch. If cost is an issue, this may be the cheaper option. The con would be that it requires extra hardware and wiring and extra configuration on your host. For a full IPexpert lab we used 5 4xFE cards in a 6U server. Either that or several USB bridges would be required to set everything up. This option will be discussed in a separate article.
2. Create an 802.1q trunk between your GNS3 environment and a physical “breakout switch”. Each virtual router port gets assigned to a VLAN on a virtual switch. That VLAN is tagged and fed to the breakout switch via a single trunk link. The breakout switch then distributes the VLANs accordingly to downstream switches that are part of your lab. The biggest pro would be that you only need a single connection between your Ubuntu host and your distribution switch. Thus, this could be accomplished on a beefy laptop/desktop with ease. The con would be that you need an extra switch sitting between your virtual routers and your lab switches and this may cause you some L2 headaches depending on your hardware. This is what we are going to go over in this article. More pros/cons/details in the main sections.
Configuring a single trunk port to a “breakout switch”
So the previous three router setup was pretty simple. In the drawing below, I’ve laid out the groundwork for how we will redesign this to utilize 802.1q trunking and QnQ to take advantage of some physical switches. Let’s take a look at our physical and logical components and how they are setup. This might help you visualize what we are accomplishing.
In our drawing above, we still have R1 and R2, but we have deleted R3, we’ll get to that in a minute. R1 and R2 are still virtual routers created by GNS3 and residing on the Ubuntu host. The FE ports on R1 and R2 are now connected to a virtual switch in GNS3. That virtual switch has a “dot1q” port that is bound to the physical Eth1 interface on our Ubuntu Host. From there, the Host is connected to the Breakout Switch and then on to Lab Switch 1. Our objective is to transparently bridge the two routers traffic to Lab Switch 1. We don’t want to see the host or the Breakout Switch when doing our labs. This must be transparent so that the layer2 protocols can function properly and we aren’t distracted with inconsistencies in the setup.
R1 – Fa0/0 will connect to Lab Switch 1 Gi0/13
R2 – Fa0/0 will connect to Lab Switch 1 Gi0/14
Again, when it’s all said and done, the virtual Vswitch and the physical Breakout Switch will be transparent. From the routers viewpoint as well as the lab switches viewpoint, the will be next hops for each other.
First, we need an additional package for 802.1q support on our Ubuntu host. This is assuming that you are already running hardware that supports it.
FROM: Ubuntu Forum
The first line will install the VLAN package so you can support trunking on your host.
sudo apt-get install vlan
The second will load the 8021q kernel module immediately by adding it to /etc/modules.
sudo modprobe 8021q
The last line adding the package to /etc/modules is permanent and will make sure it is there when you reboot.
sudo sh -c 'grep -q 8021q /etc/modules || echo 8021q >> /etc/modules'
While we are at it, let’s go ahead and set the MTU on the Ubuntu host up to a higher than default value to prevent headaches.
sudo ifconfig eth1 mtu 1536
This command is also temporary. To make it permanent, you would need to add either:
“/sbin/ifconfig eth1 mtu 1536” to your /etc/rc.local OR “mtu 1536” to your eth1 interface under /etc/network/interfaces
For the configuration above, we need to delete R3 and create a virtual switch. This virtual switch will receive the connection from R1 and R2. It will assign each of them a unique VLAN. Then, it will dump that onto a trunk port which continues on to the physical Ubuntu host and is passed to the breakout switch.
Back to our .net config. We are going to pull R3 out completely. Then add the vswitch and tag everything coming from the routers so that we can pass it to the Breakout Switch. You can do this directly in the .net file or you can do this via the GNS3 GUI. I’m more of a CLI guy so I edited the .net file first. Take a look at the result:
autostart = False [localhost:7200] workingdir = /tmp udp = 10000 [] image = /home/foo/GNS3/images/c3725-advipservicesk9-mz.124-15.T14-uncompressed.bin ram = 256 ghostios = True sparsemem = True [[ETHSW SW0]] 1 = access 101 ! READ AS PORT 1 IS AN ACCESS PORT. VLAN 101 2 = access 102 ! READ AS PORT 2 IS AN ACCESS PORT. VLAN 102 99 = dot1q 1 nio_linux_eth:eth1 ! READ AS PORT 99 IS A TRUNK. ITS NATIVE VLAN IS VLAN 1. IT CONNECTS TO HOST ! ETH1 VIA A NIO_LINUX_ETH VIRTUAL/PHYSICAL “ADAPTER” x = -234.5 y = -47.0 hx = 12.0 hy = -35.0 [[ROUTER R1]] model = 3725 console = 2001 f0/0 = SW0 1 ! READ AS F0/0 CONNECTS TO SW0 PORT 1 x = -362.0 y = -214.0 [[ROUTER R2]] model = 3725 console = 2002 f0/0 = SW0 2 x = -119.0 y = -214.0 [GNS3-DATA] ! BELOW IS STRICTLY FOR GNS3 FOR VISUAL PURPOSES [[Cloud C0]] ! MAKE ME A PRETTY CLOUD AND CALL IT C0 x = -274.5 y = 100.0 hx = 48.5 hy = -24.0 connections = SW0:99:nio_linux_eth:eth1 ! THAT CLOUD WILL BIND SW0 PORT 99 TO HOST ETH1
Notice our configuration changes. We have deleted R3. R1 and R2 now have their f0/0 going to port one and port two on our vswitch. The vswitch has assigned port 1 as an access port under VLAN 101. Port 2 is assigned as an access port under VLAN 102. So we have two routers connecting to a switch. Also from the switch is the beginning of our trunk. Under the switch config you see port 99 (it’s virtual. Remember.) and that port is defined as a dot1q trunk and is bound to our Ubuntu host on eth1. I recommend leaving the native VLAN on the trunk port set to 1. So there is no confusion on the Host. So a packet leaving R1 is picked up the vswitch. The vswitch tags it VLAN101 (unbeknownst to the router) and forwards it to eth1 on the host. The host will not manipulate the frame at all. It will simply dump it out eth1 and onto the physical wire. The Breakout Switch will pick it up, honor the tag, and forward it appropriately to its respective interfaces within the same VLAN. The egress port on the breakout switch is configured as an access port and will therefore strip the tag. Loaded into the GNS3 application will give you something like this:
We are halfway there!
Now we will move on to the Breakout Switch. There are many different options available to use as a Breakout Switch. Our effort is to emulate as much of the R&S lab as possible. For that reason, we are using a Cisco 3750 as a Breakout Switch. You can use pretty much any old switch as a breakout switch and all your L3 traffic should be fine. However, in testing for this article, the best QnQ support for L2 protocols such as CDP, VTP, STP, etc. was achieved with a 3750 and a 4948. The older 3550 and 3560 switches (or 2900s) don’t seem to handle the QnQ configuration as smoothly. The result may be L2 protocols such as CDP only working in one direction. So we’ll use the 3750. Let’s take a look at our relevant configuration on the Breakout Switch:
NOTE: MTU adjusted here as well. This will require a reboot. Don’t forget
hostname BREAKOUT-SWITCH-1 ! system mtu routing 1546 vtp mode transparent ! ! vlan 101-102 ! ! interface FastEthernet1/0/1 description UP TO UBUNTU HOST switchport trunk encapsulation dot1q switchport trunk allowed vlan 101-102 switchport mode trunk l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp no cdp enable spanning-tree portfast ! interface FastEthernet1/0/13 description DOWN TO LAB-SWITCH-1 (gi0/13) switchport access vlan 101 switchport mode dot1q-tunnel l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp no cdp enable spanning-tree portfast ! interface FastEthernet1/0/14 description DOWN TO LAB-SWITCH-1 (gi0/14) switchport access vlan 102 switchport mode dot1q-tunnel l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp no cdp enable spanning-tree portfast
What have we accomplished? A packet leaving R1 is tagged by the vswitch. It is forward out the trunk port of the vswitch and off the eth1 on the Ubuntu host. The host dumps it onto the physical wire. It is picked up by the Breakout Switch on a L2 tunnel port. So, it forwards the traffic on to gi0/13 without manipulating it. Gi0/13 strips the tag since it is an access port and forwards it on to the downstream Lab Switch 1. The two endpoints (R1 and Lab Switch 1) aren’t aware of the tagging in the middle. The result? Transparency. This is crucial for when you are ready to study your L2 functions in your lab. CDP. STP. VTP. They all work bidirectionally as needed. You’ve now extended your virtual architecture to your physical hardware!
R1#sho debug CDP: CDP packet info debugging is on CDP events debugging is on CDP neighbor info debugging is on CDP IP info debugging is on R1# *Mar 1 00:33:27.839: CDP-IP: Cannot find stub network *Mar 1 00:33:27.839: CDP-PA: version 2 packet sent out on FastEthernet0/0 *Mar 1 00:33:34.235: CDP-PA: Packet received from LAB-SWITCH-1 on interface FastEthernet0/0 *Mar 1 00:33:34.239: **Entry NOT found in cache** *Mar 1 00:33:34.239: CDP-EV: Lookup for ip phone with idb= FastEthernet0/0 ip= 220.127.116.11 mac= 0019.06a8.b1c1 platform= cisco WS-C3560G-24TS R1# R1# R1#sho cdp ne 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 LAB-SWITCH-1 Fas 0/0 141 S I WS-C3560G Gig 0/13 R1#
Turning off CDP on all the interfaces of the Breakout Switch assures us there will be no duplication of CDP entries and confusion on the lab equipment.
NOTE: Often when configuring the end to end solution for something like this, you may get duplex or speed complaints on the virtual router and/or physical switch. We have:
Router-FE | Host-GE | BreakSW-FE | Lab-SW1-GE
So there is plenty of room for confusion. The best thing to do is to adjust your speed and duplex settings on the breakout switch interfaces. This way you can configure them in a way that makes the messages go away on your more important lab components. If you don’t know how to troubleshoot speed and duplex settings, you might not be ready for your lab.
The BIG PICTURE (Preparing an IPexpert .net file with physical switches)
So you’ve played around with your .net file and breakout switch and you’re pretty comfortable. It’s time to move up to the big league. We’re going to build out the IPexpert Version 4 Volume 1 workbook topology. Remain calm. Remember that just like the lab itself, all we are doing is adding layers. The fundamental technology remains the same. Here are our L2 and L3 topologies for reference. We will need to configure the virtual routers and make sure that the slots are assigned properly so that our ports match up as best as possible. We need to configure our frame-relay topology. We need to map all of the router-to-switch interfaces to unique VLANs to trunk them to the breakout switch. Then we need to assign the correct access ports on the breakout switch to be connected to our downstream 3560s. Good stuff.
If you’ve ever manually wired up a large lab you know that attention to detail can be the difference between your first four hours spent playing or your first four hours spent reverse engineering your bad cabling. This is no different. You have additional complexity of maintaining the transparent infrastructure in the middle. It’s not impossible. It’s actually easy. But good notes and attention to detail will makes things much easier. You’ve been warned.
Here we go…..
Matching up the slots/ports for everything in your lab can be difficult. Maybe impossible depending on the lab. GNS3 is somewhat limited in the layout of slots on the virtual routers. I’ve never not been able to test functionality. But sometimes, you can’t match up a lab diagram perfectly. In the past, what I have often found easiest is to pick a connection type and see if I can match all of that up. Say Ethernet. Can I match up all the Ethernet connections in the diagram to the slots/ports on virtual routers on GNS3? If so, I focus on that. Then, for the serial ports if I can’t match them up perfectly I will draw up a reference sheet that sits beside me when I’m doing my labs. If a workbook says S0/1/0 I immediately queue in on the serial reference and I know that in my GNS3 lab, the serial ports are close just remove the preceding 0 and make them S1/0 for example, etc. And I check my reference sheet to make sure I’m matching everything up. This works fine and I promise you won’t even notice it once you are waist deep in your layer three topology.
So let’s go ahead and build out the serial portion of the lab. This is contained completely within GNS3 and is the easiest to setup.
Note: My serial port assignments do NOT perfectly match up with the IPexpert topology above.
autostart = False [localhost:7200] workingdir = /home/foo/GNS3/working udp = 10000 [] image = /home/foo/GNS3/images/c7200-jk9o3s-mz.124-25-uncompressed.bin idlepc = 0x60678af0 ghostios = True sparsemem = True [] chassis = 3640 disk0 = 32 image = /home/foo/GNS3/images/c3640-jk9s-mz.124-13a-uncompressed.bin ram = 256 ghostios = True sparsemem = True idlepc = 0x607a012c [[ROUTER R1]] console = 2001 x = -599.040764008 y = -249.61731573 [[ROUTER R2]] console = 2002 slot1 = PA-4T+ slot2 = PA-4T+ s1/0 = FRSW 2 s2/0 = R5 s2/0 x = -594.586355052 y = 166.881377145 [[ROUTER R4]] console = 2004 slot0 = PA-4T+ s0/0 = FRSW 4 x = -599.326980614 y = -67.5875676485 [[ROUTER R5]] console = 2005 slot1 = PA-4T+ slot2 = PA-4T+ s1/0 = FRSW 5 s2/0 = R2 s2/0 x = -413.582473102 y = 168.527112893 [[ROUTER R6]] console = 2006 slot1 = PA-4T+ slot2 = PA-4T+ s1/0 = FRSW 6 s2/0 = R9 s2/0 s2/1 = R9 s2/1 x = -411.475729945 y = -58.4042176954 [[ROUTER R7]] console = 2007 slot0 = PA-4T+ s0/0 = R8 s0/0 x = 99.8068941512 y = -143.60076707 [[ROUTER R8]] console = 2008 slot0 = PA-4T+ s0/0 = R7 s0/0 x = 99.9323601145 y = 40.3514410148 [[ROUTER R9]] console = 2009 slot2 = PA-4T+ s2/0 = R6 s2/0 s2/1 = R6 s2/1 x = -410.810872155 y = -242.328637006 [[ROUTER BB1]] model = 3640 console = 2011 slot0 = NM-4E x = -165.043722602 y = -158.154328933 [[ROUTER BB2]] model = 3640 console = 2012 slot0 = NM-4E x = -160.81412458 y = -40.6010542815 [[ROUTER BB3]] model = 3640 console = 2013 slot0 = NM-4E x = -155.040421025 y = 94.9776619695 [[FRSW FRSW]] 2:204 = 4:402 2:205 = 5:502 2:206 = 6:602 2:214 = 4:412 2:215 = 5:512 2:216 = 6:612 2:224 = 4:422 2:225 = 5:522 2:226 = 6:622 4:402 = 2:204 4:405 = 5:504 4:406 = 6:604 4:412 = 2:214 4:415 = 5:514 4:416 = 6:614 4:422 = 2:224 4:425 = 5:524 4:426 = 6:624 5:502 = 2:205 5:504 = 4:405 5:506 = 6:605 5:512 = 2:215 5:514 = 4:415 5:516 = 6:615 5:522 = 2:225 5:524 = 4:425 5:526 = 6:625 6:602 = 2:206 6:604 = 4:406 6:605 = 5:506 6:612 = 2:216 6:614 = 4:416 6:615 = 5:516 6:622 = 2:226 6:624 = 4:426 6:625 = 5:526 x = -498.492430622 y = 56.7107926745 [GNS3-DATA] workdir = ../working
Notice I have only assigned serial ports and complimenting DLCIs on the frame switch. No Ethernet yet. Notice also that my serial connections do not perfectly match up with the port references in the lab. Again, this is relatively minor. You just need to remember it. For my own sanity, I assigned a PA-4T+ as needed on all my routers. That way, whenever you have a serial connection in your topology, you know it’s going to be x/y in your GNS3 setup. I’ve also drawn it into a Visio Diagram so I have it for a quick reference. Below is the GNS3 buildout and below that is my Visio Diagram.
Take a look at this copy (below) of the primary frame relay cloud:
For my personal reference, in the IPexpert workbook, R5 is attached to the Frame Cloud via S0/1/0. But I don’t have port 0/1/0 available. I put all my serials in slot 1 of my virtual routers. No problem. I’ll use port 1/0 instead. And I’ll document it on my Visio Diagram with “S 0/1/0 – 1/0” so I know that “port 0/1/0 on the workbook is actually port 1/0 on my virtual router”. Now I keep this Visio Diagram as a reference when I’m doing my labs. Usually, I only need it for less than an hour while I’m building my frame infrastructure.
Now let’s move on to the Ethernet connectivity. First, we know we are going to need several VLANs for the assignments from the vswitch downstream. Let’s go ahead and just map everything out in advance. We’ll document each routers Ethernet ports and give them a VLAN number. That will make configuring the vswitch much easier. While we are at it, let’s give them vswitch port assignments too. Remember that this is transparent to the actual lab equipment so VLAN assignment is arbitrary.
R1 0/0 – v102 – port 2 R1 0/1 – v103 – port 3 R2 0/0 – v104 – port 4 R2 0/1 – v105 – port 5 R4 0/0 – v106 – port 6 R4 0/1 – v107 – port 7 R5 0/0 – v108 – port 8 R5 0/1 – v109 – port 9 R6 0/0 – v110 – port 10 R6 0/1 – v111 – port 11 R7 0/0 – v112 – port 12 R7 0/1 – v113 – port 13 R8 0/0 – v114 – port 14 R8 0/1 – v115 – port 15 R9 0/0 – v116 – port 16 R9 0/1 – v117 – port 17 BB1 0/0 –v 118 – port 18 BB2 0/0 – v119 – port 19 BB3 0/0 – v120 – port 20
So let’s incorporate this into our .net file. First, the vswitch:
[[ETHSW SW0]] 2 = access 102 3= access 103 4= access 104 5= access 105 6= access 106 7= access 107 8= access 108 9= access 109 10= access 110 11= access 111 12= access 112 13= access 113 14= access 114 15= access 115 16= access 116 17= access 117 18= access 118 19= access 119 20= access 120 99 = dot1q 1 nio_linux_eth:eth1
Make sense? Good! Now let’s build out the full .net file!
Note: Sometimes when you save your file via GNS3 it moves some of the routers around in your config. Remain calm. It’s normal and ok. Go with it.
autostart = False [localhost:7200] workingdir = /home/foo/GNS3/working udp = 10000 [] image = /home/foo/GNS3/images/c7200-jk9o3s-mz.124-25-uncompressed.bin idlepc = 0x60678af0 ghostios = True sparsemem = True [] chassis = 3640 disk0 = 32 image = /home/foo/GNS3/images/c3640-jk9s-mz.124-13a-uncompressed.bin ram = 256 ghostios = True sparsemem = True idlepc = 0x607a012c [[ROUTER R1]] console = 2001 f0/0 = SW0 2 f0/1 = SW0 3 x = -599.040764008 y = -249.61731573 [[ROUTER R2]] console = 2002 f0/0 = SW0 4 ! SEND ALL TRAFFIC FROM Fa0/0 TO PORT 4 ON THE VSWITCH. R2 KNOWS NOTHING OF ANY ! VLANS OR TAGGING. f0/1 = SW0 5 slot1 = PA-4T+ slot2 = PA-4T+ s1/0 = FRSW 2 s2/0 = R5 s2/0 x = -594.586355052 y = 166.881377145 [[ROUTER R4]] console = 2004 f0/0 = SW0 6 f0/1 = SW0 7 slot0 = PA-4T+ s0/0 = FRSW 4 x = -599.326980614 y = -67.5875676485 [[ROUTER R5]] console = 2005 f0/0 = SW0 8 f0/1 = SW0 9 slot1 = PA-4T+ slot2 = PA-4T+ s1/0 = FRSW 5 s2/0 = R2 s2/0 x = -413.582473102 y = 168.527112893 [[ROUTER R6]] console = 2006 f0/0 = SW0 10 f0/1 = SW0 11 slot1 = PA-4T+ slot2 = PA-4T+ s1/0 = FRSW 6 s2/0 = R9 s2/0 s2/1 = R9 s2/1 x = -411.475729945 y = -58.4042176954 [[ROUTER R7]] console = 2007 f0/0 = SW0 12 f0/1 = SW0 13 slot0 = PA-4T+ s0/0 = R08 s0/0 x = 99.8068941512 y = -143.60076707 [[ROUTER R8]] console = 2008 f0/0 = SW0 14 f0/1 = SW0 15 slot0 = PA-4T+ s0/0 = R7 s0/0 x = 99.9323601145 y = 40.3514410148 [[ROUTER R9]] console = 2009 f0/0 = SW0 16 f0/1 = SW0 17 slot2 = PA-4T+ s2/0 = R6 s2/0 s2/1 = R6 s2/1 x = -410.810872155 y = -242.328637006 [[ROUTER BB1]] model = 3640 console = 2011 slot0 = NM-4E f0/0 = SW0 18 x = -165.043722602 y = -158.154328933 [[ROUTER BB2]] model = 3640 console = 2012 slot0 = NM-4E f0/0 = SW0 19 x = -160.81412458 y = -40.6010542815 [[ROUTER BB3]] model = 3640 console = 2013 slot0 = NM-4E f0/0 = SW0 20 x = -155.040421025 y = 94.9776619695 [[ETHSW SW0]] 1 = access 101 2 = access 102 3 = access 103 4 = access 104 ! ON THE VSWITCH, THE CONNECTION IS RECEIVED AND A TAG IS APPLIED 5 = access 105 6 = access 106 7 = access 107 8 = access 108 9 = access 109 10 = access 110 11 = access 111 12 = access 112 13 = access 113 14 = access 114 15 = access 115 16 = access 116 17 = access 117 18 = access 118 19 = access 119 20 = access 120 99 = dot1q 1 nio_linux_eth:eth1 ! THAT TAGGED TRAFFIC IS DUMPED TO THIS TRUNK PORT, THEN FED TO HOST ETH1, ! THEN OFF TO YOUR BREAKOUT SWITCH WITH THE TAG STILL APPLIED. x = -246.5 y = -269.0 [[FRSW FRSW]] 2:204 = 4:402 2:205 = 5:502 2:206 = 6:602 2:214 = 4:412 2:215 = 5:512 2:216 = 6:612 2:224 = 4:422 2:225 = 5:522 2:226 = 6:622 4:402 = 2:204 4:405 = 5:504 4:406 = 6:604 4:412 = 2:214 4:415 = 5:514 4:416 = 6:614 4:422 = 2:224 4:425 = 5:524 4:426 = 6:624 5:502 = 2:205 5:504 = 4:405 5:506 = 6:605 5:512 = 2:215 5:514 = 4:415 5:516 = 6:615 5:522 = 2:225 5:524 = 4:425 5:526 = 6:625 6:602 = 2:206 6:604 = 4:406 6:605 = 5:506 6:612 = 2:216 6:614 = 4:416 6:615 = 5:516 6:622 = 2:226 6:624 = 4:426 6:625 = 5:526 x = -498.492430622 y = 56.7107926745 [GNS3-DATA] workdir = ../working [[Cloud C0]] x = -54.5 y = -285.0 connections = SW0:99:nio_linux_eth:eth1
Loaded into GNS3, your topology may look something like:
OK! Our virtual lab is looking good. In theory, everything virtual is in place. Traffic leaving any Ethernet interface on any router will be tagged at the vswitch and dumped out eth1 of the Ubuntu host. Now, let’s move on to the Breakout Switch config. This is another place where a little pre-planning can save us. Refer to the cheat sheet we used to configure the vswitch for the .net file. We need to get each VLAN to a specific interface that strips the tag and dumps it out to the correct port on the lab 3560 at the other end.
Note: Don’t forget to adjust the MTU and reboot if you haven’t already!
! hostname BREAKOUT-SWITCH-1 ! system mtu routing 1546 vtp mode transparent ! ! vlan 102-120 ! ! interface FastEthernet1/0/1 description UP TO UBUNTU HOST switchport trunk encapsulation dot1q switchport trunk allowed vlan 102-120 ! ALL THE TAGGED FRAMES ARE RECEIVED HERE AND PROCESSED PROPERLY ACCORDING TO THE CONFIG switchport mode trunk l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp no cdp enable spanning-tree portfast no shut ! interface range fa1/0/2 – 21 no cdp enable spanning-tree portfast l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp switchport mode dot1q-tunnel no shut ! interface FastEthernet1/0/2 description GNS3-R1-Fa0/0 To Physical Switch Cat1-Fa0/1 switchport access vlan 102 ! THE VLAN TAG IS STRIPPED HERE BEFORE BEING DUMPED TO THE DOWNSTREAM ! LAB SWITCH. SO THE LAB SWITCH NEVER SEES ANYTHING “ODD”! ! interface FastEthernet1/0/3 description GNS3-R1-Fa0/1 To Physical Switch Cat2-Fa0/1 switchport access vlan 103 ! interface FastEthernet1/0/4 description GNS3-R2-Fa0/0 To Physical Switch Cat1-Fa0/2 switchport access vlan 104 ! interface FastEthernet1/0/5 description GNS3-R2-Fa0/1 To Physical Switch Cat2-Fa0/2 switchport access vlan 105 ! interface FastEthernet1/0/6 description GNS3-R4-Fa0/0 To Physical Switch Cat1-Fa0/4 switchport access vlan 106 ! interface FastEthernet1/0/7 description GNS3-R4-Fa0/1 To Physical Switch Cat3-Fa0/4 switchport access vlan 107 ! interface FastEthernet1/0/8 description GNS3-R5-Fa0/0 To Physical Switch Cat1-Fa0/5 switchport access vlan 108 ! interface FastEthernet1/0/9 description GNS3-R5-Fa0/1 To Physical Switch Cat3-Fa0/5 switchport access vlan 109 ! interface FastEthernet1/0/10 description GNS3-R6-Fa0/0 To Physical Switch Cat2-Fa0/6 switchport access vlan 110 ! interface FastEthernet1/0/11 description GNS3-R6-Fa0/1 To Physical Switch Cat4-Fa0/6 switchport access vlan 111 ! interface FastEthernet1/0/12 description GNS3-R7-Fa0/0 To Physical Switch Cat2-Fa0/7 switchport access vlan 112 ! interface FastEthernet1/0/13 description GNS3-R7-Fa0/1 To Physical Switch Cat4-Fa0/7 switchport access vlan 113 ! interface FastEthernet1/0/14 description GNS3-R8-Fa0/0 To Physical Switch Cat2-Fa0/8 switchport access vlan 114 ! interface FastEthernet1/0/15 description GNS3-R8-Fa0/1 To Physical Switch Cat4-Fa0/8 switchport access vlan 115 ! interface FastEthernet1/0/16 description GNS3-R9-Fa0/0 To Physical Switch Cat2-Fa0/9 switchport access vlan 116 ! interface FastEthernet1/0/17 description GNS3-R9-Fa0/1 To Physical Switch Cat4-Fa0/9 switchport access vlan 117 ! interface FastEthernet1/0/18 description GNS3-BB1-E0/0 To Physical Switch Cat1-Fa0/11 switchport access vlan 118 ! interface FastEthernet1/0/19 description GNS3-BB2-E0/0 To Physical Switch Cat2-Fa0/12 switchport access vlan 119 ! interface FastEthernet1/0/20 description GNS3-BB3-E0/0 To Physical Switch Cat2-Fa0/13 switchport access vlan 120 !
That’s it. Nothing is configured on the end “lab” switches. Remember, those are for actual lab work so you need to be able to erase/reload/etc. on a regular basis. The Breakout Switch config is static and once you are up and running you shouldn’t be messing with that config much unless you are modifying the actual topology of your lab.
Let’s update our Visio Diagram. We aren’t including the transparent gear in this for a reason. We just want to see our lab. All the Ethernet connections match up so it should look pretty good.
Looks pretty good! We are basically running a full IPexpert topology with a single Ubuntu host and 5 switches. 1 Breakout and our 4 lab switches are all we needed to complete this. Now get to studying!
Easy Bonus Points
First, in case it wasn’t already clear, it is very easy to save your configs. When you are finished with a lab and want to save the configs to reload them later:
1. Write your configs to memory like normal.
2. On the top of your GNS3 GUI is a yellow arrow. In newer versions of GNS3 the icon has changed but not the location. It is for “Extract/Import startup configs”.
4. Click it.
5. Select Export.
6. Select the directory you want to save your configs to.
7. That’s it. Shut down your GNS3 topology and clear it.
8. When you are ready to get back to work load your topology, import your configs back, then turn on all your devices.
Don’t forget your switches aren’t part of your GNS3 topology. You need to save them as well.
Second, even with a beefy workstation GNS3 can put a lot of load on your PC. We aren’t here to get into tuning options. That’s a different article. But when you load up your routers with BGP and OSPF they can get a little sluggish. This is one of the reasons a dedicated PC is better. Even if your dedicated PC is running 60-80% with a GNS3 lab, you can still telnet to the virtual routers consoles remotely from your LAN/WAN. In the full .net file a little ways up, you can see R4s console in the .net file defined as 2104. That’s all you need. If your Ubuntu host has two NICs, Eth1 will be dedicated to the lab. Eth0 will be connected to your LAN/WAN. If it’s address is 192.168.1.123, then you can telnet to the console of R4 simply by telnetting to 192.168.1.123 port 2104. So you can sit comfortably at your work laptop while your noisy dedicated PC is in the other room. Most folks don’t think about this but the capability is there and very easy. For access to the switches, a terminal server with 5 ports will have you can access everything via “console” remotely.
If you can connect a lab switch and it’s transparent, what else? PIXs? ASAs? Servers? IP phones? Can you attach VMs to your virtual routers? Yes. Yes. Yes. Think about it. You can spin up a very nice Security lab. Or a Voice Lab. Or a Service Provider Lab. Or…….
Speed. As mentioned previously, speed can be tricky. We have FE interfaces on all the main routers. The BB routers are all 10Mbps interfaces. R2 has a GE interface. This are passed to a virtual switch and then on down to a Gig port on the Ubuntu Host. From there, a 100Mbps Breakout Switch and then off to Gigabit lab switches. Confused? So was I. My recommendation when implementing GNS3 with physical gear and transparent equipment in the middle is to just forget about playing with speed. You still have your gig link between S1 and S2 that is completely on the physical infrastructure and you can use that along with your 100mbps links to test STP and loop avoidance. If you see speed/dup issues on your gear, adjust your breakout switch accordingly and don’t waste time playing with non lab related stuff.
Quarks. Many people on the forums and study lists complain of inconsistencies with using GNS3. It is very rare that I see an issue with this. If you use your Ubuntu host for other applications there is always potential for problems. I always recommend a dedicated machine. It’s not that much of an investment for what your end goal is. If you catch something odd in your labbing, think thru it. Is it a “network” issue? If so, it’s probably part of your lab. Seriously. If it’s something in the frame such as an odd message, think it thru. If you are positive it’s not your lab (workbook assignment) and it’s interfering with your work, save your configs and bounce the topology. It won’t hurt and you’ll be back up and running in the time it takes you to go get another Jolt cola.
Ubuntu, GNS3 and Q&Q. It’s really cool what you can accomplish with this setup. We haven’t even touched the beginning of it. But this has NOTHING to do with your R&S exam. DON’T LOSE FOCUS. Get it up and running and stable and then leave it alone. Focus on your workbooks and studying. Play with Ubuntu after you have your number.
Resources. They are out there. A few are listed below. There are many people out there that know more than you or I ever will. Reach out to them. Mind the forum rules. Check your math first. Then ask. Someone is always standing by to help.
CCIE # 13513 R&S, Security, and SP