The Client boot up process

Let’s show in an Observer trace how the client PC boots up and starts its connection request to the application running on the server. The IP protocol stack on the PC is going to use the DHCP Protocol to start the process.
The Dynamic Host Configuration Protocol (DHCP) is a network protocol that is used to configure devices which are connected to a network so they can communicate on an IP network. It involves clients and a server that is running the DHCP Process. In a typical personal home local area network (LAN), the router is the local DHCP server while clients are personal computers or printers. The clients request configuration settings using the DHCP protocol, minimum an IP address, Subnet Mask and a Default gateway or router and one or more DNS server addresses. Once the process completes (DORA) the client implements these settings, the host is now able to communicate on that network.
The DHCP server maintains a database of available IP addresses and configuration information. When the server receives a request from a client, the DHCP server determines the network to which the DHCP client is connected, and then allocates an IP address and sends configuration information appropriate for that client. DHCP servers typically grant IP addresses to clients only for a limited interval (known as the lease time.) DHCP clients are responsible for renewing their IP address before the lease interval expires.
DHCP is used for IPv4 and IPv6. While both versions serve much the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they may be considered separate protocols.
Hosts that do not use DHCP for address configuration may still use it to obtain other configuration information. Alternatively, IPv6 hosts may use stateless address auto-configuration. IPv4 hosts may use link-local addressing to achieve limited local connectivity.
There are four frames required to complete the DHCP process:
The Client sends the DHCP Discover
The Server responds with a DHCP Offer
The Client makes the DHCP Request for the parameters received in the offer
The Server sends the DHCP ACK to complete the process

These four frames (DORA) all ride on top of the UDP transport protocol, meaning DHCP is connectionless and second the protocol uses UDP port 67 and UDP port 68. The client sends the Discover and the Request from UDP port 68 to the server’s UDP port 67. The server replies with an Offer and an ACK from UDP port 67 to the client’s UDP port 68. A couple of other items of note are these messages are sent to the Broadcast address (FF:FF:FF:FF:FF:FF) and so are non routable. If your DHCP server is on a different network you need to configure an IP Helper address in your router so that the router can forward these frames onto the different subnet where the DHCP server resides.

obs101a

Note the process – there are a couple of extra Offers and Acknowledgements because the DHCP server is on a different subnet from the client and Hot Standby Router Protocol (HSRP) is in use. This means there are two routers forwarding the client’s request to the DHCP Server. The server is replying and again both routers are forwarding the Server responses to the client. It may not be obvious but because we see two offers and acknowledgements, we can determine that we are taking the packet capture from the client side and not the server side. If we were taking the capture from the server side we would be seeing two Discovers and two Requests.
Now let’s look at the MAC addresses. First you see the client send the DHCP Discover to the destination address of broadcast. If the DHCP server were on the client’s local subnet, it would respond. In this case the DHCP server is on a different subnet and the local router(s) have IP helper addresses configured, so both routers (remember, we are running HSRP) will forward the DHCP Discover. The Server responds with a DHCP Offer on its subnet, both routers forward the DHCP Offer to the client. That is why we see the two offers coming from two different MAC addresses. The client then makes the DHCP Request to the MAC broadcast address. The two routers forward the request to the DHCP Server again based on the IP helper address. The server returns the DHCP ACK and both routers forward the ACK to the client. This explains why we see two ACKs coming from two different MAC addresses.

obs101b

The client now has all of the information to be able to communicate on the network. If we look at the DHCP ACK in more detail we can see all of the information returned from the DHCP server. It gave our client the IP address of 171.68.162.223, it shows one of the Relay Agent’s IP addresses is 171.68.162.194. We also see it gave our client a subnet mask of 255.255.255.192 or a /26 bit mask along with our default gateway address of 171.68.162.193. The last portion that we need to know is how to resolve names, so it gave us two addresses, one for the Primary DNS server 171.68.10.70 and one for the Secondary or Alternate 171.68.10.140.

obs101c

The next step in the communication process is for our client to resolve the IP address of the default gateway 192.68.162.193 to a MAC address since we don’t send frames to an IP address.

obs101d

We see the Address Resolution Protocol (ARP) Request coming from the client and being sent to the broadcast MAC address but including the IP address of 171.68.162.193 (our default gateway that was provided to us from the DHCP Process.) We then note the ARP reply from the router 171.68.162.193 telling us its MAC address is 00:00:0C:07:AC:6B. The client PC then puts this MAC address in its ARP cache and now knows where to send frames when it wants to talk to a device that it determines is not on its local subnet based on the 26 bit subnet mask. For instance the DNS Server is not on the client’s local subnet, so if the client wants to send a DNS request it would send the request to the MAC address of the default gateway.

obs101e

Presuming we started our favorite browser and typed in the URL of www.eiadata.com, this would generate the DNS request for the name.

ws-101e

The DNS server responds with the IP address of 216.147.81.250. This is the IP address that corresponds to the name of www.eiadata.com. Notice the DNS request gets sent to the MAC address of the default gateway (00:00:0C:07:AC:6B) which is the virtual MAC address that was returned in our ARP for the default gateway. The DNS response gets returned through the physical MAC address (00:30:96:32:4E:28) of the router that is the Active router in HSRP.
It is now the clients’ responsibility to determine if the address returned from our DNS request (216.147.81.250) is on our local subnet. We are going to compare our address 171.68.162.223 to 216.147.81.250 using the 26 bit mask of 255.255.255.192 and determine that the server is on a different subnet. We only have to compare the first octet or byte of each IP address. Let’s convert decimal 171 to binary which would equal 10101011. Now let’s convert decimal 216 to binary which would equal 11011000. Are the two binary numbers the same? No, therefore they are on different subnets and the client must send its TCP SYN request to the MAC address of the default gateway. This TCP SYN request frame will originate from the client’s MAC address (00:00:65:10:27:B2) and include the client’s IP address (171.68.162.223) and TCP Ephemeral Port (1029.) Our client’s frame will also include the destination MAC address of the default gateway (00:00:0C:07:AC:6B) the servers IP address 216.147.81.250 and the servers Application TCP Port for the service (TCP Port 80) for HTTP.

obs101g

LAB 1 – Client PC Startup
Take a capture from your network of a client PC starting up from power on and opening a browser session to your company’s web site. If possible do it on Monday morning or what is presumed to be a slow time on the network. Follow the processes I have shown you above. Note your appropriate MAC addresses, IP addresses and TCP Port pairs. Save your trace so we can look at this again for network response time.