Extended IPv4 ACL Drill 2
This next Extended IPv4 ACL Drill continues to focus on some key ACL concepts. You have to think about where the ACL will reside, and for what direction of packet flow, before choosing the syntax of the commands. This next lab reverses the direction of flow versus the previous ACL drill.
As with all these ACL drills, today’s post gives you a set of requirements, and then a few variations on that set of requirements. The requirements may look familiar if you saw the previous exercise, but the answer is definitely different! Your job: Create an ACL that meets the requirements.
Ground Rules
First off, a quick note about some rules for this exercise. First:
These exercises are NOT intended to be about tricky wording.Β The requirements are intended to be plain.
That said, this exercise asks you to prevent ACLs in one subnet from communicating with a server in another subnet. You can filter packets going in either direction for the purpose of meeting that goal. In this exercise, you will need to filter packets flowing from the server to the client. That is not tricky wording – it’s just a chance to think about a different way to configure an ACL!
The Requirements
First, the exercise uses the topology in Figure 1:
Figure 1: Topology Used in the ACL Drill
Use the following requirements to decide how to configure a named IPv4 ACL to permit and deny specific applications:
- Use the ACL location shown with the circled 2, that is, inbound on router R1’s S0/0/0 interface.
- Deny any TCP and UDP traffic that is not otherwise noted to be permitted per these requirements, while allowing all other IP packets.
- For any ACL statements that could use either a number or a keyword (for instance, for a TCP port number), use the keyword, not the number.
- Permit the follow applications to work correctly between the subnet where host A resides and the subnet where server S resides.
- Telnet
- World Wide Web
- SMTP
Additionally, make sure that your ACL meets the following requirements for overhead protocols. Configure ACL statements only if necessary to meet these requirements:
- To allow IPv4 ARP to work correctly
- To allow IPv4 OSPF to work correctly
You should be able to extrapolate the necessary IPv4 addressing details from the following router address/mask reference table:
Device | Interface | Address/Mask |
R1 | G0/1 | 172.16.1.1/25 |
R1 | S0/0/0 | 172.16.12.1/30 |
R2 | G0/1 | 172.16.2.2/26 |
R2 | S0/0/1 | 172.16.12.2/30 |
R2 | G0/2 | 172.16.23.2/29 |
R3 | G0/1 | 172.16.3.3/27 |
R3 | G0/2 | 172.16.23.3/29 |
Router Interfaces and Their Address/Mask Settings
Why ACL Drills Now?
FYI, I decided to create these latest exercises because I’m working on the final edit of the videos in a new product: The CCNA ICND2 Exam Prep LiveLesson. (Here’s a link to the similar product for CCENT/ICND1; the new CCNA/ICND2 product will be on the web in a week or two.) That new product has a few videos that show some of the common mistakes made when working with ACLs, in particular the kinds of issues that can happen with the direction of flow. Stay tuned on those – should be out in June 2017 – maybe that related ACL video will be one of the free ones to check out before having to buy!
Answers: Next Post!
I’ll post in the answers within the next few days. Once posted, it should be linked at the bottom of this post, as the next post in chronological order. Thanks for playing!
Did you ever notice that your graphic has two routers both named R2? If was named D2 at least we’d have an R2-D2 connection. π
π