PluginOspfd
Ospfd Plugin
Authors: Miguel Ferrer (mferrer at dit.upm.es) Francisco Jose Martin (fjmarin at dit.upm.es) Fermín Galán (galan at dit.upm.es) David Fernández (david at dit.upm.es) version 1.0, January 29th, 2009
Contents
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 <global> tag of the scenario specification files:
<extension plugin="ospfd" conf="ospfd_conf.xml" />
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 <extension plugin> 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:
- 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 (<zebra_bin> and <ospfd_bin> tags).
Examples of this command are:
vnumlparser.pl -x start@ospf_lab.xml -v -u root vnumlparser.pl -x ospf-start@ospf_lab.xml -v -u root
- 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:
vnumlparser.pl -x stop@ospf_lab.xml -v -u root vnumlparser.pl -x ospf-stop@ospf_lab.xml -v -u root
- 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:
vnumlparser.pl -x restart@ospf_lab.xml -v -u root vnumlparser.pl -x ospf-restart@ospf_lab.xml -v -u root
- redoconf or ospf-redoconf. It generates again the zebra and ospfd configuration files and copies them inside the virtual machines. In order to make the changes efective, the user must issue a ospf-restart command after this one.
Examples of this command are:
vnumlparser.pl -x redoconf@ospf_lab.xml -v -u root vnumlparser.pl -x ospf-redoconf@ospf_lab.xml -v -u root
Language reference
VM Definitions: <vm>
This tag groups all virtual machine definitions for the ospfd configuration.
Attributes
The following attributes may appear in a <vm> 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
<vm name="vm1" type="quagga" subtype="sbin-install">
Tags
The following tags may appear in a <vm> tag:
<zebra_bin>
Optional. Unique.
Specifies the path of zebra daemon if this is different of default path.
<zebra_bin>/sbin/zebra</zebra_bin>
<ospfd_bin>
Optional. Unique.
Specifies the path of ospf daemon if this is different of default path.
<ospfd_bin>/sbin/ospfd</ospfd_bin>
<zebra>
Required. Unique.
This tag includes two mandatory attributes:
- hostname: Specifies the name of the virtual machine.
- password: Specifies the password of the virtual machine.
<zebra hostname="vm1" password="xxxx"> </zebra>
<network>
Required.
There can be as much as networks exported by the virtual machine. This tag includes two more tags:
<ip>
Required. Unique.
Specifies some information of the virtual network. Includes IP address and network mask.
<ip mask="32">10.0.50.1</ip>
<area>
Required. Unique.
Specifies the area of the virtual network.
<area>0.0.0.0</area>
Example
<ospf_conf>
<vm name="vm1" type="quagga" subtype="lib-install">
<zebra hostname="vm1" password="xxxx"> </zebra>
<network>
<ip mask="32">10.0.50.1</ip>
<area>0.0.0.0</area>
</network>
<network>
<ip mask="30">10.0.0.0</ip>
<area>0.0.0.0</area>
</network>
<network>
<ip mask="30">10.0.0.4</ip>
<area>0.0.0.0</area>
</network>
</vm>
<vm name="vm2" type="quagga" subtype="lib-install">
<zebra hostname="vm2" password="xxxx"> </zebra>
<network>
<ip mask="32">10.0.50.2</ip>
<area>0.0.0.0</area>
</network>
<network>
<ip mask="30">10.0.0.4</ip>
<area>0.0.0.0</area>
</network>
<network>
<ip mask="30">10.0.0.8</ip>
<area>0.0.0.0</area>
</network>
</vm>
