Home β€Ί CCNA β€Ί Inbound and Outbound ACL Logic
A clipboard with green checkmarks and red Xs next to the text "ACL Logics" on a blue background.

Inbound and Outbound ACL Logic

Access Control Lists (ACLs) are a fundamental component of Cisco networking, used to filter traffic based on predefined rules. For CCNA and CCNP students, mastering ACLs is critical for securing networks and passing certification exams. ACLs allow network engineers to permit or deny packets based on criteria like source and destination IP addresses, protocols, and port numbers. This article explains the logic behind inbound and outbound ACLs, the differences between standard and extended ACLs, and provides practical examples and troubleshooting tips to help you succeed in your studies and real-world configurations.

Inbound ACL Logic

When a router receives a packet, it starts comparing the information in the packet header with the ACL. If the information in the packet header and an ACL entry match, the rest of the entries in ACLs are skipped, and the packet is permitted or denied as configured by the matching entry. If the information in the packet header does not match an ACE, the packet is tested with the next ACE in the list. The matching process continues until the end of the list is reached.

When the matching process ends, and no match is found, the implied statement is applied to the packet. This statement is not shown in the output. This implicit deny matches all packets that have no match found and results in a “deny” action, so Instead of proceeding in or out of an interface, the router discards and drops all of these remaining packets. This statement is referred to as the “implicit deny any” statement. So, due to this statement, an ACL should have at least one permit statement. Otherwise, the ACL blocks all traffic. The figure below illustrates the inbound ACL logic process.

Outund ACL Logic

Outbound ACL Logic

The outbound ACL logic is a little different than the inbound ACL logic. The figure below illustrates the outbound ACL logic. The router receives the traffic and sends it to the routing table. The routing table processes the packet; if the packet is not routable, the route drops the packet; if the packet is routable, then the router sends the packet for ACL matching. Next, the router checks whether the outbound interface is grouped to an ACL. If the outbound interface is not grouped to an ACL, the packet is sent directly to the outbound interface.

If the outbound interface is grouped to an outbound ACL, the packet is not sent directly to the outbound interface until it is matched with the ACEs in the ACL linked to that interface. Based on the ACL matching process, the packet is permitted or denied.

ACL Logic Operations

When a router receives a frame at the router interface, it checks the destination Layer 2 address to see if it matches its interface Layer 2 address or whether the frame is a broadcast frame. If the frame address is accepted, the frame information is stripped off, and the router checks for an ACL on the inbound interface. If an ACL exists on the inbound interface, the packet is tested against the entries in the list.

If the packet matches an entry, it is either permitted or denied. If the packet is permitted in ACEs, it is then checked against routing table entries to decide the destination interface. If a routing table entry exists for the destination address, the packet is switched to the outgoing interface; otherwise, it is dropped.

When the routing table forwards a packet to the outgoing interface, the router checks whether the outgoing interface has an ACL linked. If an ACL exists, the packet is tested against the entries in the list. If the packet matches an entry in the list, it is either permitted or denied. Suppose there is no ACL on the outbound interface or the packet is permitted. In that case, the packet is encapsulated in the new Layer 2 protocol and forwarded out the interface to the next device.

Standard ACL Decision Process

Standard ACLs examine only the packet’s source IP address; they do not check the packet’s destination or consider the ports involved. Cisco IOS tests the address against the conditions in the ACL one by one. The first match decides whether the packet is accepted or rejected. Because Cisco IOS stops testing conditions after the first match is found, the order of the conditions is serious. If no conditions match, the address is rejected.

Extended ACL Decision Process

The extended ACL decides using the source and destination addresses, protocol, and port numbers. The ACL first filters traffic on the source address, then on the port and protocol of the source. It then filters traffic on the destination address, then on the port and protocol of the destination, and finally makes a permit or denies decision. The ACEs are processed one after the other, So no-decision.

FAQs

What is the difference between inbound and outbound ACL logic?

Inbound ACLs filter packets upon arrival at an interface, matching headers and applying rules before routing. Outbound ACLs filter after routing, checking packets at the exit interface, with an implicit deny if no match is found.

Why is the order of conditions important in standard ACLs?

In standard ACLs, Cisco IOS stops at the first match, deciding to permit or deny based on the source IP. The order is crucial as it determines the first applicable rule, rejecting unmatched packets.

What happens if no ACL entry matches a packet?

If no ACL entry matches, the implicit deny any statement is applied, dropping the packet. At least one permit statement is needed, or all traffic will be blocked by this default rule.

How does an extended ACL make its permit or deny decision?

Extended ACLs filter using source/destination addresses, protocols, and port numbers, processing each criterion sequentially. The first match decides the action, ensuring detailed traffic control.

πŸ† Your Progress

Level 1
πŸ”₯ 0 day streak
πŸ“š
0 Articles
⭐
0 Points
πŸ”₯
0 Current
πŸ…
0 Best Streak
Level Progress 0 pts to next level
πŸŽ–οΈ Achievements
πŸ₯‰ Starter
πŸ₯ˆ Reader
πŸ₯‡ Scholar
πŸ’Ž Expert

More from CCNA

Articles tailored to your interests in CCNA

Forum