[TriLUG] Is this block diagram fairly accurate?

Steve Litt slitt at troubleshooters.com
Fri Apr 5 13:43:59 EDT 2013

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 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.

By the way, I found a quick and dirty way to populate my local arp
cache is:

sudo nmap -O --osscan-guess -sS

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

The preceding command leaves a bunch of arp cache entries with hardware
address "(incomplete)", so to actually view the legitimate cache I do

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.



Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

More information about the TriLUG mailing list