Vnx-plugin-ospf

OSPF Plugin

Authors:
David Fernández (david at dit.upm.es)
Miguel Ferrer (mferrer at dit.upm.es)
Francisco Jose Martin (fjmarin at dit.upm.es)
Fermín Galán (galan at dit.upm.es)
version 2.0, September 11th, 2011

Introduction

OSPF plugin is an example VNX extension plugin designed to facilitate the configuration of OSPF in virtual machines. It provides a simple XML language to express OSPF configurations which are independent of the OSPF implementation used in the virtual machine. At present, OSPF Plugin is implemented only for quagga based OSPF routers, but can be extended to support other OSPF implementations.

To use OSPF plugin in a VNX scenario, you have to add the following tag after <vm_defaults> section of <global> tag:

<extension plugin="ospf" conf="ospfd_conf.xml" />

The plugin configuration file or PCF contains the OSPF configuration written in a XML language. Using that language the configuration of a router looks like:

...
<vm name="r1" type="quagga" subtype="lib-install">
  <hostname>r1</hostname>
  <password>xxxx</password>
  <network area="0.0.0.0">10.0.0.0/16</network>
  <passive_if>eth1</passive_if> 
  <binaries>
    <zebra>/usr/lib/quagga/zebra</zebra>
    <ospfd>/usr/lib/quagga/ospfd</ospfd>
  </binaries>
</vm>
...

OSPF plugin just processes that configuration and translates it into the necessary quagga configuration files (zebra.conf and ospfd.conf) and manages the routing daemons. See the complete example below to know more about OSPF plugin capabilities.

OSPF Plugin Example Scenario

OSPF Plugin example is a simple scenario made of two routers (r1 and r2) and two hosts (h1 and h2) designed to show the capabilities of the plugin. The example is included in VNX distribution.

OSPF Plugin example scenario map
(generated using "vnx -f example_ospf-plugin.xml -v --show-map")

To start the scenario, just type:

cd /usr/share/vnx/plugins/examples
vnx -f example_ospf-plugin.xml -v -t

Note: in case you get an error related with the existance of '/root/.ssh/id_dsa.pub' file, either create that file executing "ssh-keygen -t dsa" or delete or modify the <ssh_key> tag on the scenario.

Once started, you can check the conectivity among h1 and h2 hosts:

root@h1:~# traceroute -n 10.0.2.2
traceroute to 10.0.2.2 (10.0.2.2), 30 hops max, 60 byte packets
 1  10.0.1.1  2.520 ms  2.388 ms  2.297 ms
 2  10.0.0.2  2.214 ms  2.133 ms  2.059 ms
 3  10.0.2.2  1.939 ms  1.502 ms  0.779 ms

Or check that the quagga ospf daemon is running on r1 and r2 and the neighbourhood between them is stablished:

root@r1:~# vtysh
Hello, this is Quagga (version 0.99.17).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

r1# sh ip ospf  neighbor  
    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.0.0.2          1 Full/DR           37.119s 10.0.0.2        eth2:10.0.0.1            0     0     0
r1#

To know the scenario commands made available to the user by the plugin, you can use the "exe-info" mode of VNX:

# vnx -f example_ospf-plugin.xml --exe-info
----------------------------------------------------------------------------------
Virtual Networks over LinuX (VNX) -- http://www.dit.upm.es/vnx - vnx@dit.upm.es
Version: 2.0b.893 (built on 11/09/2011_03:14)
----------------------------------------------------------------------------------
Using configuration file: /etc/vnx.conf
  TMP dir=/tmp
  VNX dir=/root/.vnx
----------------------------------------------------------------------------------

VNX exe-info mode:

User-defined command sequences for scenario 'example_ospf-plugin'
----------------------------------------------------------------------------------
 stop-www                 Stop apache2 web server
 start-www                Start apache2 web server

Plugin 'ospf' command sequences for scenario 'example_ospf-plugin'
----------------------------------------------------------------------------------
 restart                  Restarts OSPF daemons
 stop                     Stops OSPF daemons
 ospf-redoconf            Plugin specific synonym of 'redoconf'
 ospf-restart             Plugin specific synonym of 'restart'
 ospf-stop                Plugin specific synonym of 'stop'
 on_shutdown              Stops OSPF daemons (executed before shutdown)
 on_boot                  Creates OSPF config files and starts daemons (executed after startup)
 ospf-on_boot             Plugin specific synonym of 'on_boot'
 redoconf                 Recreate the OSPF config files
 ospf-start               Plugin specific synonym of 'start'
 start                    Starts OSPF daemons
----------------------------------------------------------------------------------
Total time elapsed: 0 seconds

For example, you can stop the daemon in r1 with:

vnx -f example_ospf-plugin.xml -v -x ospf-stop -M r1

and edit example_ospf-plugin-conf.xml to make any change to r1 OSPF configuration (for example, change the hostname ro router1) and reload the configuration file with:

vnx -f example_ospf-plugin.xml -v -x redoconf -M r1

After 'redoconf' command you can check the changes have been made to configuration files by accessing r1 and having a look at /etc/quagga/zebra.conf and /etc/quagga/ospfd.conf files).

Finally, you can start the daemon with the new configuration with:

vnx -f example_ospf-plugin.xml -v -x ospf-start -M r1

Note: typically plugins provide the same basic 'start|stop|restart' commands with two sequence names: general (i.e. start) and specific (i.e. ospf-start). Both execute the same actions, but the specific one is used when you want to execute commands only over a specific plugin. Selecting the general one will tipically execute commands over all plugings and some user-defined commands.

Scenario Specification

<?xml version="1.0" encoding="UTF-8"?>
<!--
~~~~~~~~~~~~~~~~~~~~
VNX Sample scenarios
~~~~~~~~~~~~~~~~~~~~

Name:        example_ospf-plugin
Description: Example scenario to show the use of ospf plugin. It is made of two 
             routers: r1 (ubuntu) and r2(uml) and two hosts: h1 (ubuntu) and h2 (uml).   

This file is part of the Virtual Networks over LinuX (VNX) Project distribution. 
(www: http://www.dit.upm.es/vnx - e-mail: vnx@dit.upm.es) 

Departamento de Ingenieria de Sistemas Telematicos (DIT)
Universidad Politecnica de Madrid
SPAIN
-->
<vnx xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="/usr/share/xml/vnx/vnx-2.00.xsd">
  <global>
    <version>2.0</version>
    <scenario_name>example_ospf-plugin</scenario_name>
    <ssh_key>~/.ssh/id_dsa.pub</ssh_key>
    <automac offset="4"/>
    <!--vm_mgmt type="none" /-->
    <vm_mgmt type="private" network="10.250.0.0" mask="24" offset="16">
       <host_mapping />
    </vm_mgmt> 
    <vm_defaults>
        <console id="0" display="no"/>
	<console id="1" display="yes"/>
    </vm_defaults>
    <extension plugin="ospf" conf="example_ospf-plugin-conf.xml" />
  </global>
    
  <net name="lan1" mode="virtual_bridge" />
  <net name="lan2" mode="virtual_bridge" />
  <net name="ptp12" mode="virtual_bridge" />
  
  <!-- NODES -->
  <vm name="r1" type="libvirt" subtype="kvm" os="linux" exec_mode="cdrom">
    <filesystem type="cow">/usr/share/vnx/filesystems/rootfs_ubuntu</filesystem>
    <mem>256M</mem>
    <if id="1" net="lan1">
      <ipv4>10.0.1.1/24</ipv4>
      <ipv6>2001:db8:1::1/64</ipv6>
    </if>
    <if id="2" net="ptp12">
      <ipv4>10.0.0.1/30</ipv4>
      <ipv6>2001:db8:12::1/64</ipv6>
    </if>
    <forwarding type="ip" />
  </vm>

  <vm name="r2" type="uml" subtype="" os="" exec_mode="mconsole">
    <filesystem type="cow">/usr/share/vnx/filesystems/rootfs_uml</filesystem>
    <mem>64M</mem>
    <kernel>/usr/share/vnx/kernels/linux</kernel>
    <if id="1" net="lan2" name="fxp0">
      <ipv4>10.0.2.1/24</ipv4>
      <ipv6>2001:db8:2::1/64</ipv6>
    </if>
    <if id="2" net="ptp12" name="fxp1">
      <ipv4>10.0.0.2/30</ipv4>
      <ipv6>2001:db8:12::2/64</ipv6>
    </if>
    <forwarding type="ip" />
  </vm>

  <vm name="h1" type="libvirt" subtype="kvm" os="linux" exec_mode="cdrom">
    <filesystem type="cow">/usr/share/vnx/filesystems/rootfs_ubuntu</filesystem>
    <mem>256M</mem>
    <if id="1" net="lan1">
      <ipv4>10.0.1.2/24</ipv4>
      <ipv6>2001:db8:1::2/64</ipv6>
    </if>
    <route type="ipv4" gw="10.0.1.1">default</route>    
    <route type="ipv6" gw="2001:db8:1::1">default</route>       
  </vm>

  <vm name="h2" type="uml" exec_mode="mconsole">
    <filesystem type="cow">/usr/share/vnx/filesystems/rootfs_uml</filesystem>
    <mem>64M</mem>
    <kernel>/usr/share/vnx/kernels/linux</kernel>
    <if id="1" net="lan2">
      <ipv4>10.0.2.2/24</ipv4>
      <ipv6>2001:db8:2::2/64</ipv6>
    </if>
    <route type="ipv4" gw="10.0.2.1">default</route>    
    <route type="ipv6" gw="2001:db8:2::1">default</route>       
  </vm>
  

  <host>
    <hostif net="lan1">
       <ipv4>10.0.1.3/24</ipv4>
       <ipv6>2001:db8:1::3/64</ipv6>
    </hostif>
    <route type="ipv4" gw="10.0.1.1">10.0.0.0/16</route>    
    <route type="ipv6" gw="2001:db8:1::1">2001:db8::/32</route>    
  </host>
  
</vnx>

Plugin Configuration File (PCF)

<ospf_conf xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="/usr/share/xml/vnx/ospf.xsd">

   <vm name="r1" type="quagga" subtype="lib-install">
      <hostname>r1</hostname>
      <password>xxxx</password>
      <network area="0.0.0.0">10.0.0.0/16</network>
      <passive_if>eth1</passive_if> 
      <binaries>
        <zebra>/usr/lib/quagga/zebra</zebra>
        <ospfd>/usr/lib/quagga/ospfd</ospfd>
      </binaries>
   </vm>

   <vm name="r2" type="quagga" subtype="lib-install">
      <hostname>r2</hostname>
      <password>xxxx</password>
      <network area="0.0.0.0">10.0.0.0/16</network>
      <passive_if>eth1</passive_if> 
   </vm>
</ospf_conf>