Exploratory Lab Report 2DHCP

Joshua Bancroft9/12/2007

Professor Bill StackpoleNoah Leaf

Page 1 of 44

IntroductionThe purpose of this lab is to explore Dynamic Host Configuration Protocol. The in-depth experimentation of the communication between DHCP client and server was investigated. Also back up DHCP servers and failover DHCP servers that when one of the servers go down then the backup server takes over and DHCP clients communicate with. Also two clients have the same address was tested to see if the DHCP client or server ARPs for a host currently using it.

Table of Contents

Introduction...............................................................................................................................................2

Activity 1: How does it work? Configure Your Table and Discover the DHCP Relay Protocol......................5

Question 1.1............................................................................................................................................5

Activity 2: Selection of Appropriate Scope..................................................................................................9

Question 2.1............................................................................................................................................9

Activity 3: Asking for a Particular Address.................................................................................................13

Question 3.1..........................................................................................................................................13

Question 3.2..........................................................................................................................................16

Activity 4: Does One DHCP Server Backing Up Another Work?.................................................................18

Question 4.1..........................................................................................................................................18

Question 4.2..........................................................................................................................................21

Activity 5: DHCP Failover...........................................................................................................................24

Question 5.1..........................................................................................................................................24

Question 5.2..........................................................................................................................................27

Activity 6: Address Conflicts and ARP........................................................................................................27

Question 6.1..........................................................................................................................................27

Question 6.2..........................................................................................................................................32

Question 6.3..........................................................................................................................................34

Question 6.4..........................................................................................................................................36

Page 2 of 44

Activity 1: How does it work? Configure Your Table and Discover the DHCP Relay Protocol

Question 1.1Describe in detail what a relay agent is doing specifically? Illustrate this by including relevant packet captures and explanations of what is happening

AssertionThe first step in which a DHCP client can receive its information is to send out a DHCPDISCOVER packet. This packet is sent out as a broadcast, which the relay agent receives and forwards it unicast to the actual DHCP server. The DHCP server then sends a DHCPOFFER to the relay agent, whom then sends it unicast to the requesting client. If the client likes the offer then it broadcasts a DHCPREQUEST. The relay agent sees the broadcast and then forwards it to the DHCP server. The server then sends a DHCPACK back to the relay agent who then sends it unicast to the client. The relay agent in this case is just forwarding all of the packets either to the DHCP server or client depending on who the receiver is.

Experimental DesignTo come to this conclusion a two different topologies where set up to test the different affects that the platform plays on how the relay agent works. For the first topology a Linux Cent OS 5 DHCP server was set up in the 10.110.73.0 subnet, while a Windows DHCP client and Windows Relay Agent were located on the 10.110.72 subnet. These two subnets were connected via a router. To see how the DHCP Relay Agent worked the DHCP client released and renewed its lease. The second topology used a Windows 2003 Server as the DHCP server located on the 10.110.72.0 network, while the Linux DHCP client and Linux DHCP relay agents were both located on the 10.110.73.0 subnet. The same experiment was conducted by releasing and renewing the lease of the client.

Page 3 of 44

Topology

Page 4 of 44

Analysis A DHCP relay agent is essentially a relay between the client and the DHCP server. It gives any data that the client is trying to send to the server directly to the server using unicast message. For example in Figure 1.1.1 the Windows DHCP client sends a broadcast to the DHCP server. This broadcast is then answered by the Linux relay agent in packet 11. This DHCPDICSCOVER packet (packet 15) is then sent from the relay agent to the Linux DHCP server. In packet 17 the DHCPOFFER sent from the client is then sent using unicast to the relay agent who then sends it back to the client (packet 18). The client then broadcasts a DHCPREQUEST (packet 19) and the relay agent responds by transmitting the packet to the DHCP server as seen in packet 20. The DHCP server then finally responds by sending a DHCPACK or packet 21 to the relay agent which then is transmitted to the client in packet 22. Another example of how a relay agent function is evident in Figure 1.1.2 where a Linux DHCP client and a Windows relay agent are on the same subnet while the Windows DHCP server is on another one. The main point of the relay agent is to transmit data from a DHCP client on one subnet (the same one as the relay agent) to a DHCP server on another subnet.

Supporting Data

Figure 1.1.1 Linux Relay Agent

Page 5 of 44

Figure 1.1.2 Windows Relay Agent

Page 6 of 44

Activity 2: Selection of Appropriate Scope

Question 2.1How does a DHCP server know what scope to use to assign a dynamic address? Provide this by including relevant packet captures and explanations. (be specific)

AssertionThe DHCP server figures out the scope of the client by using the address of the relay agent in which the client initially communicated with. Inside of the packet that the relay agent sends to the DHCP server is a “relay agent IP address” field. The DHCP server looks at this field and then AND it against the subnet. Then the DHCP server looks at the subnet declarations in the dhcpd.conf file and ANDs each of the subnet declarations to find one that matches that of the relay agent. Then it selects one of the addresses in the pool for that subnet.

Experimental DesignTo come to this conclusion a two different topologies where set up to test the different effects that the platform plays on how the relay agent works. For the first topology a Linux Cent OS 5 DHCP server was set up in the 10.110.73.0 subnet, while a Windows DHCP client and Windows Relay Agent were located on the 10.110.72 subnet. These two subnets were connected via a router. To see how the DHCP Relay Agent worked the DHCP client released and renewed its lease. The second topology used a Windows 2003 Server as the DHCP server located on the 10.110.72.0 network, while the Linux DHCP client and Linux DHCP relay agents were both located on the 10.110.73.0 subnet. The same experiment was conducted by releasing and renewing the lease of the client.

Page 7 of 44

Topology

Page 8 of 44

Analysis One of the challenging features of DHCP and using relay agents is determining from what address pool the address should be given from since the client has no IP address (Figure 2.1.1). This task is accomplished by a field in the DHCPDISCOVERY packet. This field is the “relay agent IP address” field as seen in Figure 2.1.2. The DHCP server receives the packet and processes this field and ANDs it with the subnet mask to receive the subnet of the relay agent in which the client is located. The DHCP server then goes into the dhcpd.conf and for each subnet declaration ANDs the subnet and subnet mask as seen in Figure 2.1.3. Then it compares the two, the relay agent subnet and the subnet in the dhcpd.conf file, and finds the correct subnet. Then the DHCP server selects an appropriate address from the correct subnet declaration.

Supporting Data

Figure 2.1.1 Linux Relay Agent

Page 9 of 44

Figure 2.1.2 The Relay Agent IP Address Field.

Figure 2.1.3 The dhcp.conf file that is located in the Linux DHCP server.

Activity 3: Asking for a Particular Address

Question 3.1Do Windows DHCP clients wait for the preferred answer, or take the first answer offered? If it waits, how many times does it DISCOVER before giving up?

AssertionWhen a Windows client is requesting a specific address it waits for the preferred address. After three DHCPDISCOVERY packets are sent and none offer the preferred address then the Windows client just accepts the other address.

Page 10 of 44

Experimental DesignThe Windows DHCP client got a DHCP lease from a Windows DHCP server located on the 10.110.73 subnet, while the client was located on the 10.110.72 network. On the 10.110.72 subnet there was a Windows relay agent along with another DHCP server (Linux). A windows relay agent was used to control the boot threshold to control how many seconds the other DHCP client on the 10.110.72 network would wait before responding. Then the Windows DHCP client would release the IP address and try and renew. The DHCP server that it initial received the address from is being blocked by the boot threshold on the relay agent and is adjusted to see how it reacts.

Topology

Analysis When requesting a preferred address a Windows DHCP client will wait for the preferred answer. As in Figure 3.1.1, the Windows client is trying to request the IP address of 10.110.72.10. The DHCP server that is sending offers to the client (10.110.72.7) cannot give the IP address the client is currently requesting, because either another machine has that address or it is not inside of the pool that it is giving out. Instead the DHCP server is trying to give the client an address of 10.110.72.29. The Windows DHCP client did not just accept the first offer that is received instead it waits the period of three DHCPDISCOVERY packets. If the client did not receive the preferred address by then, then the Windows DHCP client accepted the other offered address (Figure 3.1.1). There is another example of the Windows DHCP client accepting the third offer sent out by the DHCP server in Figure 3.1.2. Linux then accepts the first offer, while Windows waits for the preferred address three times. If no one can offer this address then the Windows DHCP client accepts the offer.

Page 11 of 44

Supporting Data

Figure 3.1.1 Windows client accepting the third offer by the DHCP server and also the preferred IP address

Figure 3.1.2 Another example of a Windows client accepting the third offer by the DHCP server and also the preferred IP address

Page 12 of 44

Page 13 of 44

Question 3.2Do Linux DHCP clients wait for the preferred answer, or take the first answer offered? If it waits, how many times does it DISCOVER before giving up?

AssertionWhen a Linux client is requesting a specific address it waits for the preferred address. The first DHCPOFFER that the Linux client receives is the one that it is going to request for. This does not matter if the address is the preferred one or not.

Experimental DesignThe Linux DHCP client got a DHCP lease from a Windows DHCP server located on the 10.110.73 subnet, while the client was located on the 10.110.72 network. On the 10.110.72 subnet there was a Windows relay agent along with another DHCP server (Linux). A windows relay agent was used to control the boot threshold to control how many seconds the other DHCP client on the 10.110.72 network would wait before responding. Then the Linux DHCP client would release the IP address and try and renew. The DHCP server that it initial received the address from is being blocked by the boot threshold on the relay agent and is adjusted to see how it reacts.

Topology

Page 14 of 44

AnalysisWhen a Linux DHCP client tries to request a preferred address from the DHCP server it does not matter because Linux accepts the first offer that the client receives. This is illustrated in Figure 3.2.1, when a Linux client has a preferred address of 10.110.72.10. The DHCP server does not supply this range of IP addresses so it cannot offer this address. Instead the server offers 10.110.72.30 as its first offer. The Linux DHCP client then accepts this offer and continues the rest of the process. Linux then accepts the first offer, while Windows waits for the preferred address three times. If no one can offer this address then the Windows DHCP client accepts the offer.

Supporting Data

Figure 3.2.1 Linux DHCP client accepting the first offer while requesting a different IP address.

Page 15 of 44

Activity 4: Does One DHCP Server Backing Up Another Work?

Question 4.1Does a Windows DHCP client retain its connection in this scenario, maintaining the telnet session when it is forces to change DHCP servers during a renewal?

AssertionThe telnet connection is retained through the renewal and rebinding process due to the Windows DHCP client still having the same valid address. With the same address the logical connection of the telnet application would stay open and continue to transmit. The logic connection stayed open even when renewing with another DHCP server, because both of the DHCP servers had same reservation in their DHCP configuration file.

Experimental DesignTo conduct this experiment two DHCP servers were placed on the same subnet. These DHCP servers were a Linux Cent OS 5 and a Windows 2003 Server. The two DHCP servers have different pools of address but both have the same reservation for the DHCP client. A Windows DHCP client was also place on the same subnet. The DHCP client associated with the Windows DHCP server. When the client received all the DHCP information it needed a telnet session with the Linux DHCP sever was established. A constant letter was pressed to check the logical connection of the telnet session. Then the Windows DHCP server connection was severed. This forced the DHCP client to renew with the Linux DHCP server. While renewing with the Linux DHCP server the logical connection was monitored.

Page 16 of 44

Topology

Analysis When the Windows DHCP client is in the middle of a TCP transmission (telnet) it will continue to renew its lease with the Windows DHCP server without affecting the data transfer of the TCP applications (Figure 4.1.1). While this is occurring, the telnet session is still open and still has its logical connect. If however the Windows DHCP server connection gets severed then it continues to tries renew. This renewing process starts when the T1 timer expires at 50% the lease time. This is seen in Figure 4.1.2 when the Windows DHCP client (10.110.72.13) is trying to communicate with the Windows DHCP server (10.110.72.1) but the server’s connection has been severed. If the Windows DHCP server still does not respond when T2 expires the Windows DHCP client goes into a rebinding process where it broadcasts the request for an address which is illustrated in Figure 4.1.3. This broadcast is answered by the Linux DHCP server which is on the same network (10.110.72.2). During this entire process the telnet connection was held and the logical connection was not severed. This is due to the Windows DHCP client still retaining the same IP address throughout the process since it was a reservation in both DHCP servers. Even if the lease time did run out then the client would arp it’s gateway and continue to use the address until it could contact a DHCP server. By the Windows client never losing its IP address the telnet connection was not be severed and lost.

Page 17 of 44

Supporting Data

Figure 4.1.1 The Windows DHCP client renewing its address with the Windows DHCP server (10.110.72.1)

Figure 4.1.2 The Windows DHCP client trying to renew again with the Windows DHCP server (T1 expired)

Page 18 of 44

Figure 4.1.3 The Windows DHCP client went through a rebinding period and rebroadcasted for a new DHCP server and receive acknowledgement from Linux DHCP server (10.110.72.2)

Page 19 of 44

Question 4.2Does a Linux DHCP client retain its connection in this scenario, maintaining the telnet session when it is forces to change DHCP servers during a renewal?

AssertionThe telnet connection is retained through the renewal and rebinding process due to the Windows DHCP client still having the same valid address. With the same address the logical connection of the telnet application would stay open and continue to transmit. The logic connection stayed open even when renewing with another DHCP server, because both of the DHCP servers had same reservation in their DHCP configuration file.

Experimental DesignTo conduct this experiment two DHCP servers were placed on the same subnet. These DHCP servers were a Linux Cent OS 5 and a Windows 2003 Server. The two DHCP servers have different pools of address but both have the same reservation for the DHCP client. A Linux DHCP client was also place on the same subnet. The DHCP client associated with the Windows DHCP server. When the client received all the DHCP information it needed a telnet session with the Linux DHCP sever was established. A constant letter was pressed to check the logical connection of the telnet session. Then the Windows DHCP server connection was severed. This forced the DHCP client to renew with the Linux DHCP server.

Topology

Page 20 of 44

Analysis When the Linux DHCP client is in the middle of a TCP transmission (telnet) it will continue to renew its lease with the Windows DHCP server without affecting the data transfer of the TCP applications (Figure 4.2.1). While this is occurring, the telnet session is still open and still has its logical connect. If however the Windows DHCP server connection gets severed then it continues to tries renew. This renewing process starts when the T1 timer expires at 50% the lease time. This is seen in Figure 4.2.2 when the Linux DHCP client (10.110.72.11) is trying to communicate with the Windows DHCP server (10.110.72.1) but the server’s connection has been severed. If the Windows DHCP server still does not respond when T2 expires the Linux DHCP client goes into a rebinding process where it broadcasts the request for an address which is illustrated in Figure 4.2.3. This broadcast is answered by the Linux DHCP server which is on the same network (10.110.72.2). During this entire process the telnet connection was held and the logical connection was not severed. This is due to the Linux DHCP client still retaining the same IP address throughout the process since it was a reservation in both DHCP servers. Even if the lease time did run out then the client would arp it’s gateway and continue to use the address until it could contact a DHCP server. By the Linux client never losing its IP address the telnet connection was not be severed and lost.

Supporting Data

Figure 4.2.1 The Linux DHCP client renewing its address with the Windows DHCP server (10.110.72.1)

Page 21 of 44

Figure 4.2.2 The Linux DHCP client trying to renew again with the Windows DHCP server (T1 expired)

Figure 4.2.3 The Linux DHCP client went through a rebinding period and rebroadcasted for a new DHCP server and receive acknowledgement from Linux DHCP server (10.110.72.2)

Page 22 of 44

Activity 5: DHCP Failover

Question 5.1How do the servers communicate? What specific packet traffic is used so that one server may know that the other is no longer available? Include annotated packet captures to support your findings.

AssertionThe DHCP servers use a “heartbeat” line. In this message the secondary DHCP server sends a random TCP message to the primary DHCP server. When the primary DHCP server receives this message it sends an ACK back to the secondary DHCP server. This exchange is used to check that the primary is still connected to the network and if the secondary DCHP server should become the primary. This TCP message is sent to the primary DHCP on port 647.

Experimental DesignTo conduct this experiment two DHCP servers were placed on the same subnet. These DHCP servers were both Linux Cent OS 5 servers. The two DHCP servers have the same address pool and are set up in a failover topology. A Windows DHCP client was also place on the same subnet. The DHCP client associated with the primary Linux DHCP client. Then the primary Linux DHCP connection was severed. This forced the DHCP client to renew with the secondary Linux DHCP server. During this process the “heartbeat” messages were monitored along with who the DHCP client associates with.

Topology

Page 23 of 44

Analysis When testing DHCP failover two Linux DHCP server set up on the same network. These two servers, one the primary DHCP server and the other the secondary or back up DHCP server, communicated using a TCP packet that would be acknowledged by the primary DHCP server. The primary and secondary alternate between sending these heartbeat packets and receiving these packets as seen in Figure 5.1.1. The DHCP server that then receives this random packet then sends an acknowledgment back to the sender to signify that the receiver DHCP server is still on the network. When a DHCP client sends a DHCPREQUEST packet to the primary server, both DHCP servers acknowledge the request and also update their lease tables (Figure 5.1.2). If one of the DHCP failover servers is removed from the network the heartbeat is still transmitted but times out and tries to retransmit to the down server (Figure 5.1.3). If a DHCP client is trying to renew an address or request a new address such as in Figure 5.1.4 the backup DCHP server will reply to the requests and send out appropriate addresses according to the lease table.

Supporting Data

Figure 5.1.1 The TCP heartbeat between the primary and secondary DHCP server.

Figure 5.1.2 DHCP request and both primary and secondary acknowledging the request.

Page 24 of 44

Figure 5.1.3 The heartbeat timing out because the primary DHCP server is disconnected.

b

Figure 5.1.4 The secondary DHCP server ACKing the request of the DHCP client.

Page 25 of 44

Question 5.2When using a DHCP failover scenario, is a client ever left without service? How long does the failover process take (both according to the RFC/ other reference materials AND as recorded by you during your experiment.)

AssertionThe client never loses service during the failover scenario. When the primary server cannot be reached then the DHCP client rebinds with the secondary server. This process in the experiment took around 90 seconds from the first poll that needed to be retransmitted to when the DHCP client binds with the secondary DHCP server. In the Cisco Network Registrar DHCP Failover guide states that the average failover scenario should take around 60 seconds.

Experimental DesignTo conduct this experiment two DHCP servers were placed on the same subnet. These DHCP servers were both Linux Cent OS 5 servers. The two DHCP servers have the same address pool and are set up in a failover topology. A Windows DHCP client was also place on the same subnet. The DHCP client associated with the primary Linux DHCP client. Then the primary Linux DHCP connection was severed. This forced the DHCP client to renew with the secondary Linux DHCP server. During this process the “heartbeat” messages were monitored along with who the DHCP client associates with.

Topology

Page 26 of 44

Analysis In a DHCP failover topology at least two DHCP servers share the same pool of addresses. These two servers one a DHCP primary server and the other the backup communicate via a heartbeat or poll TCP session. IF something happens to the primary DHCP server the connection between the two ceases and the secondary or backup DHCP starts to retransmit. As soon as the first message is not acknowledged a failover-poll-timer starts. This timer is usually set to 60 seconds by default as specified in the Cisco Network Registrar DHCP Failover guide (Figure 5.2.1). In the experiments of DHCP failover the secondary DHCP server did not start responding to the DHCP client until after 90 seconds. This time is from the first retransmission from the secondary DHCP client (Figure 5.2.2), to when the DHCP client binds with the secondary DHCP server (Figure 5.2.3).

Supporting Data

Figure 5.2.1 Cisco Network Registrar DHCP Failover guide stating average failover-poll timer should be set to 60 seconds.

Figure 5.2.2 The heartbeat timing out because the primary DHCP server is disconnected.

Page 27 of 44

b

Figure 5.2.3 The secondary DHCP server ACKing the request of the DHCP client.

Page 28 of 44

Activity 6: Address Conflicts and ARP

Question 6.1Who does or does not get service? Do lease tables get updated on any platform, server or client? Explain your answer and include evidence of your conclusions via packet captures and screen shots of lease tables and any error messages or contrary evidence o useable service.

AssertionWhether or not the client gets service depends on what platforms are being used and which client gets set first, if it is the DHCP client or the statically set one. In most of the experiments when the static IP client is set first then both clients have service. The exception to this is when a Windows static client is set first and then a Linux DHCP client is trying to receive that same address from a Linux DHCP server. In this situation the DHCP server arps for the address it is going to offer to the DHCP client. The Windows static client replies to the server and the server sends a NACK to the DHCP client denying it service. Another example when a client gets denied service is when a Linux static client is set after a Windows DHCP client is set. The static Linux client arps for the address that it is going to be set to and receives a reply to the arp by the Windows DHCP client. The Linux static client then does not set the IP to that address then denying service to the client. Anytime the DHCP client has an address the lease table is updated with its MAC address , UID and other information.

Experimental DesignTo conduct this experiment two clients were placed on the same subnet. One client is statically configured while the other client is configured by using DHCP. A DHCP server is also located on the same subnet. The DHCP server has only one address in its pool and this address is also currently being used by the static client. Then either the static client takes the address first then the DHCP tries to obtain the same address or vice-versa. Also the arp tables of each of the clients and server we cleared before any of the clients obtained the address.

Page 29 of 44

Topology

Page 30 of 44

Analysis

To determine who gets or is denied service main depends on the platforms of all the machines (the clients and the DHCP server). Also another determining factor is which address is set first. Results vary when coming them with ones that had the static IP address being set first and then the DHCP client, compared to the DHCP client first then the static IP. In multiple cases both clients received service. In Figure 6.1.1, both the Linux DHCP client connected to a Windows DHCP server and the Windows statically configured client both had service. This did not matter if DHCP client was set first or if the statically configured had the address first. Giving both clients some amount of service was the most common case that occurred. A similar example is when a Linux static client is set before a Windows DHCP client. Both at first seem to have service, but as soon as the Linux static client is used, all service to the Windows DHCP client is lost this can be seen in Figure 6.1.2. Another frequent case is one that only occurred with Linux statically configured client. This is when the static configured client is set second after the Windows DHCP client. In this case the Linux manually configured arped for the address that it is being set to and

Page 31 of 44

the Windows DHCP client replies to the arp forcing the client to be denied the IP address (Figure 6.1.3). Another different scenario is when the Linux DHCP server NACKed the DISCOVERY of the Linux DHCP client, knowing that the address was already in use by the Windows statically configured client (Figure 6.1.4). This NACK was sent by the DHCP server because it arped for the address that it was giving the Linux DHCP client and got a response back from the Windows statically configured client. Anytime that the DHCP client received an address the lease table in the DHCP server updated with the clients information.

Supporting Data

Figure 6.1.1 Windows DHCP server giving address to Linux DHCP client, while a Windows client is already statically configured with that address.

Page 32 of 44

Figure 6.1.2 The Windows DHCP client getting no service after the Linux static client used its service

Page 33 of 44

Figure 6.1.3 Linux static client no able to get obtain IP address since it is already in use by Windows DHCP client.

Figure 6.1.4 Linux DHCP server recognizing that Windows static client has IP set to what Linux DCHP client is requesting. DHCP server sends NACK.

Page 34 of 44

Question 6.2Does either server platform ARP for the address? If so at what point in the discovery or renewal process does it do so. Verify your answer with data.

AssertionThe only server arp that was received is when a Linux DHCP server was involved. In that case the Linux DHCP server would then arp for any address that is being offered to the client. The static client if set first would then respond to the arp and the DHCP client would send a NACK in the case of a Linux DHCP client or just give the address in the case of a Windows DHCP client. The arp occurred right after the first DISCOVERY packet sent by the client.

Experimental DesignTo conduct this experiment two clients were placed on the same subnet. One client is statically configured while the other client is configured by using DHCP. A DHCP server is also located on the same subnet. The DHCP server has only one address in its pool and this address is also currently being used by the static client. Then either the static client takes the address first then the DHCP tries to obtain the same address or vice-versa. Also the arp tables of each of the clients and server we cleared before any of the clients obtained the address.

Topology

Page 35 of 44

Page 36 of 44

Analysis The clients when connecting to a DHCP server never arp for the address. Instead sometimes the vinella DHCP server before assigning an address, will arp for the address and listen to hear a response. This situation where the server arps for the address seems to only occur when a Linux DHCP server is being used. An example is in Figure 6.2.1 where a Linux DHCP client is trying to obtain the same address as a statically configured Windows client. The DHCP server arps for the address to see if anyone currently has the address. The Windows statically configured client replies to the arp. The DHCP server then realizes some other client has that address so it sends a DHCPNACK to the client. In another example when there is a Windows DHCP client and a static Linux client. The server then arps for the DHCP client and get a response back from the static Linux client. This time though instead of the DHCP server sending a DHCPNACK the DHCP client receives an address and has network service (Figure 6.2.2). The Linux DHCP server performs the arp right after the first DISCOVERY packet by the DHCP client.

Supporting Data

Figure 6.1.1 Linux DHCP server arping to find if address is being used. Then sends NACK after finding out it is being use.

Page 37 of 44

Figure 6.2.2 Linux DHCP server arping to find if address is being used. The DHCP client uses address after knowing that another client is using it.

Page 38 of 44

Question 6.3Does either client platform ARP for the address? If so at what point in the discovery or renewal process does it do so. Verify your answers with data.

AssertionThe Linux static clients trying to be set after the DHCP client is already set to the same address are the only clients to arp for the address. By the clients arping for the address then the DHCP client replies to the arp and Linux static client gets an error message and is not set to the address.

Experimental DesignTo conduct this experiment two clients were placed on the same subnet. One client is statically configured while the other client is configured by using DHCP. A DHCP server is also located on the same subnet. The DHCP server has only one address in its pool and this address is also currently being used by the static client. Then either the static client takes the address first then the DHCP tries to obtain the same address or vice-versa. Also the arp tables of each of the clients and server we cleared before any of the clients obtained the address.

Topology

Page 39 of 44

Page 40 of 44

Analysis In some cases when a client was statically set it arped for the address that it was being set to make sure it is not currently being used/ When a Linux client is being statically configured it arped for the address. In Figure 6.3.1 the Linux client arped for the address it is going to be set to and the currently static configured Windows DHCP client answers the arp request. The Linux static client after hearing the reply then does not use that IP address and produces an error message as seen in Figure 6.3.2. This case where the client arps for the address seems to only occur with the Linux statically set client. When the Windows client is statically set, it does not arp. Also any of the clients using DHCP to obtain their addresses does not arp. In this case it uses the DHCP server and in some cases the server arps for the address before giving it to the client.

Supporting Data

Figure 6.3.1 The Linux static client arping for the address and the Windows DHCP client replying

Figure 6.3.2 The Linux static client not being able to use the address because it is already in use

Page 41 of 44

Page 42 of 44

Question 6.4When a relay agent is added to the equation does it affect the outcome? Is there a situation where you can use a relay agent to force a change in the outcome? Support your answer and hypothesis with relevant captures and other data.

AssertionThe result when adding a relay agent is not significant. By adding a relay agent it only affected the outcome when there was a Linux DHCP server. The reason for this is that with the Linux DHCP server it arped for the address it was going to set the client to. In the case where there was one one subnet the static client then answered if it was set before the DHCP client. In the case tested here (2 subnets) the static client does not answer the arp by the server, so the Linux DHCP client gives the address to the DHCP client no matter if some other client has it.

Experimental DesignTo conduct this experiment two clients were placed on the same subnet. One client is statically configured while the other client is configured by using DHCP. A DHCP relay agent is also located on the same subnet. The DHCP Server is located on a separate subnet separated by a router. The DHCP server has only one address in its pool and this address is also currently being used by the static client. Then either the static client takes the address first then the DHCP tries to obtain the same address or vice-versa. Also the arp tables of each of the clients and server we cleared before any of the clients obtained the address.

Topology

Page 43 of 44

Analysis When having two clients trying to request the same IP address, one through a relay agent to a DHCP server on another server and the other statically configured it creates a more complex situation for who gets service. The only difference when adding a DHCP relay agent and spilt the topology into two separate subnets is when the DHCP server arps for the DHCP client address before setting it. This situation only occurs when a Linux DHCP server is being used. When testing and having all three machines on the same network (The DHCP server, DHCP client and static client) the DHCP server arped for the DHCP clients address the static client would respond, if set before DHCP client receives one. This in end would make the DHCP server NACK the request deny service to the DHCP client. When separating the DHCP server and the clients and putting them on different subnet a relay agent is added to the equation. When the DHCP server then arps for the address that the DHCP client is going to be set to, it receives no answer since they are on separate subnets. This means that the DHCP client and the static client both have the same address and both have service.

Supporting Data

Page 44 of 44