Yet Another Ethernet Data Link Frame
You can almost feel the excitement in the air. R1 has received
the frame, discarded the Ethernet header and trailer, and made a routing
decision. However, R1 has an IP packet sitting in memory, and R1 knows it can't
simply send an IP packet out its Ethernet2 interface. The solution is simple,
and hopefully a little familiar: R1 needs to encapsulate the packet in another
Ethernet frame.
Until R1 transmits the bits out its Ethernet2 interface, R1's
logic is just like Hannah's logic was earlier. R1's logic goes something like
this, in this example:
-
Before sending the packet out Ethernet2, it needs to be
encapsulated inside an Ethernet frame.
-
The source MAC address of this new Ethernet header is the MAC
address of my Ethernet2 interface.
-
The destination MAC address of this new Ethernet header is the
MAC address of R2.
-
Before forwarding the first packet to R2, an ARP broadcast is
required to find R2's MAC address. R1 records that information in its ARP cache
for any additional packets.
Imagine that R1 doesn't know R2's MAC address. Figure 11-11 shows the ARP broadcast, the ARP reply, and
finally, the new Ethernet frame, which delivers the packet from R1 to R2.
Sections
Comments (0 posted)
Syndication
