This option doesn’t use the virtual switch to tag traffic but VLAN interfaces directly defined on the host (like sub interfaces on Cisco routers). GNS3 virtual routers then connect to their respective VLAN interface that tag and receive tagged frames corresponding to the vlan id. The breakout switch is still in charge of dispatching frames to the correct physical switch based on the 802.1Q tag. All the physical cabling and configuration is exactly the same as the virtual switch option. The requirements are also the same plus your physical network interface must support VLANs configuration.
Table of Contents
Topology
The following topology has been made on Linux but excepting the real network interface name, the lab is gonna be the same on Windows and Linux.
We will follow the same topology as with the virtual switch option, 2 routers and 2 real switches but this time of course no virtual switch. Our physical network interface is named eth4 (on Linux). 2 vlan interfaces are created, eth4.101 for vlan 101 and eth4.102 for vlan 102. R1 is bidden to eth4.101 and R2 to eth4.102 using the GNS3 cloud.
Host configuration
The direct VLAN mapping option requires a bit of configuration on the host.
Linux
Linux is the easiest to configure when it comes to VLAN mapping. Here we used Linux Ubuntu 11.10 and an USB-to-Ethernet adapter (named eth4 in Linux).
In order to create vlan interface on Linux, we need the vconfig utility that you can install using apt-get:
user@host:~$ sudo apt-get install vlan
Second requirement is to load the module for 802.1q support:
user@host:~$ sudo modprobe 8021q
At this point we can start to add vlan interfaces:
user@host:~$ sudo vconfig add eth4 101 Added VLAN with VID == 101 to IF -:eth4:- user@host:~$ sudo vconfig add eth4 102 Added VLAN with VID == 102 to IF -:eth4:-
Once defined, it is best to disable and enable the main interface to avoid any issue:
user@host:~$ sudo ifconfig eth4 down user@host:~$ sudo ifconfig eth4 up
Check that the vlan interfaces have correctly been created:
user@host:~$ ifconfig eth4.101 Link encap:Ethernet HWaddr 00:60:6e:05:0d:e6 inet6 addr: fe80::260:6eff:fe05:de6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:590 errors:0 dropped:0 overruns:0 frame:0 TX packets:159 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:35456 (35.4 KB) TX bytes:18749 (18.7 KB) eth4.102 Link encap:Ethernet HWaddr 00:60:6e:05:0d:e6 inet6 addr: fe80::260:6eff:fe05:de6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:595 errors:0 dropped:0 overruns:0 frame:0 TX packets:145 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:36050 (36.0 KB) TX bytes:17507 (17.5 KB)
Now we can connect virtual routers to vlan interfaces, don’t forget that GNS3 must be started as root.
To check that everything works, we can ping from R2 which has 2 sub-interfaces, respectively in vlan 10 and vlan 20 while capturing traffic on eth4. We can see the frames have 2 tags as expected (102 and 10). If we do the capture on vlan interface eth4.102, we can see the frames as they come in and out of R2 f0/0 without the vlan interface tag (102) but still tagged in vlan 10. Our QinQ connectivity works well!
R2#ping 10.2.10.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.2.10.254, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/32 ms R2#ping 10.2.20.254
Making it permanent
If you reboot Linux now you will lose all your vlan mapping configuration. We need to make the configuration permanent and there are 2 options, one is to add our configuration in Linux configuration files and the second is to create a script that we can start when needed.
Let’s do the first option and have the 802.1q module loads on boot:
user@host:~$ sudo su -c 'echo "8021q" >> /etc/modules'
It’s turn to define the vlan interfaces to be created on boot by adding the following lines in /etc/network/interfaces:
iface eth4 inet manual auto eth4.101 iface eth4.101 inet static address 0.0.0.0 netmask 0.0.0.0 mtu 9000 vlan-raw-device eth4 auto eth4.102 iface eth4.102 inet static address 0.0.0.0 netmask 0.0.0.0 mtu 9000 vlan-raw-device eth4
Second option, the script that can be manually started when needed:
#!/bin/bash modprobe 8021q ifconfig eth4 mtu 9000 vconfig add eth4 101 vconfig add eth4 102 ifconfig eth4 down ifconfig eth4 up
Windows
It can be really tricky to create vlan interfaces on Windows, in fact Windows itself doesn’t support that (don’t know about server editions, here I used Windows 7 Professional). This means you will have to rely on software utilities, usually provided by the network card constructor and made to work only with their cards. Broadcom and Intel provide these tools.
For Broadcom network cards, I used the Broadcom Advanced Control Suite 3 software, which by the way is far from being intuitive:
Once the configuration done in BACS3, the software creates vlan virtual interfaces in Windows:
We can then use these vlan interfaces in the same way as in our Linux example. Be warned that if you added the PreserveVlanInfoInRxPacket key in the registry like we did in the USB-to-Ethernet adapters option, your vlan interfaces will receive frames tagged with their respective vlan id, your virtual routers don’t know about these tags, consequently it will not work as it should.
For Intel network cards, the Intel PROSet utility can be used to create vlan interfaces:
Note that I did not find a way to define vlan interface for the ASIX AX88772 USB-to-Ethernet adapter. Therefore, it was impossible to use this option with USB adapters.
Mac OS X
It is quite easy to create vlan interfaces on OSX as it is natively supported. On my MacBook Pro, the integrated network interface (en0) and ASIX AX88772 USB-to-Ethernet adapter (en3) both support VLANs as indicated by the networksetup utility on the command line:
$ networksetup -listdevicesthatsupportVLAN en3 (USB Ethernet) en0 (Ethernet)
Next, I added 2 vlan interfaces using Mac OS X System Preferences -> Network -> Manage Virtual Interfaces.
Once the configuration done, we can use the networksetup command to verify the current vlan mapping configuration:
$ networksetup -listVLANs
VLAN User Defined Name: VLAN101
Parent Device: en0
Device ("Hardware" Port): vlan0
Tag: 101
VLAN User Defined Name: VLAN102
Parent Device: en0
Device ("Hardware" Port): vlan1
Tag: 102
Like on Linux and Windows, we can connect our virtual routers to vlan interfaces but unlike the other platforms, I haven’t been successful to make it work. As you can see on the screenshots, en0 sends and receives tagged frames correctly but it looks like that vlan0 (and any other vlan interfaces) never receives unicast tagged frames with vlan id 101; however broadcast frames are correctly received as I can see CDP neighbor on both sides. If you know the solution to this issue, please contact me.
Pros and cons
The pros:
- A single cable from the PC.
- Can bind virtual machines directly host vlan interfaces.
The cons:
- Requires an extra switch for the vlan breakout.
- May be problematic to configure on Windows, depending on the used NIC.
- Did not make it work on OSX.
- Need a expensive breakout switch to have layer 2 tunneling working both ways.
- The network interface must support 802.1Q
Conclusion
The direct VLAN mapping option can be a hell to configure, especially if not using Linux. The advantage is this option is that you can use host vlan interfaces as you want to communicate with your switches, you are not limited to the devices supported in GNS3.
