Access Control List (ACL) Scenarios

It permits all IPv6 traffic

Why it fails: Sequence 10 drops traffic sourced from 2001:DB8:2::/48 before the sequence 20 permit is evaluated, so that prefix is blocked. Permitting everything would need the deny entry absent or placed after the permit, which the ordering here prevents.

It permits only IPv6 traffic from 2001:DB8:2::/48

Why it fails: The sequence 20 permit matches any source, so all other IPv6 traffic is allowed alongside the denied prefix; only 2001:DB8:2::/48 is blocked. Permitting solely that prefix inverts the logic, since sequence 10 explicitly denies it rather than allowing it.

It denies all IPv6 traffic

Why it fails: The list denies only traffic sourced from 2001:DB8:2::/48, then permits everything else via the sequence 20 entry, so traffic from other prefixes still passes. Denying all traffic would require an implicit deny with no matching permit, which this ACL does not have.

Configure the `ip local policy route-map PBR` command to apply the route map globally.

Why it fails: The `ip local policy route-map` command applies policy-based routing to locally generated traffic from the router itself, not to transit traffic from the LAN. This would not affect traffic from the 10.1.1.0/24 subnet. The issue is that the route map is not matching the traffic correctly.

Apply the route map to the GigabitEthernet0/1 interface instead of GigabitEthernet0/0.

Why it fails: Applying the route map to GigabitEthernet0/1 would affect traffic entering from the WAN, not the LAN traffic from 10.1.1.0/24. Policy-based routing must be applied to the interface where the traffic enters the router. Since the LAN traffic enters on GigabitEthernet0/0, the policy is correctly applied there.

Add the `set ip next-hop verify-availability` command to the route map.

Why it fails: The `set ip next-hop verify-availability` command is used to verify the reachability of the next-hop before using it. It does not affect whether the route map is applied or whether the policy is evaluated. The issue here is that the policy is not being applied to the correct traffic direction, not next-hop reachability.

The access-list does not include the correct SNMP port numbers.

Why it fails: The access list already permits udp eq snmp (161) and snmptrap (162), the correct ports, so it is not the cause. It is tempting because wrong port numbers are a frequent ACL error, but the listed entries are accurate, leaving the direction of the access-group match as the real issue.

The police rate is too low and is dropping all packets before counting.

Why it fails: Police counters increment on offered packets regardless of the action taken, so a low CIR would still show conformed or exceeded counts, not zero. It is tempting because a tight rate can drop traffic, but drops are counted; zero packets means nothing is matching the class.

The class-map is using 'match-all' instead of 'match-any'.

Why it fails: With a single match statement, match-all and match-any behave identically, so the operator cannot explain zero matches. It is tempting because match-all is a common misconfiguration in multi-statement class-maps, but here the access list itself is the problem, not the match logic.

The ACL blocks all ICMPv6 traffic because the deny statements are too broad.

Why it fails: The ACL denies only echo-request and echo-reply, then permits all remaining IPv6 traffic, so other ICMPv6 types such as neighbour solicitation still pass. It is tempting because deny entries precede the permit, and the statement would be true if no permit ipv6 any any line existed.

The ACL must be applied outbound to filter echo-request.

Why it fails: Inbound filtering on Gi0/2 already matches echo-request arriving at that interface, so denying it there works; applying the ACL outbound would only catch traffic leaving, missing the incoming echo-request. Outbound ACLs suit filtering traffic the router itself originates or forwards toward a specific destination.

The ACL is missing the 'log' keyword to be effective.

Why it fails: The 'log' keyword only generates syslog messages for matched entries; it does not alter whether the deny statements take effect. The ACL already drops echo-request and echo-reply because deny entries are processed before the permit ipv6 any any. Logging would be chosen when audit trails of dropped ICMP packets are required.

No ACLs are applied to SNMP, so all access is allowed.

Why it fails: ACLs 10 and 20 are explicitly bound to the 'public' and 'private' communities, so SNMP access is filtered by those lists rather than unrestricted. The output would indicate open access only if no access-list entries appeared. The command confirms ACLs are applied per community.

The router uses SNMPv3 exclusively.

Why it fails: The output lists community strings 'public' and 'private' mapped to ACLs 10 and 20, which is SNMPv1/v2c configuration; SNMPv3 uses users, groups and views instead of community strings. SNMPv3 would be the answer if the output showed 'show snmp user' or group entries, not community-to-ACL mappings.

The 'public' community has read-write access.

Why it fails: The view column shows 'v1default' for both communities, which is the default read-only view; read-write would require a view permitting write operations or an rw community designation. The output would indicate read-write if the view or access entry granted write access, which it does not.

The route-map will override the route-target export and set the RT to 100:100.

Why it fails: Route-targets are extended community attributes used for VPN import and export decisions, while the standard community 100:100 set here is a separate attribute type. The route-map cannot overwrite a route-target with a standard community value; it only tags prefixes with 100:100.

The route-map will cause the BGP session to reset because the community format is incorrect.

Why it fails: Standard community values are 32-bit (AS:number), so 100:100 is valid and no reset occurs; the route-map simply tags incoming CE routes. It is tempting because malformed community attributes can trigger a session reset, but that applies to extended community mismatches, not this well-formed value.

The route-map will have no effect because the community is not sent to the CE.

Why it fails: The route-map runs inbound on routes received from the CE, so it matches and sets the community on those prefixes regardless of what the CE sent; the CE's own advertisements are irrelevant to the PE's inbound policy. Communities are attached to routes the CE sends, so the set operation applies.

The packet is permitted.

Why it fails: An IPv4 ACL carries an implicit deny any at its end, so unmatched packets are dropped, not permitted. The option is tempting because an ACL with no statements at all permits everything, and a permit ip any any entry is often added deliberately to override that implicit deny.

The packet is logged and then permitted.

Why it fails: Logging occurs only through an explicit log keyword on a matching ACE, and unmatched packets are dropped by the implicit deny any rather than logged and permitted. The option tempts because ACL logging is a real feature, but it accompanies explicit statements, not the default behaviour.

The ACL is ignored and the packet is forwarded.

Why it fails: An ACL is never bypassed; unmatched traffic hits the implicit deny any and is discarded, so the packet is not forwarded. The option tempts because an empty ACL or an unapplied ACL does pass traffic, which is why administrators must apply ACLs to the correct interface and direction.

The tunnel is working correctly; all packets are being encrypted and decrypted.

Why it fails: Encapsulation succeeds, but decaps, decrypt and verify all remain zero, so return traffic is not being received or processed. Claiming the tunnel works ignores this asymmetry. This option would be correct only if both encaps and decaps counters incremented, indicating bidirectional encrypted traffic.

The local crypto ACL is misconfigured; it is not matching traffic.

Why it fails: The local ident 10.1.1.0/24 matches the local address and 100 packets were encapsulated, proving the ACL matched and encryption occurred. The zero decaps counters indicate no return traffic arrived. A misconfigured ACL would show no encaps increments, which is not the case here.

The IPsec SA is not established; the tunnel is down.

Why it fails: The SA is established: encaps, encrypt and digest counters all increment, and PERMIT flags appear. The absence of decaps, decrypt and verify counters shows inbound traffic never arrived. A down SA would display no security associations or zero encaps counters, which this output contradicts.

The distribute-list is applied incorrectly and blocks all routes.

Why it fails: The stem states the distribute-list permits all routes, so it cannot be the cause of the missing routes. It is tempting because distribute-lists commonly filter OSPF routes, and an incorrectly applied one would be the right answer when neighbours form but prefixes are absent without a stated permit-all entry.

OSPF uses TCP, and CoPP only polices UDP.

Why it fails: OSPF runs directly over IP protocol 89, not TCP or UDP, so the premise is false and cannot explain the loss. It is tempting because CoPP class-maps often match UDP or TCP ports, and protocol mismatch would be the answer if OSPF genuinely used a transport protocol that the policy dropped.

The CoPP policy is applied to the wrong control plane subinterface.

Why it fails: CoPP polices traffic punted to the route processor; it is not applied to a control plane subinterface, so this mechanism does not exist as described. It is tempting because CoPP and control plane policing terminology overlap, and subinterface-level policy would be relevant when shaping per-interface transit traffic rather than protecting the RP.

The 'rate-limit' is configured in bps instead of pps, causing excessive policing.

Why it fails: While unit mismatch can cause issues, it would not cause complete unreachability unless the rate is set to 0. The question states the policy is applied, but the router becomes unreachable, suggesting dropping rather than policing.

The 'service-policy' is applied to the control-plane input direction, but SSH and SNMP are output traffic.

Why it fails: CoPP only polices traffic destined to the control plane, which is ingress from the router's perspective; SSH and SNMP arriving for the router are input, not output, so the direction is misapplied. Output policing governs traffic the router itself originates, which is why the class-map appears correct yet traffic is dropped.

The class-map for SSH and SNMP uses a 'match-all' condition, but the access-list has multiple entries that are ORed.

Why it fails: A match-all class-map with ORed ACL entries still matches any single permitted line, so SSH and SNMP would be permitted rather than dropped. Match-any versus match-all governs how multiple match statements combine, not how entries within one ACL are evaluated.

ICMP traffic from 10.1.1.1 to 10.2.2.2 is being permitted by ACL 130.

Why it fails: Line 10 denies the flow, and the debug line confirms that deny entry matched, so the packet is dropped rather than permitted. It is tempting because the trailing permit ip any any would allow the traffic if the deny entry were absent or ordered after it.

ACL 130 is applied outbound on GigabitEthernet0/0.

Why it fails: The debug output names GigabitEthernet0/0 as the ingress interface for the source packet, giving no evidence of outbound application. It is tempting because direction determines where an ACL filters traffic, and outbound placement would be correct when filtering packets leaving an interface toward a destination.

ACL 130 is not matching any packets.

Why it fails: The log explicitly records a match on line 10, so the ACL is evaluating and matching traffic. It is tempting because an empty match counter on the ACL entry can indicate a misapplied or unreferenced list, which would be the correct diagnosis when no debug output appears.

Routes with tag 100 are denied; all other routes are permitted.

Why it fails: Tag 100 routes are not denied: permit 10 matches them and rewrites the tag to 200, so they pass. Denial would require a route-map sequence with a deny statement, which is absent here. This option tempts candidates who conflate matching with filtering, a mistake relevant when route-maps genuinely deny traffic by omitting a permit sequence.

Only routes with tag 100 are permitted; all other routes are denied.

Why it fails: The route-map contains a permit sequence 20 with no match clause, which matches every remaining route and forwards it unchanged, so nothing is denied. Tag 100 routes are re-tagged to 200, and all others pass through sequence 20. Denial would require an implicit deny with no catch-all permit, as in filtering route-maps applied to BGP neighbours.

The route-map is misconfigured because sequence 20 has no match statement; it should have a match any statement.

Why it fails: Sequence 20 requires no match statement: a route-map entry with no match clause matches all routes, so it acts as a permit-any catch-all. The claim of misconfiguration is therefore false. It is tempting because explicit match statements are common, and omitting one looks like an oversight rather than deliberate design.

The ACL is applied only on the VLAN 10 subinterface, so return traffic from VLAN 20 is not filtered but the ACL on VLAN 10 drops it because the source address matches a deny entry.

Why it fails: This is incorrect because return traffic sourced from VLAN 20 enters the router through the VLAN 20 subinterface, so an inbound IPv6 ACL on VLAN 10 never sees it. Even if the ACL's deny entry matched the source address, the router would not evaluate it for packets arriving on VLAN 20; only an outbound filter on VLAN 10 could affect that flow, and the issue is a missing permit, not a deny match on the wrong interface.

The router has 'ipv6 unicast-routing' disabled, preventing inter-VLAN routing.

Why it fails: This is wrong because disabling 'ipv6 unicast-routing' globally stops the router from forwarding any IPv6 packet between subinterfaces, breaking all inter-VLAN communication, not just return traffic. The observed behavior—forward traffic succeeding and only return traffic failing—is a classic sign of a one-way ACL, not a missing routing enablement. Additionally, the router would not even build the IPv6 FIB for the subnets if unicast routing were off.

The ACL uses 'deny ipv6 any any' which blocks all traffic, but the permit statement for VLAN 10 to VLAN 20 is placed after the deny, causing it to be ignored.

Why it fails: This is wrong because IPv6 ACLs are processed sequentially with first-match semantics; a permit statement placed before the deny entry is evaluated first, so it is not ignored. If the ACL really ended with 'deny ipv6 any any' after a permit for VLAN 10 to VLAN 20, the forward traffic would be allowed and only unmatched return traffic would hit the deny. The actual problem is the absence of a permit for the return flow, not ordering—if ordering were as described, all traffic from VLAN 10 would be blocked too.

ACL 101 filters traffic entering the interface.

Why it fails: The line "Outgoing access list is 101" places ACL 101 on outbound traffic; the inbound field reads "not set", so nothing filters entering packets. It tempts because ACLs are commonly applied inbound, but this interface uses the outbound direction. Direction is determined by which field names the list.

The interface has no ACL applied.

Why it fails: The output lists "Outgoing access list is 101", so an ACL is applied, in the outbound direction; only the inbound field is unset. Claiming no ACL ignores the populated outgoing field. It tempts because "Inbound access list is not set" suggests no filtering, but that line covers one direction only.

ACL 101 is applied in both directions.

Why it fails: Only the outgoing field references ACL 101; the inbound field states "not set", so the list filters one direction, not both. Applying an ACL in both directions requires separate inbound and outbound entries. It tempts because the same number could be reused per direction, but the output shows only outbound configured.