Chapter 21. IPv4 Access Control Lists on Cisco Nexus Switches
This chapter covers the following exam topics:
4.1. Describe and configure basic routing concepts
4.1a. Packet forwarding
Most every other topic in the scope of CCNA-DC focuses on achieving a core goal of any TCP/IP network: delivering IPv4 packets from the source host to the destination host. This chapter focuses instead on preventing a subset of those packets from being allowed to reach their destinations, by using IPv4 access control lists (ACLs).
IPv4 ACLs have many uses, but the CCNA-DC exam focuses on their most commonly known use: as packet filters. You want hosts in one subnet to be able to communicate throughout your corporate network, but perhaps there is a pocket of servers with sensitive data that must be protected. Maybe government privacy rules require you to further secure and protect access, not just with usernames and login, but through protecting the ability to deliver a packet to the protected host or server. IP ACLs provide a useful solution to achieve those goals.
This chapter discusses the basics of IPv4 ACLs on Nexus switches. This chapter starts by covering the basics and types of ACLs supported by Cisco Nexus switches. The second part of the chapter completes the discussion by describing IPv4 ACLs basics and configurations.
Note
IPv6 ACLs exist as well, but they are not included in this book. It is important to check release notes/configuration guides to ensure ACL feature support because it can vary across some of the Nexus products based on ASIC usage.
“Do I Know This Already?” Quiz
Use the “Do I Know This Already?” quiz to help decide whether you might want to skim this chapter, or a major section, moving more quickly to the “Exam Preparation Tasks” section near the end of the chapter. Table 21-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. For thorough explanations, see Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”
1. Barney is a host with IP address 10.1.1.1 in subnet 10.1.1.0/24. Which of the following are things that a standard IP ACL could be configured to do? (Choose two answers.)
a. Match the exact source IP address.
b. Match IP addresses 10.1.1.1 through 10.1.1.4 with one access-list command without matching other IP addresses.
c. Match all IP addresses in Barney’s subnet with one access-list command without matching other IP addresses.
d. Match only the packet’s destination IP address.
2. Which of the following wildcard masks is most useful for matching all IP packets in subnet 10.1.128.0, mask 255.255.255.0?
a. 0.0.0.0
b. 0.0.0.31
c. 0.0.0.240
d. 0.0.0.255
e. 0.0.15.0
f. 0.0.248.255
3. Which of the following masks is most useful for matching all IP packets in subnet 10.1.128.0, mask 255.255.240.0?
a. 0.0.0.0
b. 0.0.0.31
c. 0.0.0.240
d. 0.0.0.255
e. 0.0.15.255
f. 0.0.248.255
4. ACL 1 has three statements, in the following order, with address and mask values as follows: 1.0.0.0/8, 1.1.0.0/16, and 1.1.1.0/24. If a router tried to match a packet sourced from IP address 1.1.1.1 using this ACL, which ACL statement does a router consider the packet to have matched?
a. First
b. Second
c. Third
d. Implied deny at the end of the ACL
5. On a Cisco Nexus switch, what command will allow only host 10.1.1.1 to talk with host 192.168.1.3 for web traffic that is unencrypted for ACL web subcommands?
a. permit tcp host 10.1.1.1 host 192.168.1.3 eq 80
b. permit ip 10.1.1.0/24 host 192.168.1.3
c. permit tcp 10.1.1.0/24 192.168.1.0/24 eq 80
d. permit ip any any
6. Which AAA method allows a user after login to access to a certain configuration level on a Cisco network device?
a. Authentication
b. Access-List
c. Authorization
d. Accounting
Foundation Topics
IPv4 Access Control List Basics
IPv4 access control lists (IP ACLs) give network engineers a way to identify different types of packets. To do so, the ACL configuration lists values that the routed interfaces can see in the IP, TCP, UDP, and other headers. For example, an ACL can match packets whose source IP address is 1.1.1.1, or packets whose destination IP address is some address in subnet 10.1.1.0/24, or packets with a destination port of TCP port 23 (Telnet).
IPv4 ACLs perform many functions in Cisco routers, with the most common use as a packet filter. Engineers can enable ACLs on a router so that the ACL sits in the forwarding path of packets as they pass through the router. After it is enabled, the router considers whether each IP packet will either be discarded or allowed to continue as if the ACL did not exist.
However, ACLs can be used for many other IOS features as well. For example, ACLs can be used to match packets for applying quality of service (QoS) features. QoS allows a router to give some packets better service and other packets worse service. For example, packets that hold digitized voice need to have very low delay, so ACLs can match voice packets with QoS logic, in turn forwarding voice packets more quickly than forwarding data packets.
This first section introduces IP ACLs as used for packet filtering, focusing on these aspects of ACLs: the locations and direction in which to enable ACLs, matching packets by examining headers, and taking action after a packet has been matched.
ACL Location and Direction
Cisco Nexus can apply ACL logic to packets at the point at which the IP packets enter an interface or the point at which they exit an interface. In other words, the ACL becomes associated with an interface and for a direction of packet flow (either in or out). That is, the ACL can be applied inbound to the router, before the router makes its forwarding (routing) decision, or outbound, after the router makes its forwarding decision and has determined the exit interface to use.
The arrows in Figure 21-1 show the locations at which you could filter packets, flowing left to right in the topology. Suppose, for instance, that you want to allow packets sent by host A to server S1, but to discard packets sent by host B to server S1. Each arrowed line represents a location and direction at which a router could apply an ACL, filtering the packets sent by host B.
The four arrowed lines in the figure point out the location and direction for the routed interfaces used to forward the packet from host B to server S1. In this particular example, those interfaces and directions are as follows:
Inbound on R1’s Eth1/1 interface
Outbound on R1’s Eth1/2 interface
Inbound on R2’s Eth1/2 interface
Outbound on R2’s Eth1/1 interface
If, for example, you were to enable an ACL on R2’s Eth1/1 interface, in either direction, that ACL could not possibly filter the packet sent from host B to server S1, because R2’s Eth1/1 interface is not part of the route from B to S1.
In short, to filter a packet, you must enable an ACL on an interface that processes the packet, in the same direction the packet flows through that interface.
When enabled, the router then processes every inbound or outbound IP packet using that ACL. For example, if an ACL is enabled on R1 for packets inbound on interface Eth1/1, R1 would compare every inbound IP packet on Eth1/1 to the ACL to decide that packet’s fate: to continue unchanged or to be discarded.
Matching Packets
When you think about the location and direction for an ACL, you must already be thinking about what packets you plan to filter (discard) and which ones you want to allow through. To tell the router those same ideas, you must configure the router with an IP ACL that matches packets. Matching packets refers to how to configure the ACL commands to look at each packet, listing how to identify which packets should be discarded and which should be allowed through.
Each IP ACL consists of one or more configuration commands, with each command listing details about values to look for inside a packet’s headers. Generally, an ACL command uses logic like “look for these values in the packet header, and if found, discard the packet.” (The action could instead be to allow the packet, rather than discard.) Specifically, the ACL looks for header fields you should already know well, including the source and destination IP addresses, plus TCP and UDP port numbers.
For instance, consider the example shown in Figure 21-2, where you want to allow packets from host A to server S1, but to discard packets from host B going to that same server. The hosts all now have IP addresses, and the figure shows pseudocode for an ACL on R2. Figure 21-2 also shows the chosen location to enable the ACL: inbound on R2’s Eth1/2 interface.
Figure 21-2 shows a two-line ACL in a rectangle at the bottom, with simple matching logic: Both statements just look to match the source IP address in the packet. When the ACL is enabled, R2 looks at every inbound IP packet on that interface and compares each packet to those two ACL commands. Packets sent by host A (source IP address 10.1.1.1) are allowed through, and those sent by host B (source IP address 10.1.1.2) are discarded.
Taking Action when a Match Occurs
When IP ACLs are used to filter packets, only one of two actions can be chosen. The configuration commands use keywords deny and permit, and they mean (respectively) to discard the packet or to allow it to keep going as if the ACL did not exist.
This book focuses on using ACLs to filter packets, but NX-OS uses ACLs for many more features. Those features typically use the same matching logic. However, in other cases, the deny and permit keywords imply some other action.
Types of IP ACLs
Cisco IOS has supported IP ACLs since the early days of Cisco routers. Beginning with the original standard numbered IP ACLs in the early days of IOS, which could enable the logic shown earlier around Figure 21-2, Cisco has added many ACL features, including the following:
Standard numbered ACLs (1–99)
Extended numbered ACLs (100–199)
Additional ACL numbers (1300–1999 standard, 2000–2699 extended)
Named ACLs
Improved editing with sequence numbers
This chapter focuses solely on the Cisco Nexus implementation of IPv4 ACLs, which are extended named ACLs. Briefly, IP ACLs will be either numbered or named, in that the configuration identifies the ACL either using a number or a name. ACLs will also be either standard or extended, with extended ACLs having much more robust abilities in matching packets. Figure 21-3 summarizes the big ideas related to categories of IP ACLs when they were used in IOS.
List Logic with IP ACLs
A single ACL is a single entity and, at the same time, a list of one or more configuration commands. In the case of an ACL as a single entity, the configuration enables the entire ACL on an interface, in a specific direction, as shown earlier around Figure 21-1. In the case of an ACL as a list of commands, each command has different matching logic that the router must apply to each packet when filtering using that ACL.
When doing ACL processing, the router processes the packet, compared to the ACL, as follows:
The ACL uses first-match logic. Once a packet matches one line in the ACL, the router takes the action listed in that line of the ACL and stops looking further in the ACL.
To see exactly what this means, consider the example built around Figure 21-4. The figure shows ACL 1 with three lines of pseudocode. This example applies ACL 1 on R2’s Eth1/2 interface, inbound (the same location as in Figure 21-2, earlier).
Consider the first-match ACL logic for a packet sent by host A to server S1. The source IP address will be 10.1.1.1, and it will be routed so that it enters R2’s Eth 1/2 interface, driving R2’s ACL 1 logic. R2 compares this packet to the ACL, matching the first item in the list with a permit action. Therefore, this packet should be allowed through, as shown in Figure 21-5, on the left.
Figure 21-5 ACL Items Compared for Packets from Hosts A, B, and C in Figure 21-4
Next, consider a packet sent by host B, source IP address 10.1.1.2. When the packet enters R2’s Eth1/2 interface, R2 compares the packet to ACL 1’s first statement and does not make a match (10.1.1.1 is not equal to 10.1.1.2). R2 then moves to the second statement, which requires some clarification. The ACL pseudocode, back in Figure 21-4, shows 10.1.1.x, which is meant to be shorthand for “any value can exist in the last octet.” Comparing only the first three octets, R2 decides that this latest packet does have a source IP address that begins with first three octets 10.1.1, so R2 considers that to be a match on the second statement. R2 takes the listed action (deny), discarding the packet. R2 also stops ACL processing on the packet, ignoring the third line in the ACL.
Finally, consider a packet sent by host C, again to server S1. The packet has source IP address 10.3.3.3, so when it enters R2’s Eth1/2 interface, and drives ACL processing on R2, R2 looks at the first command in ACL 1. R2 does not match the first ACL command (10.1.1.1 in the command is not equal to the packet’s 10.3.3.3). R2 looks at the second command, compares the first three octets (10.1.1) to the packet source IP address (10.3.3), and still no match. R2 then looks at the third command. In this case, the wildcard means ignore the last three octets, and just compare the first octet (10), so the packet matches. R2 then takes the listed action (permit), allowing the packet to keep going.
This sequence of processing an ACL as a list happens for any type of NX-OS ACL: IP and other protocols.
Finally, if a packet does not match any of the items in the ACL, the packet is discarded. The reason is because every IP ACL has a deny all statement implied at the end of the ACL. It does not exist in the configuration, but if a router keeps searching the list, and no match is made by the end of the list, IOS considers the packet to have matched an entry that has a deny action.
Switch(config)# ip access-list name
Switch(config-ip-acl)# [sequence-number] {permit | deny} protocol source destination
Each NX-OS IPv4 ACL has one or more access list entry commands, with an associated sequence number for each entry so they can be reordered if needed (whole number between 1 and 4,294,967,295).
Besides the ACL sequence number, each ip access-list subcommand also lists the action (permit or deny), plus the matching logic. The rest of this section examines how to configure the matching parameters for NX-OS IPv4 ACLs.
To match a specific source IP address, all you have to do is type that IP address with a /32 mask at the end of the command. For example, the previous example uses pseudocode for “permit if source = 10.1.1.1.” The following command configures that logic with correct syntax using an ACL named sample-acl:
Switch(config)# ip access-list sample-acl
Switch(config-ip-acl)# permit ip 10.1.1.1/32 any
Matching the exact full IP address is that simple. Another option is to use the host keyword instead of using the /32, as seen in the following sample ACL sample-acl-host:
Switch(config)# ip access-list sample-acl-host
Switch(config-ip-acl)# permit ip host 10.1.1.1 any
Note
An important thing to understand from this example is that all ACLs in NX-OS have what is referred to as an explicit deny. If you applied this ACL to an interface only, host 10.1.1.1 would be able to communicate because at the end of each ACL is an implicit deny statement of ip any any, which denies anything that has not been permitted using the ACL entries.
Matching TCP and UDP Port Numbers
Cisco Nexus ACLs can also examine parts of the TCP and UDP headers, particularly the source and destination port number fields. The port numbers identify the application that sends or receives the data.
The most useful ports to check are the well-known ports used by servers. For example, web servers use well-known port 80 by default. Figure 21-6 shows the location of the port numbers in the TCP header, following the IP header.
When a Cisco Nexus ACL command includes either the tcp or udp keyword, that command can optionally reference the source/destination port. To make these comparisons, the syntax uses keywords for equal, not equal, less than, greater than, and for a range of port numbers. In addition, the command can use either the literal decimal port numbers or more convenient keywords for some well-known application ports. Figure 21-7 shows the positions of the source and destination port fields in the access-list command and these port number keywords.
For example, consider the simple network shown in Figure 21-8. The FTP server sits on the right, with the client on the left. The figure shows the syntax of an ACL that matches the following:
Packets that include a TCP header
Packets sent from the client subnet
Packets sent to the server subnet
Packets with TCP destination port 21 (FTP server control port)
To fully appreciate the matching of the destination port with the eq 21 parameters, consider packets moving from left to right, from PC1 to the server. Assuming the server uses well-known port 21 (FTP control port), the packet’s TCP header has a destination port value of 21. The ACL syntax includes the eq 21 parameters after the destination IP address. The position after the destination address parameters is important: That position identifies the fact that the eq 21 parameters should be compared to the packet’s destination port. As a result, the ACL statement shown in Figure 21-8 would match this packet, and the destination port of 21, if used in any of the four locations implied by the four dashed arrowed lines in the figure.
Conversely, Figure 21-9 shows the reverse flow, with a packet sent by the server back toward PC1. In this case, the packet’s TCP header has a source port of 21, so the ACL must check the source port value of 21, and the ACL must be located on different interfaces. In this case, the eq 21 parameters follow the source address field but come before the destination address field.
For exam questions that require ACLs and matching of port numbers, first consider the location and direction in which the ACL will be applied. That direction determines whether the packet is being sent to the server or from the server. At that point, you can decide whether you need to check the source or destination port in the packet, assuming that you want to check the well-known port used by that service.
For reference, Table 21-2 lists many of the popular port numbers and their transport layer protocols and applications. Note that the syntax of the access-list commands accepts both the port numbers and a shorthand version of the application name.
Table 21-3 lists several sample access-list commands that match based on port numbers. Cover the right side of the table and try to characterize the packets matched by each command. Then, check the right side of the table to see if you agree with the assessment.
Implementing Cisco Nexus IPv4 ACLs
This chapter has already introduced all the configuration steps in bits and pieces. This section summarizes those pieces as a configuration process. The process also refers to the access-list command, whose generic syntax is repeated here for reference:
ip access-list name
Step 1. Configure one or more access-list subconfiguration commands to create the ACL, keeping the following in mind:
A. The list is searched sequentially, using first-match logic.
B. The default action, if a packet does not match any of the access-list commands, is to deny (discard) the packet.
Step 2. Enable the ACL on the chosen interface (port/routed/VACL), in the correct direction, using the ip access-group/ number {in | out} interface subcommand.
Note
IPv4 ACLs can be applied in three different manners: port for Layer 2 interfaces in the direction of in, as a standard Layer 3 ACL for both in and out, and as a VLAN access control list (VACL) by being a match in the VLAN access class list. The following example focuses on routed interface applications.
The rest of this section shows a couple of examples.
ACL Example 1
The first example shows the configuration for the same requirements, demonstrated with Figure 21-4 and Figure 21-5. Restated, the requirements for this ACL are as follows:
1. Enable the ACL inbound on R2’s Eth1/2 interface.
2. Permit packets coming from host A.
3. Deny packets coming from other hosts in host A’s subnet.
4. Permit packets coming from any other address in Class A network 10.0.0.0.
5. The original example made no comment about what to do by default; so, simply deny all other traffic.
Example 21-1 shows a completed correct configuration, starting with the configuration process, followed by output from the show running-config command.
Example 21-1 Standard ACL Example 1 Configuration
R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# ip access-list standard-acl
R2(config-ip-acl)#permit ip 10.1.1.1/32 any
R2(config-ip-acl)#deny ip 10.1.1.0/24 any
R2(config-ip-acl)#permit ip 10.0.0.0/8 any
R2(config)# interface Ethernet 1/2
R2(config-if)# ip access-group standard-acl in
R2(config-if)# ^Z
R2# show ip access-lists
! Lines omitted for brevity
IP access list standard-acl
10 permit ip 10.1.1.1 255.255.255.255 any
20 deny ip 10.1.1.0 255.255.255.0 any
30 permit ip 10.0.0.0 255.0.0.0 any
First, pay close attention to the configuration process at the top of the example. Note that the ip access-list command does change the command prompt from the global configuration mode prompt, because the ip access-list command enters a sub IP ACL configuration mode. Then, compare that to the output of the show running-config command: The details are identical compared to the commands that were added in configuration and subconfiguration mode. Finally, make sure to note the ip access-group standard-acl in command, under R2’s Eth1/2 interface, which enables the ACL logic (both location and direction).
ACL Example 2
The second example, Example 21-2, shows the configuration for a slightly more advanced ACL configuration. This example configures an ACL named advanced-acl on R2 that only allows FTP from host 10.1.1.1 to anyone and HTTP from the 10.1.1.0/24 to anyone.
Example 21-2 Advanced ACL Example 2 Configuration
R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# ip access-list advanced-acl
R2(config-ip-acl)# permit tcp 10.1.1.1/32 any eq ftp
R2(config-ip-acl)# permit tcp 10.1.1.1/32 any eq ftp-data
R2(config-ip-acl)# permit tcp 10.1.1.0/24 any eq http
R2(config-ip-acl)# permit tcp 10.1.1.0/24 any eq https
R2(config)# interface Ethernet 1/2
R2(config-if)# ip access-group advanced-acl in
R2(config-if)# ^Z
This example shows a more advanced ACL configuration, using an ACL to only allow certain TCP ports out from a single host or subnet. In this case, you are limiting it to FTP traffic from host 10.1.1.1 and allowing the 10.1.1.1.0/24 network the ability to use the Web. The example uses a source, destination, port, and protocol to determine what can communicate in the advanced ACL. This example demonstrates the power you have to lock down communication using this type of ACL within your own network.
Practice Cisco Nexus IPv4 ACLs
Some CCNA-DC topics, such as subnetting, simply require more drills and practice than others. You can also benefit from doing practice drills with ACLs in part because ACLs require you to think of parameters to match ranges of numbers, and that, of course, requires some use of math and some use of processes.
This section provides some practice problems and tips, from two perspectives. First, this section asks you to build one-line ACLs to match some packets. Second, this section asks you to interpret existing ACL commands to describe what packets the ACL will match. Both skills are useful for the exams.
Practice Building access-list Commands
This section provides some practice in getting comfortable with the syntax of the ip access-list command, particularly with choosing the correct matching logic. These skills will prove helpful when reading about ACLs.
First, the following list summarizes some important tips to consider when choosing matching parameters to any access-list command:
To match a specific address, just list the address.
To match any and all addresses, use the any keyword.
To match based only on the first one, two, or three octets of an address, use the subnet masks, respectively. Also, make sure that the source (address) parameter has the correct subnet masks.
To match a subnet, use the subnet ID as the source, and find the subnet mask prefix by using the “/” prefix length.
Table 21-4 lists the criteria for several practice problems. Your job: Create a one-line standard ACL that matches the packets..
Authentication, Authorization & Accounting (AAA) Basics
When trying to secure the management of your Cisco nexus product line, a key component to understand is Authentication, Authorization & Accounting (referred to as AAA). So let’s break down each one of the components of AAA and describe its use in securing the management of your Cisco Nexus devices.
What is AAA?
When it comes to network management security, AAA is a requirement. Here is what each of these are used for and why you should care:
Authentication: Identifies users by login and password using challenge and response methodology before the user even gains access to the network. This can be usernames and passwords stored locally on the networking device or authenticated using an Access Control Server such as Cisco ACS. The primary methods outside of locally stored username and passwords to authenticate a user are RADIUS or TACACS+. Here is a link to Cisco’s website describing the differences:
Authorization: After initial authentication, authorization looks at what that authenticated user has access to do. RADIUS or TACACS+ security servers perform authorization for specific privileges by defining attribute-value (AV) pairs, which would be specific to the individual user rights. In the Cisco NX-OS, you can define AAA authorization with a named list or authorization method.
Accounting: Accounting provides a way of collecting security information that you can use for billing, auditing, and reporting. You can use accounting to see what users do once they are authenticated and authorized. For example, with accounting, you could get a log of when users logged in and when they logged out.
Exam Preparation Tasks
Review All the Key Topics
Review the most important topics from this chapter, noted with the Key Topic icon. Table 21-5 lists these key topics and where each is discussed.
Table 21-5 Key Topics for Chapter 21
Definitions of Key Terms
After your first reading of the chapter, try to define these key terms, but do not be concerned about getting them all correct at that time. Chapter 24, “Final Review,” directs you in how to use these terms for late-stage preparation for the exam.
standard access list
wildcard mask
Appendix H Practice Problems
Appendix H, “Practice for Chapter 21: IPv4 Access Control Lists on Cisco Nexus Switches,” lists additional practice problems and answers.
Command Reference to Check Your Memory
Although you should not necessarily memorize the information in Tables 12-6 and 12-7, this section includes a reference for the configuration and EXEC commands covered in this chapter. Practically speaking, you should memorize the commands as a side effect of reading this chapter and doing all the activities in this “Exam Preparation Tasks” section. To see how well you have memorized the commands as a side effect of your other studies, cover the left side of the table, read the description on the right side, and see whether you remember the command.
Table 21-6 Chapter 21 Configuration Command Reference
Table 21-7 Chapter 21 EXEC Command Reference