PluginOspfd

Authors: Miguel Ferrer (mferrer at dit.upm.es) Francisco Jose Martin (fjmarin at dit.upm.es) Ferm&iacute;n Gal&aacute;n (galan at dit.upm.es) David Fern&aacute;ndez (david at dit.upm.es) version 1.0, January 29th, 2009

Introduction
The Ospfd plugin can be used since VNUML version 1.9 to configure and run OSPF protocol in the routers of a virtual scenario.

To do this task, virtual machines use quagga tool. This suite has two daemons, zebra and ospfd, in order to activate and configure OSPF in the virtual machines.

To configure OSPF protocol, two configuration files are needed, one per daemon.These files are located at /etc/quagga/ path in the virtual machines filesystem and are:
 * Configuration file to zebra daemon: /etc/quagga/zebra.conf
 * Configuration file to ospfd daemon: /etc/quagga/ospfd.conf

In order to run OSPF protocol, it is needed to start both daemons using the files mentioned above. The task of generating the files and starting/stoping daemons in the virtual machines is performed by the Ospfd plugin.

The plugin is based on a configuration file. In order to be used in a VNUML scenario a line as the following one has to be included in the tag of the scenario specification files:



where ospfd_conf.xml is a file conforming to the Ospfd plugin language reference. Using this configuration file, several operations can be done.

Operations
To configure and run the quagga daemons, the Ospfd plugin will execute several taks at building mode (-t) of vnumlparser.pl and at execution mode (-x) of vnumlparser.pl

Building mode
At the moment of building the scenario,the Ospfd plugin executes two tasks:
 * Write configuration files to zebra and ospfd daemons for each virtual machine which has activated the OSPF protocol. To fill these files, the Ospfd plugin will take the information of the configuration file that is specified at tag of virtual scenario XML file.
 * Copy these files in /etc/quagga/ path of each virtual machine.

Execution mode
Execution mode can execute four different actions: vnumlparser.pl -x start@ospf_lab.xml -v -u root vnumlparser.pl -x ospf-start@ospf_lab.xml -v -u root vnumlparser.pl -x stop@ospf_lab.xml -v -u root vnumlparser.pl -x ospf-stop@ospf_lab.xml -v -u root vnumlparser.pl -x restart@ospf_lab.xml -v -u root vnumlparser.pl -x ospf-restart@ospf_lab.xml -v -u root vnumlparser.pl -x redoconf@ospf_lab.xml -v -u root vnumlparser.pl -x ospf-redoconf@ospf_lab.xml -v -u root
 * start or ospf-start. This command is useful to start zebra and ospfd daemons. It executes a start command of these daemons in each virtual machine. In order to execute these commands, it is needed to know the binary file path of both daemons. This path is different in each filesystem so it is needed to specify this path if the binary file is different from the default path ( and  tags). Examples of this command are:
 * stop or ospf-stop. This command is useful to stop zebra and ospfd daemons. It executes a kill command of these daemons in each virtual machines. Examples of this command are:
 * restart or ospf-restart. This command is useful to reboot zebra and ospfd daemons. First, it executes a kill command and then it executes a start command of these daemons. Examples of this command are:
 * redoconf or ospf-redoconf. First, this command executes a kill command to terminate the daemons, then it generates again the zebra and ospfd configuration files. Finally it executes a start command of these daemons using the new configuration files. Examples of this command are:

VM Definitions: 
This tag groups all virtual machine definitions for the ospfd configuration.

Attributes
The following attributes may appear in a  tag:

name
Required. Unique.

Specifies the name of the virtual machine, as it appears in XML scenario file.

type
Required. Unique.

Specifies the type of OSPF routing daemon. Now, the unique implemented type is "quagga".

subtype
Required. Unique.

Specifies the type of filesystem using by the virtual machine. Now, there are two implemented subtypes:


 * lib-install: for root_fs_tutorial filesystem. This type has the next default binary daemon pathfile:
 * zebra: /usr/lib/quagga/zebra
 * ospfd: /usr/lib/quagga/ospfd
 * sbin-install: for root_fs_light filesystem (N3VLR filesystem).This type has the next default binary daemon pathfile:
 * zebra: /usr/sbin/zebra
 * ospfd: /usr/sbin/ospfd



Tags
The following tags may appear in a  tag:


Optional. Unique.

Specifies the path of zebra daemon if this is different of default path.

/sbin/zebra


Optional. Unique.

Specifies the path of ospf daemon if this is different of default path.

/sbin/ospfd

Required. Unique.

This tag includes two mandatory attributes:


 * hostname: Specifies the name of the virtual machine.
 * password: Specifies the password of the virtual machine.



Required.

There can be as much as networks exported by the virtual machine. This tag includes two more tags:


Required. Unique.

Specifies some information of the virtual network. Includes IP address and network mask. 10.0.50.1

Required. Unique.

Specifies the area of the virtual network.

0.0.0.0

Example
<ospf_conf> <vm name="vm1" type="quagga" subtype="lib-install"> <zebra hostname="vm1" password="xxxx"> 10.0.50.1</ip> 0.0.0.0         10.0.0.0</ip> 0.0.0.0         10.0.0.4</ip> 0.0.0.0   </vm> <vm name="vm2" type="quagga" subtype="lib-install"> <zebra hostname="vm2" password="xxxx"> 10.0.50.2</ip> 0.0.0.0         10.0.0.4</ip> 0.0.0.0         10.0.0.8</ip> 0.0.0.0   </vm>