(For more resources related to this topic, see here.)
You will observe multiple TCP connections and UDP pipes being created from both the GNS3 management console and your operating system’s command line. To get a closer look at how the conductor works, open GNS3 to a new blank canvas and issue the command debug 3 in the GNS3 command console :
=> debug 3
As you open GNS3, the conductor readies the players awaiting your instructions. The moment you drag your first Cisco router onto the workspace, GNS3 spawns an instance of Dynamips and connects to it on port 7200. You can see this in two places:
To reproduce the effects shown here, use a C7200 router image with 256MB RAM.
- By issuing a netstat–a command in a Windows/Linux/OS X command window:
C: >netstat -an … Proto Local Address Foreign Address State TCP 127.0.0.1:7200 0.0.0.0:0 LISTENING TCP 127.0.0.1:7200 127.0.0.1:49194 ESTABLISHED TCP 127.0.0.1:49194 127.0.0.1:7200 ESTABLISHED
- In the output of the GNS3 management console. The following output lines are abbreviated to conserve space:
Hypervisor manager: connecting on 127.0.0.1:7200 Hypervisor manager: connected to hypervisor on 127.0.0.1 port 7200
Also in the output of the GNS3 management console , note the following (trimmed) lines:
Hypervisor manager: hypervisor base UDP is 10001 …<snip>… PORT TRACKER: allocate port 2101 sending to dynamips at 127.0.0.1:7200 -> vm set_con_tcp_port R1 2101 returned -> [‘100-OK’] PORT TRACKER: allocate port 2501 sending to dynamips at 127.0.0.1:7200 -> vm set_aux_tcp_port R1 2501 returned -> [‘100-OK’]
The UDPbase port I’ll deal with shortly, but notice that GNS3 has told Dynamips to prepare to open ports 2101 and 2501 for console and AUX port communications respectively, which are the base ports defined in GNS3 Preferences for the Dynamips setting under the Dynamips tab. Also note that these ports are not yet opened, in the orchestral analogy you could say they are merely being tuned up at this stage.
Next, add a second router and observe (in the console output) that the console and AUX port allocations have incremented by one, but there is no change to the base UDP port.
sending to dynamips at 127.0.0.1:7200 -> vm set_con_tcp_port R2 2102 sending to dynamips at 127.0.0.1:7200 -> vm set_aux_tcp_port R2 2502
You are about to connect these two devices. Configure them with FastEthernet interfaces if necessary, or use the FastEthernet Add a link tool, and connect the two routers. Watch the console output for these lines:
Connect link from R1 f1/0 to R2 f1/0 new base UDP port for dynamips at 127.0.0.1:7200 is now: 10002 new base UDP port for dynamips at 127.0.0.1:7200 is now: 10003 sending to dynamips at 127.0.0.1:7200 -> nio create_udp nio_udp0
10001 127.0.0.1 10002 sending to dynamips at 127.0.0.1:7200 -> nio create_udp nio_udp1
10002 127.0.0.1 10001 sending to dynamips at 127.0.0.1:7200 -> vm slot_add_nio_binding R1
1 0 nio_udp0 sending to dynamips at 127.0.0.1:7200 -> vm slot_add_nio_binding R2
1 0 nio_udp1
And on your host computer, netstat -an reveals:
C:> netstat -an | find “1000” UDP 0.0.0.0:10001 *:* UDP 0.0.0.0:10002 *:*
Understanding what is going on here is the key to understanding how Dynamips achieves communication between routers. What has just happened is that a UDP tunnel has been created between these two devices.
UDP tunnel concept
Links between devices in GNS3 is achieved using UDP tunnels. What this means in this scenario is that whenever R1 sends a frame from interface f1/0, the entire frame, including the Source MAC address, destination MAC address and payload, gets put inside a UDP packet with a source port of 10001 and a destination IP address:destination port of 127.0.0.1:10002 which means that the frame will end up at R2’s f1/0 interface because it is bound to port 10002. The return frames take the reverse path: source port 10002, destination IP:port 127.0.0.1:10001.
To illustrate this, I assigned an IP addresses of 1.1.1.1 and 1.1.1.2 to interface f1/0 on R1 and R2 respectively, then captured a ping packet on the link between R1 and R2 on the host computer’s loopback interface. The Wireshark capture shown in the following screenshot shows a ping packet from 1.1.1.1 on its way to 1.1.1.2, but you can see that the entire layer 2 frame (1), including the layer 2 MAC addresses of R1 and R2 is encapsulated inside a UDP packet travelling from 127.0.0.1:10001 to 127.0.0.1:10002 (2).
Another thing to note is that the first UDP port used was the Base UDP port defined in GNS3 Preferences, Dynamips settings under the Dynamips tab.
Now would also be a good time to issue a show run command in the GNS3 management console window, to see how GNS3 is building up your topology.net file.
=> show runautostart = False [127.0.0.1:7200] workingdir = C:UserschrisAppDataLocalTempGNS3_rwftbworking udp = 10001 [[7200]] image = C:UserschrisGNS3Imagesc7200-p-mz.124-10a.image ram = 256 idlepc = 0x60750000 sparsemem = True ghostios = True [[ROUTER R1]] console = 2101 aux = 2501 slot1 = PA-2FE-TX f1/0 = R2 f1/0 [[ROUTER R2]] console = 2102 aux = 2502 slot1 = PA-2FE-TX f1/0 = R1 f1/0
Note that the amount of RAM set for each of these routers is 256MiB. Also recall that in the Hypervisor Manager settings previously shown, the Memory limit per hypervisor was set to 512MiB.
Now add another router, and watch the console output, and check your host computer’s TCP connections again with the netstat -an command. You will see of course:
Hypervisor manager: connecting on 127.0.0.1:7201
and…
TCP 127.0.0.1:7201 0.0.0.0:0 LISTENING
This shows that a second hypervisor instance has been created, and allocated TCP port 7201 for communication. You will also see this reflected in the configuration information if you issue another a show run command in the GNS3 management console window.
…<Output omitted>… [127.0.0.1:7201] workingdir = C:UserschrisAppDataLocalTempGNS3_rwftbworking udp = 10101
This also reveals that the base UDP port for this hypervisor is 10101, recall that the value for the UDP incrementation in the Dynamips Hypervisor Manager setting page was 100, so the base UDP port for this instance of the hypervisor is 100 greater than the general base UDP port of 10001 for Dynamips.
You can probably predict what UDP port numbers will be used then if you now connect R2 to R3 with a FastEthernet link. Make the link and see if your prediction was correct:
sending to dynamips at 127.0.0.1:7200 -> nio create_udp
nio_udp2 10003 127.0.0.1 10101 sending to dynamips at 127.0.0.1:7201 -> nio create_udp nio_udp3
10101 127.0.0.1 10003 sending to dynamips at 127.0.0.1:7200 -> vm slot_add_nio_binding R2 1 1 nio_udp2 sending to dynamips at 127.0.0.1:7201 -> vm slot_add_nio_binding R3 1 0 nio_udp3
Did you predict that the next connection would be made from port 10003 to 10101? Well done.
But what if you add a switch or a hub? Add a generic Ethernet switch to the topology, and issue a show run command in the GNS3 management console window. You will notice that there is NO reference to the switch in the output, and in fact if you saved your topology at this point and loaded it later, there would be no switch in your topology. That is because the switch doesn’t get allocated to a hypervisor until it has at least one connection to another item in the topology. The question is, since our topology has two hypervisors running, which hypervisor will be allocated the switch?
Connect your recently added switch to R1. Observe what happens in the GNS3 management console, and issue another show run command in the GNS3 management console window. Here is what you are looking for:
Firstly, you should see the connections being created. Note that the UDP port numbers are from the range allocated to the first hypervisor that was spawned, NOT the most recent hypervisor spawned.
sending to dynamips at 127.0.0.1:7200 ->
nio create_udp nio_udp4 10004 127.0.0.1 10005 sending to dynamips at 127.0.0.1:7200 -> nio create_udp nio_udp5
10005 127.0.0.1 10004
Secondly, in the topology description, you can see that SW1 has been assigned to the hypervisor running on TCP port 7200 which allocated UDP ports from the 10000+ range. What actually happens is that GNS3 assigns generic devices like switches, hubs, and clouds to the hypervisor to which the device is first connected.
=> show run autostart = False [127.0.0.1:7200] workingdir = C:UserschrisAppDataLocalTemp udp = 10001 [[7200]] … [[ETHSW SW1]] 1 = access 1 R1 f1/1 [[ROUTER R1]] …
And finally, if you changed your Memory usage per hypervisor setting back on page 73, don’t forget to change it back. I recommend setting it to 1024MiB .
By now you are probably wondering how GNS3 and Dynamips deal with the other supported emulators: Qemu and Oracle VirtualBox .
Conducting Qemu and VirtualBox
Recall that Dynamips is a hypervisor used to initiate the spawning of Cisco router VMs (virtual machines) instances, and configure host communication to these VMs via console AUX and virtual network interfaces.
Just like Dynamips, both Qemu and Oracle VirtualBox follow a similar hypervisor model, only in this case the hypervisor is “wrapped” to give it similar functionality to Dynamips. The wrappers for the hypervisors are called qemuwrapper and vboxwrapper respectively, and these wrappers listen on ports 10525 and 11525 as shown in the configuration options in GNS3 Preferences under the Qemu and VirtualBox settings.
Trivia: Port 10525 was chosen by Thomas Pani when he wrote pemuwrapper, the wrapper for the PIX 525 emulator, port 1525 was already assigned by the IANA. Pemuwrapper evolved into qemuwrapper, and when Alexey Eromenko, alias “Technologov” wrote vboxwrapper he simply added 1000 to the qemuwrapper port number.
Again, just like Dynamips, you can run qemuwrapper and vboxwrapper as standalone applications, then telnet to port 127.0.0.1:10525 or 127.0.0.1:11525 to issue commands like qemu version or vbox version or the commands to spawn a virtual machine if you bothered to learn the syntax.
Again, like Dynamips, qemuwrapper and vboxwrapper direct the TCP port to be used for console connections and UDP port for UDP tunnel connections, the base values for these can also be found in GNS3 Preferences under the Qemu and VirtualBox settings.
But unlike Dynamips, the wrapper is NOT the hypervisor as well. The hypervisor is Qemu or VirtualBox, so these applications had to be compiled to allow communication via UDP tunnel interfaces. In the case of Qemu prior to Version 1.1, this required a specially compiled version. The GNS3 downloads page has links to the patched Version 0.11 that I used throughout this article. VirtualBox has built-in support for UDP tunnels.
To see the full GNS3 orchestra playing, you can now add Qemu and VirtualBox devices to your topology and watch the GNS3 management console and check your TCP/UDP connections with the netstat -an command. As you watch the GNS3 management console you will see the hidden power of GNS3 beyond the GNS3 GUI as it conducts its orchestral sections of Dynamips, qemuwrapper, and vboxwrapper to play in harmony, and even see that they have their own sections in the GNS3 topology.net file, as can be seen by issuing a show run command in the GNS3 management console .
Summary
This article covers all we need to know about the GNS3 Orcehstra—the GNS3 GUI
Resources for Article:
Further resources on this subject:
- Editing attributes [Article]
- iPhone JavaScript: Installing Frameworks [Article]
- Visualizing my Social Graph with d3.js [Article]