CCNA BootCamp

4 Certs Included!

Skillset

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.

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:

Compare the defined access policy to the configured ACLs and make sure the ACLs are properly configured.

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

permit tcp 192.168.10.0 0.0.1.255 172.16.4.0 0.0.0.255 eq 22

Since 192.168.10.0/24 and 192.168.11.0/24 can be summarized as 192.168.10.0/23 (192.168.10.0 0.0.1.255 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 192.168.10.0/24 and 192.168.11.0/24 networks to all the 172.16.X.0/24 networks. There are four networks in the 172.16 range, as follows: 172.16.4.0/24, 172.16.5.0/24, 172.16.6.0/24, and 172.16.7.0/24. We know that these networks can all be summarized as 172.16.4.0/22, which in wildcard mask notation is 172.16.4.0 0.0.3.255. Therefore, the other ACE in the FROM_R1 ACL is also correct:

permit icmp 192.168.10.0 0.0.1.255 172.16.4.0 0.0.3.255 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 192.168.12.0/24 and 192.168.13.0/24 should be allowed to 172.16.4.0/24, 172.16.5.0/24, and 172.16.6.0/24. The ACE that seems to match this policy is as follows:

permit ip 192.168.12.0 0.0.1.255 172.16.4.0 0.0.3.255

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 172.16.4.0 0.0.3.255, i.e., 172.16.4.0/24 to 172.16.7.0/24. However, the policy does not include 172.16.7.0/24 as part of the networks for which IP traffic should be allowed. Therefore, we need to edit this ACL as follows:

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:

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 192.168.10.0/24 and 192.168.11.0/24 networks can open SSH connections to 172.16.4.0/24. The router in that network has an IP address of 172.16.4.100 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 192.168.12.0/24 and 192.168.13.0/24 to the 172.16.X.0/24 (except 172.16.7.0/24):

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 172.16.12.100 to 172.16.4.100, 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: 172.16.12.100 sends the traffic to its default gateway (R2); R2 checked its routing table for directions on reaching 172.16.4.100 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 (172.16.4.1) 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 192.168.13.0/24. Let’s add those routes:

ip route 192.168.12.0 255.255.254.0 10.1.23.2

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.

Summary

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

Adeolu Owokade is a technology lover who has always been intrigued by Security. He has multiple years of experience in the design, implementation and support of network and security technologies. He's a CCIE (Security) with a new found love in writing.

About Intense

Intense School has been providing accelerated IT training and certification for over 12 years to more than 45,000 IT and Information Security professionals worldwide. Come see why we have the highest pass rates in the industry!

Join our newsletter

File download

First Name

Last Name

Work Phone Number

Work Email Address

Job Title

How will you fund your training?

Why Take This Training?

What is your timeline for training?

InfoSec institute respects your privacy and will never use your personal information for anything other than to notify you of your requested course pricing. We will never sell your information to third parties. You will not be spammed.

Comments

What is Skillset?

Skillset

Practice tests & assessments.

Practice for certification success with the Skillset library of over 100,000 practice test questions. We analyze your responses and can determine when you are ready to sit for the test. Along your journey to exam readiness, we will:

1. Determine which required skills your knowledge is sufficient
2. Which required skills you need to work on
3. Recommend specific skills to practice on next
4. Track your progress towards a certification exam