PluginDhcp

Authors: Miguel Ferrer (mferrer at dit.upm.es) Francisco Jose Martin (fjmarin at dit.upm.es) Jorge Somavilla (somavilla 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
This is a simple usage example for the VNUMl [DHCP Plugin/DHCP Plugin].

Binaries
There are two binaries currently not included in VNUML available filesystems: Please download the following filesystem for your DHCP simulation.
 * dhcp3-server
 * dhcp3-relay

Scenario
Imagen:Dhcp-simple.png

VNUML Description
 <!DOCTYPE vnuml SYSTEM "/usr/share/xml/vnuml/vnuml.dtd">

1.9    dhcp_ejemplo   /usr/share/vnuml/filesystems/root_fs_tutorial /usr/share/vnuml/kernels/linux xterm  

  

 10.0.0.1     default 

 

<if id="1" net="Net0"> 10.0.0.2    </if> <if id="2" net="Net1"> 10.0.10.1    </if> <route type="ipv4" gw="10.0.10.2">10.1.10.0/24 </vm>

<if id="1" net="Net1"> </if> </vm>

<if id="1" net="Net1"> </if> </vm> <if id="1" net="Net1"> 10.0.10.2    </if> <if id="2" net="Net2"> 10.1.10.1    </if> <route type="ipv4" gw="10.0.10.1">10.0.0.0/24 </vm>

<if id="1" net="Net2"/> </vm>

<if id="1" net="Net2"/> </vm>

DHCP Description
<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE dhcp_conf SYSTEM '/usr/share/xml/vnuml/dhcp.dtd'> <dhcp_conf>

 10.0.0.0</ip> 10.0.0.10 	  10.0.0.20         10.0.0.2

10.0.10.0</ip> 10.0.10.10 	  10.0.10.20         10.0.10.1         10.0.10.2

10.1.10.0</ip> 10.1.10.10 	  10.1.10.20         10.1.10.1   </vm>

 10.0.0.1  </vm>

 10.0.0.1  </vm>

 1</if> </vm>  1</if> </vm>  1</if> </vm>  1</if> </vm>  1</if> </vm>

</dhcp_conf>

Testing
For the whole simulation the user should acquire root privileges in the host. sudo su Launch the simulation with flag -t vnumlparser.pl -t scenario_example.xml -v -u root Once VNUML has deployed the scenario, the user can start executing commands in the host. The following sequence is proposed:

In the host, execute vnumlparser.pl -x dhcp-start@scenario_example.xml -v -u root which will start all dhcp servers, relays and clients in the scenario. Depending on the complexity of the scenario, the time needed for convergence is variable.
 * global start

In order to check that dhcp started and works correctly, the user can login in the virtual machines (login:root password:xxxx), and check their status. In the server, the user can consult the status of the dhcp server service /etc/init.d/dhcp3-server status which should return the line Status of DHCP server: dhcpd3 is running. and also check that the server daemon is running ps aux | grep dhcpd | grep -v grep which will return the information about the process if it is launched. In the relays, the user can check if the relay daemons are running ps aux | grep dhcrelay | grep -v grep In the clients, the user can log in and check that they acquired a valid IP in the corresponding interface (in current example eth1) ifconfig eth1 which for example executed in the client c5, will return a piece of information where the user can find something similar to inet addr:10.1.10.11 The user can as well check for the running dhcp client daemon ps aux | grep dhclient | grep -v grep For testing purposes, the dhcp server is configured with lease time of 120 seconds, which means that clients must renew their IP leases every 120 seconds. This periodic requests can be observed running the following command in any client: tcpdump -i eth1
 * dhcp testing

Back in the host, the user can execute the following command vnumlparser.pl -x dhcp-relay-stop@scenario_example.xml -v -u root which will stop all the relay services in the scenario. Even if the relay services are stopped, the dhcp clients will already have the information about the dhcp server of the current lease, stored in the file /var/lib/dhcp/dhclient.leases. Therefore, the clients will be able to renew the IP leases with no need of the relays, including the information about the servers in the dhcp request. the user can check this invoking the following command, for example in the client c5 tcpdump -i eth1 Every 120 seconds, the interface will register IP renewal petitions like the following one, with the ip of the server (10.0.0.1): 12:00:46.015412 IP 10.1.10.11.bootpc > 10.0.0.1.bootps: BOOTP/DHCP, Request from fe:fd:00:00:09:01 (oui Unknown), length 300 and the replies from the server 12:00:46.016610 IP 10.0.0.1.bootps > 10.1.10.11.bootpc: BOOTP/DHCP, Reply, length 300
 * relays stop

With the relays stopped, the user can now restart the clients, killing the client processes in every virtual machine and starting new daemons, vnumlparser.pl -x dhcp-client-restart@scenario_example.xml -v -u root However, the new client daemons won't have the information of the server anymore, hence none of them will be able to reach the server with their petitions ('ifconfig eth1' will show no ip address acquired in the clients), except for the client c1, that does not need a working relay as it's in the same subnet as the dhcp server.
 * clients restart

If the user starts the relay 1 vnumlparser.pl -x dhcp-relay-start@scenario_example.xml -v -u root -M r1 The clients (which are configured by the plugin to retry address acquisition every 10 seconds untill success) will keep sending their dhcp requests, except for c1 that was already configured. The requests from c2 and c3, sent to the broadcast address of the network 10.0.10/24 will reach both r2 (relay down) and r1 (relay running), and will be correctly redirected to the server s1 by r1. However the requests from the clients c4 and c5 will only reach r2 (relay down), and won't be relayed forward. As a result, after the convergence time, clients c2 and c3 will acquire IP address, unlike c4 and c5. This can be tested in each client with the command ifconfig eth1
 * start relay 1

This will bring the scenario back to the status prior to relay 1 restart, where only c1 had acquired IP. vnumlparser.pl -x dhcp-relay-stop@scenario_example.xml -v -u root -M r1 vnumlparser.pl -x dhcp-client-restart@scenario_example.xml -v -u root
 * stop relay 1; clients restart

The user can now test what is the effect of starting the relay 2 instead vnumlparser.pl -x dhcp-relay-start@scenario_example.xml -v -u root -M r2 The clients c2, c3, c4 and c5 will keep sending their dhcp requests, which will now find a working relay that will redirect them to the right server. Even if the relay r1 is not active, the dhcp requests sent by the clients will find a working relay in r2, which will redirect them to the server s1 and, provided that ip forwarding is allowed in r1 (even if the relay in r1 is not running), the requests will reach the server s1. As a result, after the convergence time all the clients will have acquired an IP address. This can be tested in each client with the command ifconfig eth1 Which states that for the deployed scenario, a single dhcp relay in r2 would be sufficient.
 * start relay 2

When all the clients have acquired IP, the user can test what happens if the dhcp server is stopped. vnumlparser.pl -x dhcp-server-stop@scenario_example.xml -v -u root As mentioned before, the clients are configured with a lease time of 120 seconds, which means they have to renew the IP lease with this frecuency. Right after stopping the server, and before their leases expire, the clients will keep their addresses, as can be checked in each client with ifconfig eth1 But when the client tries to renew the lease, the request will not find any answer from the server, and the IP will be released. After a while, all the clients will have lost their IP, and the command ifconfig eth1 will not show any "inet addr" field.
 * stop server

However the requests from the clients go on, and if the user starts the server once more vnumlparser.pl -x dhcp-server-start@scenario_example.xml -v -u root The clients will eventually be provided with a new IP lease.
 * start server

Stopping the dhcp scenario vnumlparser.pl -x dhcp-stop@scenario_example.xml -v -u root Stopping the simulation with flag -P vnumlparser.pl -P scenario_example.xml -v -u root
 * Stopping the simulation