[TriLUG] Is this block diagram fairly accurate?

[Aaron Joyner]

On Fri, Apr 5, 2013 at 1:43 PM, Steve Litt <slitt at troubleshooters.com>wrote:

> On Fri, 5 Apr 2013 13:22:41 -0400
> Michael Hrivnak <mhrivnak at hrivnak.org> wrote:
>
> > On Fri, Apr 5, 2013 at 10:57 AM, Steve Litt
> > <slitt at troubleshooters.com>wrote:
> >
> > > On Fri, 5 Apr 2013 10:09:40 -0400
> > > Aaron Joyner <aaron at joyner.ws> wrote:
> > > > in particular that
> > > > computer 1&2 both have the gateway, and the gateway has both, but
> > > > that 1&2 don't have each other,
> > >
> > > Am I correct in assuming that the preceding sentence fragment is
> > > about routing -- that .1 and .2 route to .15, and .15 routes to
> > > each of them, but .1 and .2 don't route to each other because they
> > > are on the same subnet?
> >
> >
> > I think Aaron is suggesting that you show the arp cache tables here.
> > Pointing out that "Computer 1" and "Computer 2" don't have arp cache
> > entries for each other illustrates the on-demand discovery nature of
> > arp; those hosts (probably) aren't sending traffic to each other, so
> > they haven't done arp discovery on each other. In a simple scenario,
> > they each have one entry in the arp cache table, and that entry is
> > the gateway.
> >
> > Michael
>
>
> Thanks Michael,
>
> The plot thickens, again :-)
>
> On my LAN here at Troubleshooters.Com/The_Litt_household, a lot of the
> 192.168.100.0/24 clients *do* have arp cache for each other, because
> I'm always sshing or rsyncing or something else from one to the other.
> In a smoothly running LAN whose main purpose is servicing Internet
> email and The Web, this wouldn't be true.
>

Correct.



> By the way, I found a quick and dirty way to populate my local arp
> cache is:
>
> sudo nmap -O --osscan-guess -sS 192.168.100.0/24


Cheaper, dirtier, and w/o sudo:
fping -g 192.168.100.0/24 2>/dev/null

Or if you're in a hurry and know some fancy fping options:
fping -q -c1 -r1 -g 192.168.100.1/24 2>/dev/null

Or if you're *really* in a hurry and don't mind flooding the NIC and using
sudo:
sudo fping -q -c1 -r1 -i1 -g 192.168.100.0/24 2>/dev/null


And I've been able to dump cache on my local machine by running the
> following command two to four times:
>
> sudo ip neigh flush all
>

Yep.  It probably takes a couple times of running it because you've got
various background things sending the occasional packet, so the flushing
will only empty it out for a few seconds, maybe tens of seconds.


>
> The preceding command leaves a bunch of arp cache entries with hardware
> address "(incomplete)", so to actually view the legitimate cache I do
> this:
>
> arp -n | grep -v '(incomplete)'
>
> Sometimes I send the results of the preceding through an AWK script to
> present only the most commonly important stuff.


Those "(incomplete)" entries are an interesting teachable moment.  They
exist because your host sent an ARP request for those packets recently.
 That's what changes the behavior I was describing in my previous post
(which is still be held for moderation, because I'm wordy); specifically,
the kernel's behavior when it receives the ARP response packet.  If it's
expecting it, because it sent an ARP request, it will add it to the table.
 That "(incomplete") entry is the user-space visible window into the entry
in the kernel's arp cache which will expire if it doesn't get a response in
a sufficient time frame.  It would then of course revert to the behavior
controlled by the arp_accept sysctl.

Although it's a good intellectual exercise, I feel compelled to point out
that it doesn't offer any practical benefit to "pre-populate" your ARP
table.  On a modern home network the round-trip times are measured in tens
of microseconds, and ARP responses generated by the remote host are
typically single-digit milliseconds at the very worst, so you're not
loosing anything meaningful in latency to look up those entries as you need
them.

Aaron S. Joyner