[TriLUG] Is this block diagram fairly accurate?

Steve Litt slitt at troubleshooters.com
Sat Apr 6 12:17:21 EDT 2013


Your message is one of the most refined and useful teaching tools I've
encountered. Your message taught me tons about ARP, routing, gateways,
and switches -- yeah, switches. You should be incredibly proud of what
you wrote.


On Fri, 5 Apr 2013 23:17:47 -0400
Aaron Joyner <aaron at joyner.ws> wrote:

> Nope, I'm specifically still talking about ARP caches.  Host1's MAC
> will (generally) only appear in the router's ARP cache, not in
> Host2's ARP cache.  Imagine the following hypothetical scenario:
> 1) You reboot everything (hosts, switches, router, etc), nothing has
> spoken on the network yet.
> 2) Host1 attempts to address a packet to  It consults it's
> routing table, resolves the next hop as and forwards
> the packet to that address.  To do so, it consults the ARP table, and
> does not find an entry.
> 3) Host1 sends an ARP Broadcast (destination ff:ff:ff:ff:ff:ff),
> saying essentially "WHO HAS, tell".
> 4) The switch, seeing the ARP broadcast destination address of ff...
> forwards the packet to all ports.  It adds an entry to it's forwarding
> table (CAM table) for the source MAC of Host1 on the associated
> physical port.
> 5) Host2 receives the packet, it does not respond, but depending on
> the OS it *may* add an entry to its ARP cache (see
> https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt,
> specifically arp_accept, it's typically off in Linux -- for more fun
> reading, search for Gratuitous ARP).
> 6) Router/Gateway receives the packet, creates an entry in its own ARP
> cache for Host1 based on the data in the incoming packet, then it
> crafts a *unicast* reply, telling Host1 at that it owns
> the IP address
> 7) The switch receives the packet from Router/Gateway, consults it's
> forwarding table, and delivers the unicast response only to the port
> of Host1.  It also adds an entry in it's forwarding table (CAM table)
> for the source MAC of Router/Gateway's interface.
> 8) Host1 receives the ARP reply from Router/Gateway, adds an entry to
> it's ARP cache, and forwards the original packet that started this
> whole dance to
> At this point, Host1 has an entry in it's ARP table for
> Router/Gateway, and vice versa.  Host2 saw the ARP request packet
> from Host1, but probably ignored it.  It never saw a packet from
> Router/Gateway.  The switch has forwarding-table entries for both
> Host1 on Port 1, and Router/Gateway on Port 3.  If you imagine Host2
> also originating a packet to, it will go through the same
> dance, and end up with the same partially-populated ARP table,
> containing an entry for Router/Gateway, but no entry for Host1.  This
> is the normal steady-state of a network where Host1 and Host2 are
> talking to the outside world, but not each other (what I'd call the
> "typical case" for most networks).


> >
> > 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?
> >
> Yes, IP packets will have the source and destination IP in each packet
> (gee, that sentence seems awfully redundant when I type it out :) ).
> Something like the coloring you suggest might work, but I'd put the
> subnet on the inside, and the MAC on the outside, personally.  It
> better represents the way the encapsulation works.  Imagine that the
> application originating the packet stuffs some data into it, the OS
> first wraps that data in an IP frame (which adds IP/subnet info,
> etc), and then wraps that IP frame in an Ethernet frame (which adds
> MAC src/dst).


> Not all packets are IP packets, many other protocols could be flowing
> across that Ethernet network that wouldn't necessarily be associated
> with the IP subnet  The simplest to visualize is
> probably a parallel IP subnet.  Imagine if you added a second IP on a
> virtual interface on both Host1 and Host2, eg. and
>  Or imagine that they talked Appletalk, IPX/SPX, or some
> other random to each other. In general, the switch doesn't care about
> the Layer 3 protocol going across the Ethernet network.
> As was summarized elsewhere, I think it will behoove you to read
> briefly about the OSI model.  Ethernet in my previous ramblings is
> strictly a Layer1 and Layer2 construction.  IP addresses, subnets,
> etc are a Layer 3 construction.  If it's not clear after doing some
> background reading, let me know and I can try to find a good primer
> to point you at, or summarize at a bit more length here.


> > Thanks very, very much for all this great advice.
> >
> I'm happy to help.  In particular, I think this is something that
> anyone reading this is likely to benefit from thinking through, so
> it's a great topic to ask about on the list.  I was also greatly
> heartened to see that others chimed in (both on-list and off).  I'm
> certainly not a final authority on all things networking, and
> hopefully some of the other networking geeks lurking will chime in
> with explanatory flair or at least their favorite resources to point
> you at.
> Aaron S. Joyner

More information about the TriLUG mailing list