[TriLUG] Is this block diagram fairly accurate?
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.
On Apr 6, 2013, at 12:17 PM, Steve Litt wrote:
> 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 188.8.131.52. 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
>> 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 184.108.40.206, 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 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.
>>> 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