January 19th, 2006, 03:18 AM
A question about ARP tables
Scenario: A node sends an ip packet through several hops on a large ip network (the internet) to make a request from a web server for the first time. I know the packet contains, among other things, headers of the assigned ip/mac address of this sender intended to be used as a return address by the server.
Question: Are the ip/mac return addresses that the web server eventually recieves those of the originating node, or are they the ip/mac of the first router in the line of return hops to that node?
In otherwords, in the process of multiplexing and demultiplexing the headers through the stack of each consecutive router, are the ip/mac headers replaced with that of the next, successive router, all the way up to the web server (ergo the server only has to wory about sending the return packet to the first router in the return line), or is the ip/mac info of the original sender preserved as it hits the web server?
January 19th, 2006, 08:37 AM
In a nutshell:
You want to send a IP packet (Layer 3) from 220.127.116.11 to 18.104.22.168.
A router is at 22.214.171.124.
First, your box 126.96.36.199 looks up his routing table - the packet has to be
sent to 188.8.131.52.. But how? Your box broadcasts an ARP request, which
gives back the MAC address of 184.108.40.206. You add this information to your
packet - the resulting frame (Layer 2) contains the MAC addresses of
your box and the router, the IP packet still has as source 220.127.116.11, as
Then, your router strips off the Layer 2 information (the MAC addresses) and
checks his routing table. The router adds his MAC address and the one of the
next router to the original packet, leaving the content of the IP packet
unchanged. The frame is sent to the destination MAC address etc.
Conclusion: The web-server at 18.104.22.168 sees the MAC address of the last router
in the hopping chain, for example 22.214.171.124, but the IP source address of the requester,
ie. 126.96.36.199. Note that often your box is behind some NAT mechanism, ie. the
web-server will see the external address of the router "at 188.8.131.52".
Here we see an example of a routable / non-routable protocol.
If the only tool you have is a hammer, you tend to see every problem as a nail.
(Abraham Maslow, Psychologist, 1908-70)
January 22nd, 2006, 03:20 AM
Thank you for your reply.
I understand why that works. I was hoping to use tcpdump or something similar to record the nic addresses of (original)nodes making requests to my server as a way of compiling usage data of specific nodes over time, but most of those nodes aren't calling from my subnet (long hop chains)/they're assigned dynamic ip addresses/they don't accept cookies well/etc. If I can't see the originators device address, it might rule this idea out.
Do you have any suggestions I could try?
January 22nd, 2006, 04:02 AM
Why is this in the web dev forum?
"When I get a little money I buy books; and if any is left I buy food and clothes." - Erasmus
"There is no programming language, no matter how structured, that will prevent programmers from writing bad programs." - L. Flon
"Mischief my ass, you are an unethical moron." - chsh
Blog of X
January 22nd, 2006, 11:22 PM
dgnorton: how long are the DHCP assignments?
Are there too many hosts or are the leases to short to do address/mac resolution (each DHCP period...) and have a simple lookup to log all data for IP? [swap IP for mac when you store].
How accurate do u want these statistics? ballpark or on the dot?
I don't know what backend you could have on tcpdump...
If you can integrate with your DHCP/DNS you may be able to get around it.
Thinking out loud...