[quagga-dev 7773] Re: new dev model?

Adrian Terranova aterranova at gmail.com
Thu Feb 4 23:42:46 GMT 2010

On Thu, Feb 4, 2010 at 1:32 PM, Goff, Thomas <Thomas.Goff at boeing.com> wrote:
>> I'm happy to contribute the uml containers (and will try to
>> help with QA)
>> Any ideas of creating harnesses or scenarios for functions of  quagga
>> and then maybe vetting them (esp as new functionality is added?)
>> (Would you like me to try and write some?)
>> I have labs written for a particular configurations of  UML containers
>> that could be extended to functionally test, provided the tests could
>> be scripted.
>> Are there protocol test suites in the existing source trees now?
>> --Adrian
> The native support for network stack virtualization in FreeBSD 8.0
> (vimage) and recent Linux kernels (network namespaces) can also be
> useful for protocol testing.  CORE [1] and IMUNES [2] are examples of
> network emulation tools that could also be used to create and test
> reference scenarios.
> Some kind of common topology description format and scripting
> framework that enables more automated regression testing would be
> great.
>  Tom
> [1] http://cs.itd.nrl.navy.mil/work/core/
> [2] http://old.tel.fer.hr/imunes/

I like the idea of the topology description format - would prefer to
provide a description, and set of translators that could digest it to
any simulation model - as opposed to just creating single engine

CORE looks very similar to what cloonix can do - need to read more;
cloonix has the ability to run lots of instances of any x86 distro in
the container of choice (uml  or kvm)

It's the only engine that didn't tightly couple the client os with the
templating system. (the idea of being able to test a debian, openwrt,
xwrt, centos, (or other linux based)  uml routing platforms was

(begin cloonix slanted discussion)

Cloonix has a  templating system (and the ability to run a defined
kernel (UML or kvm), network topology and application / network
configuration) - there are products that are similar - vnet (can't
think of the other one off the top of my head) but with the kvm / uml
machine support, and the templating - it's possible to create
collections of machines,  routing protocols, and relationships and
functionally test them. (i.e. - the whole stack - not just - app - not
just networking)

(app + persistence + messaging + routing )

Used the product to create generic labs for network mobility -
(injecting l3 containers held by routers across different routing
protocol boundaries). It's not the only product that can do this- but
it works pretty well for running 10-20 router setups on a modest
machine (I ran a 12 machine) ospf / bgp lab on a p4 with 512MB of ram.
(GNS3 was too painful to even try)

It had other features like error injection / scriptable migration -
but there is only so much time over the xmas holiday.

An example cloonix configuration would be:

picture ->  http://www.vlcg.net/sites/default/files/Screenshot-Cloonix.png

lab example -> http://www.vlcg.net/downloads/bgp_ospf_demo_openwrt_uml.tar.gz

the topology file defines the l2 relationships
type name    mb ram kernel      rootfs    eth0_lan eth1_lan eth2_lan
UML CORE01 128 linux_openwrt openwrt_uml (none) (0101) (0102)
UML CORE02 128 linux_openwrt openwrt_uml (none) (0101) (0103)

and then the files under the directories  matching the machine name

./CORE01/etc/quagga.conf (for example)

would be copied into the rootfs, and then configured as desired.

Not to try and sell you on the whole concept - but I have a writeup I
did relative to making all routing virtual here ... (It's a difficult
idea to get thru to an all cisco work audience :( )

The proper name for the product is cloonix.


(end cloonix specific discussion)

Not to get into any specific product selection - what would need to be
created for the scenarios would be:

name of the test
node configuration for the test (what kind / how many)
l2 network connectivity (vlan / serial)
l3 addressing (ip)
quagga configuration for the test (/etc/quagga/directory) per machine
test driver (harness script)
results capture


More information about the Quagga-dev mailing list