Original Answer
This happens because of your topology. I'm going to assume that you're pinging on the 192.168.0.0/16 subnet? Even if you are pinging the outward facing interfaces (10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16) on the routers, they still route through the 192.168.0.0 subnet on the way to their destination. The reason why this happens is because you are using a hub to connect all three machines on the same subnet (rather than a switch). The nature of the hub, by default, is to broadcast all messages received on all of its interfaces (as opposed to a switch which learns via responses which machines are connected to its interfaces).
So, the ICMP packet departs R1, and when it hits the hub, it's broadcast to R2 and R3 (as well as R1). This effectively duplicates the packet in triplet. The duplicate packets hit R1, R2 and R3 and trigger the forwarding rule:
C 192.168.0.0/16 is directly connected, FastEthernet1/0
Effectively bouncing the packets back to the hub. Rinse and repeat and you have a flooded network of multiplying ICMP packets. Solution: change the hub to a switch or implement the no ip redirects rule as suggested by Ron.
Addendum: Compare and Contrast Hub vs Switch, Detailed Packet Switching Mechanics with Various Hardware Protocols
The Hub:
A hub is a simple device that only knows how to do one thing: broadcast what it receives on all interfaces. When a packet comes from one of the three routers at the center of your network, the hub does what it knows how to do:
The ICMP Protocol
The ICMP protocol has some peculiar characteristics compared to other network protocols. It sits atop the Internet (or IP) layer, which is layer 3 in the TCP/IP model. Many people assume at first glance that it would exist in layer 2 with the other application protocols, but it doesn't. This is because ICMP was originally designed to be an error messaging protocol. The ICMP protocol reports meta-data about the IP layer in case of exceptional behaviour such as packet loss or unreachable destinations. So, when an ICMP packet comes into a device (such as a router), the device checks to see where the ICMP packet it destined, and if its destination is the device itself, it responds with a new message (e.g. PING REPLY). If its destination is another device, it decrements the time to live (TTL) and sends the packet on its way according to the device's routing table.
Cisco Routing Table
There is a third piece of the puzzle to consider, and that's the Cisco device's routing table. We know how the routing table looks after the network has been running for awhile. In response to your question:
Why would any router route through the 192.168.0.0 through the
destination network (say 10.1.0.0) is directly attached to it and not
reported via any router.
This is due to the network discovery mechanisms on the Cisco routers. Pay attention to these lines in the routing table:
O 10.1.0.0/16 [110/2] via 192.168.0.1, 00:58:17, FastEthernet1/0
O 10.2.0.0/16 [110/2] via 192.168.0.2, 00:58:17, FastEthernet1/0
The O at the beginning stands for OSPF, which is a proprietary routing algorithm that populates the routing table on the Cisco device. I'm not sure of the details of how the routing table is populated, but it's kind of irrelevant. Each router knows that it can access the outward facing interfaces of the other two routers by sending traffic through the 192.168.0.0/16 subnet. So, when a packet destined for any of those interfaces (say, an ICMP PING REQUEST) comes into the router from the hub, each router knows it can reach the destination network through the local subnet. Hence, as long as the packet is not bound for the device itself, these packets will have their TTL decremented and they will be forwarded back to the hub (the following diagram happens on every device which receives a packet not bound for itself AND not sent from itself):
As you can see, the three things together create a loop which keeps forwarding and generating duplicate ICMP packets until one of the following things happen to the packets:
- The packet reaches its destination and is consumed.
- The packet's TTL reaches zero and is discarded (but an ICMP HOST UNREACHABLE response is generated and fired back out on the network).
- The packet is registered as a duplicate on the receiving device (already consumed) and is discarded.
There may be a few generalizations in my answer, but you get the picture. More packets are generated by the hub than are consumed.
How a Switch Behaves Differently (and why we use switches instead of hubs)
When you first plug in a switch, it's dumb just like the hub is. The primary difference, however, is that the switch can learn where packets are coming and going from by paying attention to the traffic coming through the device. When a packet is first encountered by the switch, it doesn't know which interface the destination is connected to, so it forwards it to all its connected interfaces. When it does this, it records the source and destination IP it its switch table. When a response coming from that destination (and destined toward the original source) is detected, it completes the entry in the switch table. After this, the switch knows which IP addresses are connected to corresponding interfaces. From this point on, when it accepts a packet, it only forwards it out the interface where it knows the destination is connected. This eliminates the duplicating packet problem.
MAC vs IP address and Packet Routing with Ethernet vs PPP
You asked:
Why would router R3 that receives packet with MAC destination of R2
(sent from R1) would respond at all on ICMP level?
Packet Routing with Ethernet and Other Protocols that Leverage MAC Addresses
Packets may start with empty or BROADCAST destination MAC addresses (depending on the hardware standard). With the Ethernet hardware standard (and a handful of others such as Wifi), when any packet is sent out from a router or host machine, the destination IP is checked against the Address Resolution Protocol (ARP) table (this is the table that keeps track of MAC addresses). If a match is found against a locally connected machine on the same subnet, then the MAC address field of the packet is updated before it's sent out on the network. HOWEVER, if the packet is destined for an IP address on a different subnet, the MAC address is set to the MAC of the Default Gateway, or a gateway to which it knows it can reach the destination IP (because the machine knows that the destination is on a different network).
Packet Routing PPP, SLIP and other Hardware Protocols that do not Leverage MAC Addresses
Generally, if two routers (gateways) are connected directly with no routers in between, this is considered a "peer-to-peer" connection. Generally, these types of connections are not Ethernet, and use other standards. The most common of these standards is the Point to Point Protocol (PPP), but there are others such as SLIP and PPPoE (PPP over Ethernet). If the router considers the "C"onnected or "O"SPF entries in its routing table as peer-to-peer connections, then the MAC address on the packet could be set to empty values, or be set to BROADCAST, or they may use dummy values, or not even use MAC addresses at all (this could differ depending on the standards of the hardware protocol connecting them, however, which I am not familiar with in this case). In order to tell exactly what's happening, you would have to learn more about the Cisco router hardware standards and how they deal with MAC addresses and peer-to-peer connections and which hardware protocol they are using (which most likely will be PPP by default).
Implications in This Scenario
As packets are transported over networks, each receiving router does one of two things (depending on the hardware protocol used):
- Ethernet, Wifi and other hardware standards: It either changes the MAC address en route if it can find a route, OR
- PPP, SLIP and other hardware standards: it leaves the MAC empty, or sets it to a special BROADCAST value which is accepted by any receiving machine, or it may not even care at all about MAC addresses, or could even set them to dummy values.
This happens at every hop along the network until a router detects that the destination IP is on its local Ethernet (or other standard that uses MAC) subnet. This is effectively how addresses are translated at the hardware or physical layer. So, to answer your question, in this scenario it appears that all R3 knows is that the packet is destined for another network that it can reach through its f1/0 interface. It doesn't care what the MAC address is because it's using a protocol that doesn't leverage MAC addresses. According to Microsoft:
Looking at the thread the MAC header that is seen on Ethereal is the
dummy Ethernet header added between WANARP and NDISWAN. This way the
network monitors (like ethereal) sees the PPP interface as an Ethernet
interface. But on wire ... the packet will not
contain that Ethernet header, but instead it will be TCP->IP->PPP
headers
So you should not look at the MAC addresses on the Network Monitor as
the real MAC addresses.
Notice there is no default gateway in your routing table:
Gateway of last resort is not set
This, along with the fact that the primary entries are listed as directly connected, suggests that it would treat all of its connections as peer-to-peer connections (and therefore MAC address agnostic).
As an aside, you might wonder why MAC addresses aren't used for PPP or, more generally, for network addressing in general. Check out this post here. The first comment on the accepted answer confirms what I've been saying:
I would have added that MAC addresses are ultimately used in IP
communications once the computers determine they're on the same
subnet ... Layer-3 / IP addressing is mostly used by routers
and only used by the host to determine if the destination is on the
same subnet. (Credit to Sean C.)
