[TriLUG] Is this block diagram fairly accurate?

[Aaron Joyner]

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).  If you can find the space to illustrate a couple
entries for each host, in particular that computer 1&2 both have the
gateway, and the gateway has both, but that 1&2 don't have each other, 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.

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

As a parting thought, it's probably not what you're trying to capture (this
seems much more logical layer than physical implementation layer), but it
would be interesting to mention aloud how typical switches and routers
achieve those decisions in hardware, rather than in software, in almost all
cases.  When explaining this level of packet routing and switching, I
always like to make a brief mention of CAM and TCAM (
http://en.wikipedia.org/wiki/Content-addressable_memory) hardware to tickle
in people's minds why Cisco routers are so much more expensive than using a
Linux box as a gateway, and give them some inkling of when to choose one
over the other.


On Fri, Apr 5, 2013 at 12:08 AM, Steve Litt <slitt at troubleshooters.com>wrote:

> Hi all,
>
> For a class I'm teaching soon, I need to have a block diagram of
> routing and ARP. Do you think the following very simplified block
> diagram of how routing and ARP work accurate? If not, what changes
> would make it more accurate?
>
> http://www.a3b3.com/stuff/routing_arp.pdf
>
> Thanks,
>
> SteveT
>
> Steve Litt                *  http://www.troubleshooters.com/
> Troubleshooting Training  *  Human Performance
> --
> This message was sent to: Aaron S. Joyner <aaron at joyner.ws>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
> address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web  :
> http://www.trilug.org/mailman/options/trilug/aaron%40joyner.ws
> TriLUG FAQ          :
> http://www.trilug.org/wiki/Frequently_Asked_Questions
>