There is currently an ongoing effort to make proper dynamic routing available in INET simulations using modified version of Quagga routing suite. Quagga-based BGP and OSPF daemons are already part of the INET Fw, and BGP is in the queue.
The Big Picture
Desired functionality is achieved by placing a thin layer between Quagga and INET. All syscalls generated during Quagga execution are intercepted and processed by this intermediate layer. To Quagga this added layer looks just like an ordinary unix kernel and hence there are no changes required in Quagga core functionality. Of course, there are some changes required in the Quagga sources to make it run in the environment of a discrete simulator, but these changes are mostly formal and can be automated to great extent.
How it works
Capturing all syscalls can be easily achieved by modifying Quagga sources to call our modified routines, i.e. oppsim_socket() instead of socket(), oppsim_read() instead of read() etc. To avoid the necessity to manually replace all such occurrences, this is done by means of macro definition, e.g. #define socket oppsim_socket, which is included by all source files.
Under normal circumstances Quagga runs as an ordinary unix process and so there are additional considerations that must be taken into account when running under discrete simulator. Most importantly, if multiple instances of Quagga routing deamons appear in one simulation (true in virtually all cases), all these instances will be sharing the same address space, namely the address space of the running INET binary. Consequently, changes to a global variable made by one daemon would be visible in all daemons simultaneously. Fortunately, there is an easy macro-way around this problem too.
Inetport
Inetport is a bunch of scripts that tries to make the patching process as much automated and as much painless as possible. Inetport is in fact a simple Makefile that executes several external utilities to carry out all necessary modifications. For successful operation, inetport requires following prerequisites installed:
- xsltproc
- doxygen
- make, perl, patch, grep
Currently inetport works only on Linux. Making it run on Windows shouldn't be difficult though, since all before mentioned utilities are also available for Windows.
Download both inetport and quagga source tarballs into the same directory and then issue following commands:
- tar xvzf inetport-0.98.5.tgz
- cd inetport-0.98.5
- make
This will take some time and after completion, quagga-0.98.5 directory will contain Quagga sources modified for INET. As a part of the patching process, Quagga makefiles are modified to produce libraries that can INET later link with. See the examples distributed along with INET for instructions how to actually enable Quagga functionality on a particular node in your simulation.
Inetport takes care of all necessary modifications, including:
- Stripping off the automake/autoconf build system and replacing it with static makefiles and config.h tuned for our intermediate layer and subsequent linkage with INET binary (i.e. makefiles produce libraries instead of executables).
- Applying several static patches (supplied in diff format) to overcome issues such as:
- naming collisions, e.g. renaming
main() routines to zebra_main(), ripd_main() etc. to avoid interference with the real main() routine of the simulator (NOTE: this particular case should be probably done by dopatch.pl)
- doxygen bugs, several valid C constructs are not parsed correctly by doxygen and even extra white space sometimes matters
- Quagga negligences, e.g. some structures are defined inside source (.c) files. This is fine with pure Quagga, since these structures are only used in that particular module, but poses problem for our mechanism of global variables handling. Such structure definitions must be placed in corresponding header for our purposes.
- MSVC compatibility, e.g. explicit structure initializers used in Quagga sources are not recognized by MSVC compiler
- Additional ad-hoc modifications are done by means of perl script dopatch.pl. These changes are by nature similar to the previous (static) ones, but this time there is a pattern that allows for reasonable automation. All modifications in this step are regexp-based and very prone to errors. As an example, doxygen does not handle anonymous structures correctly, so we give them a FOO name here.
- After these three pre-patching steps, Quagga sources are ready to be processed by doxygen. As a result of doxygen run, an xml model of the sources is created. This model is suitable for further analysis and processing.
- Running xsltproc transformations on the xml model generated by doxygen, several patch files are produced. The term patch doesn't refer to regular diff files, but to custom csv-like files recognized by dopatch.pl utility.
- Final patching is done by dopatch.pl utility. The transformed data from the xml model are used to handle the problematic aspects not covered by previous steps. Most importantly, global variables are handled in this step.
FAQ
Q. Why all this fuss? Why don't you simply provide one big .diff with all necessary modifications?
A. The whole idea is to avoid static diff files as much as possible to allow for adaptation to new Quagga versions without much effort. The more changes are hardcoded in diffs, the bigger are chances for collisions with future versions of Quagga.
Q. Still, this is way too complicated. I know how to make this better.
A. That's great, then please do so and don't forget to share your results :)
