After reading Jeremy Stretch’s recent blog post at Packetlife regarding a problem he managed to help resolve by analyzing the output of a traffic capture, I too thought I would share my own recent experience.
Recently the desktop support
team encountered a group of clerical users who were reluctant to give up their
Windows XP desktops and move to Windows 7.
The reason cited was unacceptably slow performance when using a
particular business critical application on Windows 7 workstations. This had been previously reported by a member
of the clerical team but at the time that workstation was replaced back with XP
which is obviously not a long-term answer.
This particular application
was browser based and the ‘slowness’ only occurred when users clicked links
within the application, e.g. to open customer records, or browse to a different
page. This led to speculation the
problem could be related to browser incompatibility. Some basic testing soon eliminated this
possibility. The testing also found this
did not appear to be a problem on workstations belonging to network
administrators, regardless of who was logged on to the workstation or who was logged
into the application.
Since the problem seemed to be
occurring on nearly all other standard workstations, regardless of location or
subnet, I thought it might be useful to take a packet capture to help shed some
light on the situation.
I installed and loaded up
Wireshark and logged into the application on a suspect workstation. I started the packet capture and entered the
filter ‘ip.addr == 10.0.2.8’, the IP address of the application server. I then attempted to replicate the issue by
clicking any link within the application.
The application paused for around 4 seconds and then the page refreshed. Jumping back to the packet capture:
If you click the screenshot above, you can see that the
application server is making a NetBIOS name query directly to the client
workstation 4 times, after which the page appears to load. Then I compared this
to an administrators workstation which did not have the slowness problem and
found that the server was not making any such requests.
I took at look at the DNS
server used by the server and found that the client workstations did not have a
pointer record in the reverse lookup zone.
Old XP workstations did, and lo-and-behold, machines used by
administrators with static IP addresses did too.
A quick Google search tells us
that “The behavior of Client not registering PTR record by default is modified
prior to Windows7 (mostly during Vista time) and is the intended behavior. The Dhcp Server is responsible for performing
PTR record registration on behalf of client.” - http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/3a1c9334-54ba-4845-b7c0-ef8ce5454276. This also helps to explain why workstations
with static IP addresses were unaffected.
I put this to the test and manually created some PTR records for a
couple of client workstations who were having the application problem and it
was resolved straight away.
I’m guessing that a packet
capture from the server would have shown a DNS lookup and then a NetBIOS name
query, which in hindsight would have helped for a slightly quicker resolution.
