Courseiva
ACLInterface Config

ip access-group [acl] [in|out]

Applies an access control list (ACL) to an interface to filter inbound or outbound traffic based on the ACL rules.

Definition: ip access-group [acl] [in|out] is a Cisco IOS interface config command. Applies an access control list (ACL) to an interface to filter inbound or outbound traffic based on the ACL rules.

Overview

The `ip access-group` command is a fundamental tool for implementing traffic filtering on Cisco IOS devices. It applies an Access Control List (ACL) to a specific interface, controlling which packets are permitted or denied based on the ACL's rules. This command is critical for network security, traffic engineering, and policy enforcement at the network edge or between segments.

ACLs can be standard (filtering based on source IP) or extended (filtering based on source/destination IP, protocol, and port numbers). The `ip access-group` command is used in interface configuration mode and requires an ACL to be pre-defined. It is typically applied in the inbound or outbound direction: inbound ACLs filter traffic entering the interface, while outbound ACLs filter traffic leaving the interface.

This command is essential for creating security zones, restricting access to sensitive resources, and preventing unwanted traffic from traversing the network. Alternatives include using zone-based firewalls (ZBFW) for stateful filtering or VACLs (VLAN ACLs) for Layer 2 filtering, but `ip access-group` remains the simplest and most widely used method for basic packet filtering. In a typical workflow, an engineer first designs the ACL rules, then applies them to the relevant interface using this command.

Verification is done via `show ip access-lists` and `show ip interface`. Important IOS behaviors: the ACL must exist before applying; applying a non-existent ACL will be rejected. The command immediately affects traffic; there is no reload required.

Privilege level 15 (enable) is required to configure it. The running config is updated instantly. When troubleshooting, engineers often check the interface's ACL direction and counters to see if traffic is being matched.

The command does not affect the router's own generated traffic (e.g., routing updates) unless explicitly filtered with an outbound ACL on the outgoing interface. Understanding the order of ACL entries (implicit deny at end) is crucial. This command is supported across all IOS platforms, including routers and switches (Layer 3 interfaces).

For Layer 2 switches, ACLs can be applied to VLAN interfaces (SVIs) or physical ports using the same command. The `ip access-group` command is a cornerstone of Cisco network security and a must-know for CCNA and CCNP candidates.

Syntax·Interface Config
ip access-group [acl] [in|out]

When to Use This Command

  • Restrict inbound traffic on a WAN interface to only allow specific services like HTTP and HTTPS from the internet.
  • Block outbound traffic from a specific subnet to the internet on a LAN interface.
  • Apply a standard ACL to a router's serial interface to permit or deny traffic based on source IP address.
  • Use an extended ACL on a VLAN interface to filter traffic between different departments in a corporate network.

Parameters

ParameterSyntaxDescription
aclACL name or number (e.g., 101, MY_ACL)Specifies the access control list to apply. Can be a numbered ACL (1-99 standard, 100-199 extended, 1300-1999 standard, 2000-2699 extended) or a named ACL. The ACL must already be configured. Common mistake: applying an ACL that does not exist, which results in a configuration rejection.
in|outin or outDefines the direction of traffic filtering. 'in' filters packets entering the interface; 'out' filters packets leaving the interface. Only one direction per ACL per interface is allowed. Common mistake: applying the same ACL in both directions, which is not permitted; you must use separate ACLs if needed.

Command Examples

Apply standard ACL to inbound traffic on GigabitEthernet0/0

interface GigabitEthernet0/0 ip access-group 10 in
Router(config-if)# interface GigabitEthernet0/0
Router(config-if)# ip access-group 10 in
Router(config-if)#

The command enters interface configuration mode for GigabitEthernet0/0 and applies ACL 10 to inbound traffic. No output is shown if successful; the prompt returns to interface config mode.

Apply extended ACL to outbound traffic on Serial0/0/0

interface Serial0/0/0 ip access-group 110 out
Router(config-if)# interface Serial0/0/0
Router(config-if)# ip access-group 110 out
Router(config-if)#

This applies extended ACL 110 to outbound traffic on Serial0/0/0. The command completes without error if the ACL exists and is valid.

Understanding the Output

The ip access-group command does not produce any output on success; it simply configures the interface. To verify the applied ACL, use 'show ip interface [interface]' or 'show access-lists'. In 'show ip interface', look for 'Inbound access list is 10' or 'Outbound access list is 110' to confirm the ACL is applied.

If the ACL is missing or invalid, the router will reject the command with an error like 'Access list 10 does not exist'. Always ensure the ACL is created before applying it.

Configuration Scenarios

Restrict inbound traffic to a specific subnet

A company wants to allow only HTTP and HTTPS traffic from the 192.168.1.0/24 subnet to the server 10.0.0.10, and deny all other inbound traffic on the server's interface.

Topology

Client(192.168.1.0/24)---(Gi0/0)Router---(Gi0/1)Server(10.0.0.10)

Steps

  1. 1.Step 1: Enter global configuration mode: Router> enable, Router# configure terminal
  2. 2.Step 2: Create an extended ACL: Router(config)# ip access-list extended ALLOW_WEB
  3. 3.Step 3: Permit HTTP and HTTPS from the source subnet to the server: Router(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 80, Router(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443
  4. 4.Step 4: Exit ACL configuration: Router(config-ext-nacl)# exit
  5. 5.Step 5: Enter interface configuration for the server-facing interface: Router(config)# interface gigabitethernet0/1
  6. 6.Step 6: Apply the ACL inbound: Router(config-if)# ip access-group ALLOW_WEB in
  7. 7.Step 7: Exit and verify: Router(config-if)# end, Router# show ip access-lists ALLOW_WEB
Configuration
!
interface GigabitEthernet0/1
 ip access-group ALLOW_WEB in
!
ip access-list extended ALLOW_WEB
 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 80
 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443
!

Verify: Router# show ip access-lists ALLOW_WEB Extended IP access list ALLOW_WEB 10 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq www (5 matches) 20 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443 (3 matches) Router# show ip interface gigabitethernet0/1 | include access list Inbound access list is ALLOW_WEB

Watch out: Forgetting the implicit deny at the end of the ACL. All other traffic will be denied. Ensure you have permit statements for any required traffic (e.g., ICMP for ping).

Block outbound traffic to a specific external network

A branch office must prevent internal users from accessing a known malicious external network 203.0.113.0/24. The ACL is applied outbound on the WAN interface.

Topology

Internal LAN(10.0.0.0/24)---(Gi0/0)Router---(Gi0/1)WAN---Internet

Steps

  1. 1.Step 1: Enter global configuration mode: Router> enable, Router# configure terminal
  2. 2.Step 2: Create an extended ACL: Router(config)# ip access-list extended BLOCK_MALICIOUS
  3. 3.Step 3: Deny traffic to the malicious network: Router(config-ext-nacl)# deny ip any 203.0.113.0 0.0.0.255
  4. 4.Step 4: Permit all other traffic: Router(config-ext-nacl)# permit ip any any
  5. 5.Step 5: Exit ACL configuration: Router(config-ext-nacl)# exit
  6. 6.Step 6: Enter interface configuration for the WAN interface: Router(config)# interface gigabitethernet0/1
  7. 7.Step 7: Apply the ACL outbound: Router(config-if)# ip access-group BLOCK_MALICIOUS out
  8. 8.Step 8: Exit and verify: Router(config-if)# end, Router# show ip access-lists BLOCK_MALICIOUS
Configuration
!
interface GigabitEthernet0/1
 ip access-group BLOCK_MALICIOUS out
!
ip access-list extended BLOCK_MALICIOUS
 deny ip any 203.0.113.0 0.0.0.255
 permit ip any any
!

Verify: Router# show ip access-lists BLOCK_MALICIOUS Extended IP access list BLOCK_MALICIOUS 10 deny ip any 203.0.113.0 0.0.0.255 (12 matches) 20 permit ip any any (100 matches) Router# show ip interface gigabitethernet0/1 | include access list Outgoing access list is BLOCK_MALICIOUS

Watch out: Applying the ACL inbound instead of outbound would block traffic coming from the WAN, not going to it. Also, ensure the permit ip any any is included; otherwise, all outbound traffic would be denied.

Troubleshooting with This Command

When troubleshooting ACL issues with `ip access-group`, the first step is to verify that the ACL is applied correctly on the interface. Use `show ip interface [interface]` and look for 'Inbound access list' or 'Outgoing access list'. If the ACL is not listed, it may not have been applied or the configuration was lost.

Next, check the ACL itself with `show ip access-lists [acl-name]`. Healthy output shows the ACL entries with match counts. If match counts are zero for expected traffic, the ACL may be misordered or the traffic may not be hitting the interface.

Common symptoms: traffic is being dropped unexpectedly. Check the implicit deny: if no permit statement matches, traffic is denied. Use `debug ip packet [acl]` with caution to see if packets are being permitted or denied.

Focus on the 'access list' field in debug output. For inbound ACLs, ensure the ACL is applied on the correct interface (the one receiving the traffic). For outbound, ensure it's on the interface sending the traffic.

Another common issue: ACLs do not filter traffic generated by the router itself (e.g., pings from the router). To filter that, use an outbound ACL on the outgoing interface. Also, remember that ACLs are processed top-down; the first match wins.

If a deny entry appears before a permit, traffic matching the deny will be dropped. Use `show access-lists` to see the order. If you need to insert an entry, you may need to remove and re-add the ACL.

For complex troubleshooting, correlate with `show logging` to see ACL deny messages if logging is enabled on ACL entries. Also, check interface statistics with `show interfaces` for input/output drops. If drops are incrementing, the ACL may be dropping packets.

Use `clear access-list counters` to reset counters and then test. Another diagnostic flow: 1) Verify ACL application direction, 2) Check ACL entries and order, 3) Check match counts, 4) Use debug to see real-time packet handling, 5) Check interface errors. Remember that ACLs are stateless; they do not track connection state.

For stateful filtering, consider zone-based firewall. Finally, ensure the ACL is not too large, as it can impact CPU. Use `show ip access-lists` to see the number of entries.

If performance is an issue, consider using object groups or simplifying rules.

CCNA Exam Tips

1.

Remember that standard ACLs (1-99, 1300-1999) should be placed as close to the destination as possible, while extended ACLs (100-199, 2000-2699) should be placed close to the source.

2.

The 'in' or 'out' keyword is mandatory; omitting it causes a syntax error.

3.

Only one ACL per interface per direction is allowed; applying a new ACL overwrites the previous one.

4.

ACLs without a permit statement at the end implicitly deny all traffic; be careful with outbound ACLs that might block routing updates.

Common Mistakes

Applying an ACL that does not exist yet, causing the command to be rejected.

Forgetting to specify the direction (in/out), leading to a syntax error.

Applying a standard ACL to filter destination IPs incorrectly; standard ACLs only filter source IPs.

Placing an extended ACL too far from the source, wasting router resources by processing unnecessary traffic.

ip access-group [acl] [in|out] vs show access-lists

These two commands are often mentioned together because they both involve access control lists (ACLs) but operate at different layers: ip access-group activates an ACL on an interface, while show access-lists displays the ACL definitions and hit counts. New engineers may confuse applying an ACL with viewing it.

Aspectip access-group [acl] [in|out]show access-lists
ScopeInterface traffic filteringACL configuration display
Configuration modeInterface configurationPrivileged EXEC
PersistenceSaved in running-configNot saved, transient output
PrecedenceN/A (applies ACL)N/A (display only)
Typical useApplying ACL to filter traffic on an interfaceVerifying ACL entries and match statistics

Use ip access-group [acl] [in|out] when you need to apply a specific ACL to an interface to control traffic entering or leaving that interface.

Use show access-lists when you need to view the details of configured ACLs, including sequence numbers, permit/deny rules, and hit counters for troubleshooting.

Platform Notes

In IOS-XE, the `ip access-group` command syntax is identical to classic IOS. However, IOS-XE supports additional features like ACL object groups and more efficient processing. The output of `show ip access-lists` may include additional fields like 'hitcnt' and 'bytecnt' in newer versions.

In NX-OS, the equivalent command is `ip access-group` as well, but ACLs are configured differently: NX-OS uses `ip access-list` and requires a `permit` or `deny` followed by the protocol. NX-OS also supports session-based ACLs and object groups. For example: `interface ethernet 1/1; ip access-group MY_ACL in`.

The syntax is similar but NX-OS uses `ip access-list` instead of `ip access-list extended`. In ASA, the equivalent is `access-group` applied to an interface, but the ACL syntax is different (e.g., `access-list OUTSIDE extended permit tcp any any eq www`). ASA uses `access-group OUTSIDE in interface outside`.

In IOS-XR, the command is `ipv4 access-group` (note the 'v4') and ACLs are configured under a separate configuration mode. For example: `interface GigabitEthernet0/0/0/0; ipv4 access-group MY_ACL ingress`. IOS-XR also uses 'ingress' and 'egress' instead of 'in' and 'out'.

Behavior differences between IOS versions: In IOS 12.x, ACLs are processed in software; in 15.x and later, hardware acceleration is common on switches. The command itself has remained consistent. Always check the specific platform documentation for any nuances.

Related Commands

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions