ARP Broadcast

typesh

Hey everyone, I needed some help clarifying ARP Broadcasts.

I understand that ARP is used to resolve an IP to a MAC when only the IP of the destination is known.

My question is based on Page 147 of Odom's ICND2 Second Ed. I understand why the ARP goes out with a Destination MAC Address of FFFF.FFFF.FFFF, but why is the IP 255.255.255.255? Shouldn't the IP be that of R1?

It's not an errata either (I checked the errata at Cisco Press).

johnwest43

I have noticed arp broadcasts on my netowork sometimes show the specific subnets broadcast address. for example 192.168.1.255 but i havent seen 255.255.255.255.

jahsoul

Wild guess (considering I'm still a quasi noob) but 255.255.255.255 sends broadcast to all nodes so if the diagram only shows those 2 workstations, the node that sent the ARP is technically sending broadcast to all nodes, but I'm more than likely wrong...

*back to having a headache*

alan2308

Short answer, because ARP is a broadcast.

I think you're looking at it a bit wrong. The ARP packet is asking "Which host has the IP address 192.168.1.1?" not "Hey 192.168.1.1, what is your MAC address?"

typesh

Thanks for the responses

alan2308 wrote: »

Short answer, because ARP is a broadcast.

I think you're looking at it a bit wrong. The ARP packet is asking "Which host has the IP address 192.168.1.1?" not "Hey 192.168.1.1, what is your MAC address?"

Are you sure...?

The reason I ask is because I understood ARP differently based on the tcpdump output in tcp/ip illustrated. It shows the ARP packet format as having the Target Host's IP set in the Destination IP Field.

I think the RFC says something similar:
RFC 826 (rfc826) - Ethernet Address Resolution Protocol: Or Converting Ne

The Address
Resolution module then sets the ar$hrd field to
ares_hrd$Ethernet, ar$pro to the protocol type that is being
resolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet
address), ar$pln to the length of an address in that protocol,
ar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet address
of itself, ar$spa with the protocol address of itself, and ar$tpa
with the protocol address of the machine that is trying to be
accessed.


Unless I am interpreting it wrong...

alan2308

typesh wrote: »

Are you sure...?

Yes.

I just pulled out Todd Lammle's book to verify. In his example it will have 192.168.1.255 (using my addressing scheme from earlier), but the end result will be the same as 255.255.255.255. It's a broadcast going out asking who has the IP address of 192.168.1.1. IIRC quad 255 is a broadcast for whatever the local network is (handy if you don't know yet).

Of course, using a different operating system may account for the difference in 192.168.1.255 or 255.255.255.255.

ZZOmega

alan2308 wrote: »

Short answer, because ARP is a broadcast.

I think you're looking at it a bit wrong. The ARP packet is asking "Which host has the IP address 192.168.1.1?" not "Hey 192.168.1.1, what is your MAC address?"

I think there's also a confusion as to the addressing on the frame vs. ARP Request contained in the frame.

The way I understand it, ARP requests(or any broadcast for that matter) will have destination addresses of FFFF:FFFF:FFFF and 192.168.1.255/255.255.255.255. These addresses are in place so that every devices on the local subnet will process the request. The information which is contained inside of the frame, such as the known IP to unknown MAC resolve request (ARP), is dependant on the situation and will be different every time. The addressing on the frame however, is the same for every time.

burbankmarc

ZZOmega is pretty much right.

ARP is a Frame, not a packet, so it's not destined to any IP. It operates at layer 2.

In the picture you can see that there's no TCP/IP information for the ARP request, since it all operates at layer 2.

typesh

ZZOmega wrote: »

I think there's also a confusion as to the addressing on the frame vs. ARP Request contained in the frame.

Ahh I see what you mean.

I just ran a sniffer and issued a ping to 192.168.1.200 (who is not currently in my arp cache).

I noticed the same fields as burbankmarc in the capture:

Frame 30 (42 bytes on wire, 42 bytes captured)
Ethernet II, Scr: My MacADD, Dst: FF:FF:FF:FF:FF:FF
Address Resolution Protocol (request):
...lines omitted...
Sender MAC: MyMacAdd
Sender IP: My IP
Target MAC: 00:00:00:00:00:00
Target IP: 192.168.1.200

So the information on the frame has my Mac Address and the Destination Mac of all Fs.

And the information in the frame has my IP and MAC, and the destinations IP, but not their MAC.

No broadcast IP anywhere in the capture... (was looking for 255.255.255.255. or 192.168.1.255)

alan2308

Ok, I finally busted out Wireshark and checked myself. The destination IP is (in my case) 192.168.1.200 rather than a broadcast address. So typesh, why are you pinging my printer?

For the record, I run Ubuntu 9.10 x64.

typesh

alan2308 wrote: »

So typesh, why are you pinging my printer?

For the record, I run Ubuntu 9.10 x64.

LOL!!! You caught me!

My test was also done on ubuntu

Heero

typesh wrote: »

Ahh I see what you mean.

I just ran a sniffer and issued a ping to 192.168.1.200 (who is not currently in my arp cache).

I noticed the same fields as burbankmarc in the capture:

Frame 30 (42 bytes on wire, 42 bytes captured)
Ethernet II, Scr: My MacADD, Dst: FF:FF:FF:FF:FF:FF
Address Resolution Protocol (request):
...lines omitted...
Sender MAC: MyMacAdd
Sender IP: My IP
Target MAC: 00:00:00:00:00:00
Target IP: 192.168.1.200

So the information on the frame has my Mac Address and the Destination Mac of all Fs.

And the information in the frame has my IP and MAC, and the destinations IP, but not their MAC.

No broadcast IP anywhere in the capture... (was looking for 255.255.255.255. or 192.168.1.255)

Basically, where it says Target IP: xxx.xxx.xxx.xxx, that just means that it trying to find the MAC address for that IP address. there is no IP layer on an arp packet.

alan2308

nevermind