Recursive Routing in Cisco Packet Tracer (8.2.2.0400)

[Breixo]

Because I’m quite curious about computer networks (and have started reviewing the CCNAv7 content), I decided to verify the behavior of Recursive Routing using Cisco Packet Tracer (version 8.2.2.0400). I know that the best tool for tasks like this —emulations or simulations— is Cisco Modeling Labs (CML), but my computer’s specifications do not allow me to test this in such a virtualized environment.

First, I set up a physical network topology with 4 routers (Cisco ISR4331), connected point-to-point in sequence from R1 to R4 (R1–R2–R3–R4). I want to verify that, with default configurations, R1 sends an ICMP Echo Request message to R4 (10.0.3.4) and, consequently, that R1 receives an ICMP Echo Reply message from R4. The IPv4 routing table outputs of R1, R2, R3, and R4 are shown below:

1. R1:

   C       10.0.1.0/24 is directly connected, GigabitEthernet0/0/1
   L       10.0.1.1/32 is directly connected, GigabitEthernet0/0/1
   S       10.0.2.0/25 [1/0] via 10.0.1.2
   S       10.0.3.0/24 [1/0] via 10.0.2.3

2. R2:

   C       10.0.1.0/24 is directly connected, GigabitEthernet0/0/1
   L       10.0.1.2/32 is directly connected, GigabitEthernet0/0/1
   C       10.0.2.0/25 is directly connected, GigabitEthernet0/0/0
   L       10.0.2.2/32 is directly connected, GigabitEthernet0/0/0
   S       10.0.3.0/24 [1/0] via 10.0.2.3

3. R3:

   S       10.0.1.0/24 [1/0] via 10.0.2.2
   C       10.0.2.0/25 is directly connected, GigabitEthernet0/0/0
   L       10.0.2.3/32 is directly connected, GigabitEthernet0/0/0
   C       10.0.3.0/24 is directly connected, GigabitEthernet0/0/1
   L       10.0.3.3/32 is directly connected, GigabitEthernet0/0/1

4. R4:

   S       10.0.1.0/24 [1/0] via 10.0.2.2
   S       10.0.2.0/25 [1/0] via 10.0.3.3
   C       10.0.3.0/24 is directly connected, GigabitEthernet0/0/1
   L       10.0.3.4/32 is directly connected, GigabitEthernet0/0/1

Note: I know it doesn’t make much sense to use subnet mask lengths shorter than /30 on point-to-point links. I simply chose this host notation because I believe it's more intuitive (R1 = .1, R2 = .2s, R3 = .3s, R4 = .4) and took the opportunity —from R1’s perspective— to practice forcing the processing of an IPv4 routing table closely resemble the output of the 'show ip route' command, which lists destination networks in ascending numerical order.

As expected:

R1#ping 10.0.3.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.4, timeout is 2 seconds:
...!!
Success rate is 40 percent (2/5), round-trip min/avg/max = 0/0/0 ms

R1#ping 10.0.3.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms

I then added a 5th router (Cisco ISR4331) connected point-to-point to R4 (R1–R2–R3–R4–R5). Now, I want to verify that, with default configurations, R1 does not send an ICMP Echo Request message to R5 (10.0.4.5), and, consequently, that R1 does not receive an ICMP Echo Reply message from R5. The IPv4 routing table outputs of R5, R4, R3, R2, and R1 are shown below:

• R5:

  S       10.0.1.0/24 [1/0] via 10.0.2.2
  S       10.0.2.0/25 [1/0] via 10.0.3.3
  S       10.0.3.0/24 [1/0] via 10.0.4.4
  C       10.0.4.0/23 is directly connected, GigabitEthernet0/0/0
  L       10.0.4.5/32 is directly connected, GigabitEthernet0/0/0

• R4:

  S       10.0.1.0/24 [1/0] via 10.0.2.2
  S       10.0.2.0/25 [1/0] via 10.0.3.3
  C       10.0.3.0/24 is directly connected, GigabitEthernet0/0/1
  L       10.0.3.4/32 is directly connected, GigabitEthernet0/0/1
  C       10.0.4.0/23 is directly connected, GigabitEthernet0/0/0
  L       10.0.4.4/32 is directly connected, GigabitEthernet0/0/0

• R3:

  S       10.0.1.0/24 [1/0] via 10.0.2.2
  C       10.0.2.0/25 is directly connected, GigabitEthernet0/0/0
  L       10.0.2.3/32 is directly connected, GigabitEthernet0/0/0
  C       10.0.3.0/24 is directly connected, GigabitEthernet0/0/1
  L       10.0.3.3/32 is directly connected, GigabitEthernet0/0/1
  S       10.0.4.0/23 [1/0] via 10.0.3.4

• R2:

  C       10.0.1.0/24 is directly connected, GigabitEthernet0/0/1
  L       10.0.1.2/32 is directly connected, GigabitEthernet0/0/1
  C       10.0.2.0/25 is directly connected, GigabitEthernet0/0/0
  L       10.0.2.2/32 is directly connected, GigabitEthernet0/0/0
  S       10.0.3.0/24 [1/0] via 10.0.2.3
  S       10.0.4.0/23 [1/0] via 10.0.3.4

• R1:

  C       10.0.1.0/24 is directly connected, GigabitEthernet0/0/1
  L       10.0.1.1/32 is directly connected, GigabitEthernet0/0/1
  S       10.0.2.0/25 [1/0] via 10.0.1.2
  S       10.0.3.0/24 [1/0] via 10.0.2.3
  S       10.0.4.0/23 [1/0] via 10.0.3.4

As unexpected:

R1#ping 10.0.4.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.4.5, timeout is 2 seconds:
...!!
Success rate is 40 percent (2/5), round-trip min/avg/max = 0/0/0 ms

R1#ping 10.0.4.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.4.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms

Is this behavior a bug in Cisco Packet Tracer version 8.2.2.0400? Or, if I add an Nth router (Cisco ISR4331), connected point-to-point to R(N–1) (R1–R2–R3–R4–R(N–1)–RN), will this still happen?