Welcome to Jeremy’s IT Lab. This is a free, complete course for the CCNA. If you like these videos, please subscribe to follow along with the series. Also, please like and leave a comment, and share the video to help spread this free series of videos. Thanks for your help. In this video we will cover standard ACLs, access control lists. I’ll be splitting up ACLs into two days, this video and the next one, Day 35, which will cover another kind of ACL. ACLs are in the exam topics under section 5, security fundamentals. Specifically, topic 5.6, which says you must be able to configure and verify access control lists. It doesn’t specify IPv4 or IPv6, but for the CCNA you just have to learn IPv4 ACLs. Perhaps later I’ll make an extra video introducing IPv6 ACLs, but currently it’s not necessary for the CCNA. Here’s what we’ll cover in today’s video. First, what are ACLs? I’ll introduce their basic purpose. I’ll talk about ACL logic, how they are actually processed by the router. I’ll introduce the basic types of ACLs on Cisco routers. After that I’ll show you how to configure two kinds of ACLs, standard numbered ACLs and standard named ACLs. As always, watch until the end of the quiz for a bonus question from Boson ExSim for CCNA, the best practice exams for the CCNA, and in my opinion the best tool to get ready for the CCNA exam. So, what are ACLs? ACLs, Access Control Lists, actually have multiple uses. The name ‘access control’ tells us that they control access to the network. For example, Host A should be allowed to access Server A, but Host B should not be allowed to access Server A. In Day 34, this video, and Day 35 we will focus on ACLs from a security perspective. So, like I just said, controlling which devices have access to which parts of the network. However, although that is the main purpose of ACLs, that’s not the only purpose. Later in the course you’ll see some other uses of ACLs. But for now, we’ll focus on ACLs from a security perspective, controlling who has access to different parts of the network. So, when using ACLs in this way, ACLs function as a packet filter, instructing the router to permit or discard specific traffic. As you know, if a router receives a packet and it has a route to the packet’s destination, it will by default forward the packet according to its routing table. However ACLs let us control that. Even if the router has a route to the destination, the packet might be discarded if the ACL tells the router to do so. ACLs can filter traffic based on the source and destination IP addresses, source and destination Layer 4 port numbers, etc. For the CCNA, we’ll just focus on those two, IP addresses and port numbers, but you can get more advanced with ACLs also. Okay, I think showing you will make things easier to understand than just explaining. So, we have two routers, R1 and R2, with a point-to-point connection. The 192.168.1.0/24 network is connected to R1, and I’ve shown a couple PCs in the network, PC1 and PC2. Notice that, instead of including a switch in the diagram and showing the PCs connected to the switch, I represent the network segment like this. This is common in network diagrams. In reality, all of the PCs in the 192.168.1.0/24 network are connected to a switch, and the switch is connected to R1, but we don’t actually have to include the switch in this diagram. The 192.168.2.0/24 network, with PC3 and PC4, is also connected to R1. The 10.0.1.0/24 network, with SRV1, is connected to R2, and the 10.0.2.0/24 network, with SRV2, is also connected to R2. I’ll use this network to demonstrate how ACLs work. So, without looking at the actual configurations yet, let’s build an ACL so you can see how they work. We shouldn’t just configure ACLs randomly, we must use them to achieve a certain requirement. For example, let’s say the network policy is that hosts in 192.168.1.0/24 should be able to access the 10.0.1.0/24 network. They should be able to access files on SRV1, for example. However, hosts in the 192.168.2.0/24 network should not be able to access 10.0.1.0/24. PC3 and PC4, for example, should not be able to access files on SRV1. How can we use ACLs to achieve this? First up, ACLs are configured globally on the router, in global config mode. ACLs are made up of an ordered sequence of ACEs, access control entries. For example, to fulfill our requirement, we could configure ACL 1 like this on R1 or R2. ACE 1 says if source IP equals 192.168.1.0/24, then permit the packet, let the router forward it. ACE 2 says if source IP equals 192.168.2.0/24, deny the traffic. ACE 3 says that all other traffic should be permitted. The order of these entries is very important, but I’ll talk more about that later. Configuring an ACL in global config mode will not make the ACL take effect. After being created, the ACL must be applied to an interface. ACLs are applied either inbound or outbound. Let’s see how that works. Here’s that same ACL as before. Let’s say we configured it on R1. So it has been created, but it hasn’t been applied yet. Let’s walk through some examples of applying ACL 1 to different interfaces in different directions. Once again, here are the requirements. Depending on which interface we apply the ACL to, and which direction we apply it in, we will either succeed in meeting the requirements or fail. For example, what if we applied it outbound on G0/2. That means it will only take effect on traffic exiting G0/2. Does that fulfill the requirements? The answer is no, it doesn’t fulfill the requirement. Why not? Because R1 will only use the ACL to filter traffic exiting G0/2, not entering it. If PC3 tries to ping SRV1, when the ping reaches R1 it won’t even check the ACL, because the traffic is entering G0/2, not exiting it. So, R1 will forward the traffic to R2, which will forward it to SRV1. Now, when SRV1 sends the reply to PC3, R1 will check the ACL to decide if the traffic should be forwarded out of G0/2 or not. It will check the entries of ACL1 in sequence. If source IP = 192.168.1.0/24. Well, the source is SRV1, so that doesn’t apply. If source IP = 192.168.2.0/24. That doesn’t apply either, the source is not in that subnet. So, R1 reaches the last entry which says permit all other traffic, so it forwards the reply to PC3. PC3 was able to access SRV1, even though hosts in 192.168.2.0/24 shouldn’t be able to. Clearly, we didn’t apply this ACL correctly. What if we applied the ACL inbound on G0/2? That means R1 will check the ACL for all traffic entering G0/2. So, if PC3 tries to ping SRV1, R1 will check the ACL. Once again, it will check the entries in order, from top to bottom. If source IP = 192.168.1.0/24. The source isn’t in that subnet, so it checks the next entry. If source IP = 192.168.2.0/24. The source is 192.168.2.1, which is in 192.168.2.0/24, so there’s a match! That means that R1 will take the specified action, which is deny. So, R1 drops the traffic, it doesn’t forward the packet. Once a router finds a match and takes an action, it stops checking the other entries in the ACL, so this ‘permit all other traffic’ is ignored. So, does this fulfill our requirements? Yes and no. 192.168.1.0/24 will be able to access 10.0.1.0/24 no problem, there is no ACL stopping them from communicating. Also, hosts in 192.168.2.0/24 are prevented from accessing 10.0.1.0/24, as you just saw R1 dropped the traffic from PC3. However, by applying the ACL inbound on G0/2 we are being too restrictive. This blocks hosts in 192.168.2.0/24 from communicating with all other networks outside of their local LAN. PC3 and PC4 can communicate with each other, but that’s it. So, this is not the best way to apply this ACL. There are some other possibilities we could try, such as applying it to R1’s G0/0 or R2’s G0/0, but let’s take a look at the best option. The best location to place this ACL is outbound on R2’s G0/1 interface. Let’s see how it works. If PC3 tries to ping SRV1, R2 will check the ACL before forwarding the packet out of its G0/1 interface. The first entry says if source IP equals 192.168.1.0/24 then permit, but the source isn’t in that subnet. So R2 checks the next entry. If source IP is in 192.168.2.0/24, then deny. The source is in that subnet, so the packet will be denied and R2 will not forward it. So, that satisfies the second requirement, hosts in 192.168.2.0/24 can’t access 10.0.1.0/24. What if PC1, in 192.168.1.0/24, tried to ping SRV1? Before forwarding the packet out of its G0/1 interface, R2 will check the ACL. If the source IP is in 192.168.1.0/24, then permit. The source is 192.168.1.1, so the packet is permitted and R2 forwards it to SRV1. Both requirements have been satisfied, and there is no effect on other traffic. I hope that demonstration helped you understand what an ACL is and how they work. If you’re still a little confused, don’t worry. Let me explain a little more about some of the things I just mentioned. So, ACLs are configured in global config mode, but then you must apply it to an interface. When applying it to an interface, you specify a direction. This tells the router to either check packets that enter the interface, or check packets that exit the interface. ACLs are made up of one or more ACEs, access control entries. When the router checks a packet against the ACL, it processes the ACEs in order, from top to bottom. I just showed you this. For example here in ACL 1, the router will check if the packet’s source is in 192.168.1.0/24, then it will check if the packet’s source is in 192.168.2.0/24, and if it doesn’t match either of those it will permit it. Another point I briefly mentioned before, if the packet matches one of the entries in the ACL, the router takes the action and stops processing the ACL. All entries below the matching entry will be ignored. Let me show you an example. Here we have a router and another ACL. The first entry in the ACL says if source IP = 192.168.1.0/24, then permit. However the second entry says if source IP = 192.168.0.0/16, then deny. What effect will this have if applied outbound on the G0/0 interface of this router? If a packet with a source IP of 192.168.1.1 arrives on G0/1, before forwarding the packet out of G0/0 the router will check it against the ACL. The source is 192.168.1.1, which matches the first entry, so the router will forward the packet as normal. This second entry will simply be ignored. Now I’ve reversed entries 1 and 2 in ACL 2. What will the effect be if the same packet is received by the router? It will once again check ACL 2 before forwarding the packet. The first entry tells the router to deny the packet, so it will be discarded, not forwarded out of the interface. Entry 2, which tells the router to permit that packet, is ignored. So, I think you can see how important the order of the entries in an ACL is. Now, here’s one more point about ACLs. A maximum of one ACL can be applied to a single interface per direction. So, one inbound ACL is allowed and one outbound ACL is allowed, for a maximum of two ACLs. If you apply a second ACL to an interface in the same direction as another one, it will replace the previous one. Next up, another important part of ACLs, the ‘implicit deny’. Here’s a question. What happens if a packet doesn’t match any of the entries in an ACL? So, here’s the same ACL, and the same router. This time the router receives a packet with source IP 10.0.0.1. Before forwarding it out of G0/0, the router checks it against the ACL. 10.0.0.1 doesn’t match the first entry. And it doesn’t match the second entry either. So, what happens? The answer is, the router will deny the packet, it will not forward it. This is what we call the ‘implicit deny’. Even though there is no entry in the ACL telling the router to deny the packet, it’s like there is an invisible entry at the end, if source IP = any, then deny. This is true for all ACLs. To summarize this point, there is an implicit deny at the end of all ACLs. This tells the router to deny all traffic that doesn’t match any of the configured entries in the ACL. Always be aware of the implicit deny when configuring ACLs, or you might deny traffic that you didn’t want to deny. Now that you have an idea of the basic operations of ACLs, let me introduce the different types of ACLs you will learn about in today’s video and in Day 35. There are two main types of ACLs, and those two types have two sub-types. The first type are standard ACLs, these match based on source IP address only, so they are quite simple. The two types of standard ACLs are standard numbered ACLs, which are identified with a number like 1, 2, etc. And there are also standard named ACLs, which are identified with a name. There are also differences in how you configure numbered and named ACLs, but we’ll get to that later. In addition to standard ACLs, there are also extended ACLs. These are more complex and can match based on source and/or destination IP address, source and/or destination port numbers, as well as some other things. Like standard ACLs, there are numbered and named versions of extended ACLs, too. As I said in the beginning of the video, today we’ll focus on standard ACLs. All of the examples so far have been standard ACLs, filtering packets only based on their source IP address. In Day 35 I’ll tell you all about extended ACLs, but now let’s learn some more about standard ACLs and then see how to actually configure them. So let’s get into standard numbered ACLs. As I just mentioned, standard ACLs match traffic based only on the source IP address of the packet. So, standard ACLs are quite simple. The router doesn’t check the destination IP, the source Layer 4 port, the destination port, etc. It just looks at the source IP address of the packet and decides to forward or block it. Numbered ACLs are identified with a number. You can, of course, configure multiple ACLs on a single router, so you need to identify each ACL. Numbered ACLs use a number like ACL 1, ACL 2, etc. There are also named ACLs, which I’ll introduce later. Here’s an important point. Different types of ACLs have a different range of numbers that can be used. Standard ACLs can use 1 to 99 and 1300 to 1999. Originally, standard ACLs could only use 1 to 99, meaning you could have a maximum of 99 standard ACLs on a single router. Later this was expanded to include 1300 to 1999. So, you can’t configure a standard ACL with the number 100, for example. The number has to be in one of these ranges. Here are a bunch of different ACL types, and the different number ranges that identify them. You don’t have to memorize all of these, of course. For now, just remember the standard ACL ranges, 1 to 99 and 1300 to 1999, listed as ‘Standard IP’ ACLs in this chart. ‘IP ACL’ is the type of ACL you have to learn for the CCNA. I just wanted to show you that there are lots of different types of ACLs, and each have their own range of numbers. Here’s the basic command to configure a standard numbered ACL. ACCESS-LIST, followed by the number. We’re configuring standard ACLs, so this number must be in the range 1 to 99 or 1300 to 1999. Then you specify either deny or permit, and then the IP address and wildcard mask to match against. Hopefully you remember wildcard masks from the EIGRP and OSPF videos. Don’t try to use a standard subnet mask when configuring ACLs. So, this is how you configure a single entry in access-list 1. Here are some examples. ACCESS-LIST 1 DENY 1.1.1.1 0.0.0.0. So, this denies 1.1.1.1/32, meaning only 1.1.1.1, a single host. Now, when you specify a /32 mask in an ACL, you don’t actually have to specify the wildcard mask. You can just specify 1.1.1.1, and the router will understand that it’s /32. So, these are just two different ways of configuring the exact same thing. Now, there is one more method of configuring a /32 entry. It’s considered an old method, but it still works on modern routers. To specify a single host, you can use the HOST keyword before the IP address. Again, in effect this is exactly the same as the previous two, it’s just a different way of configuring it. So, all three of these are the same in effect. Note that the 2nd and 3rd options here can only be used for /32, to specify a single host. If you’re matching a /24 network, for example, you’ll have to use the 1st option, you have to specify the wildcard mask of 0.0.0.255. Okay, so let’s say we used one of those options to configure an entry in ACL 1 that blocks 1.1.1.1/32. If we leave the ACL as is, all other traffic will be blocked, too, because of the implicit deny. So, let’s make another entry in this ACL to permit traffic. Here it is. ACCESS-LIST 1 PERMIT ANY. This tells the router to permit all traffic, with any source IP. Now, here’s a quiz. The ANY keyword is convenient, but how can we specify an IP address and wildcard mask that has the same effect? Pause the video and think about it, what IP address and wildcard mask matches all addresses? Okay, the answer is 0.0.0.0 255.255.255.255, which is 0.0.0.0/0, and matches all addresses. So, these two options are exactly the same. As you can see, ACL configuration can be quite flexible. In these examples I’ll use a variety of methods so you can be aware of all of them, but feel free to pick your favorite and just use that. ‘ANY’, for example, is much quicker to type than 0.0.0.0 255.255.255.255. Finally, here’s one more thing you can configure for an ACL, a remark. This is like an interface description. It doesn’t have any effect on the ACL, it’s just a description that helps you remember the purpose of the ACL when looking at it in the configuration. Note that the command is ACCESS-LIST 1 REMARK, followed by the remark. The hashtags, or pound symbols, whatever you call them, aren’t a necessary part of the command. I just use them to make it easier to see when looking at the config. Okay, so I tried actually configuring that ACL, let’s check it out. For both the deny and permit entries I decided to enter the whole IP address and wildcard mask. Then I used SHOW ACCESS-LISTS, which displays all ACLs on the router. There are a few things to point out here. First up, notice that the router automatically converted DENY 1.1.1.1 0.0.0.0 to just DENY 1.1.1.1. The router does this when you use a /32 mask. Also, PERMIT 0.0.0.0 255.255.255.255 was automatically converted to PERMIT ANY. You probably also noticed that the remark isn’t displayed in this command, it’s only displayed in the config. Finally, notice that each entry is given a number indicating the order. I configured the DENY statement first, and it was assigned 10, then the PERMIT statement was assigned 20. Remember, the order of these entries is very important. If the PERMIT ANY entry was first, all traffic would be permitted and the DENY 1.1.1.1 entry would be useless. On modern devices, the router should prevent you from doing configurations like that, but you should still be aware of how important the order is. Okay, next I used the command SHOW IP ACCESS-LISTS. Notice that the output is exactly the same as for SHOW ACCESS-LISTS. As you saw before, there are many kinds of ACLs. SHOW ACCESS-LISTS displays all kinds, but SHOW IP ACCESS-LISTS displays only IP ACLs, the kind we will be configuring in these videos. You can use either command to check your ACLs, it doesn’t matter. Finally, I used SHOW RUNNING-CONFIG, followed by the pipe, and then INCLUDE ACCESS-LIST to only show lines in the config that include ACCESS-LIST. Notice once again that the deny and permit entries were automatically changed by the router. Also, the remark is displayed this time. Now, remember I said you have to actually apply the ACL to an interface? Here is the command. From interface config mode, use IP ACCESS-GROUP, that’s right, it’s ACCESS-GROUP, not ACCESS-LIST, then the ACL number, then IN or OUT. Now let’s get into a real example of using these configurations, that should help you understand. Here’s the same network as before. I’ll give some requirements, and we’ll use ACLs to restrict the traffic to fulfill those requirements. On R1 I’ll configure standard numbered ACLs as I just showed you, then I’ll introduce standard named ACLs and we’ll configure them on R2, so you can see how to configure both types. Okay, first here are some requirements which we can achieve by configuring an ACL on R1. PC1 should be able to access the 192.168.2.0/24 network, but other PCs in 192.168.1.0/24 shouldn’t be able to access 192.168.2.0/24. So, here’s how I configured and applied an ACL to fulfill these requirements. First, I configured ACL 1 with an entry permitting 192.168.1.1/32. That will achieve the first requirement, allowing PC1 to access 192.168.2.0/24. Then I configured an entry denying the 192.168.1.0/24 network. This will fulfill the second requirement. The order of these is very important. If I denied 192.168.1.0/24 first, PC1 would not be able to access 192.168.2.0/24, even if I put an entry permitting PC1 after the deny entry. Remember, ACLs are processed in order from top to bottom. Once a match is found, the action is taken and any remaining entries after the matching entry are not processed, they are ignored. Finally, I configured a permit any entry at the end. Remember the implicit deny that is hidden at the end of every ACL. If I don’t include this permit any at the end, the ACL won’t only block PCs in the 192.168.1.0/24 network, it will block all other traffic. The only device that will be able to access the 192.168.2.0/24 network would be 192.168.1.1, PC1. Every single other device would be blocked. Our requirements don’t tell us to block all other traffic, so we should insert this permit any. Finally I applied the ACL to R1’s G0/2 interface with IP ACCESS-GROUP 1 OUT. Why outbound on G0/2? I could have, for example, applied it inbound on G0/1. Well, here’s a good rule-of-thumb for applying standard ACLs to interfaces. Standard ACLs should be applied as close to the destination as possible. You may be thinking, what do I mean by ‘destination’, even though standard ACLs only filter by source IP? Well, in this case we are trying to control access to the 192.168.2.0/24 network, so that is the ‘destination’. If I applied ACL 1 inbound on R1’s G0/1 interface, it would prevent all PCs in the subnet except R1 from accessing anything outside of the local network. However, if I apply it correctly, outbound on G0/2, the ACL only controls traffic that tries to access the 192.168.2.0/24 network. So, remember this rule-of-thumb. Standards ACLs should be applied as close to the destination as possible. If you don’t do that, you might block more traffic than you intended. Now let’s see how that ACL will work. PC1 tries to ping PC3. The ping is received by R1. It doesn’t check the ACL yet, because we didn’t apply it to the G0/1 interface. R1 looks up the destination in its routing table, and sees it’s connected to the G0/2 interface. However, ACL 1 is applied outbound on G0/2, so before forwarding the ping it checks ACL 1. It starts at the top, with entry 10, permit source IP 192.168.1.1. The ping’s source is PC1, 192.168.1.1, so that’s a match. It will take the action, which is to permit the packet, so it forwards it to PC3. PC3 will be able to reply, because there is no ACL blocking the return path from PC3 to PC1. What if PC2 tries to ping PC3? R1 receives the ping on G0/1, but it doesn’t check the ACL because it’s not applied to that interface. Once again it checks the routing table and sees that it should forward the packet out of G0/2, but because ACL 1 is applied outbound on G0/2 it checks ACL 1 first. It checks the top entry first, permit 192.168.1.1/32. The source of the ping is 192.168.1.2, so it doesn’t match. Then it checks the next entry, deny 192.168.1.0/24. PC2’s IP is in this subnet, so it matches this entry and R1 takes the action, which is to deny. It won’t forward the ping to PC3. Okay, now let’s move on to standard named ACLs. Standard named ACLs are still standard ACLs, so they match traffic based only on the source IP address of the packet. However, instead of a number they are identified with a name. You could, for example, name the ACL ‘BLOCK_BOB’. Standard named ACLs are configured by entering ‘standard named ACL config mode’, and then configuring each entry within that mode. So, a little different than standard numbered ACLs. Here’s how you enter that config mode, IP ACCESS-LIST STANDARD, followed by the name. Remember to use IP in front of the command. For standard numbered ACLs the command is ACCESS-LIST, but in this case it’s IP ACCESS-LIST. Then you enter standard named ACL config mode and configure the deny and permit entries. Note that you can now specify an entry number before each entry, although you don’t have to. If you don’t entries will be numbered 10, then 20, then 30, etc, just like in the standard numbered ACLs we configured. Each entry’s number will be 10 more than the previous one. But with this function, you can manually specify the entry number to control the order of the entries. So, here’s an example. First I create the ACL BLOCK_BOB and enter standard named ACL config mode. Then I configured a statement denying 1.1.1.1/32. Note that I manually configured the entry number of 5, instead of the default of 10. Then I configured a permit any entry, with an entry number of 10. I then configured a remark. This isn’t necessary, of course, but remarks can be helpful when looking at the configuration later. Then I moved to interface configuration mode, and applied the ACL in the same way as before, IP ACCESS-GROUP, ACL name, and then IN or OUT. Let’s check with some show commands. Once again, I used SHOW ACCESS-LISTS. The ACL is shown, and you can see each entry with the entry numbers I manually configured. Then I checked the running config. Notice I used a different method of filtering the output, SECTION ACCESS-LIST. This displays just the ACL section of the running config. If I used ‘INCLUDE ACCESS-LIST’ like before, it would display the ACL’s name. However, it wouldn’t actually display any of the entries, since those lines of the config don’t include ACCESS-LIST, even though they are part of an access list. When I filter using SECTION, I can view the whole ACL. You can see each entry including the remark, although interestingly the entry numbers are not displayed in the config. Okay, let’s try configuring some standard named ACLs on R2. So, here are the requirements. PCs in 192.168.1.0/24 can’t access 10.0.2.0/24. PC3 can’t access 10.0.1.0/24, but other PCs in 192.168.2.0/24 can. PC1 can access 10.0.1.0/24, but other PCs in 192.168.1.0/24 can’t. We’ll need two ACLs to do this properly. If you think you can, try to solve this yourself. But I’ll show you my solution. So, we’ll configure one ACL to control access to 10.0.2.0/24 and apply it outbound on R2’s G0/2. Then we’ll configure another ACL to control access to 10.0.1.0/24 and apply it outbound on R2’s G0/1. Here’s how I did that. Here’s the first ACL, I called it TO_10.0.2.0/24. First I denied the 192.168.1.0/24 network, but permitted other traffic. Then I applied it outbound on G0/2. So, PC1 and PC2 will be blocked from accessing SRV2, but PC3 and PC4 will be able to. Okay, that’s the first ACL. I called the second ACL TO_10.0.1.0/24. First I denied PC3, 192.168.2.1. Then I permitted the rest of the PCs in PC3’s network. I then permitted PC1, but denied the other PCs in PC1’s network. Then I permitted all other traffic. Finally I applied the ACL outbound on the G0/1 interface. And that’s it. ACL configuration can be flexible sometimes, so there are other ways to configure these ACLs that will work, too. But this is my solution. Let’s check those ACLs with SHOW IP ACCESS-LISTS. Do you notice something strange about the TO_10.0.1.0/24 ACL? Look at the sequence numbers. 30, then 10, then 20, then 40, then 50. And look at the order I configured them. The sequence numbers match the order I configured the entries, but their actual order in the ACL is totally different. Why is that? This is a very advanced question about the internal operations of Cisco IOS and how ACLs are processed, you definitely won’t find this on the CCNA exam but let me briefly summarize it. The router may re-order the /32 entries, the entries that match only a single specific host. This improves the efficiency of processing the ACL. However, it does not change the overall effect of the ACL. So, it makes sense for the router to change the order if it helps the router process it more efficiently without affecting the outcome. Note that this is done for both standard named and standard numbered ACLs, it just didn’t apply to the simpler examples I showed for standard numbered ACLs. Also note that I checked in Packet Tracer, and Packet Tracer does not do this. It will simply display the entries in order of sequence number, as you would expect. Before finishing up, I’ll just walk through one more example of an ACL being processed. PC2 wants to access server 1, so it pings to test connectivity. The ping reaches R2, which is directly connected to SRV1’s network. However, the TO_10.0.1.0/24 ACL is applied outbound to G0/1 so R2 will check the packet against that ACL before forwarding it. The source is 192.168.1.2, so it doesn’t match the top entry. It doesn’t match the next one either, or the next one. However, it matches entry 40, because the source is in the 192.168.1.0/24 network. So, it denies the packet, it does not forward it to SRV1. Okay, let’s review and then move on to the quiz. In this video I covered what ACLs are. They are used to identify and control traffic in the network. I introduced ACL logic, how ACLs are processed. The entries in an ACL are processed from top to bottom, and once a matching entry is found the action is taken and the remaining entries are not processed. I introduced the ACL types you need to know for the CCNA. They are standard ACLs and extended ACLs, and each of those can be configured as numbered or named ACLs. In this video I covered standard ACLs, which are simple and just match traffic based on the source IP address of the packet. I showed two main ways of configuring standard ACLs, standard numbered ACLs and standard named ACLs. They are both just different ways of configuring standard ACLs. Standard numbered ACLs are configured like this, a series of entries configured in global config mode with the ACCESS-LIST command. For standard named ACLs, you use the IP ACCESS-LIST command to enter standard named ACL config mode, and then configure the entries. Make sure to watch until the end of today’s quiz for a bonus question from Boson ExSim, the best practice exams for the CCNA, CCNP, and more. Okay, let’s go to question 1 of the quiz. Which ACL, when applied outbound on R2’s G0/1, permits only PC1 and PC4 to access 10.0.1.0/24? Here are four ACLs, which one fulfills that requirement? Pause the video to think about your answer. The answer is ACL 1. Entry 10 permits PC1 and entry 20 permits PC4. The implicit deny will deny all other traffic. So, ACL 1 fulfills the requirements, and the other ACLs do not. Let’s go to question 2. Which interface should the following ACL be applied to, and in which direction, to fulfill the requirement? Here’s the ACL, and here’s the requirement. Pause the video to think about your answer. Here’s the answer. The interface should be R2’s G0/2 interface, and the direction should be outbound. Remember that rule-of-thumb, standard ACLs should be applied as close to the destination as possible. We are controlling access to 10.0.2.0/24, so that is the destination. Therefore the ACL should be applied outbound on R2’s G0/2. Let’s go to question 3. You issue the following commands on R2. Which statement about the effect of the configurations is correct? Here are the configurations on R2. And here are the options. A, all traffic will be denied. B, traffic from the 10.0.0.0/24 network will be denied. C, traffic from the 172.16.0.0/24 network will be denied. Or D, traffic from the 192.168.0.0/24 network will be denied. Pause the video to think about your answer. The answer is B, traffic from the 10.0.0.0/24 network will be denied. Each interface can only have one ACL applied in each direction. If you apply another ACL to the same interface in the same direction, it will replace the previous one. In this case, the last ACL you applied was ACL 10, which denies traffic from 10.0.0.0/24, so B is the correct answer. Let’s go to question 4. If this ACL is applied inbound on R1 G0/0, which PCs will be able to ping SRV2? A, PC1 and PC2. B, PC1, PC2, and PC4. C, PC1 only. D, all PCs. Or E, PC3 and PC4 only. Pause the video to think about your answer. The answer is D, all PCs. This is because of where the ACL was applied, inbound on R1’s G0/0 interface. When the PCs try to ping SRV2, R1 won’t check the ACL as it sends the pings out of G0/0. When the reply from SRV2 arrives on R1’s G0/0 interface, it will check the ACL. However, the source of the reply will be SRV2’s IP of 10.0.2.100, which will be permitted by the ‘permit any’ at the end of the ACL. So, all PCs will be able to successfully ping SRV2. Okay, let’s go to question 5. What happens if a packet doesn’t match any entries of an ACL? A, the packet will be forwarded to the default gateway. B, the packet will be checked using the next available ACL. C, the packet will be dropped. Or D, the action of the most specific match will be taken. Pause the video to think about your answer. The answer is C, the packet will be dropped. Every ACL includes an ‘implicit deny’ at the end which will deny all packets that don’t match any of the ACL’s entries. So, C is the correct answer. Okay, that’s all for the quiz. Now let’s take a look at a bonus question from Boson ExSim for CCNA. Okay, here's today's Boson ExSim practice question. Which of the following statements is true regarding ACLs? Select the best answer. A, ACLs are processed from the least specific entry to the most specific entry. B, ACLs are processed from the first entry in the list to the last entry. C, ACLs are processed from the last entry in the list to the first entry. Or D, ACLs are processed from the most specific entry in the list to the least specific entry. Okay, if you just watched the video you should be able to answer this question. So, pause the video now to think about the answer. Okay, so let's check. As I mentioned in the video, ACLs are processed from top to bottom, and what that means is from first to last. So, B should be the correct answer. I'll select B and then click on show answer. And indeed it is correct. So, here's Boson's explanation, quite detailed. You can pause the video now if you want to read Boson's explanations, and I recommend you do. These explanations are one of the great things about Boson ExSim. Okay, and there's also a reference to both the chapter in the official cert guide by Cisco Press and a link to some Cisco documentation which is available free online. Configuring IP Access Lists: Process ACLs. So, this is another great resource. Okay, so that's Boson ExSim for the CCNA. These are the practice exams I used to study for my CCNA and CCNP, and I really highly recommend them. So if you want to get a copy of Boson ExSim, please follow the link in the video description. There are supplementary materials for this video. There is a flashcard deck to use with the software ‘Anki’. There will also be a packet tracer practice lab so you can get some hands-on practice. That will be in the next video. Sign up for my mailing list via the link in the description, and I’ll send you all of the flashcards and packet tracer lab files for the course. Before finishing today’s video I want to thank my JCNP-level channel members. To join, please click the ‘Join’ button under the video. Thank you to Junhong, OJ, Magrathea, TheGunguy, l33america, Njabulo, Benjamin, Tshepiso, Justin, Prakaash, Nasir, Erlison, Apogee, Marko, Flodo, Daming, Joshua, Jhilmar, Ed, Value, John, Funnydart, Scott, Hassan, Marek, Velvijaykum, C Mohd, Mark, Yousif, Sidi, Boson Software, Devin, Lito, Yonatan, and Vance. Sorry if I pronounced your name incorrectly, but thank you so much for your support. One of you is still displaying as Channel failed to load, if this is you please let me know and I’ll see if YouTube can fix it. This is the list of JCNP-level members at the time of recording by the way, November 21st 2020. If you signed up recently and your name isn’t on here don’t worry, you’ll be in future videos. Thank you for watching. Please subscribe to the channel, like the video, leave a comment, and share the video with anyone else studying for the CCNA. If you want to leave a tip, check the links in the description. I'm also a Brave verified publisher and accept BAT, or Basic Attention Token, tips via the Brave browser. That's all for now.