[TriLUG] Is this block diagram fairly accurate?
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
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 220.127.116.11. 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 18.104.22.168, 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
More information about the TriLUG