Week 4 - asheesh8/NET-150-TECH-JOURNAL GitHub Wiki
LAB 3-1 ARP OBSERVATION Ashish Subedi NET-150-01
DELIVERABLE 1: Screenshot 2026-02-16 004509.png
Screenshot shows the ARP broadcast request….
- Source MAC: 08:00:27:00:fd:9d (my computer)
- Destination MAC: ff:ff:ff:ff:ff:ff (broadcast address)
- Message: "Who has 192.168.1.250? Tell 192.168.1.32"
DELIVERABLE 2: REPLY
Screenshot shows ARP reply from gateway….
- Source MAC: 00:00:5e:00:01:ca (gateway)
- Destination MAC: 08:00:27:00:fd:9d (my computer)
- Message: "192.168.1.250 is at 00:00:5e:00:01:ca"
Screenshot 2026-02-16 004635.png
DELIVERABLE 3: WHAT WAS THE MESSAGE
ARP Request message: "Who has 192.168.1.250? Tell 192.168.1.32"
ARP Reply message: "192.168.1.250 is at 00:00:5e:00:01:ca"
DELIVERABLE 4: ARP NEIGHBOR TRAFFIC
Screenshot of ARP traffic with neighbor at 192.168.1.100…
- Request: "Who has 192.168.1.100? Tell 192.168.1.32"
- Reply: "192.168.1.100 is at 1c:69:7a:a6:48:eb"
Screenshot 2026-02-16 004711.png
DELIVERABLE 5:
Screenshot 2026-02-16 004808.png
DELIVERABLE 6: GOOGLE DNS 8.8.8.8
When I pinged 8.8.8.8, I could NOT see Google's MAC address in the ARP traffic.
- "Who has 192.168.1.250? Tell 192.168.1.39"
- Only ARP traffic for my gateway (192.168.1.250), not for 8.8.8.8
Why tho?
ARP only works on the local network (Layer 2). When I ping 8.8.8.8, my computer realizes that IP address is not on my local subnet (192.168.1.x). Instead of trying to ARP for Google's MAC address, my computer sends the packet to the default gateway/router at 192.168.1.250.
My computer only needs to know the gateway's MAC address via ARP. The gateway then forwards my packet to Google on the internet using Layer 3 routing. This is why I can only see ARP traffic for 192.168.1.250 and not for 8.8.8.8.
In summary, I learned to use Wireshark to capture and analyze ARP protocol traffic to understand how Layer 2 MAC addresses and Layer 3 IP addresses work together on a local network.
CMDS:
- sudo ip -s -s neigh flush all - clears the ARP cache
- arp -a - views current ARP cache entries
- ip neigh show - alt way to view ARP cache
- ip route | grep default - finds default gateway
- ping -c 4 - sends only 4 ping packets to test connectivity
Problem: At first I was only seeing ARP requests with no replies in my capture. Solution: I was pinging random IP addresses that didn't exist on my network. Fixed it by pinging my gateway (192.168.1.250) which I pinged 20 times to find.
Problem: Had too much traffic in Wireshark and couldn't find ARP packets. Solution: Filter arp req
ARP is used to translate IP addresses (Layer 3) to MAC addresses (Layer 2) on a local network. When a device needs to communicate with another device on the same subnet, it broadcasts an ARP request asking "who has this IP address?" and the device with that IP responds with its MAC address.
Lab 3-2
Deliverable 1:
Source MAC: 4c:6d:58:1a:df:3c (JuniperNetwo_1a:df:3c) Destination MAC: 08:00:27:00:fd:9d (PCSsystemtec_00:fd:9d)
This is NOT Google's MAC address. This is my default gateway/router's MAC address right..? Looks like a Juniper Networks device, the router probably received the packet from Google and then forwarded it to me with its own MAC as the source on my local Lan
Deliverable 2: Neighbor IP
Source MAC in ping reply: 1c:69:7a:a6:48:eb Destination MAC in ping reply: 08:00:27:00:fd:9d
Deliverable 3:
Partner's MAC address: 1c:69:7a:a6:48:eb It matches! because... my friend (192.168.1.100) is on the same LAN/broadcast domain as me.
I did not have a proper partner because I am doing this assignment late. Sorry about that again Mr Ginter. But while pinging your ip addy ending in .100 I was able to find the source and destination mac addresses. I think as a hypothesis, from both perspectives wouldnt the destination and source just be flipped on certain packets? While remaining within the same broadcast domain.