ACL practice questions

Standard IPv4 ACLs use numbers in the range 100-199.

Why it fails: Standard IPv4 ACLs are numbered in the ranges 1–99 and 1300–1999, not 100–199. The number range 100–199 is explicitly reserved for extended numbered ACLs, which evaluate source and destination IP addresses, protocol, and port numbers. Misidentifying 100–199 as standard ACL numbers confuses the ACL type and its underlying matching logic.

Standard IPv4 ACLs filter only the source IP address and are best placed close to the source to be most effective.

Why it fails: Standard ACLs indeed filter only on the source IP address, but that limited matching capability requires them to be placed as close to the destination as possible, not the source. If placed near the source, a standard ACL entry that denies a particular source would block that source's traffic to all destinations, including legitimate ones. Positioning near the destination limits the ACL's impact to the intended target network, avoiding accidental collateral denial.

Numbered ACLs allow individual access control entries (ACEs) to be deleted without removing the entire ACL.

Why it fails: Numbered ACLs do not permit deletion of an individual access control entry; to remove one ACE, the entire ACL must be deleted and re-entered without that entry. Named ACLs, in contrast, assign sequence numbers to each ACE, allowing selective deletion, insertion, and resequencing without recreating the full list. This operational limitation of numbered ACLs applies to both standard and extended numbered variants and is a common source of configuration errors.

Standard ACLs should be placed as close to the source as possible.

Why it fails: Placing a standard ACL close to the source is incorrect because it will evaluate every packet from that source regardless of its final destination, potentially dropping traffic that should be allowed to other networks. Since standard ACLs cannot match the destination address, a permit or deny statement applies globally to all destinations for the specified source. Cisco recommends applying standard ACLs near the destination, while extended ACLs — which can match destination — should indeed be placed close to the source to reduce unnecessary transit traffic.

Standard ACLs can filter traffic based on destination IP address.

Why it fails: Standard ACLs do not look at the destination IP address at all — each ACE contains only a permit/deny decision based on the source address, with an optional wildcard mask. Because the router never inspects the destination field of the packet, a standard ACL cannot differentiate between traffic going to one host and traffic going to another. This is why extended ACLs are required when you need to match both source and destination addresses.

Standard ACLs can filter traffic based on TCP or UDP port numbers.

Why it fails: Standard ACLs cannot filter by TCP or UDP port numbers because they operate only at Layer 3 and match solely on the source IP address and wildcard mask. Port fields are Layer 4 information, which the standard ACL code never examines; only an extended ACL (numbered 100–199 or named) can specify protocol and port numbers in its entries. Thus, any attempt to use a standard ACL to block a specific web service or application port will fail.

Because allowing a VLAN on a trunk automatically disables it

Why it fails: The command 'switchport trunk allowed vlan add 99' merely adds VLAN 99 to the list of VLANs whose tagged frames may traverse the trunk. This does not disable the VLAN; in fact, it explicitly permits it. A VLAN is disabled by using the 'no vlan 99' to remove it or 'shutdown vlan 99' to administratively bring it down. Thus, allowing a VLAN on a trunk never automatically disables it; the two operations are completely independent.

Because VLANs can cross trunks only when PAT is enabled

Why it fails: PAT (Port Address Translation) is a Network Address Translation technique that maps multiple private IP addresses to a single public IP address for outbound Internet traffic. Trunk operation is a Layer 2 function where 802.1Q tags in Ethernet frames identify different VLANs as they traverse a trunk link. PAT has no relationship to Layer 2 VLAN tagging or carriage across a trunk. VLANs cross trunks purely via 802.1Q or ISL encapsulation, not through PAT or any other Layer 3 translation mechanism.

Because VLAN 99 must always be the native VLAN

Why it fails: The native VLAN is a special VLAN on an 802.1Q trunk that carries its frames untagged, typically configured with 'switchport trunk native vlan <vlan-id>'. There is no requirement that VLAN 99 be the native VLAN; any VLAN can be configured as native, and any VLAN can be carried across a trunk as a tagged VLAN. If VLAN 99 is not the native VLAN, it simply sends and receives 802.1Q-tagged frames. Therefore, needing VLAN 99 to be the native VLAN is a misconception; its operability depends on it being defined and active, not on its native status.

The SSID broadcast setting, because the client must not be joined correctly.

Why it fails: The SSID broadcast setting only controls whether the network name appears in probe responses, not whether an already-associated client can send or receive traffic. Because the client successfully joined and pulled an address from the correct subnet, it is not a join failure. If broadcast were disabled, the client would still be able to connect if it manually knew the SSID, and would not explain an application-specific issue.

The voice VLAN on the wired access port connected to the AP uplink.

Why it fails: The voice VLAN on the wired access port is used to separate VoIP traffic from data traffic on the wired infrastructure, and it does not affect how a wireless client forwards traffic after joining a WLAN. A client that has already received an address from the correct subnet is clearly operating on the data VLAN, not the voice VLAN, and general employee access works correctly. Since the problem is restricted to one application, changing the voice VLAN setting on the AP uplink would have no bearing on this scenario.

The OSPF router ID on the client device.

Why it fails: OSPF router IDs are used by routers participating in OSPF to identify themselves in link-state advertisements; end-client devices such as laptops or phones do not run OSPF and never exchange routing protocol information with the network. A client's network stack obtains an address via DHCP and uses a default gateway for off-subnet traffic, so OSPF router ID is irrelevant. The application-specific failure cannot be caused by a parameter that does not exist on the client device.

The policy needs to match only one source subnet.

Why it fails: If the policy needs to match only a single source subnet, a standard access list using a wildcard mask like 0.0.255.255 fully satisfies that goal. Standard ACLs evaluate only the source address, so one permit or deny statement can identify the subnet without extra protocol or port granularity. This requirement does not require an extended ACL at all.

The ACL must be placed near the destination.

Why it fails: Placement near the destination is a recommended practice once an extended ACL is selected, because it limits extraneous traffic traversing the network. However, the physical or logical placement of an ACL does not determine whether a standard or extended ACL is required; a standard ACL can also be deployed, although it is typically positioned near the source. Therefore, this is a design guideline, not a selection premise.

The network uses IPv6 instead of IPv4.

Why it fails: Whether the network is IPv4 or IPv6 does not alter the fundamental limitation: a named IPv6 ACL is essentially equivalent to an extended ACL in capability, and the choice between standard-like and extended-like matching still depends on the need for granular match criteria. If the requirement is only to match a source subnet, either address family can use a simple source-only ACL. Thus, using IPv6 does not inherently force the extended ACL variant.

Replace SSH with Telnet to simplify troubleshooting

Why it fails: Replacing SSH with Telnet would downgrade the remote-management session to plaintext, exposing usernames, passwords, and executed commands to any observer on the network path. Telnet lacks encryption and integrity protection, making the administrative session vulnerable to eavesdropping and session hijacking, whereas SSH provides robust encryption and strong authentication. This swap would weaken, not simplify, management security.

Configure an extended ACL to limit remote access to specific source IP addresses

Why it fails: This answer is wrong because it is not an authentication control; it merely restricts source IP addresses. If authentication remains weak, an attacker can simply originate from an allowed source (e.g., by spoofing) or compromise that host, effectively bypassing the ACL. Substituting an ACL for proper authentication leaves the device with a weaker security posture, undermining secure remote administrative access.

Disable password authentication and rely solely on device location in the network

Why it fails: Disabling password authentication and relying only on network location is fundamentally unsafe because location is not an identity factor. An attacker can spoof a trusted IP address or compromise a device inside the trusted segment, gaining access without proving authorization. Additionally, this proposal has no connection to switch trunking, which concerns VLAN propagation over inter-switch links and does not strengthen remote-administration authentication in any way.

The command 'show ip nat statistics' displays the current active translations including inside and outside addresses.

Why it fails: The 'show ip nat statistics' command provides aggregate counters such as total translations, hits, misses, and pool usage, but it does not display the actual NAT translation entries. To see the individual inside local, inside global, outside local, and outside global address mappings, you must use 'show ip nat translations'. Therefore, this command is incorrect for viewing active translations.

To verify that static NAT is working, you should check the output of 'show ip interface brief' and look for the translated IP.

Why it fails: The 'show ip interface brief' command only displays interface status, protocol, and IP address information, not NAT translation details. It would not reveal any static NAT mappings or translated addresses. To verify a static NAT configuration, you need to use 'show ip nat translations' to see the actual mapping, or 'show ip nat statistics' to confirm that the translation counter is incrementing.

access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 access-list 100 deny ip any host 203.0.113.1 interface GigabitEthernet0/0 ip access-group 100 out

Why it fails: This is incorrect because applying the ACL outbound on G0/0 (facing SW1) would filter traffic leaving R1 toward R2. While it could work, it is less efficient because the traffic has already been routed through R1. Additionally, the implicit deny at the end of the ACL would block all other traffic to the loopback, but the outbound application is not the recommended direction.

access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 interface GigabitEthernet0/1 ip access-group 100 in

Why it fails: This is incorrect because it lacks the explicit deny statement for all other IP traffic to the loopback. Without the deny, the implicit deny at the end of the ACL will block all other traffic, but the explicit deny is necessary to clearly show the requirement is met. More importantly, the ACL does not deny traffic from other sources to the loopback; the implicit deny only applies to the ACL itself, but the question requires explicit denial.

access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 access-list 100 deny ip any any interface GigabitEthernet0/1 ip access-group 100 in

Why it fails: This is incorrect because the deny statement 'deny ip any any' blocks all IP traffic, including traffic to other destinations, not just the loopback. The requirement is to deny only traffic to the loopback, not all traffic. This would break connectivity for other traffic.

deny ip 10.10.10.0 0.0.0.255 host 172.16.1.10

Why it fails: Denying all IP traffic from the subnet to the web server blocks every protocol, not just HTTP, violating the requirement that other traffic be allowed. It is tempting because it stops HTTP, but it would be correct only if all access to that host were to be prohibited, not a single application.

deny udp 10.10.10.0 0.0.0.255 host 172.16.1.10 eq 80

Why it fails: HTTP uses TCP port 80, so denying UDP port 80 blocks no web traffic; the entry must specify tcp. It is tempting because port 80 is the HTTP port, but UDP 80 is not used by standard web browsing, and this option would be correct only for blocking a UDP-based service on that port.

permit tcp 10.10.10.0 0.0.0.255 host 172.16.1.10 eq 80

Why it fails: This entry permits exactly the HTTP traffic the requirement forbids, so it does the opposite. It is tempting because the source, destination and port match precisely, but the action must be deny. A correct ACL would deny tcp 10.10.10.0 0.0.0.255 host 172.16.1.10 eq 80 before permitting other traffic.

The PAT translation table is full, causing new TCP connection requests to be dropped.

Why it fails: PAT uses source port translation to map many internal addresses to a single public IP. ICMP (ping) does not consume a port mapping and can still be translated even when the table is exhausted. New TCP connections, required for web traffic, will fail when no free source port is available.

The 'overload' keyword was omitted, causing the router to use dynamic NAT with a single-address pool.

Why it fails: The configuration shown includes the 'overload' keyword. Even if it were missing, dynamic NAT without overload would not allow any internal host other than the first one to use the IP, but pings would also fail from other hosts. This does not match the symptom.

A static NAT entry for a web server is using the same public IP address as the PAT overload.

Why it fails: Configuring a static NAT entry with the same IP as the overloaded outside interface would typically cause a conflict or prevent the PAT translation from working correctly for all traffic, including ping. The router would likely generate an error or reject the command.

Generate a new RSA key pair and restart the SSH service.

Why it fails: Generating a new RSA key pair and restarting the SSH service is unrelated to the actual failure. The 'connection refused' occurs at the TCP/VTY layer because the VTY lines only permit Telnet ('transport input telnet'), so the router rejects the SSH handshake before any key-based authentication or encryption is negotiated. Even if the key pair is absent or stale, SSH would fail differently (e.g., 'no host key' or authentication errors), not with a transport-level refusal; regenerating keys does not modify the line's transport input policy.

Configure 'ip ssh version 1' to enable backward compatibility.

Why it fails: The router already runs SSH version 2, and version 1 is less secure and not required for compatibility. Changing the version does not override the VTY transport input restriction, so SSH connections will still be refused.

Configure AAA authentication on the VTY lines.

Why it fails: AAA authentication is not required for SSH to function; the router is already using local authentication (implied by the working Telnet). The refusal occurs before authentication, at the transport protocol layer, so adding AAA would not resolve the issue.

Configure 'ip nat outside' on GigabitEthernet0/0, 'ip nat inside' on GigabitEthernet0/1, keep ACL 10 as is, and add 'overload' to the PAT command.

Why it fails: This configuration marks the WAN side as inside and the LAN side as outside, so packets from the LAN are received on the 'outside' interface and are not matched by the 'ip nat inside source list' rule. Additionally, ACL 10 still permits the wrong subnet, so even if the interface roles were fixed, the NAT process would not select the intended internal addresses for translation. Adding 'overload' cannot compensate for the reversed inside/outside design and the faulty ACL.

Configure 'ip nat inside' on GigabitEthernet0/1, 'ip nat outside' on GigabitEthernet0/0, correct ACL 10 to permit 192.168.1.0 0.0.0.255, and add 'overload' to the PAT command.

Why it fails: With 'ip nat inside' assigned to GigabitEthernet0/1 (the WAN link) and 'ip nat outside' on the LAN interface, the router treats the public-facing connection as the internal side. Because the LAN is thus marked 'outside', traffic from 192.168.1.0/24 is never evaluated against the NAT ACL, even though ACL 10 now lists the correct subnet; the 'overload' keyword only enables port multiplexing on a correctly directed NAT rule. Consequently, internal hosts are not translated and the design fails.

Configure 'ip nat inside' on GigabitEthernet0/0, 'ip nat outside' on GigabitEthernet0/1, correct ACL 10 to permit 192.168.1.0 0.0.0.255, but do not add 'overload' to the PAT command.

Why it fails: Although the inside/outside markings and ACL 10 are correct, omitting 'overload' disables Port Address Translation. Without 'overload', the command attempts to translate inside local addresses to addresses from a configured global pool on a one-to-one basis; if the pool has only the single public IP on GigabitEthernet0/1, only one internal host can be translated at a time and the rest will fail. Adding 'overload' is mandatory for PAT-style many-to-one sharing of a single WAN address.

Enter the interface facing the source, apply the ACL inbound, then enter global configuration mode and create the ACL with deny and permit statements.

Why it fails: You cannot apply an access-list to an interface before it exists. The 'ip access-group' command on an interface references a named or numbered ACL that must already be defined in the running configuration; if it is not, the router returns an error and the command is rejected. Even if ACL creation were possible from interface configuration mode, which it is not, the interface would have no policy to reference, so entering global configuration mode to create the ACL first is mandatory.

Enter global configuration mode, create the ACL with permit ip any any first, then deny tcp 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 eq telnet, then enter the interface facing the source and apply the ACL inbound.

Why it fails: ACLs are evaluated sequentially from top to bottom, and the first matching entry determines what happens. Placing 'permit ip any any' as the first line matches every IP packet, including the Telnet traffic from 192.168.1.0/24 to 10.0.0.0/24, so the subsequent deny statement is never evaluated and the Telnet filter is completely bypassed. To block Telnet, the specific deny entry must appear before any broad permit, making the line order critical for the ACL to function correctly.

Enter global configuration mode, create the ACL with deny tcp 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 eq telnet, then enter the interface facing the source and apply the ACL inbound, without adding a permit statement.

Why it fails: Every IP access-list has an implicit 'deny ip any any' at the end, so any traffic not explicitly matched is dropped. Since the only explicit entry is the deny for Telnet, all other traffic from the 192.168.1.0/24 network to the 10.0.0.0/24 network would also be denied when this ACL is applied inbound on the source-facing interface. To meet the requirement of blocking only Telnet while permitting everything else, you must add an explicit 'permit ip any any' after the deny entry, making the intended allow behavior explicit and overriding the implicit deny.

ip access-list extended BRANCH_IN permit tcp 192.168.1.0 0.0.0.255 host 203.0.113.10 eq 80 permit icmp any any echo-reply ! interface GigabitEthernet0/0 ip access-group BRANCH_IN out

Why it fails: Applying the ACL outbound on GigabitEthernet0/0 is directionally incorrect: inbound evaluates packets arriving from the 192.168.1.0/24 LAN before routing, whereas outbound evaluates packets leaving that interface toward the LAN, which would not inspect the HTTP requests going toward 203.0.113.10. The ACL is therefore useless for the stated purpose, and the implicit deny would still block the permitted traffic. The task specifically requires inbound application on the internal-facing interface.

ip access-list extended BRANCH_IN permit tcp 192.168.1.0 0.0.0.255 host 203.0.113.10 eq 80 permit icmp any any ! interface GigabitEthernet0/0 ip access-group BRANCH_IN in

Why it fails: The ICMP statement `permit icmp any any` is overly broad because it matches every ICMP message type, including echo requests, destination unreachable, and parameter problem. The requirement is to allow only ICMP echo-reply (type 0) so that return pings from the server are accepted; any other ICMP type should fall through to the implicit deny. Without the `echo-reply` keyword, the ACL permits far more control traffic than intended.

ip access-list extended BRANCH_IN permit tcp 192.168.1.0 0.0.0.255 host 203.0.113.10 eq 80 permit icmp any any echo-reply ! interface GigabitEthernet0/0 ip access-group BRANCH_IN in ! interface GigabitEthernet0/1 ip access-group BRANCH_IN in

Why it fails: Binding the same ACL to both GigabitEthernet0/0 and GigabitEthernet0/1 inbound creates an asymmetric filter: on G0/1 it inspects packets entering from the external network, and because the only TCP permit is sourced from 192.168.1.0/24, legitimate return traffic from the web server (source 203.0.113.10) would be denied by the implicit deny. Applying an ACL on the external-facing interface also violates the explicit instruction to apply it only on the internal-facing interface, and it disrupts inbound connectivity that the requirements never intended to restrict.

Because Telnet uses UDP, not TCP.

Why it fails: Telnet is an application-layer protocol that relies on TCP port 23 to provide a reliable, connection-oriented byte stream for interactive terminal sessions. UDP is a connectionless protocol not used by Telnet, so any ACL that tries to filter Telnet as UDP would fail to match Telnet traffic entirely. Therefore, this statement is factually incorrect.

Because the ACL should be a standard ACL, not an extended ACL.

Why it fails: Standard ACLs (numbered 1-99 or 1300-1999) can match only the source IP address and cannot examine protocol types or destination ports. Because the intention is to block only Telnet traffic to a specific server, an extended ACL is required to specify TCP and the destination port. So the claim that it should be a standard ACL is wrong.

Because the host keyword can never be used with TCP statements.

Why it fails: The 'host' keyword in an extended ACL is used to specify a single IP address for a source or destination, and it can be combined with any IP protocol, including TCP, UDP, and ICMP. There is no restriction preventing 'host' from being used in TCP permit or deny statements. Thus, this statement is invalid as a reason for the ACL blocking extra traffic.

It is the same thing as a client SSID.

Why it fails: An SSID (Service Set Identifier) is the human-readable name of a wireless network that clients scan for and select to connect, typically broadcast in beacon frames. CAPWAP is a backend protocol that only operates on the wired network between an AP and a controller, invisible to wireless clients. Confusing them mixes the client-facing characteristic of a WLAN with the control-plane tunneling mechanism used behind the scenes, and they have no functional equivalence.

It is a replacement for WPA2 and WPA3.

Why it fails: CAPWAP is a tunneling protocol, not an encryption or authentication standard, so it cannot replace WPA2 or WPA3. WPA2 and WPA3 secure the wireless link by using AES-CCMP or AES-GCMP encryption and handshake-based authentication between the client and the AP. CAPWAP, in contrast, operates behind the AP layer, not between the client and AP, and it carries encrypted payloads rather than providing the encryption itself.

It is used only for IPv4 ACL filtering.

Why it fails: CAPWAP is a Layer 3 protocol that encapsulates AP-controller traffic using UDP/IP, which has no connection to IPv4 ACL filtering. Access control lists (ACLs) are a separate security mechanism that permits or denies packets based on source/destination addresses, ports, or protocols, and they are configured on routers, switches, or WLCs. CAPWAP does not filter traffic; it simply provides a tunnel for control and data messages, so calling it an ACL tool is incorrect.

ip access-list extended BLOCK_HTTP deny tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 80 permit ip any any interface GigabitEthernet0/1 ip access-group BLOCK_HTTP in

Why it fails: This is incorrect because the ACL is applied inbound on GigabitEthernet0/1, which is the interface facing the 192.168.2.0/24 network. The requirement is to filter traffic from 192.168.1.0/24 before it enters R1, so the ACL must be applied inbound on GigabitEthernet0/0.

ip access-list extended BLOCK_HTTP deny tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 80 permit ip any any interface GigabitEthernet0/0 ip access-group BLOCK_HTTP out

Why it fails: This is incorrect because the ACL is applied outbound on GigabitEthernet0/0. The requirement specifies inbound application. Applying outbound would filter traffic after routing, which is less efficient and does not match the requirement.

ip access-list extended BLOCK_HTTP deny tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 80 permit ip any any interface GigabitEthernet0/0 ip access-group BLOCK_HTTP in interface GigabitEthernet0/1 ip access-group BLOCK_HTTP in

Why it fails: This is incorrect because it applies the ACL inbound on both interfaces. The requirement only asks for application on GigabitEthernet0/0. Applying it on G0/1 is unnecessary and could cause unintended filtering of traffic from 192.168.2.0/24.

Enter interface configuration mode, apply ACL inbound, then create ACL with permit statement, add deny ip any any, exit to global config.

Why it fails: This sequence is invalid because the ACL must exist before you can apply it to an interface. In Cisco IOS, entering interface configuration mode and attempting to bind a non-existent ACL (e.g., with ip access-group) will produce an error or an empty group, so the permit and deny entries are never defined. The proper order is: create the ACL in global configuration mode, exit, then enter interface configuration mode and apply it inbound—never the reverse.

Enter global configuration mode, create ACL with deny ip any any first, then permit statement for HTTP, enter interface, apply ACL inbound.

Why it fails: This ordering is incorrect because ACLs are processed sequentially, top-to-bottom, and the first match takes action. Placing deny ip any any as the first entry causes all packets—including the HTTP traffic from 192.168.1.0/24 to 10.0.0.1—to be immediately dropped, and the subsequent permit statement will never be evaluated. To allow the desired HTTP traffic and block everything else, the permit statement must precede the deny all entry.

Enter global configuration mode, create ACL with permit statement for HTTP, add deny ip any any, apply ACL outbound on interface GigabitEthernet0/1.

Why it fails: This option fails primarily because the ACL is applied outbound on GigabitEthernet0/1, whereas the requirement specifies inbound filtering. On a LAN-facing interface, inbound evaluates packets arriving from the source network before routing; outbound would apply after routing, missing the intended placement and potentially not matching the traffic path. Additionally, the permit statement here is underspecified—it lacks the source and destination details (192.168.1.0/24 to 10.0.0.1)—so even with correct direction, it would not enforce the desired granularity.

A standard ACL is normally placed as close to the source as possible.

Why it fails: Standard ACLs are actually placed as close to the destination as possible, not the source, because they filter only on the source address. If applied near the source, a deny statement could block all traffic from a host to any destination, including networks that should be permitted. Extended ACLs, with their ability to match protocol and ports, are the ones normally applied near the source to filter traffic before it consumes bandwidth.

An extended ACL cannot filter ICMP traffic.

Why it fails: Extended ACLs can definitely filter ICMP traffic because they can match the IP protocol field for ICMP (protocol number 1) and optionally specify ICMP message types and codes. For instance, an extended ACL can permit ICMP echo-request while denying echo-reply, selectively dropping ping responses but not the requests. This contradicts the claim that extended ACLs cannot filter ICMP.

Both ACL types require named ACL syntax to match traffic.

Why it fails: Both numbered and named ACL syntax are valid for standard and extended ACLs in Cisco IOS; numbered ACLs use defined number ranges (standard 1-99 or 1300-1999, extended 100-199 or 2000-2699), while named ACLs use a descriptive word. The choice of syntax is based on administrative preference and the need for features like editing or removing individual entries, not on whether the ACL is standard or extended. Therefore, named ACL syntax is not required to match traffic with either type.