ACL practice questions

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

ip access-list standard INTERNET-FILTER permit 10.1.1.0 0.0.0.255 ! interface GigabitEthernet0/1 ip access-group INTERNET-FILTER in

Why wrong: This is incorrect because a standard ACL can only filter based on source IP, not destination or port. It would permit all traffic from the internal network, not just HTTP to the web server, and would not block other traffic.

ip access-list extended INTERNET-FILTER permit tcp host 10.1.1.100 10.1.1.0 0.0.0.255 eq 80 deny ip any any ! interface GigabitEthernet0/1 ip access-group INTERNET-FILTER in

Why wrong: This is incorrect because the permit statement has the source and destination reversed. It permits traffic from the web server to the internal network, not the other way around. Also, the deny any any would block all traffic, including necessary internal traffic.

ip access-list extended INTERNET-FILTER permit tcp 10.1.1.0 0.0.0.255 host 10.1.1.100 eq 80 deny ip any any ! interface GigabitEthernet0/0 ip access-group INTERNET-FILTER in

Why wrong: This is incorrect because the ACL is applied inbound on the external interface (GigabitEthernet0/0) instead of the internal interface. This would filter traffic coming from the internet into the router, not internal traffic going out.

ipconfig /all

Why wrong: ipconfig /all displays the client's IP addressing details, including IPv4 address, subnet mask, default gateway, DNS servers, and MAC address. It does not enumerate active TCP or UDP endpoints, so it cannot reveal whether a connection to the web server was established, is in SYN_SENT, or was reset. While it verifies Layer 3 configuration, it offers no visibility into transport-layer sessions or the server's listening state.

tracert 192.168.1.100

Why wrong: Tracert performs a route trace to the destination, which requires that the destination is reachable at Layer 3; since ping already failed, tracert will likely also fail and does not provide information about active connections.

ping -t 192.168.1.100

Why wrong: ping -t 192.168.1.100 sends continuous ICMP echo requests, but ICMP is a distinct protocol from TCP. Even if the web server's TCP port 80 were accepting connections, ping would not reflect that; conversely, a failed ping does not prove the web service is down. This command only tests Layer 3 reachability and packet loss, and since the initial ping already failed, repeating it infinitely adds no new information about active connections or listening ports.

The ACL is applied to the interface in the wrong direction (inbound instead of outbound).

Why wrong: If the ACL were applied in any direction, the output would show an access list number or name, even if it were the wrong direction. Both lines are 'not set', proving that no ACL is assigned.

The access-list 110 syntax has incorrect subnet masks causing no matches.

Why wrong: ACL syntax errors, including incorrect wildcard masks, would not prevent the ACL from being displayed as applied on the interface; 'show ip interface' would still list the ACL number or name even if its matching logic was flawed. The output shows 'Inbound access list is not set' and 'Outgoing access list is not set', which proves that no ACL is attached to GigabitEthernet0/0 at all. Furthermore, if the masks were wrong, the ACL would still be present in 'show ip access-lists', so the absence from the interface output definitively rules this out as the cause.

The interface GigabitEthernet0/0 is administratively down, preventing ACL processing.

Why wrong: The exhibit's first line clearly states 'GigabitEthernet0/0 is up, line protocol is up', meaning the interface is operational and capable of forwarding traffic. An administratively down interface would display 'administratively down, line protocol is down' and would not pass any packets, making ACL processing irrelevant. Since the interface is up, the lack of ACL hit counts must be explained by the ACL not being applied rather than by an interface state issue.