The packet capture below includes ARP again, and a quick review of one of the basic tasks somebody will carry out if they believe there are connectivity issues (you may have heard many people say 'can you ping X?', and this is covered below).
"ARP! ARP! ARP!"
Packets 1 and 2 in the capture will look very familiar. If you look at packets 9 and 10 in 'Getting to Google, Part 1', you will see that they are very close to identical. Given the purpose of ARP, and the fact that these packets were captured very shortly after the packets seen in that post, why does my virtual host need to send out the same ARP request again? Surely it already has the MAC address for the default gateway! The answer lies in Microsofts Knowledgebase article 949589, which advises:
"ARP caching behavior has been changed in Windows Vista. The TCP/IP stack implementations in Windows Vista comply with RFC4861 (Neighbor Discovery protocol for IP version 6 [Ipv6]) for both the IPv4 and the IPv6 Neighbor Discovery process."
The ARP cache is essentially a table that records all of the information from previous ARP replies. To see the current ARP cache contents, you can simply open a command prompt and enter arp -a . A quick example is below and you can see that we have the entry for 192.168.126.2.
Just two seconds... that KB article is for Vista. My virtual host is Windows 7... As we can see below, the article does appear to apply to Windows 7 also! The Base Reachable Time for the interface in question is indeed 30,000ms, as per the Knowledgebase article. Actually, checking further down in the article also confirms that this applies to Windows 7.
Can I ping it? YES YOU CAN! Hopefully...
So... you may have heard the standard IT troubleshooting phrase 'can you ping xxxxx?'. If network connectivity issues are present, this is a simple tool that uses the ICMP protocol to check connectivity to another specific host. In the following screenshot, you can see the use of the ping command.
From the Windows 7 host, we try to ping the default gateway IP (although note that the target IP does not need to be 'local' ie on the same network). An ICMP 'echo request' is sent from the virtual host to the default gateway. This is essentially my virtual host saying 'Hello, are you there?'. The default gateway receives the echo request, and responds with an ICMP 'echo reply', confirming that it is there. Four pings, or echo requests, are sent by default - as in certain situations not all get a response, such as in cases of intermittent connectivity.
It should be noted that sometimes, even when there are not connectivity issues, pings may not work, as they can be dropped by security applications on the host (trying to hide it) or by any devices, or 'hops', in between the source and destination.
Looking at the ICMP packets in more detail, you can see that the ICMP echo request has an ICMP 'type' of 8, which identifes this packet as an echo request packet. The echo reply packet has an ICMP 'type' of 0, which identifes this packet as an echo reply. You can also see in the main packet capture screenshot at the top of this post that the sequence numbers increment. This is so each echo reply can be matched up with its respective echo request.
Q: How did you know about the Microsoft Knowledgebase article?
A: Google is your friend (though some people disagree, that is an entirely different discussion!) - as I knew what I was looking for, a search for 'Windows 7 arp cache timeout' yielded the following:
- second hit was a brief article located at msmvps.com. And that linked to the MS article!
- third hit was support.microsoft.com/kb/949589
- fourth hit was a http://www.petri.co.il/ article. Not directly related, but just including a shout out as there are some fantastic articles on that site!
As a quick aside, although searching usually gets you to answers, there are two great articles on the QA blogs site which can be read here and here* I have fairly strong opinions on the subject matter myself, and disagree with some points made but thats what makes the subject interesting. On the other hand, I agree with a lot of what is written in them - I would like to throw 'Plan B (book) into the equation also, but with any approach there are pros and cons!
Q: How do you know about ICMP 'types' and 'codes'?
A: I have spent a fair bit of time in IT - with time and experience, this knowledge becomes second nature, trust me! Types and codes for ICMP (and indeed types and codes for other IP protocols) are coordinated by the Internet Assigned Numbers Authority (IANA). The current IANA page relating to ICMP types and codes is here
Q: I noted that in the ICMP echo request screenshot that the Internet Protocol Version 4 line was red... Red is bad, isnt it?
A: Well caught! In this particular case, it isnt bad. To ensure that transmitted packets have not been corrupted, some protocols include 'checksums' which are fields containing values that are the result of a mathematical calculation based on other protocol fields. In this case, Wireshark has performed the calculation itself, and is advising that the checksum is incorrect. This is actually due to an option known as 'checksum offloading' (which Wireshark handily mentions) meaning that the checksum is calculated by the Network card, so the outgoing packet is captured before the checksum is calculated! As this only happens on outgoing packets, we can be sure that no corruption has occured!
*Full disclosure - my wife works for QA :-)
