Access Control List (ACL) Scenarios

The VXLAN tunnel interface on the spine

Why it fails: Spine switches in an ACI fabric forward VXLAN-encapsulated traffic based on the fabric's forwarding tables but do not host EPG-level contract enforcement. Contract policy is enforced at the leaf where endpoints attach, so the spine tunnel interface is not the enforcement point described.

The bridge domain subnet SVI on the border leaf

Why it fails: A bridge domain SVI provides default gateway functionality for a subnet, not contract enforcement between EPGs. Contracts are applied at the leaf access policy layer using the EPG and contract relationship, so the SVI is not where the permitted TCP port 443 rule is enforced.

The APIC controller cluster policy compiler

Why it fails: The APIC cluster compiles and distributes policy to the leaves but does not sit in the data path, so it cannot enforce the TCP 443 permit rule on live traffic. Enforcement occurs on the leaf switch hardware, making APIC the policy source rather than the enforcement point.

The routers have a different IOS version that interprets 'outbound' as 'in'.

Why it fails: The direction parameter is validated by the Ansible module itself, not by the router's IOS. The `ios_acl_interfaces` module only accepts the exact string values `in` or `out` for `direction`, so passing `outbound` would either cause a validation error or be ignored/defaulted; it cannot be reinterpreted by the device. Different IOS versions do not change how the module handles the parameter because the module runs on the control node and translates the validated value into the correct CLI command. Thus, the router's IOS version is irrelevant to the symptom.

The engineer forgot to include the 'state: present' parameter, so the module did not apply the ACL.

Why it fails: In Ansible's `ios_acl_interfaces`, `state: present` is the default behavior, so omitting it would still apply the configured ACLs to the interface. If the module for some reason did not apply the ACL, the interface would have no `ip access-group` binding at all, resulting in no ACL filtering for either direction. The problem here is an ACL that is actually active but applying inbound, which indicates a successful application with the wrong direction parameter—not a failure to apply anything. Hence, this option does not explain the symptom.

The ACL itself is defined with the wrong direction in the playbook.

Why it fails: The ACL definition itself is direction-agnostic; it contains only match criteria (like source/destination addresses) and actions (permit/deny). The direction in which the ACL is evaluated is determined exclusively by the `direction` field in the interface's `access_groups` configuration, which is part of the module's interface-level parameters. If the ACL rules themselves were incorrect, the filtering action would be wrong irrespective of direction, but the symptom of applying inbound when outbound was intended points to the binding configuration, not the ACL content. Therefore, defining the ACL with a 'wrong direction' is not a valid explanation.

Routes advertised to 10.1.1.2 will have the MED set to 50, influencing outbound path selection from AS 65000.

Why it fails: MED is fundamentally an inbound path-selection metric: it is advertised to a neighbor so that the neighbor can decide which of multiple paths into your AS to prefer. The claim that this affects outbound path selection from AS 65000 is incorrect—outbound path selection is driven by Local Preference, AS-path length, and origin, not by MED set on routes you advertise. The route-map only influences how AS 65001 chooses to reach your networks, not how your own routers choose egress paths.

Routes received from 10.1.1.2 will have the MED set to 50.

Why it fails: The route-map is attached with the 'out' keyword in the neighbor statement, meaning it processes only routes being advertised toward 10.1.1.2, not routes received from that neighbor. Inbound update policy would require a separate route-map applied with 'in', and that would be configured on the receiving router to modify attributes before installing routes in the BGP table. Therefore, the MED of 50 is never applied to prefixes learned from 10.1.1.2.

The MED value will be set to 50 for all routes in the BGP table.

Why it fails: This neighbor-specific route-map is applied only to the session with 10.1.1.2, not globally to all BGP speakers or the entire BGP table. MED is a per-neighbor attribute and is inserted into the UPDATE messages sent to that peer; other neighbors receive their own advertised routes without this MED modification, and locally originated or learned routes in the BGP table retain their original MED values unless explicitly changed by other policies.

Telnet from 10.0.0.0/8 is denied.

Why it fails: Entry 10 permits Telnet from 10.0.0.0/8.

SSH from 172.16.0.0/16 is denied.

Why it fails: Entry 30 permits SSH from 172.16.0.0/16.

All traffic is permitted.

Why it fails: Telnet and SSH from unauthorized sources are denied.

Outgoing traffic from the router to 192.168.1.0/24 on port 80 is permitted; all other outgoing traffic is denied.

Why it fails: This is incorrect because the ACL is applied with the 'in' keyword, meaning it is evaluated only for packets that are entering the interface from the attached network, not for packets leaving the router. Additionally, the ACL's source field is 192.168.1.0/24 and its destination is 'any', so the permitted flow would be from that subnet to any host, not to that subnet. Thus the statement mischaracterizes both the direction of enforcement and the source/destination relationship.

Incoming traffic from any source to 192.168.1.0/24 on port 80 is permitted; all other incoming traffic is denied.

Why it fails: This is wrong because it inverts the source and destination addresses in the access-list entry. In the ACE 'permit tcp 192.168.1.0 0.0.0.255 any eq 80', the first address and wildcard define the source, while 'any' is the destination. So inbound traffic with a source address in 192.168.1.0/24 is matched, regardless of where it is going; traffic from other sources to the 192.168.1.0/24 network would require a different ACE with 'any' as the source and that network as the destination.

The access-list will permit all TCP traffic from 192.168.1.0/24, regardless of destination port.

Why it fails: This is incorrect because the access-list entry is not a general TCP permit; it includes the 'eq 80' qualifier, which restricts the match to packets whose destination TCP port equals 80 (HTTP). Without that qualifier, the ACE would match all TCP packets from that source network, but with it, non-HTTP TCP traffic (e.g., SSH on port 22, HTTPS on 443) does not match and is subject to the implicit deny. So only TCP port 80 traffic from 192.168.1.0/24 is permitted, not all TCP traffic.

The switch is not configured for 802.1X on the interface.

Why it fails: This is incorrect because Cisco TrustSec does not strictly require 802.1X authentication on an interface. When the interface is configured with 'cts manual' and a manually assigned SGT is applied to untagged traffic, the switch can classify packets without any 802.1X session. The absence of 802.1X only means there is no dynamic authentication or SGT propagation via RADIUS, but manual SGT assignment can still be fully operational. Therefore, a missing 802.1X configuration does not explain why role-based policies are not enforced.

The 'cts manual' command is incorrect; 'cts dot1x' should be used instead.

Why it fails: This is wrong because 'cts manual' is a completely valid command for trusted interfaces where SGTs are manually assigned to untagged or non-802.1X traffic. It is not a typo or an invalid alternative to 'cts dot1x'—the two modes serve different purposes: 'cts dot1x' is used when the switch relies on 802.1X and RADIUS to dynamically receive SGTs, while 'cts manual' is used for static SGT assignment on trusted links. The problem is not the command syntax but that the SGT mappings themselves are missing on the switch, so the classification cannot occur regardless of which mode is configured.

The 'show cts role-based counters' command shows no drops, indicating the ACLs are not configured.

Why it fails: This is incorrect because 'show cts role-based counters' only displays the number of packets that were actually dropped by role-based access control lists. If enforcement is not active—for example, because the SGTs are missing or the RBACL is not applied to the relevant source/destination pair—the counters will remain at zero, even if an ACL is configured somewhere. The command does not show whether ACLs are configured or attached; it only shows the outcome of enforcement. Therefore, zero drops simply indicate that no packets were rejected, which is consistent with the switch lacking SGT mappings and never evaluating a policy.

The switchport is configured as 'switchport mode trunk', which does not support dACLs.

Why it fails: dACLs are fully supported on trunk-mode switchports; the switch applies a downloadable ACL as a per-port, per-host policy after 802.1X authentication, regardless of whether the interface is an access or trunk port. A trunk configuration does not preclude dACL enforcement, especially when a single authenticated host is mapped to the interface. Therefore, the guest's lack of restriction cannot be attributed to trunk port mode.

The guest is not being authenticated; the switch is using MAB instead.

Why it fails: If MAB were in use, the switch would still query RADIUS and would apply any dACL attributes included in the Access-Accept message, so MAB does not inherently skip dACLs. Moreover, the scenario indicates the guest completed 802.1X authentication, so MAB is not the mechanism in play. The failure to filter traffic stems from the RADIUS server not returning the dACL attributes, not from the authentication method.

The switch is not configured with 'ip access-group' to apply the dACL.

Why it fails: Downloadable ACLs are installed dynamically by the switch when the RADIUS Access-Accept includes the dACL attributes; no explicit 'ip access-group' command is required or used to bind a dACL to an 802.1X-authenticated port. Manual access-group configurations apply static ACLs and are not part of the dACL workflow, so their absence cannot explain the missing filter. The switch would automatically enforce the dACL if the RADIUS server actually delivered it.

The access list used for NAT does not permit the web server's IP address.

Why it fails: An ACL referenced in a NAT configuration (e.g., ip nat inside source list) serves only to match inside local addresses for dynamic translation. Static NAT entries are created with an explicit ip nat inside source static command and are never filtered by an ACL. Therefore, even if the ACL denied the web server's address, it would have no bearing on a static mapping; the inability to reach the web server is due solely to the missing static entry.

The ip nat inside and ip nat outside commands are applied on the wrong interfaces.

Why it fails: If ip nat inside and ip nat outside were swapped on the interfaces, the router would fail to correctly translate traffic for all hosts, and outbound sessions would typically break as well. The scenario focuses on a single internal web server being unreachable from outside, which indicates a missing static mapping rather than a global interface configuration error. Correct interface placement is a prerequisite, but the specific symptom of only the web server failing points to the absence of the static NAT command, not to misapplied interface directives.

The global configuration mode is missing the ip nat pool command.

Why it fails: An ip nat pool defines a range of global addresses for use with dynamic NAT or PAT, typically paired with a source ACL in a command like ip nat inside source list <acl> pool <name>. Static NAT, which is what a web server requires for inbound access, does not involve a pool; it uses the ip nat inside source static command to map one specific inside local address to one inside global address. The absence of a pool is irrelevant because static NAT never references a pool, so this cannot explain why the web server is unreachable.

The port connected to the DHCP server should be untrusted for DAI to work correctly.

Why it fails: The DHCP server port must be configured as trusted, not untrusted, for DAI to operate correctly. DAI does not inspect ARP packets that arrive on trusted ports; an untrusted DHCP server port would cause DAI to drop the server's ARP messages, breaking DHCP and subsequent security verification.

The DHCP server is in a different VLAN, and DAI cannot validate cross-VLAN ARP.

Why it fails: DAI inspects ARP packets on a per-VLAN basis using the DHCP snooping binding table, which contains entries for multiple VLANs. The location of the DHCP server is irrelevant because its port is trusted and its ARP traffic is exempt from inspection; only the hosts' ARP messages are validated against their own VLAN's bindings.

DAI is checking the destination MAC address, which does not match the expected value.

Why it fails: DAI does not validate the destination MAC address in an Ethernet or ARP frame. Instead, it validates the sender hardware address and sender protocol address against the DHCP snooping binding table, then checks the frame's source MAC address. The destination is irrelevant to the binding check; DAI only cares who is speaking, not to whom the packet is directed.

It sets the local preference to 50 for routes received from the neighbor.

Why it fails: Local preference is a BGP attribute that influences egress traffic within the local AS and is configured with the set local-preference command, not set metric. Moreover, this route-map is applied in the outbound direction, so it modifies routes being advertised to 10.1.1.1, not routes received from that neighbor. Therefore, this option misidentifies both the attribute and the traffic direction.

It filters routes with a metric of 50 from being advertised to the neighbor.

Why it fails: A set metric clause assigns the metric value to routes that match the route-map's permit statement; it does not act as a filter. Filtering would require a deny statement or a match clause that evaluates the existing metric and then denies/filters the route. Since the route-map permits all routes and applies the set metric command, all routes are advertised with their metric changed to 50, not filtered out based on a metric of 50.

It sets the weight to 50 for routes learned from the neighbor.

Why it fails: Weight is a Cisco-proprietary BGP attribute configured with the set weight command, not set metric, and it is a locally significant value used for outbound interface selection on the router itself. Additionally, weight is applied to routes received from a neighbor (inbound direction) or generated locally—not to routes advertised outbound to a peer. Because this route-map is outbound to 10.1.1.1, it cannot set weight on routes learned from that neighbor.

All ICMPv6 traffic is permitted inbound on Gi0/0.

Why it fails: ICMPv6 encompasses many message types beyond echo-request and echo-reply, such as neighbor solicitation (type 135), neighbor advertisement (type 136), router solicitation (type 133), and router advertisement (type 134). The ACL in question explicitly permits only types 128 and 129, so claiming all ICMPv6 is allowed is false. Unspecified ICMPv6 types would not match the permit statements and would be caught by the final deny, resulting in dropping.

The ACL is applied outbound, so it filters traffic leaving Gi0/0.

Why it fails: The 'in' keyword in the ACL ipv6 access-group command indicates the filter is applied to traffic entering the interface, not leaving it. If the ACL were applied outbound, it would inspect packets exiting Gi0/0, but the question's configuration specifies inbound processing. Misreading the direction would lead to incorrect placement, as applying it outbound would not achieve the desired filtering of incoming ping traffic.

The ACL permits all IPv6 traffic because the deny statement is at the end.

Why it fails: ACL packet matching is sequential; a packet is evaluated against each line until a match occurs. Permitting all IPv6 traffic would require a permit ipv6 any any statement, but the ACL instead ends with an explicit deny ipv6 any any. The deny statement at the end does not 'permit' anything; it is the default drop for unmatched packets, ensuring that only the explicitly permitted echo-request and echo-reply traffic is forwarded.

The local preference of routes received from 10.1.1.1 is set to 150.

Why it fails: Local preference is a BGP attribute that is set globally on the router or via a route-map on incoming routes, not on routes being advertised to a neighbor. This route-map, which is applied in the outbound direction, modifies attributes like MED, not local preference. Additionally, a value of 150 for local preference is a common configuration but would require a specific 'set local-preference' command, which is not part of this route-map. Hence, the statement is incorrect.

The route-map filters routes; only those with metric 50 are advertised.

Why it fails: A route-map that sets the MED attribute does not perform filtering because it has no 'match' criteria and does not use 'permit' or 'deny' logic to selectively drop routes. Instead, it acts as a policy that modifies attributes of all routes that are permitted through the map. The phrase 'only those with metric 50 are advertised' confuses the set operation with a conditional filter; MED is being assigned, not compared against an existing value for filtering purposes.

The password is applied to the BGP session, but the route-map is ignored due to the password.

Why it fails: Configuring a BGP session password (MD5 authentication) and applying a route-map to a neighbor are independent configuration tasks that operate at different layers. The password authenticates the TCP transport connection, while the route-map controls BGP attribute modification during the update exchange. There is no functional interaction that would cause the route-map to be ignored; both features can coexist on the same neighbor without affecting each other's operation.

Only SSH traffic to 10.1.1.1 is permitted.

Why it fails: This is incomplete because the ACL contains two explicit permit statements: one for TCP port 22 to host 10.1.1.1 and one for ICMP echo-reply. The ICMP echo-reply entry is a separate, valid ACE that matches only the specific ICMP type used in responses to ping. Therefore the claim that only SSH traffic is permitted overlooks the second ACE, making the 'only' statement incorrect.

All ICMP traffic is permitted.

Why it fails: The second ACE in the ACL is narrowly scoped to ICMP echo-reply, which is ICMP type 0. Other ICMP message types such as echo-request (type 8), destination unreachable (type 3), or time exceeded (type 11) are not matched by this entry and, because the ACL ends with an implicit deny, they would be dropped. Therefore 'all ICMP' is far too broad and is not what the configuration actually permits.

Only traffic from host 10.1.1.1 is permitted.

Why it fails: The permit statements define destinations, not sources: the TCP ACE's 'host 10.1.1.1' appears in the destination field, meaning SSH traffic is allowed when it is destined to 10.1.1.1, not when it originates from that host. Similarly, the ICMP echo-reply ACE matches a reply sent from a remote address to this router, not a packet sourced from 10.1.1.1. This misreading reverses the directionality of the ACL, so the statement is incorrect.