This post is the beginning of new troubleshooting saga – Everybody lies ... except network traffic. Chapter 1: the case of the mysterious DHCP Server.

In my daily job as an IT consultant sometimes I have to deal with problems. Different kind of problemss – easy, hard ... it depends on the case. A few days before my current week off (SPRING !!!) I got a problem which was described as follows;

  • Workstation is working in a network segment with DHCP server. Workstation was able to acquire a correct IP address, but ...
  • Later, after acquiring network configuration from DHCP server, workstation configuration was altered with a different set of DNS servers, DNS name suffix etc. This configuration suggested another network segment, connected with this network segment through some routers.

Everything worked, except some problems with accessing network resources with different addresses in both network segments (but similar names – similar if you eliminate the DNS suffix from the equation).

After some speculations – well ... it is with Windows 7 so maybe it is DirectAccess or IPv6 in general or maybe it is just a little gnome altering configuration – it's time for an ultimate question and answer: gathering network traffic from affected workstation.

Network traffic never lies

The main reason DHCP clients exist on a host is to acquire IP configuration. To fulfill this goal DHCP clients use a series of packets, broadcasted to request IP configuration. And the workstation which was a subject of this problem was doing exactly what we expected. In network traffic a chat between the client and the DHCP server was visible in the form of following request exchange:

  • DHCP Discover –> DHCP Offer
  • DHCP Request –> DHCP Ack.

Our client, which was exchanging packets with a DHCP server in local network segment (Server A), in result acquired IP address and some configuration.

(click to enlarge)

But after the DHCP client acquired an IP address it has a right to request some additional information about the network (if such are available from server). To do this client is sending another packet which is called DHCP Inform. As a response the client gets another DHCP Ack message which contains the requested information. And this was what our client did:

(click to enlarge)

However, instead of getting DHCP Ack from the DHCP server on the local network segment the answer came from Server B, which was located in another network segment and was configured with slightly different options.  Because the network configuration (router) allowed such messages to cross network segment boundaries it was completed successfully and  this was the mystery to be solved.

Conclusions ...

We have at least two conclusions from this story:

  1. If you have two DHCP servers serving clients from one network segment for the same IP scope, make sure that these are configured in the same way.
  2. (This will be common for the entire troubleshooting saga (I hope next stories will follow shortly)) If there is a problem in a network environment, in most cases the easiest and quickest way to solve it is to take a look at network traffic.

P.S.#1 If anyone is interested in DHCP protocol flow -  KB 169289 and RFC2131 are there for you.

P.S. #2 Just BTW – in another case I was working on lately, I learned about a small change in behavior of a DHCP server in Windows Server 2008 R2 - KB 2005980 describes it to you.

P.S. #3 This question was asked on my Polish blog when I described the same post – what about ipconfig output in this case. Well ... it showed ServerA as the one who served the client.