Lab 3‐1 ‐ ARP Observation - rune-seregina/net-150-sp24 GitHub Wiki
This lab was meant to gets some hands-on access to demonstrate how ARP works, specifically within Linux (kali). Using WireShark, I observed as my own and other devices on the LAN's ping packets used ARP to broadcast and resolve MAC addresses.
Having issues with the "arp -d" command, I used "sudo su" to gain elevated priveleges and used "ip -s -s neighbor flush all" to clear my arp cache. In Windows, arp -a should show the arp cache and arp -d should clear it.
Deliverable 1: Find the ARP broadcast that your computer used to find the gateway's MAC address. Provide a screenshot that shows the source and destination MAC address of this broadcast.
Deliverable 2: Find the ARP reply from the gateway back to your computer. Provide a screenshot that shows the ARP reply packet indicating the MAC address for your gateway.
Deliverable 3: What is the message sent in the ARP Request? What is the message sent in the ARP Reply?
Deliverable 4. Figure out how to create a display filter for ARP traffic only and provide a screenshot showing any ARP traffic related to your neighbor's system.
Deliverable 5. Using a piece of paper and a pencil/pen or even a whiteboard. Draw out the sequence of ARP request and Response to and from your neighbor. Take a picture of this with a mobile device and include it as part of your deliverable.
Deliverable 6. This is important. What do you see in the ARP request and reply? Can you discern the MAC address for the google DNS server or not? Can you explain what happened?
The ARP packet shows the resolution that is the same as the default gateway.
Since google's DNS server is not on the LAN, the switch does not know the MAC address! It just goes to through the default gateway's MAC address and goes outside of the LAN to its destination.