Hi,

I did a quick study to support IOU in GNS3/Dynagen last week but you have done a deeper analysis than me, this is really cool and this is gonna help I, Pavel or someone else (any volunteer ? ;)) to think how we could integrate IOU.

Creating Qemu, Dynamips and IOU networks would really be awesome ;)

Cheers,

_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.

A new frontier is open ;))

I also have interest in connection to real network and traced IOU a little bit. I diffinitely see point and agree with this


But it is also true that I suffered previous few days much, trying to win all the awkwardness of gns gui and had about 20 segfalts in short term with version 0.7.3. I think for man going Cisco it's not that difficult to use command line and text file.

My idea connecting IOU to real network was to use linux bridge utils. I started blog to write about that http://crypt47.blogspot.com/2011/01/iou-exploration.html

But didn't get too far with coding(I'm not a real programmer). Hope link to perl implementation will help.

Absolutely. Let me know if you need anything, I'm more than happy to contribute.


I tend to agree, dealing with text files and a shell prompt is part of an engineers skill set. On the flip side, its hard to push people into a certain direction; if one prefers GUIs to control his topology and is eager to learn networking, why lock him out?

Integrating IOU into the GNS GUI portion might not be the hard part. I understand that with GNS, a customized version of dynagen does the heavy lifting behind the scenes - once IOU integration is built into dynagen/a wrapper, it can be integrated into GNS too. If you prefer CLI operation, just use the modified dynagen version. This is what I would do :-)

I have given this a little thought - is the aproach above the only option? Isn't it possible to skip all the UNIX sockets and use native UDP support on IOU to connect to a different dynamips instance or different IOU. If that would be the case, we could skip the multiplexing logic and just make a IOU format decapsulation.

Hi jumbo,


Indeed, using sockets isnt the only approach. From what I've gathered so far, IOU supports UDP transport aswell, but it works slightly different (check out the -u option and do some packet captures). Afaik, it was designed to interconnect various physical servers, where each of these servers may run multiple IOU instances. When receiving such packets, the complete outer headers can be stripped, but in the UDP payload, there is still the IOU header in front of the encapsulated L2 frame present.

In the "grand scheme", there is always the need of doing IOU-specific en- and decapsulation for the IOU header, otherwise you cannot establish connectivity. The perl script does this in a manual, 1:1 fashion - plus pcap'ing it to/from an interface.

Its not hard to switch this approach to udp encapsulation that is understood by dynamips and qemu. If you like, i can provide the required diff. Functionality wise, its the same as using the original perl script, a bridged (dummy) interface and dynamips gen_eth IO. Although you are stuck in the 1:1 scheme aswell; its not possible to attach multiple interfaces between a dynamips and a single IOU router, for example without extra config tricks (unique IOU pseudo instance id per dynamips interface).

The question is if one wants to run multiple instances of the script (be it pcap or udp transport), manually, and life with the limitations, or if someone is willing to integrate this into dynagen/GNS.

I tried making sense out of the dynagen source, to check how much effort such integration would mean - but im too much of a python noob :)

Thanks for the answer that clarified a lot.



In order to integrate this into dynagen one does not really need to write anything in python, I can do that, becuase that is the easy integration part.

What we actually need (which is much harder to do), is a IOU hypervisor/wrapper that would:
1. encapsulate all those socket/UDP rewrites and provide a clean "per connection" UDP tunnel
2. provide IPC commands over TCP session
3. IPC for add/delete IOU instance
4. IPC for stop/start IOU instance
4. IPC for create/delete a NIC of a specific IOU instance
5. IPC for associating a IOU instance NIC with a UDP tunnel
6. IPC for changing the console port of a IOU instance

The IOU hypervisor/wrapper could be written in any language, will run independenly of dynagen, after start it will listen on a TCP port for incoming IPC connection from dynagen. Dynagen will feed the proper IPC commands to the wrapper, create instances, create nics, provide UDP tunnel details (src port, dst IP, dst port) etc.

We have already 2 wrappers that behave exactly like this:
1. dynamips hypervisor - see the hypervisor.mode file for the IPC description in dynamips sources. Hypervisor.c file contains the C code that implements this.
2. qemuwrapper - see the comments in the qemuwrapper.py file in any GNS3 installation

Also, one can easily observe how the GNS/dynagen is sending the IPC commands to the hypervisors by writing debug=1 into the .net file or into the GNS3 console window.

yeah, would be very nice to use GNS graphical interface on top of IOU for an easy management of topology...and small amount of resources because using IOU you can open plenty of routers without a real impact on cpu/memory resources... plus posibility to connect with pemu/quemu for PIX/ASA/JUNOS .

+1. Very interesting.

Found perl script, that cracks down defences:

#!/usr/bin/perl -w
#name deleted to protect the innocent
sub patch {
$fn = shift;
$offset = shift;
$nop = 144;
print "Attempting to patch $fn";
if (-e $fn) {
$opened = open (FH, "+<$fn");
if (! $opened) {
print "ERROR: Couldn't open $fn.\n";
} else {
binmode FH;
seek FH, $offset, 0;
print FH chr($nop);
print FH chr($nop);
close FH;
print "Success!\n";
}
} else {
print "ERROR: Can't find '$fn'. Skipping.\n";
}
}
&patch("i86bi_linux-ipbase-ms", 242067);
&patch("i86bi_linux-adventerprisek9-ms", 242067);
&patch("i86bi_linux-tpgen+ipbase-ms.PAGENT.4.7.0", 3264721);
exit 0;

BTW, the converter (and multiplexer) probably must be written in compiled language, such as C.

This is because using perl or python between two "C" programs (IOU and Dynamips or Qemu) hurts the performance by a lot, so the CPU usage won't probably be lower than using pure Dynamips.
----

About perl script: I need some clarification: if I run two instances of the perl bridge script, can it work as a multiplexer ?
perl-script-101 reads data as IOU 101 (actually connects to Dynamipcs e1/0)
perl-script-102 reads data as IOU 102 (actually connects to Dynamipcs e1/1)

Just like an Ethernet NIC only read data that belongs to his MAC address (in non-promiscuous mode)
One script don't have to include the multiplexer logic then. Only look for what is destined for him.

Can this be made? Several instances be run of the same script to act as multiplexer together?

-Technologov