Welcome to the third article in this troubleshooting series, where we are presented with different troubleshooting scenarios and asked to resolve the issues. The scenario in this lab will focus on sub-sections 7.4 and 7.8 of the CCNA R&S exam topics, which cover IP routing and access lists troubleshooting.

We will be using the following setup for this troubleshooting scenario:

The following access policy has been defined for the network shown above and it has been implemented using ACLs on R3:

  • Permit SSH connections from networks and to network
  • Permit ICMP (ping) from networks and to all the 172.16.X.0/24 networks.
  • Permit all IP traffic from networks and to networks, and
  • Permit TCP traffic from networks and to network
  • Deny all other undefined traffic.

Review the configuration on the devices (restrict your troubleshooting to the routers) and ensure that not only is the policy properly configured but that there is IP connectivity between the networks.

Two files are attached to this article:

  • trblsht_routing_acl_init.pkt: This Packet Tracer file contains the lab setup with various configuration issues.
  • trblsht_routing_acl_final.pkt: This Packet Tracer file contains the lab with the issues resolved.

Troubleshooting Scenario Resolution

When ACLs come into the picture, you may need to take another approach to troubleshooting because a traffic flow test case that you want to use may be blocked by the ACL. In this article, we will take the following approach:

  1. Compare the defined access policy to the configured ACLs and make sure the ACLs are properly configured.
  2. Test using various traffic flow cases that should be allowed/denied.
  3. Resolve any issues that arise.

Step 1: Review ACLs

For easy reference, I will paste the ACL configuration on R3 here:

ip access-list extended FROM_R1
 permit icmp echo
 permit tcp eq 22
ip access-list extended FROM_R2
 permit ip
 permit tcp

Let’s start with the FROM_R1 ACL. The first access policy defined says that SSH should be allowed from and to The second ACE in the FROM_R1 ACL seems to match this policy:

permit tcp eq 22

Since and can be summarized as ( in wildcard mask notation), then we can confirm that this ACE is correct.

The second defined policy says that ping should be allowed from the and networks to all the 172.16.X.0/24 networks. There are four networks in the 172.16 range, as follows:,,, and We know that these networks can all be summarized as, which in wildcard mask notation is Therefore, the other ACE in the FROM_R1 ACL is also correct:

permit icmp echo

It seems the FROM_R1 ACL is fine, so we can now move on to the next ACL: FROM_R2. The third defined access policy says that all IP traffic from and should be allowed to,, and The ACE that seems to match this policy is as follows:

permit ip

At first glance, this ACE looks correct but, if we look deeper, we notice something is wrong with the destination network portion of the ACE: It matches, i.e., to However, the policy does not include as part of the networks for which IP traffic should be allowed. Therefore, we need to edit this ACL as follows:

ip access-list extended FROM_R2
 no permit ip
 permit ip
 permit ip

Finally, the last access policy says that TCP should be allowed from and to The last ACE in the FROM_R2 seems to implement this policy:

permit tcp

Looking at this ACE, we see a problem – the source and destination networks are in reverse – therefore, we need to fix it as follows:

ip access-list extended FROM_R2
 no permit tcp
 permit tcp

To conclude on the ACLs, we need to check how they are applied:

interface GigabitEthernet0/1
 ip address
 ip access-group FROM_R1 out
interface GigabitEthernet0/2
 ip address
 ip access-group FROM_R2 in

As you can see, the FROM_R1 ACL is applied on R3’s Gi0/1 interface in the outbound direction while FROM_R2 is applied on R3’s Gi0/2 interface in the inbound direction. Think about the traffic flow for a minute and the ACEs contained in the ACLs; are the ACLs applied in the right direction? You should conclude that the FROM_R1 ACL is applied in the wrong direction, i.e., it will apply to traffic leaving the Gi0/1 interface instead of traffic coming in through that interface. Therefore, we need to make the following change:

interface GigabitEthernet0/1
 no ip access-group FROM_R1 out
 ip access-group FROM_R1 in

Step 2: Test Traffic Flow

In this step, we will test our configuration to check that everything is working as it should. One thing you should do while creating test cases is to test not only for traffic that should be permitted but also for traffic that should be denied. This way, you stand a higher chance of knowing whether you have mistakenly allowed something to go through.

The first test we will do is if the hosts in the and networks can open SSH connections to The router in that network has an IP address of with a username of “admin” and password of “cisco”:

The second test we will perform is to ping from these same hosts to any device in the 172.16.X.0/24 network. For brevity sake, I will show just two ping sessions—you can confirm the rest:

Now let’s move to the R2 side. We will test that IP traffic (e.g., ICMP ping) can go from and to the 172.16.X.0/24 (except

If you continue troubleshooting, you will discover that this device can ping its default gateway (R2) and so you should move your troubleshooting to that device. If you issue the show ip route command on R2, you will see this:

Strange-looking routing table, right? Well, maybe that’s because IP routing is not enabled on this router:

We need to enable IP routing using the ip routing command. You may also want to enable IP CEF (ip cef) because it was automatically disabled when routing was disabled.

Now if we check the routing table on R2, we see that it has a default route to R3:

However, if we try to ping again from to, it will fail. One thing that helps me during troubleshooting is to turn on ICMP debugging (maybe with an ACL) if possible. So we can turn on ICMP debugging on R3_1 (debug ip icmp) and try to ping again:

Note: Be careful of using the debug command in a production network, as you may actually overwhelm the device.

Think for a minute about how the traffic flowed: sends the traffic to its default gateway (R2); R2 checked its routing table for directions on reaching and sends it to R3; R3 has a direct connection to that network, so it forwards it to R3_1. We know R3_1 received the ping packet because it sends an echo reply as shown in the debug output above. However, the next message tells us the problem: R3 ( sends an ICMP unreachable to R3_1. Therefore let’s check what is happening on R3:

R3 does not have a route to that network. If we check the entire routing table, you will also discover that R3 doesn’t have a route for Let’s add those routes:

ip route

With the routing sorted, we should now have a reply to our ping:

You can try other tests to make sure everything is working as it should.


I hope you have found this lab challenging. In this lab, we have looked at IP routing and ACL troubleshooting.