Understanding implicit deny with outbound ACLs You configured: access-list 110 deny tcp 10.1.1.128 0.0.0.63 any eq smtp access-list 110 deny tcp any eq 23 interface ethernet0 ip access-group 110 out What is the effective result on traffic leaving E0?

Introduction / Context:Cisco ACLs are processed top-down and terminate on the first match. If no lines match, an implicit deny any drops the packet. Many outages occur because engineers add only deny entries and forget a final permit line, unintentionally blocking all traffic. This question illustrates that behavior on an outbound ACL.

Given Data / Assumptions:

• ACL 110 has two explicit deny lines (SMTP from a /26 source block; Telnet from any source).
• The ACL is applied outbound on Ethernet0.
• No explicit permit statements follow.

Concept / Approach:

After evaluating all entries, if a packet does not match a permit statement, it hits the invisible final line deny ip any any. Since the list contains only deny entries and there is no subsequent permit, all traffic—whether SMTP/Telnet or anything else—will be dropped outbound.

Step-by-Step Solution:

Verification / Alternative check:

Use show access-lists 110 to watch counters. You will see denies increment, while all other traffic silently drops due to implicit deny (not counted on a specific line). Adding access-list 110 permit ip any any at the end would restore other traffic.

Why Other Options Are Wrong:

• Allowing email/Telnet or “everything but email and Telnet” assumes a final permit that does not exist.
• Inbound vs outbound confusion: the ACL is applied outbound.
• “Only Telnet blocked”: SMTP is also explicitly denied, and others are implicitly denied.

Common Pitfalls:

• Forgetting a final permit in restrictive ACLs.
• Misplacing direction (in vs out) and misinterpreting results.

Final Answer:

No IP traffic will be allowed out E0.