[TriLUG] Is this block diagram fairly accurate?

[Steve Litt]

On Fri, 5 Apr 2013 10:09:40 -0400
Aaron Joyner <aaron at joyner.ws> wrote:

> It might seem helpful to show that the ARP cache is functionally very
> similar to the routing table, just with different column data
> (ip->mac, as opposed to ip/cidr->ip).  

Nice characterization! I hadn't noticed that until now.

> If you can find the space to
> illustrate a couple entries for each host, 

:-)  So much info, so little space. I already have so much stuff
crammed into that diagram that it's risking font illegibility for those
with bad vision or in presentation situations with a weak projector and
lots of ambient light.


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

> that would likely be helpful when
> explaining the flow of arp discovery to someone.  Typing that also
> makes me realize you didn't include an arp cache for the
> Router/Gateway (on either of it's interfaces).  I'd recommend doing
> that.

Let me see if I can fit it in...

> 
> I think you can achieve those changes by making each box a touch
> bigger, and shifting the IP&MAC of each host to be displayed under
> its name.  This would help prevent confusion with it being seen as
> too-closely associated with the ARP cache, and give you room to fill
> in example entries of the ARP cache.
> 
> Labeling the arrows "MAC address" between the host and the Ethernet
> indeed captures the relevant packet header for that layer of
> transmission... but it's a bit at odds with the subnet notation on
> the right ("192.168.100.0/24subnet").  In a perfect world, I'd think
> of those arrows as a set of nested
> boxes, something like [mac[ip[data]]], but I don't have any good
> suggestions for representing that concisely around the arrows.  

Perhaps I could make the Ethernet lines blue on the outside (with
subnet address) and red on the inside (labeled MAC address). Do I have
this correct that packets between computers on the same subnet still
have the source and destination IP address in the packet?

> Also,
> I don't know that duplicating what ever is there (above and below the
> switch) is strictly necessary?  If you have the space it probably
> doesn't hurt. Still, it might be more clear to point out there that
> all the Ethernet layer cares about is a single broadcast domain,
> there's nothing technically requiring that to only be one IP subnet.

Aaron, I don't understand anything in the preceding paragraph. I think
the preceding paragraph is beyond my networking knowledge, but perhaps
you're just using different words than the ones I'm used to.

As far as duplicating above and below the switch, what I was trying to
do is show that 100.1, 100.2, and 100.15 are on the same subnet
connected to the same switch. Is there a better way to do that?


> I think this paragraph comes down to this question, "Will you have
> exposition to go with this graph, or do you expect it to stand
> alone?" 

After this and other evaluations, it's looking more and more like it
will need further exposition.

> It'll work fine as a thing to point at, or with some text
> elaborating on the data flows, but if it's going to stand alone it
> might benefit with a bit more thinking.

I'd love to figure out a way to improve the diagram to the point where
parallel explanation is unnecessary.

Thanks very, very much for all this great advice.

SteveT