[TriLUG] Is this block diagram fairly accurate?

Jim Cook james_cook at mindspring.com
Sat Apr 6 16:10:47 EDT 2013


+1.   I was thinking the same thing last night.

Aaron - thank you.

-Jim

On Apr 6, 2013, at 12:17 PM, Steve Litt wrote:

> Aaron,
> 
> 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.
> 
> SteveT
> 
> 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 68.68.0.1.  It consults it's
>> routing table, resolves the next hop as 192.168.100.15 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 192.168.100.15, tell 192.168.100.1".
>> 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 192.168.100.1 that it owns
>> the IP address 192.168.100.15.
>> 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 192.168.100.15.
>> 
>> 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 68.68.0.1, 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).
> 
> [clip]
> 
>>> 
>>> 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).
>> 
> 
> [clip]
> 
>> 
>> 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 192.168.100.0/24.  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. 10.0.0.1 and
>> 10.0.0.2.  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.
>> 
> 
> [clip]
> 
>>> 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
> -- 
> This message was sent to: Jim <james_cook at mindspring.com>
> 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/james_cook%40mindspring.com
> TriLUG FAQ          : http://www.trilug.org/wiki/Frequently_Asked_Questions




More information about the TriLUG mailing list