Friday, August 12, 2011

Q-in-Q from GNS3

Following on from the previous post stating my intentions, I have been messing about with GNS3, the graphical front-end to Dynamips and Dynagen.  GNS3 is great for simulating Cisco routers, however it cannot easily do the same for switches, as much of the functionality of switches is performed in custom silicon.

I did all of my routing lab preparation for the CCNP using GNS3, and am looking to do the same for the CCIE.  However, what to do about switches?  Well, I'll have to buy some.  Which means I'll need to connect the simulated routers to the real world.  There are many posts elsewhere about how to do it, so I am going to just put up a quick post about Q-in-Q, and connecting GNS3 to a set of real-word switches and extending layer 2 between them.

First, connecting GNS3 to the real world.  I am running GNS3 on Ubuntu in a VMWare Workstation guest OS.  So, first, I bridged the eth0 of the VM to the ethernet interface on my laptop.  The only limitation I can see going forward here is that I can't seem to increase the MTU of the guest OS eth0.  Any VMWare/Linux gurus out there, let me know, but when I search, it appears it can be done in VMWare Workstation.  It shouldn't be a problem unless I start punting around large packets.

My laptop has a Broadcom chipset, and once I got underway, I was experiencing problems because the interface was dropping the VLAN tags.  I found that I had to edit the registry (host OS is Windows 7) and search for (what should be the only instance of):

TxCoalescing Ticks

And in the same place, add a new String Value:

with a value of "1".

If you have a different ethernet chipset, you may need to sort this out, too.  Anyhow, next I connected my laptop ethernet to a 3560 switch, which is connected to a 2960 switch where my target test PC is located.  The 2960 has a VLAN for the PC, VLAN 5.  This is the "client" VLAN to be tunnelled to the router.

Now, in GNS3, I connected a generic switch to the real ethernet interface with an 802.1q trunk.  Then a router, connected to an access port, VLAN 7.  VLAN 7 is going to be the host VLAN carrying the tunneled client VLAN(s) for this router (R3 in the diagram; R1 and R2 are shut down).

On the router, R3, I create a subinterface tagged with the "client" VLAN, VLAN 5.  Now, for the Q-in-Q magic.  The port on the 2960 connecting to the 3560 is configured as a normal trunking port, carrying the client VLAN.  On the 3560, the port is configured as a dot1q-tunnel port, with the access VLAN of 7 (the host VLAN).  So essentially what is happening as a packet is sent from the target PC is the following:

  • The PC sends a frame and it arrives on the 2960.  This is on an access port, VLAN 5.
  • The 2960 forwards the frame to the 3560 via the dot1q trunk, adding the VLAN 5 tag.
  • The 3560 recieves this frame on its Q-in-Q interface.  A second VLAN tag is added to the existing frame, VLAN 7.  This frame is then forwarded to the GNS3 virtual switch.
  • The GNS3 ethernet switch receives the frame on the dot1q trunk, and strips the VLAN 7 tag from the frame.  This leaves a dot1q frame tagged with VLAN 5.  This is forwarded to the router, which accepts it on the subinterface.
In the reverse direction:

  • The router sends a frame, tagged with VLAN 5 to the GNS3 ethernet switch.  The switch adds the VLAN 7 tag and forwards it to the 3560.
  • The 3560 receives the frame, strips the VLAN 7 tag and forwards it to the 2960.
  • The 2960 strips the VLAN 5 tag and forwards the frame to the PC.
In a proper Q-in-Q tunnel situation, switches at either end of a provider cloud would add and remove tages, but here, essentially the GNS3 router and switch are doing a VLAN hopping-type thing.  Security admins everywhere are having palpitations.

And there you have it.  In addition, som l2protocol-tunnel commands allow the router and switch to seem adjacent.  In some cases, especially with GNS3 this does not hold, but it seems to work OK.  So, here is the topology of the GNS3, and the configuration (click to enlarge).

And the result from the router pinging the PC:


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/18/40 ms
 And the CDP, showing the adjacency of the virtual router and 2960 switch:

Router#sho cdp nei
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
bldg-a-cc.9bc0   Fas 0/0            173          S I      WS-C2960P Gig 0/1

And on the switch:

bldg-a-cc.9bc0#sho cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
Router           Gig 0/1           149             R S I  3725      Fas 0/0

So there you have it a Q-in-Q connection from GNS3 to some real switches.  And to prove (although you still need to take my word for it) that I actually have switches, here there are.

1 comment:

  1. Awesome Blog.
    BTW, you can also use 2600 router with NM-16ESW module for switching.
    My Blog -