1

I am trying to play (in GNS3 if that matters) with a very simple topology of three routers connected via hub. The time I am trying to ping from one of the router to another say R1 to R2. The R3 replies with ICMP redirect message causing R1 to re issue the ping request to R2. The loop continues infinitely wrecking havoc on simulated network. The question is why R3 replies to R1 for ICMP message not directed to it (ping is from R1 to R2). enter image description here

R3 routing table :-

R3>enable
Password:
R3#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
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
C        10.3.0.0/16 is directly connected, FastEthernet0/0
L        10.3.0.1/32 is directly connected, FastEthernet0/0
C     192.168.0.0/16 is directly connected, FastEthernet1/0
      192.168.0.0/32 is subnetted, 1 subnets
L        192.168.0.3 is directly connected, FastEthernet1/0
R3#

UPDATE: The problem is not ICMP redirect but the fact that any router will place the ICMP ping packet it cannot handle back to the interface it arrived from flooding the network till TTL expires.

  • Can you give us a diagram of the network as well as the ip addressing info for each router and the output of their routing tables? – joeqwerty Jul 22 '16 at 3:42
  • 1
    I would like to look at the configurations of R1 and R3. You can also use the no ip redirects command (a best practice) on your router interfaces. – Ron Maupin Jul 22 '16 at 3:51
  • Please add the output of the routing table for each router and show us the ping command you're running. – joeqwerty Jul 22 '16 at 3:53
  • I was really most interested in the routing table for R1. Could you add the routing table for R1 and R2? – joeqwerty Jul 22 '16 at 4:07
  • 1
    I understand the problem as you've described it but I'd like to see the routing table from R1 and R2 so that I can understand them. – joeqwerty Jul 22 '16 at 4:16
3

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:

Hub IO

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):

ICMP Diagram

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:

  1. The packet reaches its destination and is consumed.
  2. The packet's TTL reaches zero and is discarded (but an ICMP HOST UNREACHABLE response is generated and fired back out on the network).
  3. 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):

  1. Ethernet, Wifi and other hardware standards: It either changes the MAC address en route if it can find a route, OR
  2. 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.)

  • 1
    You should update this answer to remove the initial comment as it almost made me downvote it although the answer seems rather accurate actually. – Julie Pelletier Jul 23 '16 at 11:49
  • 1
    I will certainly not downvote the as I do not have neither kind of experience or rating. So please please be kind to me :) Indeed replacing hub with switch resolves the problem. Also notice that the same problem woud occur if only R1 and R2 are up. However I have following questions - It sounds like replicating the packet to the same port where the packet has arrived from (mirroring in some sense) is normal hub behavior? Sounds strange to me. - Why would router R3 that receives packet with MAC destination of R2 (sent from R1) would respond at all on ICMP level? – Boris Jul 23 '16 at 18:25
  • 1
    - 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. – Boris Jul 23 '16 at 18:27
  • 2
    @Boris: That is the difference between a hub and a switch. Hubs are extremely dumb which is why they are almost not used anymore. – Julie Pelletier Jul 23 '16 at 22:34
  • 1
    Marking it as answer as it includes my comments about the MAC issue which is the root of the problem. – Boris Jul 26 '16 at 4:48

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.