IP Routing and MAC address

http://groups.google.ca/group/comp.dcom.sys.cisco/msg/1b8aac0039384ff5
================================================================================
:In basic TCP/IP, if a packet is NOT destined for a host on the local
:subnet, it will then send the packet to the default gateway. Here is my
:question, when the host's deems the packet to need routing, what exactly
:does it do to with the packet when it is sent to the router ?

:Does it encapsulate it in a 'routing' packet (for lack of a better term),
:then send it to the router ?

No.

:When the router receives it, does it strip
:the 'routing' packet info, examine it, and then transmit it out onto the
:LAN ?

Not applicable because no such encapsulation is occuring.

:If the router has to send it to another gateway, does it then re-
:encapsulate it in another 'routing' packet ?

No.

When a device (host or router) determines that a packet is not destined
locally, it looks through it's routing tables to find the IP of the
next hop device. The next-hop IP that it finds from this lookup should
be one that the first device does NOT have to be route to (e.g., the
next hop IP is in an IP address range served by one of the interfaces
of the first device.)

The sending device then looks in its ARP tables for that next-hop IP to
see if it knows the MAC address of the next-hop IP: there might be
a static entry for it in the table, or it might recently have looked
it up and still remember what the MAC was. If the sending device does
not know the next-hop IP's MAC address, then the sending device sends
out a broadcast ARP packet with the destination IP filled in; all
devices that receive that ARP packet look into the packet to see if their
IP is there, and the one whose IP it is sends back an ARP reply
containing the MAC address. If the sending device did indeed have to
ARP the IP to locate the MAC address, then the sending device could
buffer the original packet until it gets a reply, or the sending device
could instead drop the original packet: if the protocol was one
that offers reliable transportation (such as TCP) then the original
sender will retransmit the packet, and if the protocol protocol was
not one that offers reliable transportation (such as UDP), then the
router is just exercising the unreliability part of the transport ;-)

So now we're in the state where the sending device knows the next-hop
IP and the MAC address of that next hop. It then takes the packet that
it was working with, and rewrites the destination MAC to be the MAC
of the next hop, and rewrites the source MAC to be it's own MAC address.
It fixes up the checksums on the packet, and dispatches the packet out
the appropriate interface. It does NOT re-write the destination IP!

Now, when you are working with TCP/IP all the time, it's easy to get
into the habit of thinking that devices pay attention to packets that
have their IP address as the destination, but that's really not how
ethernet works. Instead, devices pay attention only to packets which
contain their MAC address as the destination MAC, or else contain
one of the special broadcast or multicast MAC addresses. Thus, the
next-hop device will receive the packet not based upon the IP address
(which might be somewhere on the other side of the world), but based
upon the fact that the sender found the specific MAC address to send
to on the local segment at the level -below- IP addresses. Therefore
when the next-hop device receives the packet, the destination IP
in the packet will still be the ultimate destination IP, not the IP
of the router.

The next-hop device then goes through the whole routing table lookup
sequence, finding the next hop IP to send the packet to, finding the
MAC address of that next hop IP, rewriting the source and destination
MACs, fixing the checksum, and sending on to the next hop.

It all works through a chain of routing devices, each one of which
might not know how to directly reach the destination, but knows
which device that it can talk to directly that it can send the packet
to in order to get the packet further towards it's IP destination.

The reason the source MAC is re-written as well as the destination
MAC is so that the next-hop device knows how to directly send back
replies [such as ICMP Unreachable] without having to go through
the routing table to figure out how to reply.

Further to this: anytime a device needs to reply to a packet for any
reason (e.g., it might be part of a TCP stream that is carrying FTP
traffic and it needs to respond with an ACK), then the device creating
the reply can in theory just blindly copy out the source IP and source
MAC from the packet it is replying to, put those in the destination IP
and destination MAC fields, copy out the destination IP and destination
MAC from the packet it is replying to, put those in the source IP and
source MAC fields, add the data it wants, and then just dispatch the
reply packet *without going through the routing procedure* (as long as
it knows which interface to use.)

Taking this one step further: if you have communication over a local
loop with no routing involved, then the -only- time any IP needs to
be paid attention to is for the very first routing decision that
located the MAC of the destination machine. After that, in theory
the entire rest of the connection could work entirely at the MAC
layer with nonsense IPs (or stealth data transfer ;-0) in the packet
headers. MACs are important for getting traffic where it is really
supposed to go, and the IP is only used to find out what the next
MAC along the line should be. [In practice, unix-type machines
often -do- go through routing for each packet, as the unix networking
control structures usually do not keep track of the interface,
and because routing can change dynamically in the middle of a connection,
and because you don't necessarily want the reply packets to go out
the same interface that the original packets came in.]
--
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald Knuth