Authors: Jorge Somavilla (somavilla 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) David Fernández (david at dit.upm.es) version 1.0, January 29th, 2009
This is a simple usage example for the VNUML DHCP Plugin.
There are two binaries currently not included in VNUML available filesystems:
The user must install these binaries in the filesystem used for the simulation, and store it in the following path
Alternatively, download this version of root_fs_tutorial to the following path
then from a terminal create a symbolic link to the filesystem
cd /usr/share/vnuml/filesystems/ ln -s root_fs_tutorial-0.5.1-dhcp root_fs_tutorial
The roles in the scenario are the following:
- s1: DHCP server
- r1 and r2: Routers with DHCP relay services.
- c1 to c5: DHCP clients
Please download the scenario configuration files from section Download.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE vnuml SYSTEM "/usr/share/xml/vnuml/vnuml.dtd"> <!-- VNUML DHCP Test Scenario --> <vnuml> <global> <version>1.9</version> <simulation_name>dhcp_example</simulation_name> <automac/> <vm_mgmt type="none" /> <vm_defaults exec_mode="mconsole"> <filesystem type="cow">/usr/share/vnuml/filesystems/root_fs_tutorial</filesystem> <kernel>/usr/share/vnuml/kernels/linux</kernel> <console id="0">xterm</console> </vm_defaults> <extension plugin="dhcp" conf="dhcp_conf.xml" /> </global> <net name="Net0" mode="uml_switch" /> <net name="Net1" mode="uml_switch" /> <net name="Net2" mode="uml_switch" /> <vm name="s1"> <if id="1" net="Net0"> <ipv4>10.0.0.1</ipv4> </if> <route type="ipv4" gw="10.0.0.2">default</route> </vm> <vm name="c1"> <if id="1" net="Net0"/> </vm> <vm name="r1"> <if id="1" net="Net0"> <ipv4>10.0.0.2</ipv4> </if> <if id="2" net="Net1"> <ipv4>10.0.10.1</ipv4> </if> <route type="ipv4" gw="10.0.10.2">10.1.10.0/24</route> <forwarding type="ip"/> </vm> <vm name="c2"> <if id="1" net="Net1"> </if> </vm> <vm name="c3"> <if id="1" net="Net1"> </if> </vm> <vm name="r2"> <if id="1" net="Net1"> <ipv4>10.0.10.2</ipv4> </if> <if id="2" net="Net2"> <ipv4>10.1.10.1</ipv4> </if> <route type="ipv4" gw="10.0.10.1">10.0.0.0/24</route> <forwarding type="ip"/> </vm> <vm name="c4"> <if id="1" net="Net2"/> </vm> <vm name="c5"> <if id="1" net="Net2"/> </vm> </vnuml>
<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE dhcp_conf SYSTEM '/usr/share/xml/vnuml/dhcp.dtd'> <dhcp_conf> <vm name="s1" type="dhcp3"> <server> <lease_time>130</lease_time> <subnet> <ip mask="24">10.0.0.0</ip> <range> <first>10.0.0.10</first> <last>10.0.0.20</last> </range> <router>10.0.0.2</router> </subnet> <subnet> <ip mask="24">10.0.10.0</ip> <range> <first>10.0.10.10</first> <last>10.0.10.20</last> </range> <router>10.0.10.1</router> <router>10.0.10.2</router> </subnet> <subnet> <ip mask="24">10.1.10.0</ip> <range> <first>10.1.10.10</first> <last>10.1.10.20</last> </range> <router>10.1.10.1</router> </subnet> </server> </vm> <vm name="r1" type="dhcp3"> <relay> <toserver>10.0.0.1</toserver> </relay> </vm> <vm name="r2" type="dhcp3"> <relay> <toserver>10.0.0.1</toserver> </relay> </vm> <vm name="c1" type="dhcp3"> <client> <if>1</if> </client> </vm> <vm name="c2" type="dhcp3"> <client> <if>1</if> </client> </vm> <vm name="c3" type="dhcp3"> <client> <if>1</if> </client> </vm> <vm name="c4" type="dhcp3"> <client> <if>1</if> </client> </vm> <vm name="c5" type="dhcp3"> <client> <if>1</if> </client> </vm> </dhcp_conf>
For the whole simulation the user should acquire root privileges in the host.
Launch the simulation with flag -t
vnumlparser.pl -t dhcp_scenario.xml -v -u root
Once VNUML has deployed the scenario, the user can start executing commands in the host. The following sequence is proposed:
- global start
In the host, execute
vnumlparser.pl -x dhcp-start@dhcp_scenario.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.
- dhcp testing
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
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)
which for example executed in the client c5, will return a piece of information where the user can find something similar to
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 has been configured with lease time of 130 seconds, as it can be seen in the DHCP description XML, which means that clients must renew their IP leases every 130 seconds. This periodic requests can be observed running the following command in any client:
tcpdump -i eth1
- relays stop
Back in the host, the user can execute the following command
vnumlparser.pl -x dhcp-relay-stop@dhcp_scenario.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
- clients restart
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@dhcp_scenario.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.
- start relay 1
If the user starts the relay 1
vnumlparser.pl -x dhcp-relay-start@dhcp_scenario.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
- stop relay 1; clients restart
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@dhcp_scenario.xml -v -u root -M r1 vnumlparser.pl -x dhcp-client-restart@dhcp_scenario.xml -v -u root
- start relay 2
The user can now test what is the effect of starting the relay 2 instead
vnumlparser.pl -x dhcp-relay-start@dhcp_scenario.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
Which states that for the deployed scenario, a single dhcp relay in r2 would be sufficient.
- stop server
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@dhcp_scenario.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
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
will not show any "inet addr" field.
- start server
However the requests from the clients go on, and if the user starts the server once more
vnumlparser.pl -x dhcp-server-start@dhcp_scenario.xml -v -u root
The clients will eventually be provided with a new IP lease.
- Stopping the simulation
Stopping the dhcp scenario
vnumlparser.pl -x dhcp-stop@dhcp_scenario.xml -v -u root
Stopping the simulation with flag -P
vnumlparser.pl -P dhcp_scenario.xml -v -u root
DHCP Plugin Document Type Definition: dhcp.dtd. Download to the following path